본문 바로가기

전공/그 외

[소프트웨어공학] 전공 필기 시험 정리

✔️ 모듈

1. 모듈과 모듈화

모듈화란 소프트웨어를 각 기능별로 나누는 것을 의미한다.그리고 그 결과로 각 기능별로 분할된 것을 모듈이라고 한다.

 

2.  독립성

좋은 모듈화는 용도에 맞게 잘 구분된 기능을 가진 독립적인 모듈로 나누는 것이다.

모듈의 독립성을 판단하는 것은 결합도와 응집도가 있다.

 

3. 결합도(Coupling)

  • 결합도는 외부의 모듈과의 연관도 또는 모듈 간의 상호의존성을 나타내는 정도
  • 결합도는 소프트웨어 구조에서 모듈 간의 관련성을 측정하는 척도

1) 결합도의 특징

  • 모듈 연관성 없음
  • 인터페이스 의존성
  • 복잡성 감소
  • 파급효과 최소화

2) 결합도의 유형

결합도의 유형은 내용>공통>외부>제어>스탬프>자료 결합도 순으로 결합도가 낮아진다.

 

내용 결합도(Content Coupling)
  - 내용 결합도는 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도이다.
  - 한 모듈에서 다른 모듈의 중간으로 분기되는 경우에도 내용 결합도에 해당된다.


 공통(공유) 결합도(Common Coupling)
  - 공통 결합도는 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도이다.
  - 공통 데이터 영역의 내용을 조금만 변경하더라도 이를 사용하는 모든 모듈에 영향을 미치므로 모듈의 독립성을
    약하게 만든다.


 외부 결합도(External Coupling)
  - 외부 결합도는 어떤 모듈에서 외부로 선언한 데이터(변수)를 다른 모듈에서 참조할 때의 결합도이다.
  - 참조되는 데이터의 범위를 각 모듈에서 제한할 수 있다.

 

  제어 결합도(Control Coupling)
  - 제어 결합도는 한 모듈에서 다른 모듈로 논리적인 흐름을 제어하는 데 사용하는 제어 요소(Function Code,
    Switch, Tag, Flag)가 전달될 때의 결합도이다.
  - 상위 모듈이 하위 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어
    설계된 경우에 발생한다.

 

 스템프(검인) 결합도(Stamp Coupling)
  - 스탬프 결합도는 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도이다.
  - 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도이며 자료 구조의 어떠한 변화, 즉 포맷이나 구조의 변화는
    그것을 조회하는 모든 모듈 및 변화되는 필드를 실제로 조회하지 않는 모듈에까지도 영향을 미치게 된다.

 

 자료 결합도(Data Coupling) 

  - 자료 결합도는 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도이다.
  - 어떤 모듈이 다른 모듈을 호출하면서 매개 변수나 인수로 데이터를 넘겨주고, 호출받은 모듈은 받은 데이터에
    대한 처리 결과를 다시 돌려주는 것이다.
  - 자료 결합도는 모듈 간의 내용을 전혀 알 필요가 없는 상태로서 한 모듈의 내용을 변경하더라도 다른 모듈에는
    전혀 영향을 미치지 않는 가장 바람직한 결합도이다.

 

4. 응집도(Cohesion)

  • 모듈의 독립성을 나타내는 개념으로, 모듈 내부 구성요소 간 연관 정도
  • 응집도는 정보 은닉 개념의 확장개념으로, 하나의 모듈은 하나의 기능을 수행하는 것을 의미

 1) 응집도의 특징

  • 유사기능 영역 구성
  • 단일 책임할당
  • 함수 간 상호협력

2) 응집도의 유형

응집도의 유형은 우연적<논리적<시간적<절차적<통신적<순차적<기능적 응집도 순서로 응집도가 높아진다.


 우연적 응집도(Coincidental Cohesion)
  - 모듈 내부의 각 구성 요소들이 서로 관련없는 요소로만 구성된 경우의 응집도

 

논리적 응집도(Logical Cohesion)
  - 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도

 

 시간적 응집도(Temporal Cohesion)
  - 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도

 

 절차적 응집도(Procedural Cohesion)
  - 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도


 교환(통신)적 응집도(Communication Cohesion)
  - 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도


 순차적 응집도(Sequential Cohesion)
  -  모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도

 

 기능적 응집도(Functional Cohesion)
  - 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도

 

결합도가 높은 클래스의 문제점

  • 연관된 다른 클래스가 변경되면 더불어 변경이 필요
  • 다른 프로그램에서 클래스 재사용 어려움
  • 수정하려는 클래스를 이해하기 위해 연관된 클래스를 함께 이해해야 함

 응집도가 낮은 클래스의 문제점

  • 코드를 이해하기 어려움
  • 유지보수가 어려움
  • 다른 클래스의 변화에 민감

 


 

