소프트웨어 프로세스. 1 내용  소프트웨어 프로세스  생명주기의 의미  생명주기 모델 –Waterfall Model –prototyping model –Spiral Model –Iteration Model.

Presentation on theme: "소프트웨어 프로세스. 1 내용  소프트웨어 프로세스  생명주기의 의미  생명주기 모델 –Waterfall Model –prototyping model –Spiral Model –Iteration Model."— Presentation transcript:

1 소프트웨어 프로세스

2 1 내용  소프트웨어 프로세스  생명주기의 의미  생명주기 모델 –Waterfall Model –prototyping model –Spiral Model –Iteration Model

3 2 소프트웨어 개발이란 ? Requirements Problem Space Solution [Question]  Problem 이 무엇인가 ?  Solution 은 무엇인가 ?  Solution 구현을 위한 mechanism 은 무엇인가 ?  어떻게 구현할 것인가 ?  해결되어야 할 문제가 무엇인가 ?  고객이 구현된 산출물을 사용할 수 있는가 ?  보완할 필요가 있는가 ?  개발기간동안 발행되는 변화 / 변경을 어떻게 control 할 것인가 ? [Question]  Problem 이 무엇인가 ?  Solution 은 무엇인가 ?  Solution 구현을 위한 mechanism 은 무엇인가 ?  어떻게 구현할 것인가 ?  해결되어야 할 문제가 무엇인가 ?  고객이 구현된 산출물을 사용할 수 있는가 ?  보완할 필요가 있는가 ?  개발기간동안 발행되는 변화 / 변경을 어떻게 control 할 것인가 ?

4 3 개발단계 정의 (Definition) 개발 (Development) 유지보수 (Maintenance) 무엇어떻게변경 보호활동 (Umbrella Activities)

5 4 소프트웨어 개발 시 발생되는 이슈  지속적인 요구사항의 변경 – 변경에 따른 관리의 어려움 – 계획의 점검 시점, 비용의 estimation 이 어려움  여러 소프트웨어 시스템의 결합 – 새로운 시스템은 기존에 존재하는 시스템 (legacy system) 과 함께 결합되는 경우 – 이미 이관된 시스템과 개발중인 시스템의 개발팀이 상이한 경우 – 하나의 시스템을 위한 여러 개의 하위 소프트웨어 시스템을 여러 개발팀 / 조직에서 개발하는 경우  소프트웨어 프로세스를 통해 해결 가능

6 5 소프트웨어 프로세스  고품질의 소프트웨어를 구축하는 데에 요구되는 태스크 (Task) 에 대한 프레임워크 (Framework)  소프트웨어 개발활동에 필요한 다양한 태스크와 이에 대한 산출물  소프트웨어 프로세스 모델 – 소프트웨어의 생명주기와 관련된 모델 – 프로세스의 관리 및 개선에 관한 모델

7 6 내용  소프트웨어 프로세스  생명주기의 의미  생명주기 모델 –Waterfall Model –prototyping model –Spiral Model –Iteration Model

8 7 소프트웨어 생명주기 (Software Life Cycle )  Software is like humans.  It has a life cycle.  Software in a system is conceptualized first.  It becomes obsolescent at the end.  The period in between is called the software life cycle.

9 8 내용  소프트웨어 프로세스  생명주기의 의미  생명주기 모델 –Waterfall Model –prototyping model –Spiral Model –Iteration Model

10 9 소프트웨어 생명주기 모델 (Software Life Cycle Model)  소프트웨어 생명주기 모델 이란 ? –Attempt to generalize the development process into specified steps with associated activities and artifacts – 프로젝트 특성 ( 기간, 사용기술, 도메인 ) 에 따라 결정하여 적용한다.  왜 생명주기 모델을 사용하는가 ? – 개발 과정을 나눔으로써 관리하기가 쉽다 중요한 활동 식별, milestone 정의, 진척도 측정의 용이

11 10 소프트웨어 생명주기 모델 (Software Life Cycle Model)  대표적인 생명주기 모델 –Build and Fix Model –Waterfall Model –prototyping model –Spiral Model –Iteration Model  소프트웨어 개발의 두 가지 접근법 –“Big bang” 접근 제품이 한번에 전달 된다 Waterfall Model –Cyclical 접근 / iterative 한 접근방법 제품이 단계마다 개발되고 전달 된다 Spiral Model Iteration Model

12 11 Built-and-Fix Model  Unfortunately, many s/w products are developed with built-and-fix model.  Without specification or any attempt in design, just build a product, and reworked as many times needed to satisfy the customer.

13 12 Waterfall model (1/3)  Classic Lifecycle, 순차모델  소프트웨어 개발 각 단계들을 정의, 순차적으로 접근하는 방법 요구사항 분석 설계 구현 테스트 유지보수

14 13 Waterfall model (2/3)  특징 – 각 단계의 활동들이 선형적으로 수행 ( 각 단계 종료 후 다음 단계로 진행 )  장점 – 일정 개발 및 관리가 용이하며, 전체 과정의 이해가 용이 – 기술적인 위험이 적고, 응용분야를 잘 알고 있는 경우에 적합한 모델  단점 – 소프트웨어의 요구사항이 초기에 명확하게 정의되기 어려움 – 소프트웨어가 개발의 후반부에서 구체화되므로 중요한 문제점들이 뒤늦게 발견 됨 – 실제로 작동하는 프로그램은 개발 주기가 끝날 때야 확인할 수 있음 – 실제 프로젝트에서는 각 단계에서 제안하는 선형적인 흐름을 따르지 않는다

