소프트웨어 공학 (Software Engineering ) 프로세스 문양세 강원대학교 IT 대학 컴퓨터과학전공

1. 소프트웨어 공학 (Software Engineering) 프로세스 문양세 강원대학교 IT대학 컴퓨터과학전공

2. In this chapter … 프로세스 • We will cover … • 소프트웨어 프로세스 • 바람직한 프로세스의 특징 • 소프트웨어 개발 프로세스 모델 • 지원 프로세스

3. 프로세스 프로세스 • 정의 • 어떤 일을 하기 위한 특별한 방법으로 일반적으로 단계나 작업으로 구성됨(웹스터 영어 사전) • 운영체제에서의 프로세스? • 소프트웨어를 개발하는 과정, 즉 작업 순서 • 순서제약이 있는 작업의 집합 (작업이 순서 제약에 따라 수행됨) • 원하는 결과  높은 품질과 생산성이 목표 • 프로세스가 없는 개발 • Code-and-Fix

4. Code-and-Fix 문제점 프로세스 • 요구나 설계 작업의 중요성을 깨닫지 못함 • 즉흥적인 방법으로는 사용자의 높은 요구 수준에 도달하기 어려움 • (요구 수준 도달을 위해) 계속 고치는 작업이 필요 • 신중하게 잘 설계하지 않으면 소프트웨어 구조가 나빠짐 • 즉흥적인 방법은 설계를 “해도 되고 안 해도 되는” 작업이므로 잘 설계되지 않음 • 계획이 없어 작업의 목표가 없음 • 일을 한 후에도 잘한 것인지 못한 것인지 판단할 수가 없음 • 비용과 일정의 조절을 할 수가 없음 • 체계적인 테스트 작업이나 품질 보증 차원의 활동에 대한 인식이 없음 • 발견되지 않은 결함이 남아 계속 고치게 됨 • 시스템이 더욱 악화

5. In this chapter … 프로세스 2.1 소프트웨어프로세스 2.2 바람직한 프로세스의 특성 2.3 소프트웨어 개발 프로세스 모델 2.4 지원 프로세스

6. 소프트웨어 프로세스 프로세스 • 소프트웨어 개발에 대한 기술적, 관리적 이슈를 다루는 작업 • 여러 가지 다른 타입의 작업이 소프트웨어 개발을 위해 수행됨 이들 작업을 모아서 소프트웨어 프로세스라 칭함 • 여러 작업이 서로 다른 목적을 가지며, 여러 사람들에 의해 수행됨 소프트웨어 프로세스는 개발 모델(내용)에 따라 여러 컴포넌트 프로세스, 즉, 여러 부프로세스가 존재

7. 프로세스와 프로세스 모델 프로세스 • 소프트웨어 프로젝트 • 비용, 일정, 품질의 세 목표의 예상치 달성을 위해, “수행할 작업을 조직화한 프로세스”를 이용 • 결국, 비용, 일정, 품질에 대한 목표를 성취하는 것 • 프로세스 명세 • 프로젝트에서 수행하여야 하는 작업과 이들의 수행 순서를 정의 • (실제 작업이 수행되는) 실행 프로세스는 다를 수 있음 • 프로세스 모델 • 일반적인 프로세스를 기술한 것 (generic process, 예: 폭포수 모형) • 작업의 단계와 순서, 각 단계 수행의 제약사항이나 조건 등을 모아 놓은 것 • 프로세스(혹은 프로세스 명세)는 프로세스 모델의 인스턴스(instance)로 이해 가능

8. 프로세스의 종류 프로세스 • 프로젝트의 중심 프로세스 • 개발 프로세스: 실제 수행해야 할 개발과 품질 보증 작업에 해당 • 관리 프로세스: 비용, 품질, 기타 목표를 맞추기 위한 계획, 제어 작업에 해당 • 기타 프로세스 • 형상 관리 프로세스: 변경을 관리하여 제품의 일관성을 유지 • 프로세스 관리 프로세스: “프로세스”도 변하는 것으로, “프로세스” 자체를 관리하는 프로세스  소프트웨어 프로세스 개선이 목적임

