[소프트웨어공학]소프트웨어 프로세스

소프트웨어 프로세스

소프트웨어 시스템을 개발하거나 유지보수할 목적으로 수행되는 활동 일체 또는 절차

활동: 누가 언제하는 지와 어떤 결과물을 만드는가?

개발 조직은 적당한 프로세스 모델을 보유하여 공통의 개발 문화와 공통의 기술을 제공해야 함

 

프로세스 모델이 존재해야 하는 이유

- 전체 프로세스의 이해에 도움을 줌

- 구조화된 방법을 개발에 적용

- 자원 사용에 대한 사전 계획을 가능하게 함

- 자원 사용을 통제할 수 있음

- 시스템 개발 과정을 추적하고 관리할 수 있음

 

프로세스 모델 선택 시 고려 사항

- 개발 조직마다 프로세스가 다름

- 프로젝트 유형에 따라 다름

- 대형 시스템의 경우 부분마다 다른 프로세스를 적용

 

소프트웨어 명세 : 소프트웨어의 기능과 운영상 제약 조건을 정함

소프트웨어 개발 : 소프트웨어를 설계하고 프로그래밍 함

소프트웨어 검증 : 고객이 원하는 것을 수행하는지 검사함

소프트웨어 진화 : 소프트웨어를 변경함

 

폭포수 모델

선형 순차 모델

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

기본적으로 각 단계는 병행 수행되지 않고, 거슬러 반복되지 않으며 한 방향으로 진행

실제로 수정을 위한 재작업을 위해 앞 단계로의 피드백이 불가피

 

7단계

1. 타당성 조사
   투입 비용 대비 이익 평가 (조직 측면의 타당성, 경제적 타당성, 기술적 타당성, 운영의 타당성)
   시간적 제약과 정신적 압박감이 존재
   타당성 조사 보고서(문제의 정의, 기술적/경제적 타당성, 해결 방안과 기대 효과, 비용과 인도 날짜 등을 포함)
2. 요구 분석과 명세
   프로젝트의 성패를 좌우하는 중요한 단계
   요구사항? 문제의 해결을 위해 시스템이 갖추어야 하는 조건이나 능력, 요구사항 명세서나 계약서에 명시
   요구사항 명세서 SRS : 의뢰자와 개발자 간의 의사소통 수단으로 정확하고 일관성있으며 완전해야 함
   요구사항 명세서 구성 : 시스템의 목적과 범위(문제점을 구체적으로 기술하고 대안을 제시) + 기능적 요구사항, 비기능적 요구사항 + 기타 제약 조건 등
3. 설계와 명세
   'what'을 'how'로 변환하는 작업 : 요구사항들을 구현 작업에 적합하게 명확하고 조직화된 구조로 바꿈
   설계 단계의 구분(아키텍쳐 설계, 인터페이스 설계, 프로그램 설계)
   설계 방법 
     - 전통적 설계 방법
     - 객체지향 설계 방법
4. 코딩과 단위 테스트
   설계 결과를 프로그램으로 작성함
   구현된 모듈이 명세서를 만족하는지 테스트하여 확인
   고려사항 (코딩 표준의 준수-조직이 정한 레이아웃 주석의 사용 변수나 함수 이름 등, 테스트 절차의 준수, 코드 인스펙션-코드의 정적 분석 방법)
5. 통합과 시스템 테스트
   통합 테스트(모듈을 통합하여 점증적으로 시스템 구축)
   시스템 테스트(모든 모듈을 통합한 후 완성된 시스템이 요구사항을 만족하는지 확인)
   알파 테스트(소프트웨어 개발 현장에서 수행, 일반 소프트웨어의 경우 독립적 테스트 팀이 먼저 알파 테스트를 수행한 후 베타 버전을 릴리스 함, 주문형 소프트웨어의 경우 개발자 플랫폼에서 실제 사용 환경을 시뮬레이션한 후 개발자와 고객 사이에 제품의 인수에 대한 동의가 이루어질 때 까지 수행-인수 테스트)
   베타 테스트(고객의 실제 사용 환경에서 수행, 일반 소프트웨어의 제품 출시 전에 가망 사용자로부터 미리 제품을 평가 받음)