✔️ 객체 지향

1. 객체 지향이란?

- 실 세계의 개체(Entity)를 "속성"과 "메서드"가 결합된 형태의 객체로 보고 구현대상을 객체와 객체들 간 관계로 모델링하는 방법

- 객체는 클래스의 인스턴스이며, 추상화, 상속, 다형성, 캡슐화, 정보은닉의 특징을 가짐

 

2. POP와 OOP

1) 절차지향 (POP)

  - 실행되는 순서가 위 -> 아래로 순차적으로 진행되는 형태를 가진 언어

  - 프로그램 재사용 시 기존에 만들어진 코드를 복사하여 붙여넣기 하는 방법 사용

 

2) 객체지향 (OOP)

  - 모듈성을 높이기 위해 함수가 등장

  - 객체 등장 (함수보다 더 높은 모듈 관리를 위해 자신이 가진 고유의 데이터와 그 데이터를 처리할 수 있는 메서드를 가짐) 

  - 객체지향을 통해 보다 높은 유지보수성 유지가 가능

 

3. 객체, 클래스, 인스턴스

1) 객체 (Object)

  - 현실 세계에 존재하는 유,무형의 모든 것

  - 객체는 정적인 요소(변수)와 동적인 요소(메서드)를 가짐

 

2) 클래스 (Class)

  - 현실 세계의 객체를 컴퓨터 메모리에 생성할 수 있는 템플릿       

 

3) 인스턴스(Instance)

  - 컴퓨터 메모리에 존재하는 객체

  - 다양한 Car 인스턴스를 메모리에 생성 가능

 

4. 상속 (Inheritance)

  - 이미 존재하는 클래스를 바탕으로 필요한 변수와 메서드를 추가로 정의해준 것

  - 코드의 재사용성을 높이는 객체지향의 핵심 개념

  - 상위 클래스일 수록 일반화, 보편화 특징을 가지고, 하위 객체일 수록 특수화, 개별화 특징

  - 상속 시 extends 라는 상속 관계 예약어를 사용

  - 단, 부모 클래스와 자식 클래스의 관계가 일반화, 특별화 관계('is a ~')에 있어야 함

 

> 상속의 종류

  - 단일 상속 : 하나의 하위 클래스가 하나의 상위 클래스를 갖도록 하는 구조

  - 다중 상속 : 하나의 클래스가 두 개 이상의 상위 클래스를 갖도록 계층구조를 생성

  * 자바는 단일 상속만 지원

 

5. 다형성 (Polymorphism)

  - 하나의 인터페이스를 이용하여 서로 다른 구현을 제공

  - one interface, multiple implementation 으로 표현

    ex) 동일한 인터페이스가 제공된 하나의 리모컨으로 모든 TV를 작동할 수 있을 것임

  - 오버로딩(Overloading)

       : 한 클래스 안에 같은 이름의 메서드를 여러 개 정의하면서, 그 인자의 개수나 유형을 다르게 해 놓은 형태

   - 오버라이딩(Overriding)

       : 상속 관계에 있는 하위 클래스가 상위 클래스가 가지고 있는 메서드를 재정의하는 것. 재정의된 메서드가 선언된 형태는 상위 클래스에서 선언된 것과 같음

 

6. 추상화 (Abstraction)

  - 구체적인 사실들을 일반화시켜 기술하는 것

  - 현실 세계에 존재하는 다양한 객체들의 공통된 특성을 모아 일반화해 놓은 것 -> 클래스 정의에 중요한 역할

    ex) "비행기" , "자동차" , "열차" , "배" -> 운송수단의 동일한 특징인 화물이나 승객을 운반함

         이것은 "운송수단"이라는 클래스로 정의할 수 있음

 

7. 캡슐화 (Encapsulation)

  - 변수와 메서드를 하나의 추상화된 클래스로 묶는 과정

  - 변수와 메서드를 하나로 묶어 독립적으로 동작하지 않도록 함

  - 캡슐 속 객체는 데이터와 메서드를 포함하고 있어 따로 분리할 수 없음

  - 객체가 제공하는 메서드를 통해 객체를 이용하고, 데이터 실제로 어떻게 처리되는지는 알 필요 없음

 

8. 정보 은닉 (Information Hiding)

  - 객체지향 언어에서는 캡슐화된 변수나 메서드를 선택적으로 공개하거나 숨길 수 있음

  - 숨겨햐 하는 정보는 "Private", 공개하는 정보는 "Public" 으로 구분

 

