01 | 소프트웨어 개발 프로세스 / Model

* KOWC에 등록된 동국대학교 최은만 교수님의 강의내용을 공부목적으로 정리한 글임을 밝힙니다.

| 출처 : http://www.kocw.net/home/search/kemView.do?kemId=331697&ar=relateCourse 

 

 

 

Code-and-Fix vs SDLC model

---

Code-and-Fix

개발 초기단계부터 명확한 계획이나 가이드라인(or 프로세스) 없이 개발해 나가기에, 중요한 작업의 누락이나 불명확한 개발기간, 소요비용 추정의 어려움 등으로 비효율이 발생하며, 무엇보다 개발 막바지에 문제가 발생할 경우 초기 약간의 수정만으로 해결 가능했던 사항이 막대한 비용발생 사항으로까지 이어질 수 있다는 리스크 존재

 

 

SDLC(Software Development Life Cycle) model

제품컨셉결정부터 소멸단계에 이르기까지 거치게 되는 일련의 소프트웨어(제품) 개발 과정(process)으로, 최종 목표달성에 필요한 작업을 구조화함으로써 명확한 작업지시와 효율적인 관리 및 유지보수가 이루어지도록 함

 

 

 

SDLC model 종류

---

• 폭포수 모형
• 프로토타이핑 모형
• 점증적 모형
• 나선형 모형
• V 모형
• 일정 중심 설계 모형
• 진화적 출시 모형

 

 

 

폭포수 모형 (Waterfall model)

---

단계 간 중복이나 상호작용 없이 바로 이전 단계의 피드백만이 순차적으로 이루어지므로, 각 단계는 다음 단계 시작 전 종료되어야 함

 

프로세스가 단순하고 산출물이 명확하며 코드생성 전 충분한 연구분석이 가능하나, 개발 이전단계가 지나치게 강조될 경우 실제 개발과 테스트가 지연될 수 있고 단계 간 피드백이나 전환이 쉽지 않음

 

연구중심 문제나 변화가 적은 프로젝트에 적합 

 

 

출처 : http://wiki.hash.kr/index.php/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%AA%A8%EB%8D%B8

 

 

계획

소요 비용, 시간, 인력 등을 산정하고 초기 전략을 수립하는 단계

특히 ROI (Return Of Investment) 을 계산하여 해당 프로젝트의 수익성을 따져보고, 리스크분석을 통해 위험과 그에 따른 비용을 최소화할 수 있는 방향으로 계획을 수립해야 함

 

 

요구분석

'What' 초점을 맞추어 프로그램이 갖추어야 할 기능/성능을 분석함

현 단계의 작은 오류가 향후 단계로 갈수록 큰 위험과 비용을 초래하므로 초기 요구사항을 잘 Fix 시켜두는 것이 중요

SRS(Software Requirement Sepcificaiton Document, 요구분석서) 작성 이루어짐

 

 

설계

'How' 에 초점을 맞추어 아키텍쳐, DB, Class, UI 등 구체적인 SD(Software Design)를 작성하는 단계 

 

 

구현

실제 코딩하는 단계로, 설계단계와 병행이 이루어지기도 함

인력이 많이 투입되고 일정(시간)에 따른 압력 고려하여 적절한 요구가 이루어질 수 있도록 계획하는 것 중요

 

 

통합 및 테스트

개발자가 모듈을 통합해 나가며, QA 팀에서 테스트 시작하는 단계

* 테스트 : 단계적(단위, 통합, 시스템) 테스트와 목적 중심(스트레스, 성능, 베타, Acceptance, Usability) 테스트로 이루어짐

 

 

설치 및 유지보수

시스템 타입에 따른 설치와 이전(Migration) 이루어지는 단계로, 특히 Data, System, 이전사용자 등이 새로운 프로그램에 제대로 마이그레이션 이루어질 수 있도록 하는 것 중요

 

유지보수는 릴리즈 이후 이루어지며 결함 수정, 새로운 기능/성능 추가 등이 이루어짐

 

 

 

프로토타이핑 모형 (Rapid Prototyping Model, RAD)

---

최종제품 개발 전 시범 시스템을 만들어 사용자의 의견을 반영함으로써 개발도중 발생할 수 있는 사용자 요구사항의 변경에 따른 리스크를 줄일 수 있음

 

구체적/세부적인 알고리즘을 구현하기보다 대략적인 동작방식/구성요소를 시험 제작하여 개발자와 사용자 간의 의사소통을 돕고 사용자 요구를 명확히 파악하는 데 도움이 됨

 

 

 

 

앞선 폭포수 모델이 각 프로세스가 순차적으로 진행되며 한 사이클 내에 모든 작업이 완료되어 사용자 요구변경에 대한 유연한 대처가 어려웠다면, 프로토타이핑 모델의 경우 개발단계에서 유지보수가 이루어지기에 사용자 요구를 좀 더 정확히 반영할 수 있다는 장점이 있음

 

 

 

점증적 모형

---

개발시간 단축을 위해 시스템을 여러번 나누어 릴리스 하는 방법

 

중요하고 기초적인 기능을 우선 개발하여 사용하게 함으로써 이전에 없던 제품의 경우 시장 선도지위 확보와 사용자 초기 교육이 가능하고 개발과 운영이 동시에 이루어지기에 신속한 문제파악 및 오류해결이 가능

 

 

 

릴리스 구성 방법에는 크게 점증적, 반복적 방법이 있음

 