6. 인도와 유지보수
   실제 사용을 위해 고객에게 소프트웨어 배포 - 인도
   유지보수(소프트웨어 진화) : 고객이 사용한 후 폐기까지 일어나는 수정 및 보완 활동
   유지보수 노력이 적게 드는 소프트웨어를 개발하는 것이 중요
7. 유지보수의 종류
   수정 유지보수(오류 수정)
   적응 유지보수(변경된 환경- 법, .. 에 적응)
   완전 유지보수(기능 개선, 성능 향상)
   예방 유지보수(유지보수성을 높이기 위한 것)

장점

• 선형 모델로 단순하고 이해가 쉬움
• 단계별로 정형화된 접근 방법과 체계적 문서화 가능
• 프로젝트 진행 상황을 명확히 알 수 있음

단점

• 요구사항을 완벽히 작성해야 함
• 변경을 수용하기 어려움
• 시스템의 동작을 후반에나 볼 수 있음
• 대형 프로젝트에 적용하기 어려움
• 문서화를 위한 노력이 지나침
• 위험 분석 결여(대형 프로젝트의 경우 비용 낭비가 큼), 일정의 지연 가능성이 큼

반복진화형 모델

불안정한 요구사항으로 초기 버전을 만들고 요구사항을 정제하여 새로운 버전을 개발하는 작업을 반복하면서 시스템을 완성해 가는 방식

- 분명한 요구사항과 시스템의 범위를 정해질 때 까지 노력이 선행됨

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

- 최종 버전이 나온 후 유지보수 단계로 들어감

 

장점

• 요구사항이 완성되지 못한 경우에도 초기 버전을 만들고 점차적으로 명확한 요구사항을 도출함

단점

• 관리적 관점에서 개발 비용의 예상이 힘들고 재작업이 잦아지면 종료 시점이 늦춰질 가능성이 큼
• 공학적 관점에서 잦은 요구사항 변경은 소프트웨어 구조에 악영향을 주고 유지보수성이 떨어진다

점증적 모델과의 차이점

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

(개발이 진행되면서 요구의 변화를 수용함, 명확히 이해할 수 없는 새로운 기술을 적용할 때 사용, 한꺼번에 모든 기능을 포함해 인도해야 하는 경우에 사용)

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

(중요한 요구사항을 먼저 개발함, 조금씩 개발하면서 여러 번의 릴리스가 일어남)

 

프로토타이핑 방법

소프트웨어 요구사항을 파악하기 좋은 방법

시제품을 만들어 고객에게 피드백을 받을 수 있다.

 

종류

throwaway prototyping

- 프로토타입을 고객과의 의사소통 수단으로만 사용

- 요구가 확인되면 프로토타입을 버리고 새로 시스템을 개발함

evolutionary prototyping

- 잘 알고 있는 부분부터 시작해 발전시켜 완제품을 만듦

 

장점

• 프로젝트의 실현 가능성, 소프트웨어의 개발 가능성을 판단할 수 있음
• 개발자와 사용자 간의 의사소통이 명확해 짐
• 기능적 요구사항 외에도 성능이나 유용성 등을 품질 요구를 분명히 할 수 있음
• 시스템을 미리 사용함으로써 사용자 교육 효과가 있음
• 개발 단계에서 유지보수가 일어나는 효과가 있음

단점

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

점증적 모델

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

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

- 각 모듈을 증분(increment)이라 함

- 핵심 모듈을 먼저 개발하고 인도함

요구사항 개요 정의 ->

요구사항들을 증분에 배정 ->

시스템 구조 설계 ->

증분을 개발 -> 증분을 확인 -> 증분을 통합 ->

시스템 확인 -> (미완성 시스템)최종 시스템

장점

• 중요한 증분이 먼저 개발되므로 사용자는 시스템을 이른 시기에 사용해볼 수 있음
• 릴리스 방식이 요구사항 변화에 대응하기 용이함
• 증분들은 점차로 규모와 기능이 축소되어 관리가 어렵지 않음
• 먼저 개발되는 중요 부분이 반복적으로 테스트됨

단점

• 기능적으로 분해하기 어려울 수 있음
• 적당한 크기의 증분들로 나누기 어려움
• 증분을 개발하기 전에 명확한 요구사항을 정의해야 함

나선형 모델

반복 진화형 모델의 확장 형태

전체 생명주기에 위험분석과 프로토타이핑을 계획하고 사용하여 위험을 최소화한다