9. 메시지 (Message)

  - 객체 간 서로 통신하는 방법

  - 객체 간 메시지를 주고 받기 때문에 여러 객체는 동일한 프로세스를 가질 필요가 없음

  - 서로 메시지를 주고 받는 데 객체가 존재하는 위치는 제약이 되지 않음

  - 메시지 전달 시, "대상 객체", "전달하고 싶은 메시지", "부과 정보" 가 필요

    ex) car.changeGear(lowerGear)

 

 

>> 요약 버전

더보기

🙌 추상화

객체를 모델링할 때 필요로 하는 만큼만 속성과 메서드를 추출해내는 것

모델에 무엇을 포함하고 무엇을 뺄 것인지 아는 것이 가장 중요

 

🙌 상속

상위 클래스의 속성과 행위를 하위 클래스가 그대로 이어받는 것

상속을 이용하면 구현이 편리해지고 유지보수가 용이

 

🙌 다형성

상속을 받으면서 자신만의 커스터마이징이 가능함

메소드 오버라이딩(로직수정), 메소드 오버로딩(파라미터에 따라 다른 동작시키기 ) 등이 있다.

 

🙌 캡슐화

객체가 자신의 동작 원리를 클래스라는 껍데기로 감추는 것

해당 객체를 제외하고는 원리를 알 길이 없다.

 

🙌 정보은닉

캡슐화된 항목의 인터페이스와 구현을 명확히 분리하여 각 클래스의 내부 항목에 관한 정보를 다른 객체로부터 숨긴다.

메시지 전달에 의해 다른 클래스 내의 메서드가 호출된다.

 


✔️ 클래스 간의 관계

1. 연관 관계

클래스는 서로 특정 의미를 가짐

 

2. 일반화 - 특수화 관계

두 클래스 간 상속관계를 나타낸 것으로, 위로 갈수록 추상/일반화, 아래로 갈수록 구체/특수화

 

3. 집합관계

하나의 클래스가 독립 가능한 여러 컴포넌트 클래스로 구성. 관계도에서 전체 클래스 쪽에 빈 마름모를 그린다.

 

4. 복합관계

하나의 클래스가 독립 불가능한 여러 컴포넌트 클래스로 구성. 관계도에서 전체 클래스 쪽에 색칠한 마름모를 그린다.

 


✔️ 클래스 설계 원칙

1. 단일 책임 원칙

클래스는 한 가지 책임(기능)만 갖도록 설계한다.

 

2. 개방 폐쇄의 원칙

확장(상속)에는 열려있고, 변경에는 닫혀있어야 한다.

 

3. 리스코프 교체의 원칙

상위 클래스는 하위 클래스로 대체할 수 있어야 한다.

 

4. 의존 관계 역전의 원칙

클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스)에 의존해야 한다.

 

5. 인터페이스 분리의 원칙

하나의 일반적인 인터페이스보다는 구체적인 여러 인터페이스가 낫다.

 


✔️ 디자인 패턴

 

1. 디자인패턴의 장단점

장점

-개발자(설계자) 간 원활한 의사소통

-소프트웨어 구조 파악 용이

-재사용성을 통한 개발 시간단축

-설계 변경 요청에 대한 유연한 대처

 

단점

-객체지향 설계/구현 위주

-초기투자 비용부담

 

범위 \ 목적 생성패턴
(객체의 생성과정에 관여)
구조패턴
(클래스나 객체의 합성에 관여)
행위패턴
(클래스나 객체들의 상호작용과 책임을 분산)
클래스 Factory Method Adapter Interpreter
Template Method
객체 Abstract Factory
Builder
Prototype
Singleton
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

 

2. 생성 패턴

- 객체의 생성과 참조 과정을 캡슐화하여 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 하여 

프로그램에 유연성을 더해주는 패턴

 

Factory Method

객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴

상위 클래스에서 인스턴스 작성법의 뼈대를 세우고 구체적인 작성은 하위 클래스에서 실행하는 패턴

상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당

 

Abstract Factory

클래스가 아닌 인터페이스를 통해 연관된 부품을 조합해서 인스턴스 생성을 실행하는 패턴

 

Builder

복잡한 인스턴스를 조립하여 만드는 구조로, 객체를 생성하는 방법과 객체를 구현(표현)하는 방법을 분리하는 패턴

 

Prototype

모형이 되는 인스턴스를 복사해서 새로 인스턴스를 만드는 패턴

 

Singleton

특정 클래스의 인스턴스가 오직 하나만 존재하도록 제한하는 패턴

여러 프로세스가 동시에 참조할 수 없어 불필요한 메모리 낭비를 최소화할 수 있음

 

