Ch02. 소프트웨어 프로세스

▶2주차 필기 내용

Ch02. 소프트웨어 프로세스

[소프트웨어 프로세스] -소프트웨어 시스템을 개발하는데 관련된 활동의 집합 -다양한 유형의 시스템 개발에 적용 가능한 ‘보편적’ 소프트웨어 공학 기법 존재 X [기본적인 소프트웨어 공학 활동] -소프트웨어 명세화(specification) : 요구사항 분석 -소프트웨어 개발(development) : 설계/구현 -소프트웨어 검증(validation) : 테스팅 -소프트웨어 진화(evolution) : 유지 보수 [프로세스 설명에 포함되어야 하는 것] - WHAT(제품/산출물), WHO(역할), WHEN(순서/절차), HOW(기법/노하우/방법론) 1. 제품(product), 산출물(deliverable/artifect) - 프로세스 활동의 결과물 - 명세화, 설계, 구현, 테스팅 2. 역할(role) - 프로세스에 참여하는 사람들의 책임 - 프로젝트 관리자, 형상(버전) 관리자, 프로그래머 3. 사전/사후 조건(pre/post condition) - 프로세스 활동이 이루어지거나 제품 만들어지는 전후 만족되어야 하는 조건 [소프트웨어 프로세스 종류] -대부분의 실제 프로세스는 계획주도와 애자일 접근법을 둘 다 포함함 ▶[‘계획주도’ 프로세스] : plan-driven -모든 프로세스 활동을 미리 계획하여 계획 대비 실적을 측정 -안정성 O ▶[‘애자일‘ 프로세스] : agile -계획을 점증적으로 세우고 고객 요구 반영하여 프로세스 간단히 변경 -유연성 O/ 쉽게 변경 O

---

  2.1 소프트웨어 프로세스 모델들

[소프트웨어 프로세스 모델]

-실제 대부분의 대형 시스템 개발 프로세스는 이들 모델의 요소를 포함

폭포수 모델 (waterfal)	-계획주도 프로세스 -명세화/개발/검증/진화를 개별적 프로세스 단계로 구분함
점증적 개발 (incremental)	-계획주도 or 애자일 -명세화/개발/검증 활동이 ‘중첩’. 반복됨 -시스템은 이전 버전과 비교하여 기능을 추가하면서 일련의 증분(incremental)으로 개발함
통합 및 설정 (integration and configuration)	-계획주도 or 애자일 -‘재사용’ 할 수 있는 기존의 부품 설정 통합하여 개발

 

▶ [폭포수 모델]

-폭포수 모델은 ‘단계’로 구분됨

요구사항 분석 및 정의	-시스템의 서비스, 제약조건, 목표를 설정하여 ‘문서화’ (시스템 명세서 작성)
시스템 및 소프트웨어 설계	-시스템 아키텍처(전체 구조) 수립, -소프트웨어 구성요소 추상화와 이들 간의 관계
구현 및 단위 테스팅	-소프트웨어 설계를 프로그램으로 실체화 -단위 테스팅에서 각 단위가 명세에 맞는지 확인
통합 및 시스템 테스팅	-프로그램 단위를 통합하여 완전히 시스템으로서 테스트하고 요구사항 충족 여부 확인
운영 및 유지보수	시스템 설치되고 사용됨 오류수정, 구현을 개선, 새로운 요구사항 반영

   <폭포수 모델의 특징>

-원칙적으로 각 단계의 결과로 하나 이상의 산출물(문서) 나와야 함

-이전 단계 끝나기 전까지 다음 단계 시작X

   <실제 소프트웨어 개발은 각 단계가 중첩됨>

-한 단계(구현/설계)에서 다르 단계(설게/요구사항)로의 피드백이 일어남

-이전 단계의 문서를 수정하게 되면 프로세스 지연 발생

-추가 변경 반영하지 않도록 명세서 확정

-변화하는 고객 요구사항에 대응 어려움

  <폭포수 모델 적용 가능 분야>

-변경 적고, 요구사항 이해도가 높으며 요구사항 변경 제한된 분야

-임베디드 시스템 :하드웨어와 연동해야 하므로 구현 시까지 의사 결정 못 미룸

-중대한 시스템 : 명세 설계에 대한 분석, 검토가 필요함

-대규모 소프트웨어 시스템: 여러 회사, 장소에서 개발하므로 완성된 명세서가 필요

    <폭포수 모델 적합 X 예>

-자유로운 팀 커뮤니케이션 가능. 요구사항 빠르게 변화

-> 이 경우는 반복적 개발/애자일 방법이 더 적합

 

▶ [점증적 개발] : incremental development

-초기구현 -> 사용자 피드백 받아서-> 여러 버전을 거쳐 진화하는 방식으로 요구한 최종 시스템을 개발하는 것

-명세/개발/검증 명확 구분X, 각 단계가 중첩되어 있음 O

-요구사항 쉽게 변하는 시스템 개발에 적합. 변경에 대처 쉬움

-시스템의 각 증가분(버전)은 고객이 필요로 하는 기능 일부를 포함

-초기증가분은 가장 중요하거나 긴급하게 요구되는 기능을 포함시켜놓음

    <장점>

-요구사항 변경 구현 비용 줄어듬

-이미 개발된 내용에 대해 고객 피드백 받기 쉬움

-모든 기능 개발 전에 유용한 소프트웨어를 고객에게 전달하여 설치, 사용 가능하게 함

 

    <문제점>

-프로세스가 가시적이지 않음

-새로운 증가분 추가됨에 따라 시스템 구조 저하되는 경향 있음

-대규모 시스템 개발에는 부적합

---

   2.2 프로세스 활동