가장 중앙의 원을 타당성 조사 단계, 다음 원을 요구사항 정의 단계, 그 다음 원을 설계 단계로 ... 하고 각 단계는 목표와 대안의 결정, 대안의 평가(위험 요소 분석), 개발과 확인, 다음 단계의 계획으로 구성된다

위험 관리를 지원하는 프로세스의 프레임워크

위험 관리에 비용이 들지만 가치가 있음

실험적이고 복잡한 대형 프로젝트에 적합(경험이 없는 프로젝트)

 

장점

- 대형 프로젝트에서 위험 관리를 통해 성공 가능성을 높일 수 있음

- 프로젝트 특성이나 개발 조직에 맞게 변형될 수 있음

단점

- 경험이 부족하여 충분히 검증되지 못함

- 모델 자체가 복잡

- 프로젝트 관리가 어려움

 

V 모델

폭포수 모델의 확장 형태로 생명주기 단계별로 상응하는 테스트 단계가 존재

아래 방향으로 진행하다가 코딩 단계를 거치면서 위로 향함

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

 

각 개발 단계의 작업을 확인하기 위해 상응하는 테스트 작업을 수행

생명 주기 초반부터 테스트 작업 지원

폭포수 모델에 비해 반복과 재처리 과정이 명확함

테스트 작업을 단계별로 구분하므로 책임이 명확함

 

애자일 방법 Agile

변화를 수용하고, 협업을 강조하며 제품의 빠른 인도를 강조하는 반복적 개발 방법(개발론)

문서화 작업보다 코드를 강조, 문서보다 소프트웨어 자체를 중요시 함

요구사항의 변화는 불가피하고 이것에 대응하는 것이 현실적

기존의 개발 프로세스는 설계 기간이 길며 재작업시 오버헤드가 크다는 생각

환경의 빠른 변화에 대응하고 빠른 인도가 중요하다

 

애자일 선언문 Agile Manifesto: 개개인 상호작용이 중요, 작동하는 SW가 중요, 고객과의 협력, 변화에 대응이 중요

요구사항이 바뀌기 쉬운 중소형의 비즈니스 시스템, 전자 상거래 응용에 적합

 

익스트림 프로그래밍 XP

XP는 대표적인 애자일 방법

좋은 실천 지침들을 적극적으로 적용할 것

매우 잦은 수행, 빠른 개발, 반복

 

- 작고 빈번한 릴리스 -> 빠른 피드백과 지속적 개선

- 고객도 개발 팀의 일원

- 프로세스 중심이 아닌 사람 중심의 작업과 짝 프로그래밍

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

- 코드의 품질 개선을 위해 리팩토링 제안

 

짝 프로그래밍

두 사람이 짝이 되어, 한 사람이 코딩을 다른 사람은 검사를 수행 (30분마다 역할을 바꿈)

장점

- 코드에 대한 책임 공유

- 비형식적 검토를 수행

- 코드 개선을 위한 리팩토링을 장려함

- 생산성이 떨어지지 않음

 

테스트 선행 개발

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

테스트 별로 테스트 케이스를 만듦

    요구사항은 스토리카드로 표현되고 스토리 카드는 태스크틀로 분해됨

    요구사항과 코드와의 관계가 명확해 짐

통합 테스트를 강조하며 통합 과정에서 기존 소프트웨어에 오류가 유입되지 않도록 함

    기존 테스트 케이스의 재사용(오염되지 않은 것이 증명된)

 

스크럼

애자일 개발 과정의 관리에 초점

프로젝트 관리 프레임워크 또는 소프트웨어 개발 프로세스의 프레임워크

계획과 스프린트의 반복으로 이루어짐

프로젝트 계획(제품 백로그: 우선순위의 목록)

스프린트 사이클(스프린트마다 백로그 일부를 가져와 수행)

    제품 증분을 개발하는 작은 프로젝트

    3~9명의 스크럼 팀에서 한 달 이내로 개발

    스프린트 계획(스프린트 백로그에서 이번 사이클에서 개발해야하는 목록을 가져옴)

    일일 스크럼 회의

    스프린트 리뷰와 회고

스크럼 팀의 구성 : 개발팀, 제품 책임자, 스크럼 마스터(프로젝트 관리자)