3. 구조 패턴

구조 패턴은 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴으로, 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다.

 

Adapter

서로 다른 인터페이스를 가져 호환성이 없는 클래스의 인터페이스를 이용할 수 있도록 연결하는 패턴

 

Bridge

구현부에서 추상층을 분리하여 서로 독립적으로 확장할 수 있도록 구성한 패턴. 기능과 구현을 두 개의 별도 클래스로 구현

 

Composite

여러 객체를 트리구조로 하여 재귀적으로 다룸

 

Decorator

객체에 부가적인 기능을 추가하기 위해 다른 객체를 덧붙이는 것

 

Facade

복잡하게 얽힌 클래스를 개별 제어하는 것이 아니라 창구 역할을 하는 클래스를 상위에 하나 더 배치해서 시스템 전체의 조작성을 향상

 

Flyweight

인스턴스가 필요할 때마다 매번 생성하는 것이 아니라 가능한 공유함으로써 메모리를 절약

 

Proxy

접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 함으로써 네트워크/대용량 객체에 이용

 

3. 행위 패턴

행위 패턴은 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴이다. 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다.

 

Interpreter

문법 규칙을 클래스로 표현하는 패턴

 

Template Method

상위 클래스에서 처리의 뼈대를 세우고, 구체적인 처리를 하위 클래스에서 실행하는 패턴

 

Chain of Responsibility

요청이 처리되지 못하면 연결되어 있는 내부의 다른 객체로 토스하는 패턴

 

Command

요청을 클래스의 형태로 캡슐화하여 기록

 

Iterator

자료구조처럼 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴

 

Mediator

서로 다른 객체 사이에 중재자 역할을 하는 클래스를 두어 객체 사이의 의존성을 줄임

 

Memento

특정 시점에서의 객체 상태를 저장하여 Undo 기능이 가능하도록 하는 패턴

 

Observer

상태가 변화하면 상속되어 있는 다른 객체들에게 변화를 통지하는 패턴

 

State

객체의 상태를 클래스로 표현하여, 상태에 따라 다른 동작을 처리할 수 있게 하는 패턴

 

Strategy

동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴

클라이언트는 독립적으로 알고리즘을 선택하고 전부 교체하여 수정하기 쉽다.

 

Visitor

각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴

분리된 처리 기능은 각 클래스를 Visit(방문)하여 수행. 이를 소프트웨어 생명 주기 모형이라고 하는데, 크게 다음과 같은 특징을 가지고 있다

  • 폭포수 모형
  • 프로토타입 모형
  • 나선형 모형

✔️ 소프트웨어 생명주기 모델

1. 폭포수 모형(Waterfall Model)

  • 폭포수 모형은 항공 방위 소프트웨어 시스템 개발 경험을 토대로 처음 개발되어 1970년대 부터 널리 알려졌다
  • 유사한 개발 경험이 있는 경우 효율적이고 품질면에서 우수하다
  • 명확성이나 정밀성을 강조하는 경우 코딩이나 테스트 작업이 지연될 수 있다

1) 폭포수 모형의 특징

  • 각 단계가 명확하다
  • 요구사항의 변경이 어렵다
  • 2가지 과정이 병행 되거나 이전단계로 넘어갈 수 없다
  • 주로 이전에 진행했던 개발 프로젝트의 솔루션 구축에 사용되던 방법

2) 폭포수 모형의 개발 순서

1. 타당성 검토

2. 계획단계

3. 요구 분석 단계 

  • 개발하고자 하는 소프트웨어에 대한 요구사항 수집, 문제 이해 및 분석 단계
  • 소프트웨어 엔지니어 또는 분석가: 고객의 요구사항을 기능, 성능, 인터페이스 등으로 파악하고 문서화
  • 산출물: 요구사항 명세서(Requirement Specification) (Requirement Specification) 

4. 설계 단계

  • 프로그램의 데이터 구조, 소프트웨어 구조, 인터페이스 구조, 알고리즘 등 모든 시스템의 구조 결정
  • 산출물: 설계 명세서

5. 구현단계

  • 설계 명세서를 시스템의 실제 모습으로 변환 시키는 것
  • 산출물: 프로그램 

6. 시험(검사)단계

  •  프로그램이 입력에 따라 요구되는 결과대로 작동하는지, 내부적 이상 여부 및 오류 발견을 위해 수행
  • 테스트 계획을 세운 후 문서화

7. 유지보수 단계

  • 개발된 소프트웨어의 변경사항을 수정하는 것
  • 수정 유지보수, 적응 유지보수, 기능 추가 유지보수 등이 있음