[프로세스 활동]

-실제 소프트웨어 프로세스는 명세, 설계, 구현, 테스팅 등의 활동이 중첩되어 있음

-기본 프로세스 활동 : 명세화/개발/검증/진화

-개발 프로세스마다 기본 활동이 다른 방식으로 구성됨

-폭포수 모델은 순차적으로 구성

-점증적 모델에서는 중첩되어 있음

 

[1. 소프트웨어 명세화]

▶[요구 공학] (requirements engineering) : 요구사항 도출해내는 과정

-시스템이 제공해야 하는 서비스를 이해하고 정의하며 시스템의 운영과 개발에 대한 제약 조건을 찾아내는 프로세스

-요구공학 이전에 **타당성 조사(할까 말까) 나 마케팅 조사 수행할 수 있음

 

▶[요구 공학 프로세스 주요활동]

요구사항 도출과 분석 (requirements elicitation and analysis)	-기존 시스템 관찰, 사용자와 토의, 업무 분석 등을 통해 요구사항 도출
요구사항 명세화 (requirements specification)	-요구사항 문서 작성(사용자 요구사항, 시스템 요구사항)
요구사항 검증 (requirements validation)	-요구사항의 현실성/일관성/완정성 검사

 

 

[2. 소프트웨어 설계 및 구현]

▶소프트웨어 설계/구현

-시스템 명세로부터 실행 가능한 시스템으로 변환하는 프로세스 (What 으로부터 How)

 

[설계 프로세스 활동] : Design activities

▶아키텍처 설계

-시스템의 전체적 구조

-주요 컴포넌트(서브 시스템)와 이들 간의 관계를 식별

▶데이터베이스 설계

-시스템 데이터 구조 설계. 기존 데이터베이스 사용하는 경우를 고려

▶인터페이스 설계

-컴포넌트 간 인터페이스 정의

-인터페이스 명세 있으면 컴포넌트 개별적 설계 가능

▶컴포넌트 선택 및 설계

-재사용 가능 컴포넌트 찾음

-새로운 컴포넌트를 설계

 

[시스템 설계]

-설계와 구현 중첩되는 경우 多

-프로그래밍은 개별적 활동

-테스팅과 디버깅

: 개발한 코드는 단위 테스팅 필요

: 테스팅으로 결함의 존재 확인

: 디버깅은 결함의 위치 찾아 수정 작업

 

[3. 소프트웨어 검증]

▶[검증 및 확인] : V&V (verification & validation)

-시스템이 명세 준수하는지(검증), 시스템이 고객 기대 충족하는지(확인)

-테스팅은 주요한 검증 기법

▶[테스팅 프로세스 단계]

1. 컴포넌트 테스팅( =단위 테스팅. Unit 테스팅)

-개별 컴포넌트(함수,객체 등)를 테스팅

2. 시스템 테스팅

-컴포넌트를 통합하여 시스템 구성하고 이를 테스팅

-컴포넌트 간 예기치 못한 상호작용과 인터페이스 문제 등을 찾음

-기능적/비기능적 요구사항 만족 여부, 창발적 시스템 속성을 테스트

3. 고객 테스팅

-고객의 실제 데이터를 이용하여 테스트

 

[V 모델]

-테스트 계획이 테스팅과 개발 활동 사이를 어떻게 연결하는지 보여줌

-소프트웨어 검증 활동이 폭포수 모델의 각 단계에 대응되는 것을 알 수 O

 

[4. 소프트웨어 진화] : Software evolution

[소프트웨어 진화]

▶소프트웨어의 유연성(flexibility)

-크고 복잡한 시스템이 만들어짐

-소프트웨어 변경은 하드웨어 변경에 비해 쉬움

▶요구사항이 변화하므로 소프트웨어도 진화하고 변경되어야 함

▶개발과 유지보수의 구분이 줄어들고 있음

-완전히 새로 만든 소프트웨어 시스템은 거의 X

-요구사항 변화를 지속적으로 반영하면서 소프트웨어가 진화

---

   2.3 변경 처리

-소프트웨어 프로젝트에서 변경은 불가피

<변경 처리/시스템 요구사항 변화를 위한 2가지 방법> 1. 시스템 프로토타이핑 2. 점증적 인도

-재작업은 개발 비용을 증가시키므로 재작업 비용 줄이는 것 필요

 

[1. 프로토타이핑]

▶[프로토타입] : prototype

-특수 목적을 가진 소프트웨어 시스템의 초기 버전 (시연용)

-아이디어 시연, 설계 옵션 시도, 문제점과 해결책 찾음

▶[프로토타입 용도]

⇒ 요구 공학 프로세스

-요구사항 도출과 검증에 도움

-프로토타입 사용해보며 아이디어 얻음

⇒ 설계 프로세스

-설계 문제에 대한 해결책 찾음. 설계의 타당성 확인 위해 실험

-사용자 인터페이스 개발

[2. 점증적 인도]

-점증적 인도 : 개발을 마친 증가분 일부를 고객에게 전달함으로써 고객의 업무 환경에서 사용할 수 있도록 배포하는 것.

---

   2.4 프로세스 개선

*프로세스 개선: 기존 프로세스 이해 후 이 프로세스를 바꾸어 제품 품질 향상시키거나 개발 시간 단축시키는 활동

[프로세스 개선/변경 기법]

1. 프로세스 성숙도 접근법

2. 애자일 접근법

 

[프로세스 성숙도 모델 수준]

1. 초기(initial)

2. 관리(managed)

3. 정의(definde)

4. 정량적 관리(quantitatively managed)

5. 최적화(optimizing)

[소프트웨어 공학]  한티 미디어 10판 교재