점증적 방법

시스템을 기능별로 여러개의 서브시스템으로 나누어 일부 기능을 갖춘 서브시스템을 우선 릴리스 한 뒤, 다음번 릴리스 때 새로운 기능을 추가해 나가는 형태

 

| ex) 네비게이션

[릴리스 1 : 경로 찾기]

[릴리스 2 : 주차보조]

[릴리스 3 : 멀티미디어]

...

 

반복적 방법

처음부터 시스템 전체 기능을 대상으로 하되 릴리스 할 때마다 기능을 업그레이드하는 형태

 

| ex) 네비게이션

[릴리스 1 : 경로 찾기, 주차보조, 멀티미디어 기능]

[릴리스2 : 경로검색 속도 향상, 위치정보 정확도 향상, 콘텐츠 스트리밍 속도/화질 향상]

...

 

 

 

나선형 모형 (Spiral model)

---

개발 주요기능을 나누어 여러 사이클을 반복하고, 그러한 반복과정에서 확인되는 리스크 요인을 밝혀내어 점진적으로 개선해 나감으로써 위험을 최소화하는 것이 목적 (보다 완벽한 제품개발)

 

프로토타입과 폭포수모델에 위험관리가 추가된 형태로 볼 수있으며 비용이 많이 소요되는 대규모 장기 프로젝트에 적합

(성과를 확인해가며 조금씩 투자해 나갈 수 있기에 위험부담 감소) 하나, 모델이 상대적으로 복잡하여 프로젝트 관리 자체가 쉽지 않을 수 있음

출처 : https://blog.naver.com/search100/80097787566, 소심쟁이

 

 

진화단계

1) 계획수립(Planning) : 목표, 기능선택, 제약조건 결정

2) 위험분석(Risk Analysis) : 기능선택의 우선순위, 위험요소 분석

3) 개발(Engineering) : 선택된 기능의 개발

4) 평가(Evaluation) : 개발 결과 평가

 

 

 

V 모형 (Verificaiton model)

---

폭포수모형의 변형으로 개발된 제품에대한 검증 및 테스트가 강조된 모델로, 요구분석(시스템구조), 인터페이스, 모듈에 대한 검증이 이루어지며 이를 통해 궁극적으로 오류를 최소화하는 것이 목적

 

특히 생명과 연관되어 있거나, 한 번 출시되면 변경이 힘든 임베디드 분야의 경우 품질에 대한 높은 신뢰도가 더욱이 확보되어야 하기에 여러번의 검증절차를 거치는 V 모형을 채택할 필요 있음

 

다만 V 모델 역시 전체 사이클이 한 번만 돌기에 변경에 대한 유연성 떨어짐

 

 

 

 

 

일정중심 설계모형

---

사용자요구의 우선순위에 따라 중요한 기능부터 설계 및 구현함으로써 명시된 출시일정을 맞추기 위함

 

상대적으로 중요도가 낮아 출시에 포함되지 않을 기능까지 초기 단계에서는 분석 및 대략적인 설계가 이루어지므로 불필요한 시간낭비가 발생할 수 있음

 

 

 

 

 

진화적 출시 모형 (Evolutionary delivery model)

---

베타버전을 출시해 고객의 요구를 여러 사이클에 거쳐 반영하며 개선해 나가는 방법

 

프로토타이핑 모형이 제품의 대략적인 모양새 빠르게 바꾸어가며 가시적으로 보여줌으로써 고객 요구를 최대한 반영하기 위함이라면, 해당 모델의 경우 고객의 모든 요구를 모두 반영한다기보다 고객의 반응으로 바뀔 가능성이 적은 시스템 핵심에 초점을 맞추어 개발이 이루어지고 이후 반응을 봐가며 개선/확장해 나가는 방식

 

 

 

 

 

애자일 모형 (Agile model)

---

기존모델들이 계획수립과 문서화, 형식적 절차를 따르는데에 지나치게 많은 시간이 소요된다는 단점 극복을 위해 등장한 라이트 한 개발 방법론으로, 실질적인 코딩에 초점을 맞추어 일정기간 스토리 별로 빠르게 산출물을 만들어내어 그때그때 필요한 요구를 수정해 나가는 방식이기에 변화에 빠르게 대응하기 용이함

 

다만 초기 계획이나 전략수립이 구체화되어 있지 않기에 관리적 측면에서 비용(자본,인력,시간)에 대한 리스크 부담이 크며, 개발자 입장에서도 요구사항이 명확히 파악되지 않을 경우 불필요한 빈번한 수정으로 인하여 피로감 느낄 수 있음

 

대규모 프로젝트나 규모가 큰 조직보다는 비교적 소규모 조직이나 빠른 프로토타입을 만들어 볼 경우, 내지는 기존 전통모델이 효율적인 산출물을 내지 못할 때 도입해 봄으로써 문화적 변화를 도모해 볼 수 있음

 

 

 

모델선택

---

개발하려는 제품 목적과 특성, 규모 등에 따라 적절한 방법론을 선택(요구사항 변동에 대한 유연성, 오류 최소화 등)

한 가지 모델만이 아니라 여러 모델을 프로젝트 특성에 맞게 적절히 혼합도 가능

 

 

 

 

 

 

 

 

[참고]

 

https://needjarvis.tistory.com/147

위험을 최소화하는 SW 개발 프로세스, 나선형(Spiral) 모형, 모델

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=k97b1114&logNo=140165417042 

점증형 모형