3) 폭포수 모형의 장점과 단점

장점

  • 모형의 적용 경험과 성공사례가 많다
  • 단계별 정의가 분명하고, 전체 공조의 이해가 용이하다
  • 단계별 산출물이 정확하여 개발 공정의 기준점을 잘 제시한다

단점

  • 개발 과정중에 발생하는 새로운 요구나 경험을 반영하기 어렵다. 때문에 사용자에게 요구사항을 명확하게 제시 받아야 한다
  • 오류 없이 다음 단계로 진행하기 어렵다. 단계별로 오류없이 진행해야 하는데 현실적으로는 어렵다
  • 업무에 운용할 때 검출 되지 않은 오류가 발견될 수 있다. 개발 단계에서는 발견되지 않았던 오류가 운용하면서 발견되므로
    사용자의 인내심이 요구된다

2. 프로토타입 모형 (Prototype Model)

- 시스템 개발 초기에 사용자(고객)의 요구 기능을 시제품으로 만들어 사용자로 하여금 기능과 사용성 등에 대해 검증시켜 가면서 시스템을 개발하는 기법

  • 시제품을 만들어 사용자의 피드백을 신속하게 제공 받을 수 있다
  • 시제품은 사용자의 시스템 사이의 인터페이스에 중점을 두어 개발한다
  • 시스템의 구현 단계에서 사용할 골격 코드가 된다
  • 공동의 참조모델을 제공한다
  • 시뮬레이션을 통해 최종 결과물 예측이 가능한 모형이다

1) 프로토타입 모형의 특징

  • 요구사항의 변경이 용이하다
  • 최종 결과물의 일부 또는 전체 모형을 볼 수 있다
  • 고객이 만족할 때까지 해당 과정을 반복한다
    ① 고객이 만족하지 않으면 프로토타입을 다시 만든다
    ② 고객이 만족하면 이를 토대로 구현 단계에 들어간다
  • 단기간에 개발하기 때문에 비효율적인 코딩을 할 수 있다.

2) 프로토타입 모형의 개발 순서

1. 요구 수집

  • 고객의 일부 요구사항 또는 불완전한 요구 사항으로부터 제품을 윤곽을 잡음

2. 빠른 설계

  • 주어진 요구사항을 기반으로 빠른 설계를 함
  • 주로 제품의 사용자 인터페이스에 초점을 맞춤

3. 프로토타입 구축

  •  설계된 원형을 RAD(Rapid Application Development) RAD(Rapid Application Development) 도구 등을 사용하여 빠르게 구현함
  •  고객이 요구하는 기능을 구현하고 필요한 요소를 파악하는데 중점을 둠
  • 프로그램의 신뢰도나 품질이 아니라 가능한 빨리 원형을 구현하는 것이 목적

4. 고객 평가

  • 고객과 개발자가 함께하는 가장 중요한 단계
  • 고객 요구사항을 정확하게 규명하기 위해 원형에 대한 사용 및 평가 시간을 충분히 제공
  • 개발될 소프트웨어의 요구사항 정제에 중요한 정보로 활용

5. 프로토타입 조정

  •  원형이 어떻게 수정되어야 할지를 결정함 
  • 원형 개발과 검증, 요구사항 정제의 순환을 반복하여 추가적인 정보를 통해 요구사항을 완성해 나감

프로토타입은 개발과 구현 테스트 단계로 넘어가지 않는다. 요구 분석 단계에서 사용되며 프로토타입의 평가가 끝나고 개발이 승인되면 다른 모형을 이용하여 본격적인 개발이 이루어진다

 

3) 프로토타입 모형의 장점과 단점

장점

  • 요구사항을 충실히 반영하며, 요구사항 변경에 용이하다
  • 최종 결과물이 만들어지기 전에 의뢰자가 최종결과물 일부를 볼 수 있다
  • 의뢰자나 개발자 모두에게 공동의 참조모델을 제공한다

단점

  • 실제 소프트웨어와에 차이가 발생할 수 있다
    프로토타입과 실제품과의 괴리감으로 사용자가 혼란에 빠질 수 있다
  • 단기간에 제작하므로 비효율적 코딩이 사용된다
    비효울적인 언어나 알고리즘을 사용할 수 있다

 

4) 프로토타입의 종류

Working Prototype

프로토타입형 프로그램을 이용해서 사용자의 요구를 반아들이면서 개발하는 방식

Program Prototype

이미 개발된 프로그램을 사용자에게 설명하면서 사용자의 요구를 받아들이는 방식

Paper Prototype

프로그램은 없고 문서만으로 사용자에게 설명하면서 사용자의 요구를 받아 들이는 방식