9. 프로세스의 정의 프로세스 • 작업 결과와 검증 조건을 명확히 정의하여야 함 • 각 단계의 결과를 명확히 정의하고 끝나는 시점에 검증 • 소프트웨어 작업 결과의 예: 요구 분석서, 설계 문서, 코드 등 • 작업 방법 • 특정 단계의 작업을 어떻게 수행하는지 언급이 필요함 • 진입 조건, 출구 조건 • 진입 조건: 각 단계의 작업을 시작하기 위해 만족하여야 할 조건 • 출구 조건: 그 단계의 작업을 종료하기 위하여 결과물이 만족하여야 할 조건

10. In this chapter … 프로세스 2.1 소프트웨어프로세스 2.2 바람직한 프로세스의 특성 2.3 소프트웨어 개발 프로세스 모델 2.4 지원 프로세스

11. 바람직한 프로세스의 특징 프로세스 • 어떤 프로세스를 사용하는 것이 가장 적합한가? • 정의된 프로세스는 여러 프로젝트에 적용됨 • 여러 프로젝트에 대해 목표 달성을 위한 바람직한 특징이 필요함 • 바람직한 프로세스의 특징 (1) 예측 가능성 (2) 테스팅과 유지보수 지원 (3) 변경 지원 (4) 결함 제거

12. (1) 예측 가능성 (Predictability) 프로세스 • 프로세스가 프로젝트를 완성하기 전에 얼마나 정확히 예측 가능한가? • 비용을 얼마나 잘 예측할 수 있는가? • 품질을 얼마나 잘 예측할 수 있는가? • 예측 가능한 프로세스는 통계적으로 관리가 가능 • 과거 유사 프로젝트를 수행했을 때, 비용이 얼마나 들었는가? • 과거 유사 프로젝트가 어느 단계에서 얼마나 오류가 발생했는가? • 통계에 근거한 프로세스 제어 • 프로세스 없이도 좋은 품질과 낮은 비용의 소프트웨어를 만들 수는 있지만, • 프로세스 없이는 한 번의 프로젝트를 완료하였다 해도 다음에 이를 재현할 수는 없다.

13. (2) 테스팅과 유지보수 지원 프로세스 • 유지보수에 드는 비용은 개발 비용을 초과함 • 코딩은 전체 개발 노력의 1/3에 해당 • 프로그래머는 20% 정도 시간만을 프로그래밍에 투자 (Boehem)[나머지 시간은? 매뉴얼 작성, 의사소통, 기타 등] • 프로세스의 목적은? • 설계와 코딩에 드는 노력을 낮추는 것이 아니라, • 테스팅과 유지보수에 드는 노력을 낮추어야 한다. • 설계, 코딩을 대충하란 이야기? No!!!  테스팅과 유지보수가 쉽도록 설계하고 코딩해야 함

14. (3) 변경 지원 프로세스 • 완성된 제품도 변경을 요할 수 있다.(환경, 요구사항 변화) • 개발 과정에서도 변경을 요할 수 있다. • 고객의 요구가 프로젝트 중간에 바뀔 수 있음 • 개발자의 판단에 의해 설계 내용이 변경될 수 있음 • 변경은 항시 일어남 변경을 쉽게 다룰 수 있는 프로세스가 요망됨

15. (4) 결함 제거 프로세스 • 오류는 개발 과정의 全단계에서 발생할 수 있음 • 요구 분석: 20%, 설계: 30%, 코딩: 50% • 오류가 발생된 후 발견이 지연될수록 수정 비용이 높아짐 • 예를 들어, 요구분석에 오류가 있다면, 이는 설계 및 코드에도 영향을 줌  오류 탐색과 수정은 소프트웨어 개발 전체 단계에 지속적인 프로세스가 되어야 함

