일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- MAC
- 메카님
- linear difference equation
- STCF
- 게임 개발
- ret2libc
- dtft
- convolution
- DSP
- Race condition
- MLFQ
- pdlc
- frequency-domain spectrum analysis
- information hiding
- sampling theory
- Frequency Response
- stride
- 배경 그림
- 운영체제
- Security
- 유니티
- SNR
- 유스케이스
- DP
- 게임개발
- Unity #Indie Game
- dirty cow
- AINCAA
- link layer
- polymorphism
- Today
- Total
다양한 기록
Generic Software Process Models (Life Cycle Models) 본문
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 |