5) 프로토타입의 원칙

브룩스 이론 : 프로토타입에 대한 프로그램 관리에 대한 이론

  • 프로토타입 소프트웨어는 폐기처분하는 첫번째 시스템이다
  • 일정이 지연된다고 해서 새로운 인원을 투입하면 일정이 더욱 지연된다

 

3. 나선형 모형 (Spiral Model)

보헴 (Boehem)이 제안한 것으로 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형이다

  • 모든 단계를 반복하며 점진적으로 발전시켜 완벽한 최종 소프트웨어를 개발하는 방법이다
  • 대규모 시스템 소프트웨어 개발에 적합하다

1) 나선형 모형의 특징

  • 위험 관리가 중심인 소프트웨어 생명주기 모형
  • 폭포수 모형과 프로토타입 모형의 장점을 살린 모형
  • 위험 요소 및 타당성을 분석하여 프로젝트의 추진 여부를 결정한다

2) 나선형 모형의 개발 순서

1. 계획 및 정의 (Planning)

  • 개발자는 고객에게 요구사항을 수집
  • 개발자는 시스템의 성능, 기능을 비롯한 시스템의 목표를 규명하고 제약 조건을 파악
  • 목표와 제약 조건에 대한 여러 대안들을 고려하고 평가함으로써 프로젝트 위험의 원인을 규명 가능

2. 위험 분석 (Risk Analysis)

  • 초기의 요구 사항을 토대로 위험 규명
  • 위험에 대한 평가가 이루어지면 프로젝트를 계속 진행할 것인지 아니면 중단할 것인지를 결정

3. 공학적 개발 (Engineering)

  • 시스템에 대한 생명주기 모델을 선택하거나 원형 또는 최종적인 제품을 만드는 단계

4. 고객 평가 (Customer Evaluation

  • 구현된 소프트웨어(시뮬레이션 모형, 원형 또는 실제 시스템)를 고객이나 사용자가 평가 함
  • 고객의 피드백을 얻는데 필요한 작업이 포함
  • 다음 단계에서 고객의 평가를 반영할 수 있는 자료 획득 가능

3) 나선형 모형의 장점과 단점

장점

  • 가장 현실적인 모형으로 대규모 시스템에 적합하다
  • 누락되거나 추가된 요구사항 대응이 가능하다
  • 정밀하여 유지보수 과정이 필요 없다

단점

  • 위험성 평가에 크게 의존한다. 위험성을 사전에 발견하지 못할 경우 문제가 발생한다
  • 최신 기법이라 아직 널리 사용되지 않는다

 

4. V모델(Verification Model)

폭포수 모델에서 시스템 검증과 테스트 작업을 강조한 모델

검증 단계에서 테스트 단계가 오류 발생 시 돌아갈 단계를 이어놓은 것

 

2) 테스트 순서

 1) 단위 테스트 : 개별 모듈 검증
 2) 통합 테스트 : 모듈 간의 인터페이스 확인
 3) 시스템 테스트 : 모듈이 모두 통합된 후 사용자의 요구 사항들을 만족하는지 확인
 4) 인수 테스트 : 시스템이 예상대로 동작하고 요구 사항에 부합하는지 확인

 

3) V 모형의 장점과 단점

장점

  • 모든 단계에 검증 및 확인이 있어서 오류를 줄일 수 있다.
  • 높은 신뢰도를 요구하는 프로젝트에 적합한 모델이다

단점

  • 작업이 끝나버리면 변경이 쉽지 않다
  •  반복이 없어 변경 사항을 다루기가 쉽지 않음

 

5. 통합 프로세스(UP,Unified  Process) 모델

1) 통합 프로세스 특징

- 반복적 개발 방법론으로, 폭포수 모델의 단점인 비가역적 진행을 보완

- 1999년 Jacobson, Booch, Rumbaugh에 의해 개발됨

- 소프트웨어 개발이 각각 생명주기를 가지는 여러 번의 반복(iteration)을 거쳐 수행되는 모델 ™

- 반복마다 실행 가능한 릴리즈가 산출

- 반복이 거듭될수록 향상되어 결국 최종 시스템으로 가까워짐

 

2)  통합 프로세스 모델의 절차

1) 도입(Inception)

• 소프트웨어 개발 주문에 관련된 사람들(고객, 사용자, 재무적 지원자 등)과의 준비적 상 호 작용 단계

• 요구사항 분석, 원형에 대한 설계, 구현 단계

 

2) 상세(Elaboration)

• 어떠한 시스템이 필요한지를 확정하는 단계

• 요구사항 분석 및 아키텍쳐(Architecture) 확정 단계

 