16. In this chapter … 프로세스 2.1 소프트웨어프로세스 2.2 바람직한 프로세스의 특성 2.3 소프트웨어 개발 프로세스 모델 2.4 지원 프로세스

17. 소프트웨어 프로세스 모델 프로세스 • 프로세스 모델 • 일반적인 모델이 될만한 프로세스를 기술한 것 • 프로세스의 generic 버전에 해당함 • 소프트웨어 생명 주기 개념화 단계 유아 및 성장기 성년기 (제품으로서) 유아기 개발 전 개발 후 개발 단계

18. 건축 프로세스 프로세스 (요구 분석)집을 짓기 위해서는 건축설계사가 집주인과 만나 어떤 집을 원하는지 들어본다. (구조 설계)건축설계사는 집주인의 요구를 반영하여 층별 배치도와 개략적인 조감도를 그린다. (상세 설계)평면도, 측면도를 필요한 자세한 설계 도면을 준비한다. (구현(코딩))설계가 끝나면 시공단계에 들어가서 실제로 집을 짓는다. (테스트)집을 지은 후에는 전등이 잘 켜지는지, 난방이 잘되는지 등의 각종 점검을 수행한다. (유지보수)집이 완성된 후에는 하자에 대한 유지보수를 수행한다.

19. 소프트웨어 프로세스 모델 프로세스 • 개발 프로세스: 개발 과정을 체계적으로 정리한 과정 • 실정에 맞는 개발 팀의 고유한 모델의 정립 필요 • 소프트웨어 개발에 필요한 작업 • 요구 분석과 정의 • 시스템 설계 ( 건축의 구조 설계에 해당) • 프로그램 설계 ( 건축의 상세 설계에 해당) • 프로그램의 작성(구현) • 테스트(단위 테스트, 통합 테스트, 시스템 테스트) • 시스템 설치 • 유지보수

20. 대표적인 소프트웨어 프로세스 모델 프로세스 폭포수 모델 (Waterfall Model) 프로토타이핑모델 (Prototyping Model) 점증적 모델 (Incremental Model), 나선형 모델 (Spiral Model) V 모델 (V Model) 일정 중심 설계 모델 진화적 출시 모델 (Evolutionary Delivery Model)

21. 폭포수 모델 (Waterfall Model) (1/3) 프로세스

22. 요구 분석 설 계 구 현 시 험 인수설치 폭포수 모델 (Waterfall Model) (1/3) 프로세스 계 획

23. 폭포수 모델 (Waterfall Model) (2/3) 프로세스

24. 폭포수 모델 (Waterfall Model) (3/3) 프로세스 • 1970년대 소개항공 방위 소프트웨어 개발 경험으로 습득 • 각 단계가 다음 단계 시작 전에 끝나야 함 • 순서적 - 각 단계 사이에 중복이나 상호작용이 없음 • 각 단계의 결과는 다음 단계가 시작 되기 전에 점검 • 바로 이전 단계로의 피드백만이 가능함 • 단순하거나 응용 분야를 잘 알고 있는 경우 적합 • 한 번의 과정, 비전문가가 사용할 시스템 개발에 적합 • 결과물(deliverable) 정의가 중요

25. 폭포수 모델의 프로세스 및 결과물 요약 프로세스 P 계획 R 요구 분석 D 설계 • 문제정의 • 타당성 분석 • 비용, 일정예측 • DFD • 자료사전 • 소단위명세서 • 시스템구조설계 • 프로그램설계 • UI 설계 구조설계서 상세설계서 계획서 요구 분석서 I 구현 T 시험 A 인수/설치 • 통합시험 • 기능시험 • 성능시험 • 프로그래밍 • 단위테스트 통합된 프로그램 설치된 소프트웨어 프로그램 • 설치 • 인수 시험 (활동) (결과물)

