0. 들어가기 앞서
이번 포스트는 필자가 '소프트웨어 공학' 강의에서 필기한 내용, 교수님의 강의록을 기반으로 정리하여 작성하는 것이다 보니 논리적 비약이나 오류가 있을 수도 있습니다. 혹시 잘못된 내용이 있다면 종류를 막론하고 피드백 부탁드립니다.
1. 소프트웨어 개발 프로세스
-목적: 질(Quality), 생산성(Productivity)
-프로세스(Process): 목표 달성을 위해 수행되는 순차적 단계
-소프트웨어 (개발) 프로세스: 예산과 일정 내에 고품질의 소프트웨어를 생산하기 위한 순차적 단계
-소프트웨어 프로세스 모델의 종류: Waterfall and V-Model, Prototyping, Iterative Development, Rational Unified Process(RUP), Agile 등
2. Waterfall and V-Model(폭포수 모델, V-모델)
-Waterfall Model(폭포수 모델)
-고전적 형태의 소프트웨어 개발 프로세스
-이전 단계가 완료 되었을 때만 다음단계로(피드백 없음)
-고객의 요구사항 파악과 사용할 기술 결정이 쉬울 때 사용
-장점: 간단하고 명확하게 문제를 독립적으로 실행될 구분된 개발 단계로, 계약 조직에서 관리가 쉬움
-단점: 요구사항이 이른 시간에 확정될 필요성이 있음, 각 단계 마무리에 문서가 요구됨, All or Nothing Delivery(위험부담이 큼), 피드백 수용과 변경이 어려움
-V-Model(V-모델)
-폭포수 모델의 확장 형태로 요구사항 분석과 각 디자인 단계에 상응하는 소프트웨어 테스트 존재
-장점: 높은 테스트 효율성, 소프트웨어 신뢰도/성능 상승
-단점: 폭포수 모델의 정형성
3. Prototyping(프로토타이핑)
-고객의 요구사항이 명확하지 않을 때(개발 초기), 시스템 모형을 간단히 만들어 사용자에게 보여 주고 피드백을 받음
-명확성(clarification)이 추가적으로 필요한핵심 기능(특징)만 빠르게(Quality 중요X)
-다른 소프트웨어 프로세스 모델의 일부로 사용됨
-장점: 요구사항이 구체적으로 안정화, 요구사항이 이른 시간에 확정될 필요성이 없음, 프로토타입 개발 경험이 Main 개발에도 도움
-단점: 추가적인 일정상 비용
4. Iterative Development(반복적 개발)
-폭포수 모델의 각 단계들을 반복적으로
-반복마다 소프트웨어의 점진적 발전(All or Nothing X => 위험부담 감소)
-고객이 빠른 응답을 원할 때 사용
-XP, Agile 등이 반복적 개발에 의존
-장점: 각 개발 주기마다 피드백이 가능(요구사항이 이른 시간에 확정될 필요성이 없음), 변경이 쉬움
-단점: 전체 개발 비용 증가, 시스템 Architecture가 복잡해질 가능성
5. Unified Process(UP)
-반복적 개발(위험 부담 감소), Architecture 중심 개발
-반복 각각마다 중점을 두고 개발하는 부분이 다름
-UP: UML 저자가 만든 오픈 소프트웨어 개발 프로세스
-RUP: UP의 상업적 버전
-UP 진행과정(4단계)
1. Inception Phase: 소프트웨어의 생명 주기 정의
2. Elaboration Phase: 안정적인 기본 Architecture 구축
2. Construction Phase: 효율적으로 소프트웨어의 나머지 기능 개발
4. Transition Phase: 고객이 수용가능한 소프트웨어 완성, 배포
6. Agile(에자일)
-반복적 개발, 짧은 개발 주기, 문서작업 최소화, 빠른 프로토타이핑, 미리 정해지지 않은 프로세스
-Agile Manifesto(에자일 선언문)
1. 공정과 도구보다는 개인과 상호작용을
-규범적 프로세스 보다는 팀 멤버 각각의 개발을 존중
2. 포괄적인 문서보다는 작동하는 소프트웨어를
3. 계약 협상보다는 고객과의 협력을
-고객은 적극적으로 개발 프로세스에 관여하여 요구사항의 우선순위를 제시하고 각 반복적 단계를 평가
-소프트웨어는 고객의 요구사항이 구체화되며 점진적으로 개발
4. 계획을 따르기 보다는 변화를 대응하기를
-시스템 요구사항은 언제나 변화할 수 있음을 인지하고 이를 수용할 수 있게끔 설계
-eXtreme Programming(XP): 반복적 개발의 'Extreme'(극단적) 에자일 모델
-최소한의 비지니스적 기능을 갖추도록 개발 후 점진적으로 기능을 추가하며 자주자주 배포
-새 기능을 구현하기 전 유닛 테스트 작성, 테스트 또한 데이터가 아닌 프로그램으로 자동화
-꾸준한 코드 리팩토링을 통해 코드의 단순화+유지보수(기능적 개선X)
-프로그래머가 짝을 이뤄 작업(Pair programming)하고 공동의 오너십(ownership)을 가짐
-고객 또한 개발팀의 멤버로 지속적으로 구현팀에게 요구사항을 전달해 주고 소프트웨어가 요구사항을 만족하는지 확인 해 줄 책임을 가짐
-고객 요구사항은 시나리오(scenarios)나 사용자 스토리(user stories)로 표현되며 개발자는 이를 태스크 단위로 쪼갬
각각의 소프트웨어 개발 프로세스는 장단점이 있으며 한가지만 고집하기 보다는 상황에 따라 적절한 소프트웨어 개발 프로세스를 채택하는 것이 중요!!