3) 구축(Construction)

• 기본 기능만을 가진 제품 산출 단계로 주요 설계 및 구현을 수행

• 여전히 릴리즈를 위해서는 기능을 보강해야 함 

 

4)이행(Transition)

• 제품 릴리즈 완성 단계 서로 서 구현 및 테스트 수행

 

3)  통합 프로세스 모델의 장단점

장점

- 위험 요소 초기 발견 가능

- 아키텍쳐에 대한 정의를 중요한 요소로 삼고 개발하기 때문에 이해가 쉽고 견고하며 변경 관리가 용이함

 

6. 점진적(단계적) 개발 모델

 

릴리즈 구성에 따른 분류

1) 점증적 개발 방법

2) 반복적 개발 방법

 

 

7. 애자일(Agile) 모델

- 변화를 수용하고, 협업을 강조하며, 제품의 빠른 인도를 강조하는 반복적 개발방법

- 문서화 작업보다 코드, 소프트웨어 자체를 중요시함

 

2) 애자일 모델 특징 

애자일(Agile) 방법론은 구체적인 개발 프로세스가 아닌 개발 지침, 철학에 가깝다.

변화를 수용하고 협업과 제품의 빠른 인도를 강조하는 반복적 개발 방법

문서화보다 코드, 프로그램, 소프트웨어 자체를 중요시 함

요구사항의 변화는 불가피하며 이에 대응하는 것이 현실적이다.

기존의 개발 프로세스는 설계 기간이 길며 재작업 시 오버헤드가 크다.

환경의 빠른 변화에 대응하는 것이 중요하다.

 

3) 애자일 선언문(Agile Manifesto) 

공정과 도구보다 개인과 상호작용을,

포괄적인 문서보다 작동하는 소프트웨어를,

계약 협상보다 고객과의 협력을,

계획을 따르기보다 변화에 대응하기를,

 

4) 애자일 방법론의 종류

익스트림 프로그래밍(Extreme Programming, XP)

짝 프로그래밍(Pair Programming)

테스트 주도 개발(Test Driven Development, TDD)

 

1. 익스트림 프로그래밍(Extreme Programming, XP)

- XP의 실천 지침

- 작고 빈번한 릴리즈 - 빠른 피드백과 지속적인 개선

- 리팩토링을 통한 코드 품질 개선

 

2. 짝 프로그래밍(Pair Programming)

- 두 사람이 짝이 되어 한 사람이 코딩을, 다른 사람은 검사를 수행

- 30분마다 역할 교체하며, 코드에 대한 책임 공유

- 두 사람이 짝을 이뤄 개발하지만 각각 개발하는 경우에 비해 생산성이 크게 떨어지지 않는다.

 

3. 테스트 주도 개발(Test Driven Development, TDD)

- 선 개발 후 테스트 방식이 아닌 선 테스트 후 개발 방식의 프로그래밍 방법을 말한다.

다시 말해 먼저 요구사항에 필요한 자동화된 테스트 코드를 작성한 후 테스트를 통과하기 위한 코드를 개발하는 방식의 개발 방식을 말한다.

 


5) 애자일 모델의 장단점

장점

장점
내용
Agile 특징
Time-To-Market
- 요구사항 변화를 빠르게 수용하여 적시에 서비스 제공
적극적 요구반영
품질 향상
- 고객에게 주기적 피드백, 빈번한 테스트
고객 참여
ROI 증대
- 가치있는 기능을 빠르고 안정적으로 전달
짧은 릴리즈
생산성향상
- 불필요 산출물 제거 및 협업 강화
사람 중심

단점

단점
내용
보완 사항
명세화 부족
- Agile 프로세스 문서, 지침 부족
전문가 양성
요구사항
/잦은 변경
- 비기능적 요구사항 고려 부족
- 잦은 변경으로 테스트 증가
변경관리 체계 도입
사업 관리 부분 미흡
- 방법론 측정 지표가 개발자 위주
- 상위 관리자의 요구 충족이 어려움
측정 지표 보완
대형 프로젝트
도입의 어려움
- 대형 프로젝트의 복잡도 및 리스크 증가
부분적 도입 및 리뷰를 통한 단점 완화

 

  특  징  /  적  용 장  점 단  점
1. 폭포수 모델 - 각 단계가 끝나야 다음 단계가 시작 가능함 (순서적)
 - 단순하거나 응용 분야를 잘 알고 있을 경우 적합
 - 결과물 정의가 중요
 - 이미 잘 알고 있는 문제나 연구 중심 문제에 적합
 - 변화가 적은 프로젝트에 적합