26. 폭포수 모델 – 계획 (Planning) 프로세스 문제의 실현 가능성을 타진한다. (feasibility study) 영구 기관(엔진)을 만들 수는 없다?, 물로 가는 자동차는? 개발하고자 하는 시스템의 성격을 파악하여 비용과 기간을 예측한다. 예측을 잘못하면 소위 “열심히 하고 욕먹는 결과”를 초래한다. 개발 방법과 각 단계에 필요한 자원을 결정한다. 좋은 도구를 사용할 경우, 인력을 크게 줄일 수도 있다. 열역학 법칙을 깬 세계 최초영구기관?

27. 폭포수 모델 – 요구 분석 (Requirement Analysis) 프로세스 • 개발을 의뢰한 사용자(일반인, 운영자, …) 요구나 주어진 문제를 정확히 분석하고 이해하는 과정이다. • 발주자와 개발자가 요구 분석 사항에 동의하여야 다음 단계 진행이 가능하다. • 소프트웨어가 어떤 품질을 만족해야 하는지 결정한다. • 소프트웨어가 어떤 기능을 제공해야 하는지 결정한다.( 세부적으로 어떻게 구현할 지는 추후 설계 단계에서 생각한다.) • 요구분석서는 사용자와 개발자의 의사 소통 수단으로서, 정확하고 간결하고 완벽하며 이해하기 쉽고 일관성을 유지하도록 작성해야 한다.

28. 폭포수 모델 – 설계 (Design) 프로세스 • 시스템 구조 설계 • 소프트웨어 구조를 어떻게 가져갈 것인가? • 일반적으로, 소프트웨어 모듈을 정의하고, 각 모듈간의 관계를 정의한다. • 프로그램 설계 • 각 모듈내의 알고리즘을 설계한다. • 모듈간의 인터페이스 방법을 설계한다. • 사용자 인터페이스 설계 • 입력 형식(메뉴, 음성입력 등)을 결정하고 설계한다. • 출력 형식(화면, 소리 등)을 결정하고 설계한다.

29. 폭포수 모델 – 설계 (시스템 구조 설계 예제) 프로세스 SANTA PDSN/IWF GGSN LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS IXPC (Inter/eXter Process Communication) MS LME SMSC IPLS WISE INBH NMS WINGS AAA JUICE SANTA 메시지 송수신 페이징 처리 과금 처리 기타 연동 단말 정보 처리 정보 관리 및 공유 데이터베이스 메시지 파일 메시지 정보 관리 제어 및 호처리 운용 및 유지보수 운용자 정합 데이터베이스 관리 메시지 상태 관리 통계/장애/상태 관리 Graphical UI 파일(메시지) 관리 호처리 제어 운용/형상/구성 관리 Textual UI

30. 폭포수 모델 – 설계 (사용자 인터페이스 설계 예제) 프로세스 GUI(Graphical User Interface): Java 기반으로 이식성 높고 편리한 환경 제공 TUI(Textual User Interface): 원격지에서 MML을 사용한 운영 기능 제공 명령어 입출력 환경

31. 폭포수 모델 – 구현 (Implementation) 프로세스 • 미리 정해진 모듈 설계에 따라 프로그래밍, 즉 코딩을 수행한다. • 코딩된 각 모듈은 테스트의 기본 단위이다. 모듈 테스트는 테스트 단계가 아닌 구현 단계로 보기도 한다. • 코딩 작업 자체도 개발회사 전체적인 표준이 있어야 한다. • 헤더 주석, 변수 작명 규칙, 모듈의 최소 및 최대 크기 등 • 모듈 테스트도 회사 전체의 표준이 있어야 한다. 테스트 계획서, Code Inspection, …

32. 폭포수 모델 – 구현 (모듈 테스트의 예제) 프로세스

