다양한 기록

Generic Software Process Models (Life Cycle Models) 본문

소프트웨어공학

Generic Software Process Models (Life Cycle Models)

라구넹 2024. 10. 26. 22:56

1. Code-and-Fix Model

- 디자인, 사양 없고 유지보수에 고생

- 개발하긴 쉬운데 가장 돈이 많이 들게 됨


2. Waterfall Model (리니어 모델)

요구사항 정의 - 분석 - 설계 - 구현 - 유지보수 ..

다음 단계로 넘어가면 이전 단계로 돌아가기 어려움

- 요구 사항이 명확한 경우 유용

- 현실은 더 복잡하고 요구사항은 바뀜

- 소비자는 코드가 준비될 때까지 마냥 기다려야 함

- 커스터머로의 피드백 부족은 실수가 재앙이 됨


3. Prototype Model

SW는 사람이 하는 일 +@를 함 .. 고객이 제대로 표현하기가 힘듦

요구사항을 그냥 얻어내기는 힘드니까 일단 프로토타입을 만들고 요구사항을 확실히 얻어내는 방식 => 시제품

"Quick and dirty"

a) Throw-away(Rapid) prototyping

b) Evolutionary prototyping => Agile

 

특징

- 제한된 기능

- 낮은 신뢰성

- 부족한 성능

- GUI 많이 사용됨

- 상호작용 포맷

- 시스템의 초기 버전은 컨셉을 입증하고 설계 옵션을 시험하는데 사용됨

 

장점

- 시스템 사용성 향상

- 사용자의 실제 요구에 더 가깝게 일치

- 디자인 품질 향상

- 유지보수성 향상

- 개발 노력 감소


4. Sprial model

== evoltionary model

- 스파이럴의 각 루프는 프로세스의 페이즈를 나타냄

- 구체화, 설계같은 고정된 페이즈 없음 .. 요구될 때 정해짐

- 리스크는 프로세스에서 명시적으로 평가되고 해결됨

 

Risk

- 대부분 사람 문제.. 이직을 한다거나

- 하드웨어 지원 안됨

- 테스팅 시간이 너무 오래 걸림

- 만들다가 경쟁사가 출시함

- 통합 실패

... 해결이 안되면 과감히 포기

 

특징

- 반복적인 프로토타이핑을 폭포수 모델의 체계적인 측면과 결합

- 소프트웨어 수명 주기 전반에 걸쳐 사용 가능

- 기준점 마일스톤 .. 작업 결과물, 달성해야 할 조건

- 대규모 시스템 개발에 현실적인 접근 방식 .. 위험을 반복적으로 줄이고, 프로토타이핑 접근 방식의 반복적 사용을 허용

- 문제는 고객이 제어가 안되는 걸 두려워서 싫어함

- 소프트웨어는 여전히 개별 페이즈에서 개발됨

=> 다른 방법 .. Interactive-and-incremental model


5. RAD (Rapid Application Dvelopment) 긴급 응용 모델

- 짧은 개발 주기

- 요구사항이 잘 정의되고 뭘 할 것인지 범위가 명확해야 가능

- 대규모 프로젝트의 경우 방대한 인적 자원 필요

- 개발자와 고객은 빠른 속도에 대응할 수 있어야 함

- 이미 있는 컴포넌트 가져다 쓰는 경우가 보통이라 모듈화가 잘 안된 시스템은 못함

- 각 구성요소가 아예 독립적으로 나누어져야 사용 가능

- 가술적 위험이 높은 경우(새로운 기술 관련) 적합하지 않을 수 있음


6. Formal Methods

- 수학적인 원칙을 이용해서 요구사항을 아주 정확히 정의

- 높은 퀄리티의 소프트웨어 얻을 수 있음

문제

- 시간 오래 걸리고 돈 많이 듦

- 가르쳐야 됨

- 이해하기도 힘듦

 

주 목적은 시스템의 에러를 줄이는 것..

크리티컬한 시스템에 사용됨

- 에어 트래픽 컨트롤 인포메이션 시스템

- 철도 시그널링 시스템

- 우주선 시스템

- 메디컬 컨트롤 시스템..

 

개발 비용은 많이 들지만 확실한 소프트웨어 개발 가능

 

Head(Create) = Undefined exception (empty list)
Head(Cons(L, v)) = if L = Create then v else Head(L)
Length(Create) = 0
Length(Cons(L, v)) = Length(L) + 1
Tail(Create) = Create
Tail(Cons(L, v)) = if L = Create then Create else Cons(Tail(L), v)

위와 같은 방식으로 표현

리스트의 경우 첫번째 원소가 헤드, 그 뒤 나머지가 테일

Tail(Cons(L, v)) = if L = Create then Create else Cons(Tail(L), v)

이런 글의 의미를 보면 L이 빈 리스트이면 빈 리스트를 리턴하고(v가 헤드가 되기 때문),

아니면 L의 헤드를 제거하고 v를 이어 붙여 리턴하게 된다고 표현한다.

'소프트웨어공학' 카테고리의 다른 글

Agile Process - Scrum  (0) 2024.10.28
Agile Process - Kanban, Lean  (0) 2024.10.28
Process in Software Engineering  (0) 2024.10.26
분석 클래스 모델의 작성  (0) 2024.10.26
클래스 다이어그램  (0) 2024.10.26