- 프로세스가 단순하여 초보자가 쉽게 적용 가능
 - 중간 산출물이 명확, 관리하기 좋음
 - 코드 생성 전 충분한 연구와 분석 단계
- 초반 단계들을 지나치게 강조하면 코딩, 테스트가 지연
 - 각 단계의 전환에 많은 노력
 - 프로토타입과 재상용의 기회가 줄어둚
 - 소용 없는 다종의 문서를 생산할 가능성 있음
2. 프로토타이핑 모델 - 프로토타입(시범 시스템)의 적용
 - 트로토타이핑 도구 이용
 - 공동의 참조 모델
 - 단순한 요구 추출 및 제작 가능성 타진
 - 개발 착수 시점에 요구가 불투명할 때 
 - 실험적으로 실현 가능성을 타진해 보고 싶을 때
 - 혁신적 기술을 사용해 보고 싶을 때
- 사용자의 의견 반영이 잘 됨
 - 사용자가 더 관심을 가지고 참여할 수 있고 개발자는 요구를 더 정확하게 도출할 수 있음
- 오해, 기대심리 유발
 - 관리가 어려움 (중간 산출물 정의가 난해)
3. 점진적 모델 - 선형 순차적 모델의 요소들에 프로토 타입의 반복성의 개념 포함
 - 개발 사이클이 짧은 환경
 - 빠른 시간 내에 시장에 출시해야 할 때 
 - 개발 시간을 줄이기 위해 시스템을 나누어 릴리즈
 - 점증적 & 반복적으로 릴리스
 - 기능이 부족하더라도 초기 사용가능
 - 빠른 출시로 초기 시장 선점 가능
 - 자주 릴리스하여 문제를 신속히 해결
- 대규모 시스템 개발에 적합
 - 반복적인 개발 및 테스트
 - 처음 릴리즈에 핵심 기능이 구현되고, 이후 릴리즈는 부가 사항이 구현
 - 한 릴리즈에 추가하지 못한 기능은 다음 릴리즈에 추가 가능
- 각 릴리즈에 중복되는 작업이 발생 할 수 있음
4. 나선형 모델 - 프로토 타입 모델의 반복성과 선형 순차적 모델의 시스템적인 요소를 결합
 - S/W 기능을 나누어 점증적으로 개발
 - 여러 번의 점증적인 릴리즈
 - 계획 수립, 위험 분석, 개발, 평가 단계로 구성
 - 재정적 또는 기술적으로 위험 부담이 큰 경우
 - 요구 사항이나 아키텍처 이해에 어려운 경우 
- 대규모 시스템 개발에 적합
 - 반복적인 개발 및 테스트
 - 한 사이클에 추가하지 못한 기능은 다음 단계에 추가 가능
- 위험 분석이 중요
 - 관리가 중요
 - 새로운 모형
5. V 모델 - 폭포수 모델의 변형이나 작업 결과의 검증에 초점
 - 신뢰성이 높이 요구되는 분야
- 오류를 줄일 수 있음 - 반복이 없어 변경 사항을 다루기가 쉽지 않음

 

 

9.  4GT 모형(4세대 기법)

1) 개요

- 사용자와 개발자가 쉽게 접근하고 사용할 수 있는 CASE를 비롯한 자동화 도구, 4세대 언어(ex. VB) 등을 이용해 요구사항 명세서로부터 원시 코드를 자동으로 생성할 수 있게 해주는 모형

 

2) 특징

1) CASE

- 자동화 도구를 사용하기에 소프트웨어 생산성 향상을 구현하는 공학기법이다.

- 원시 코드를 자동으로 생성해준다.

- 설계 단계를 단축할 수 있다.

 

2) 4GT 모형

- 개발자가 조사한 요구사항을 자동으로 구현시키는 비절차적 기법

- 4세대 언어를 사용함으로써 원시 코드를 자동으로 생성가능

- 중소형 소프트웨어 개발에 사용하면 개발 시간이 감소되지만 대규모 소프트웨어 개발에서는 분석, 설계 단계 등에서 더 많은 시간을 필요로 한다.

 

3.) 개발 순서

 

 

 

 

 

 

 

출처: https://runninnonempty.tistory.com/31 [리버피닉스를 추모하며 자바를 공부하자]

https://velog.io/@anhesu11/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C%EC%9D%98-%EC%83%9D%EB%AA%85%EC%A3%BC%EA%B8%B0-%EB%AA%A8%ED%98%95

https://computer-science-student.tistory.com/140

https://luv-n-interest.tistory.com/349

https://devuna.tistory.com/106

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=roser111&logNo=221664035126 출처: https://devuna.tistory.com/66