2022. 11. 27. 03:58ㆍOthers/SE
Code-And-Fix
-> SW 위기 초래
프로세스와 방법론
| 프로세스(Process) | 방법론(Methodology) | |
| 특징 | - 단계적인 작업의 틀을 정의한 것 - 무엇을 하는가에 중점 - 결과물의 표현에 대하여 언급 없음 - 패러다임에 독립적 - 각 단계가 다른 방법론으로도 실현 가능 |
- 프로세스의 구체적인 구현 - 어떻게 하는가에 중점 - 결과물을 어떻게 표현하는지 표시 - 패러다임에 종속적 - 각 단계의 절차, 기술, 가이드라인을 제시 |
| 사례 | - 폭포수 프로세스 - 나선형 프로세스 - 프로토타이핑 프로세스 - Unified 프로세스 - 애자일 프로세스 |
- 구조적 분석, 설계 방법론 - 객체지향 방법론 - 컴포넌트기반 개발방법론(CBD) - 애자일 방법론 |
- 프로세스: 어떤 일을 하기 위한 특별한 방법으로 일반적으로 단계나 작업으로 구성됨.
바람직한 프로세스의 특징
- 예측 가능성
- 테스팅과 유지보수 지원
- 변경 용이성
- 결함 제거 용이성
소프트웨어 생명주기(Life Cycle) : 소프트웨어 제품이 구상되기 시작하여 제품이 폐기될 때까지의 일련의 기간
폭포수(Waterfall) 모델
계획(Planning)
- 문제의 실현 가능성을 타진(Feasibility Study)
- 개발하고자 하는 시스템의 성격을 파악하여 비용과 기간을 예측 (Estimation)
- 개발 방법과 각 단계에 필요한 자원 결정
- 위험 분석 (Risk Analysis) : 시스템 개발 중 발생할 수 있는 위험 요소 분석 및 대처 방안 강구
- 일정 계획
- 관리 전략 수립
요구 분석(Requirements Analysis)
- 개발을 의뢰한 사용자 요구나 주어진 문제를 정확히 분석하고 이해하는 과정
- 요구사항 – 시스템이 가져야 할 능력(Capability)과 조건(Condition)
- What 의 단계: 무엇을 만들 것인가에 집중
- 응용 분야(도메인)에 집중
- 결과물: 요구분석서
설계(Design)
- How의 단계: 어떻게 만들 것인 가에 집중
- 솔루션에 집중
- 아키텍처,데이터베이스, UI 설계
- 결과물: 설계서
구현(Implementation)
- ‘Do it’ 단계: 미리 정해진 모듈 설계에 따라 프로그래밍을 수행
- 코딩과 단위 테스트
시험(Testing)
- 각 모듈이 정의된 인터페이스에 따라 잘 동작하는지 통합해 가면서 테스트 수행
- 통합은 개발자가 주로 담당하고, 테스트는 품질보증팀이 주로 담당
- 알파 테스트(Alpha Test): 개발 기관 내부에서 실제 사용해보는 시험
- 베타 테스트(Beta Test): beta version에 대해 선택된 고객을 대상으로 실제 사용해보는 시험
인수/설치와 유지보수
- 시스템의 타입에 따라 다른 설치 방법
- 인수 설치와 유지보수
폭포수 모델의 특징
- 각 단계가 다음 단계 시작 전에 끝나야 함
- 각 단계별로 특정 산출물이 정해짐 (Document-driven approach)
- 순서적 - 각 단계 사이에 중복이나 상호작용이 없음
- 단순하거나 개발자가 응용 분야를 잘 알고 있는 경우 적합
- 결과물 정의가 중요
장점
- 프로세스가 단순하여 초보자가 쉽게 적용 가능
- 중간 산출물이 명확하여 프로젝트 관리 용이
단점
- 계획, 분석, 설계의 처음 단계를 지나치게 강조하면 후반부 단계인 코딩, 테스트가
지연될 수 있음
- 각 단계의 전환에 많은 노력이 요구됨
프로토타이핑 모델(Rapid Prototyping Model)
Quick and dirty 방식
장점
- 사용자의 의견 반영이 잘 됨
- 사용자가 더 관심을 가지고 참여할 수 있고 개발자는 요구를 더 정확히 도출할수 있음
단점
- 프로토타입이 시스템의 전부라고 오해할 수 있음
- 관리가 어려움
진화적 모델(Evolutionary Model)
한 번의 릴리스(Release) 대신 다수의 릴리스를 통해 소프트웨어 개발, increment가 증가할 수록 기능이 추가됨
요구사항이 분할되고 우선순위가 높은 요구사항이 먼저 개발된 후 릴리스 됨
개발 사이클이 짧은 환경
점증적(Incremental) 방법 – 기능별로 릴리스
반복적(Iterative) 방법 – 릴리스 할 때마다 기능의 완성도를 높임
프로젝트 실패에 대한 위험을 낮출 수 있음
나선형(Spiral) 모델
risk-driven process model
소프트웨어의 기능을 나누어 점증적으로 개발
여러 번의 점증적인 릴리스(Incremental Releases)
계획 수립(Planning): 목표, 기능 선택, 제약 조건의 결정
위험 분석(Risk Analysis): 기능 선택의 우선순위, 위험요소의 분석
개발(Engineering): 선택된 기능의 개발
평가(Evaluation): 개발 결과의 평가
장점
- 대규모 시스템 개발에 적합 - risk reduction mechanism
- 반복적인 개발 및 테스트 - 강인성 향상
- 한 사이클에 추가 못한 기능은 다음 단계에 추가 가능
단점
- 관리가 중요
- 위험 분석이 중요
- 적용이 쉽지 않음
V 모델
폭포수 모델의 변형
- 시스템 검증과 테스트 강조
- 폭포수 모델에서는 감추어져 있는 반복과 재 작업을 드러냄
- 작업과 결과의 검증에 초점
검증과 테스트를 강조하므로 오류를 줄일 수 있음
반복 과정이 없어 변경을 다루기가 쉽지 않음
신뢰성이 높이 요구되는 응용 분야에 적용
Unified 프로세스
UML과 관련된 프로세스 모델로 RUP(Rational Unified Process)라고도함.
4단계(Phase)로 구성
- 도입(Inception) :최종제품과 프로젝트의 전반적인 범위를 정의하고 관련된 비즈니스 비전 정의
- 정련(Elaboration) : 산출물을 정제하고 구조를 정의하며 개발 및 배치를 위한 정확한 계획을 수립
- 구축(Construction) : 시스템 설계, 프로그래밍, 테스팅 작업
- 전환(Transition) : 운영 환경에 시스템 배치
아키텍처 중심, 반복적, 점증적인 모델
Agile 프로세스의 특성
Modularity : 애자일 프로세스는 모듈화되어 여러 개의 activity로 나눌 수 있음
Iterative : 짧은 사이클 안에서 하나의 activity를 완성시키면서 반복적으로 프로젝트를 수행함
Time-bound : 반복 주기를 1 ~ 6주 가량으로 정하고 프로세스 진행
Incremental
Convergent(수렴성) : 주어진 제약사항 범위에서, 프로젝트 수행 시 발생하는 risk에 대해 능동적으로 대처함
People-oriented
Collaborative
관리 프로세스 :비용과 품질 목표를 달성하기 위하여 프로젝트를 관리하는 데 필요한 모든 작업, 계획, 모니터링과 제어, 분석
품질 보증 (Quality Assurance, QA) 프로세스
인스펙션 프로세스
형상 관리(Configuration Mgmt) 프로세스
소프트웨어 개발방법론
구조적 방법론
- 실 세계의 문제를 처리(Process) 중심으로 모델링
- 자료 흐름도
- 구조도
객체지향 방법론
- 실 세계의 문제를 객체(Object) 중심으로 모델링
- UML
애자일 방법론
- 점증적인 프로세스를 채택
- 짧은 반복 주기를 반복하며 점증적으로 자주 출시
- 익스트림 프로그래밍(eXtreme Programming, XP)
- 스크럼(Scrum)
- 기능 중심 개발(Feature Driven Development, FDD)
익스트림 프로그래밍(eXtreme Programming, XP)
- 사용자 스토리(User Story)
- 매일 빌드와 통합
- 테스트 주도 개발(Test-Driven Development)
- 페어 프로그래밍(Pair Programming)
Scrum (스크럼)
- 개발 팀원 모두가 함께 소통하고 협력하여 짧은 주기를 반복하며 소프트웨어를 개발하는 작업, 역할, 결과물
- 백로그를 정하고 여기에 우선순위를 부여
- 짧은 주기(스프린트)