15 14 Waterfall model (3/3)  피드백을 적용한 순차 모델  분석, 설계, 구현, 테스트, 유지보수라는 틀을 제시, 소프트웨어 시스템을 개발하기 위한 전형으로서 남아 있음 요구사항 분석 설계 구현 테스트 유지보수

16 15 Prototype Model (1/3)  개발하려는 시스템의 주요 기능을 초기에 실제 운영할 모델로 개발하는 방법 요구사항 분석 프로토타입 개발 / 개선 프로토타입 고객 평가 프로토타입 고객 평가 구현 인수 및 설치

17 16 Prototype Model (2/3)  특징 – 요구사항이 불분명한 경우 유용한 모델 – 고객과 개발자간의 원활한 의사소통 가능  단점 – 프로토타입을 실제 제품으로 오해할 수 있음 – 비기능적 요구사항 및 품질 대한 부분은 확인하기 어려움 – 시제품은 작동여부를 확인하기 위한 것으로 적절하지 못한 프로그래밍 언어 및 비효율적인 알고리즘이 사용되는 경우가 있음

18 17 Prototype Model (3/3) 고객의 의견 수렴 시제품 개발 및 수정 고객의 시제품 테스트 Stop Start Engineer product Requirements gathering and refinement Quick design Refining prototype Customer evaluation of prototype Building prototype

19 18 Spiral Model (1/2)  폭포수 모델과 원형 패러다임의 장점에 위험 분석 (risk analysis) 을 추가  시스템을 개발하면서 생기는 위험을 관리하고 최소화 하려는 것이 목적  A simplified spiral model is as a waterfall model with each phase preceded by risk analysis. –Before commencing each phase, an attempt is made to control (resolve) the risks. If it is impossible to resolve all the significant risks at a stage, then the project is immediately terminated.

20 19 Spiral Model (2/2)  특징 – 대규모 시스템 및 위험 부담이 큰 시스템의 경우 적합  단점 – 모델이 복잡하여 프로젝트 관리에 어려움이 있음 – 위험 평가는 매우 중요하며, 전문적 지식이 필요함

21 20 계획 목표, 대안, 제 약사항 결정 고객 평가 평가결과와 다음 반복을 위한 계획 개발 개발과 다음 단계 작업 산출물의 검증 고객의 feedback 을 반영한 계획 고객 평가 초기 위험 분석 고객의 반응에 따른 위험 분석 추진여부 결정 Toward a completed system 첫 번째 prototype 다음 단계의 prototype 시스템 개발Cost Time 위험 분석 각 대안의 위험 분석 및 접근방법 선택 초기 요구사항 분석과 계획 수립

22 21

23 22 Iteration Model (1/3)  특징 –Waterfall model 의 순차개념과 prototype model 의 반복성 개념을 결합시킨 형태 – 소프트웨어 기능을 점진적으로 개발하는 것이다 – Prototype 과는 달리 실제 작동하는 핵심적인 기능들을 구현 – 반복마다 실행 가능한 릴리즈가 산출되고 이는 반복이 거듭될수록 향상되어 결국 최종 시스템으로 발전  유형 –Incremental Model ( 점증적 모델 ) –Evolutionary Model ( 진화적 모델 )

24 23 Incremental Model  Divide project into builds  Operational quality portion of product within weeks  Smaller capital outlay, rapid return on investment

25 24 Incremental Model  요구사항이 개발 초기 정의되었을 경우 적용 ( 무엇을 만들어야 되는지 확실하게 아는 경우 ) Analysis Design Code Test Design Code Test Design Code Test Delivery of 1 st Iteration Delivery of 2 nd Iteration Delivery of 3 rd Iteration Iteration/Increment 1 Iteration/Increment 2 Iteration/Increment 3

26 25 Evolutionary Model  요구사항이 개발 초기 정의되지 않았을 경우 적용 ( 무엇을 만들어야 하는지 확실하게 모르는 경우 ) Analysis Design Code Test Iteration 1 Iteration 2 Iteration 3 Analysis Design Code Test Analysis Design Code Test Delivery of 1 st Iteration Delivery of 2 nd Iteration Delivery of 3 rd Iteration

27 26 Unified Software Development Process

28 27 V 모델  특징 – 개발 단계별 테스트 활동에 focusing 한 모델 Test Specification Test Specification Test Specification Customer Requirements Technical Requirements High Level Design implementation Unit Test Integration Test System Test Acceptance Test Detailed Design

29 28 V 모델  예 - 2 Customer Requirements System Requirements System Architectural Design Acceptance Test System Test Integration Test SW Tech Reqs High Level Design Detailed Design System Test Unit Test Integration Test Implementation SYSTEM LEVEL COMPONEN T LEVEL Software Component Life Cycle Reqs Spec

30 29 팀 구성  5 명 이하의 팀원으로 구성  팀장 선출  팀명 – 팀장이 충분한 리더쉽을 발휘할 수 있는가 ? – 적절한 업무 분담이 가능한가 ? – 개발이 가능한 사람이 있는가 ? – 적극적으로 프로젝트에 참여하고 타인의 의견을 존중할 준비가 되어 있는가 ?

31 30 팀 프로젝트 시작  요구사항 – 개발할 응용소프트웨어 : 개별적으로 선택한다. – 단, 온라인으로 접속 가능한 응용소프트웨어다. – 데이터베이스의 생성 및 추가, 삭제, 변경 등의 작업이 들어간다. – 사용자인터페이스는 윈도우 기반에서 작동되는 GUI 다.  요령 – 이미 개발되어 예제로 나와있는 것을 참조한다. – 참조할 자료는 수업 중에 숙지하고 변경 가능한 것을 선택한다. – 팀의 능력을 파악하고 적절한 것을 선택한다. – 차후에 발전시켜서 사용할 수 있는 것으로 선택한다.