소프트웨어 프로세스

프로세스 활동

- 명세 : 기능과 제약 조건

- 개발 : 설계, 프로그래밍

- 검증 : 요구 사항 충족

- 진화 : 고도화, 변경

 

폭포수 모델

- 고전적 소프트웨어 생명 주기

- 각 단계는 병행 수행 X, 한 방향으로 진행됨

- 수정을 위한 앞단계로의 피드백이 필수

 

폭포수 흐름

- 타당성 조사

 

- 요구 분석과 명세 : 명세서(SRS), 시스템의 목적과 범위, 기능적 요구사항, 비기능적 요구사항, 기타 제약 조건 등

 

- 설계와 명세 : what 을 how 로 변환하는 작업,

   아키텍쳐 설계, 인터페이스 설계, 모듈 설계 등, 객체지향 설계 방법, 전통적 설계 방법(구조적 분석)

 

- 코딩과 단위 테스트 : 구현된 모듈이 명세를 만족하는지 테스트, 코딩표준의 준수, 테스트 절차의 준수, 코드 인스펙션(눈으로 검사, 정적 분석)

 

- 통합과 시스템 테스트 : 통합 테스트, 시스템 테스트

  알파테스트 : 소프트웨어 개발 현장에서 수행한다. 주문형 소프트웨어의 경우, 고객의 인수에 대한 동의가 이루어질 때 까지 반복 수행

  베타테스트 : 고객의 사용 환경에서 수행, 가망 사용자로부터 평가 받음

 

- 인도와 유지보수 : 고객에게 소프트웨어를 배포 하는 것

   유지보수의 종류 : 수정, 적응, 완전(기능 개선, 성능 향상), 예방(유지보수성 향상)

   

장단점

- 선형 모델, 단순하고 이해 쉬움

- 정형화된 접근 방법

- 진행 상황 명확함

 

- 변경을 수용하기 어려움

- 시스템의 동작을 후반에나 볼 수 있음

- 대형 프로젝트는 어려움

- 문서화 힘듬, 위험 분석 결여

 

 

반복진화형 모델

- 초기 버전을 만들고 요구사항을 정제하며 새로운 버전을 개발하며 반복

- 한 번의 진화 단계에서 프로토타이핑을 통해 요구사항을 보완

 

장단점

- 요구사항을 완성 하기 전 초기 버전을 만들며 명확한 요구사항을 도출

 

- 관리적 관점에서 예상이 힘들고 재작업이 잦아짐

- 공학적 관점에서 잦은 수정작업은 악영향을 주어 문제가 생기기 마련

 

점증적 모델과 차이점

- 반복 진화형 모델 : 요구사항이 불안정하고 명확하지 못할 때

   요구의 변화, 새로운 기술 적용, 한꺼번에 모든 기능을 포함해 인도해야 할 때

 

- 점증적 모델 : 요구사항의 중요도에 따라 나누고 작업 순서를 정함

   조금씩 개발하며 여러 번의 릴리스가 일어남

 

프로토타이핑 방법

사용자와 개발자도 미리 예측하는 데에는 한계가 있음.

- 빠른 계획 > 빠른 설계 > 프로토타입 > 실행과 피드백 > 반복

 

종류

- throwaway : 프로토타입을 고객과의 의사소통 수단으로 사용, 요구 확인 시, 버리고 새로 시스템 개발

- evolutionary : 잘 알고 있는 부분부터 시작하여 계속적으로 발전시켜 완제품을 만듬

 

장단점

- 실형 가능성 판단 가능

- 의사소통 명확함

- 성능과 유용성 등을 품질 요구에 분명히 할 수 있음

- 사용자에게 교육 효과

- 개발 단계에서 유지보수가 일어나는 효과

 

- 문서화가 힘들며, 관리자는 진척사항을 제어하기 힘듬

 

점증적 모델

- 여러개의 모듈들로 분해하고 점증적으로 개발하여 인도하는 방식

- 선형 순차 모델을 여러 번 적용하고 그 결과를 조합

- 요구사항 정의 > 시스템 구조 설계 > 모듈 개발, 확인, 통합, 시스템 확인 반복

 

장단점

- 핵심 시스템을 이른 시기에 사용

- 요구 사항 변화에 대응

- 중요 부분이 반복적으로 테스트

 

- 기능적으로 분해 난이도 증가

- 명확한 요구사항을 정의해야함

 

나선형 모델

반복 진화형 모델의 확장형

- 위험분석과 프로토타이핑을 계획하고 사용하여 위험을 최소화

- 가장 중앙의 원을 타당성 조사 단계, 다음 원은 요구사항 정의 단계, 다음 원은 설계 단계 ~

 

장단점

- 대형 프로젝트에서 위험 관리를 통해 성공 가능성

- 특정이나 개발 조직에 따라 변형 가능

 

- 현 시점 경험이 부족하여 검증되지 못한 모델

- 모델 자체가 복잡하고 시간 비용이 많이 소요 됨

 

 

V 모델

- 폭포수 모델의 확장 형태, 생명주기 별 테스트 단계가 존재

- 테스트 작업을 중요시하여 적정 수준의 품질 보증

 

코드 뿐 아니라 요구사항 설꼐 결과도 테스트 가능해야 함

테스트 작업을 단계별로 구분하므로 책임이 명확해 진다.

 

 

애자일 방법

- 변화, 협업, 제품의 빠른 인도를 강조하는 개발 방법

- 문서화(설계)보다 소프트웨어(코딩) 자체를 중요 시 하낟.

 

애자일 선언문 : 개개인/상호작용, 작통하는 SW, 고객과의 협력, 변화에 대응

요구사항이 자주 바뀌거나, 전장 상거래 응용

 

익스트림 프로그래밍(XP)

- 대표적인 애자일 방법의 하나

- 좋은 실천 지침을 적극적으로 적용할 것을 주문

 

- 빠른 피드백과 지속적 개선

- 고객도 개발 팀의 일원이 됨, 요구사항 개선

- 프로세스 중심 X, 사람 중심의 작업과 짝 프로그래밍

- 단순한 설계, 테스트 선행 개발

- 품질 개선을 위한 리팩토링을 제한

 

짝 프로그래밍

- 한 사람이 코딩을, 다른 사람은 검사를 수행, 정해진 시간마다 역할을 바꿈

- 책임 공유, 비형식적 검토, 리팩토링을 장려함, 생산성이 떨어지지 않음

 

테스트 선행 개발 TDD

- 테스트 케이스를 먼저 작성하고, 이것을 통과하는 코드를 만들 것

- 요구사항은 스토리 카드로 표현되고, 스토리 카드는 테스트들로 분해됨

- 통합 테스트를 강조, 기존 테스트 케이스의 재사용

 

스크럼

- 애자일 개발 과정의 관리에 초점을 둔 프로젝트 관리 프레임워크 or 소프트웨어 개발 프로세스의 프레임워크

- 스크럼 프로세스는 계획과 스프린트의 반복으로 이루어짐

백로그 : 우선 순위 요구사항의 목록

 

프로젝트 계획(제품 백로그)

스프린트 사이클

-  한달 내로 개발  > 스프린트 계획(스프린트 백로그) >회의 > 리뷰와 회고 > 반복

팀의 구성

- 개발팀, 제품 책임자, 스크럼 마스터