33. 폭포수 모델 – 시험 (Test) 프로세스 • 각 모듈들이 정의된 인터페이스에 따라 잘 동작하는지 통합 시험(integration test)을 수행한다. • 여러 모듈을 조금씩 결합하면서 단계적으로 시험하는 방법을 취한다. •  테스트: 개발 기관 내부에서 실제 사용해보는 시험이다.  version: 블레이트앤소울을엔씨소프트 직원들을 대상으로 open한다. •  테스트: 선택된 고객을 대상으로 실제 사용해보는 시험이다.  version: 플레이드앤소울을프로게이머들을 대상으로 open한다.

34. 폭포수 모델 – 인수 (Acceptance) 프로세스 • 패키지 소프트웨어인 경우,사용자가 소프트웨어를 설치할 수 있도록 설치 안내서를 제공한다. • 주문형 소프트웨어인 경우,사용자 앞에서 직접 설치하며, 필요한 경우 인수 시험(acceptance test)을 실시한다. • 설치 단계가 끝나면 소프트웨어 생명 주기에 있어서 운용 및 유지보수 단계로 넘어간다.

35. 폭포수 모델의 결과물(Deliverable) 프로세스 단, 프로젝트의 규모 및 성격에 따라서 크게 달라질 수 있다.

36. 폭포수 모델의 장단점 프로세스 • 장점 • 개발자가 어떤 작업을 수행하고 있는지 그 단계가 명확하다. • 프로세스가 간단하여 일반인도 쉽게 이해할 수 있다. • 중간 산출물이 명확하게 지정되어 있다. • 단점 • 처음 단계를 지나치게 강조하면 코딩, 테스트가 지연된다. • 각 단계의 전환에 많은 노력을 기울여야 한다. (뒤로 돌아가기 어렵다.) • 소용없는 다종의 문서를 생산할 가능성 있음

37. 프로토타이핑모델 (1/3) 프로토타이핑이란 시스템의 일부 혹은 모델을 만드는 과정이다. 시뮬레이션을 수행하거나, 데모 시스템을 만드는 방법 등이 있다. Rapid Prototyping Model ( 컬러링 예제) 요구 분석 프로토타입 개발/개선 google phone prototype 프로토타입 평가 구현 인수/설치

38. 프로토타이핑모델 (2/3) • 시범 시스템의 적용 • 사용자의 요구를 더 정확하게 추출한다. • 알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작을 통해 요구사항을 명확히 하고 위험을 줄일 수 있다. • 프로토타이핑 도구 • 화면 생성기 • 비주얼프로그래밍 • 4세대 언어 등 • 공동의 참조 모델(reference model)제공 • 개발 단계에서 유지보수가 이루어짐

39. 프로토타이핑모델 (3/3) • 프로토타이핑의 단점 • 오해 (프로토타입을 보고, 전부 다 개발한 것 아니냐고 할 수 있음) • 기대심리 유발 (프로토타입이 이 정도이니, 최종 결과물은 …) • 관리가 어려움(중간 산출물 정의가 난해)

40. 점증적 모델 (1/2) 프로세스 • 개발 싸이클이 짧은 환경 • 빠른 시간 안에 시장에 출시하여야 이윤에 직결된다.  빨리 만들어 일단 반응을 보자. • 개발 시간을 단축하는 법  시스템을 나누어 릴리스한다. 개발 시스템 개발자 릴리스 1 구축 릴리스 2 구축 릴리스 3 구축 릴리스 1 사용 릴리스 2 사용 릴리스 3 사용 사용자 완성 시스템

41. 점증적 모델 (2/2) 프로세스 • 릴리스 구성 방법 • 점증적(incremental) 방법 – 기능별로 릴리스 • 반복적(iterative) 방법 – 릴리스할 때마다 기능의 완성도를 높임 • 단계적 개발 • 기능이 부족하더라도 초기에(빠른 시점에) 사용 교육이 가능 • 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음 • 자주 릴리스하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히 고쳐나갈 수 있음 • 개발 팀이 릴리스마다 다른 전문 영역에 초점 둘 수 있음 이번 Release에서는 성능 짱 이번엔 GUI 짱 … • 좋은 점만 있니? 빈번한 업그레이드에 따른 피로도 누적 (예: 안드로이드)

42. 나선형 모델 (1/3) 프로세스

43. 나선형 모델 (2/3) 프로세스 • 소프트웨어의 기능을 나누어 점증적으로 개발 • 실패의 위험을 줄임  위험 분석에 초점을 맞춘 개발 모델 • 테스트 용이 • 피드백이 용이 • 여러 번의 점증적인 릴리즈(incremental releases) • 진화 단계 • 계획 수립(planning): 목표, 기능 선택, 제약 조건의 결정 • 위험 분석(risk analysis): 기능 선택의 우선순위, 위험요소의 분석 • 개발(engineering): 선택된 기능의 개발 • 평가(evaluation): 개발 결과의 평가

44. 나선형 모델 (3/3) 프로세스 • 대규모 시스템 개발에 적합 • Risk reduction mechanism • 반복적인 개발 및 테스트 • 강인성 향상 • 단점 • 관리가 중요 (상당히 복잡하고, 긴 과정 …) • 위험 분석이 중요 • 상대적으로 새로운 모델 ( 적용이 쉽지 않음)

45. V 모델 프로세스 폭포수 모델에 시스템 검증과 테스트 작업을 강조함 신뢰성이 높이 요구되는 분야에 적용 폭포수 모델에서 감춰진 반복과 재작업을 드러내 놓은 모델임 인수/설치 요구분석 검증 요구 분석 시스템 테스트 인터페이스 검증 시스템 설계 통합 테스트 모듈 검증 상세 설계 단위 테스트 구현(코딩)

46. 일정 중심 설계 모델 (1/2) 프로세스 • 점증적 모델과의 비교 • 반복적 사이클을 거친다는 점에서 유사 • 최종 목표와 출시가 명확하지 않으며, 중간에 중단할 수 있는 점이 다름 • 기능의 우선순위에 따라 개발을 진행하다가출시일이 되면 중단함

47. 일정 중심 설계 모델 (2/2) 프로세스 • 특징 • 사용자의 요구에 대하여 우선순위를 정하고, 이를 기초로 각 사이클을 계획 • 초기 단계에 중요한 기능들을 설계, 구현하여 시스템의 골격을 만듦 • 상대적으로 덜 중요한 기능을 나중에 함으로 일정 조정 가능 • 단점 • 우선순위가 낮아 출시에 포함되지 않을 기능을 분석하고 설계하는 데 시간을 낭비 • 적용 • 소프트웨어 제품의 출시 날짜가 매우 중요한 경우 • 목표 일정을 달성할 수 있을지 불확실할 때

48. 진화적 출시 모델 (1/2) 프로세스 버전 하나를 개발하여 고객에게 보여주고, 고객 반응에 따라 제품을 개발하고 발전적으로 출시해 나감

49. 진화적 출시 모델 (2/2) 프로세스 • 진화적 출시 (evolutionary delivery) • 고객의 요구를 여러 사이클에 걸쳐 개발하여 보여주면서 제품을 개선해 나가는 모델 • 프로토타이핑 모델과 다른점 • 고객의 요구를 프로토타이핑 모델처럼 전적으로 수용하지는 않음 • 진화적 출시는 고객의 반응으로 바뀔 가능성이 적은 부분을 시스템의 핵심으로 개발(즉, 바뀔 가능성이 적은 부분 먼저 개발함) • 프로토타이핑 모형은 시스템에서 눈에 띄는 부분을 먼저 강조하고, 나중에 시스템 기반에 있는 구멍을 메워나가는 식

50. 모델이많은 이유 프로세스 • 모델의 선택은 프로젝트의 상황과 요구에 좌우됨 • 모델을 잘 선택하면, 소프트웨어 생산성이 높아짐 • 경우에 따라서는 최적의 효과를 내기 위하여 (두세 개) 모델의 융합이 이루어지기도 함