2. Software processes

앞서 Introduction에서 보았듯이, software engineering은 software processes로 볼 수 있으며, 과정은 다음과 같다.

1) Specification -> Development -> Validation -> Evolution

 

2.1 Software process models

 

software process model은 간단하게 모델화된 프로세스 표현이며, 다음과 같이 분류될 수 있다.

1) The waterfall model 

2) Incremental development model

3) Integration and configuration 

 

2.1.1 The waterfall model 

하나의 phase에서 다음 phase로 단계적으로 cascading되는 특성 때문에, waterfall model이라고 불린다. 

Software process과정 각각을 직접적으로 표현한다.

1) Requiement analysis and definition -> System and software design -> Implemenation and unit testing ->

Integration and system testing -> Operation and maintenance

waterfall model의 각 phase의 결과는 승인된 한개이상의 문서를 포함한다. 이 뜻은, 프로세스가 진행됨에 있어서 중간에 변경사항이 발생할 경우, 해당하는 단계로 되돌아가서 다시 진행해야한다는 것을 의미한다. 따라서, 미리 결정된 사용자의 요구사항을 변경하지 못해, 결과적으로 사용자가 원하는 것과 거리가 먼 소프트웨어가 탄생할 가능성이 높다.

이러한 waterfall model을 적용하기에 적합한 시스템은 다음과 같다.

 

1) 하드웨어 시스템과 상호작용해야하는 Enbedded System

2) Safety, Security가 Specifiation, Design과정에서 매우 중요한 Critical System

3) 여러 회사에 의해 개발되는 Large Software System

즉, 요구사항이 자주 바뀌지 않고, 공식적인 communication이 일어나는 상황에서 적절한 model

 

2.1.2 Incremental model

프로세스의 과정인 Specifiction, Devleopment, Validation이 분리된 것이 아닌 프로세스 중간에 끼워넣어질 수 있다. 요구되는 시스템이 개발될 때까지, 소프트웨어의 버전을 계속 진화시키며 개발한다. 개발 단계마다 요구사항의 증분(Increment)가 추가되며, 버전의 업그레이드로 반영된다. 초기의 Increment는 가장 중요하고 긴급하게 요구되는 기능만을 개발한 형태가 된다. 

 

장점 : 1) 요구사항의 변화에 따른 비용의 절감, 2) 개발과정에서 고객의 피드백 반영 쉬움 3) 조기에 쓸만한 소프트웨어의 배포가 가능

 

문제점 : 1) 프로세스의 비가시성, 2) 새로운 Increment가 더해질 때마다 degrade되는 system structure

 

Incremental model은 거대하고 복잡하고, 수명이 긴 시스템인 여러 다른 팀들이 안정화된 프레임워크나 아키텍처를 가지고 개발하는 시스템의 경우에는 적용하기 힘들다.

 

2.1.3 Integration and configuration

이미 존재하는 software component를 프로젝트에 Integration하고 Configuration하여 사용하는 프로세스 모델

각 프로세스 단계는 다음과 같다.

1) Requirement specification -> Software discovery and evaluation(쓸만한 컴포넌트 탐색 후 평가)  -> Requirement refinement(찾아낸 쓸만한 컴포넌트를 반영하여 요구사항 수정) -> Application system configuration(쓸만한 소프트웨어는 현재 프로젝트에 맞추어 커스터마이징) -> Component adaptation and integration(없는 컴포넌트 개발 후 통합)

 

개발의 양을 줄여주어 빠른 개발이 가능하고 비용을 줄일 수 있다. 기존에 검증된 컴포넌트를 사용함으로서 안정성을 높일 수 있다.

 

2.2 Process activities 

 

Software process는 Specification, Development, Validation, Evolution으로 구성된다. 

 

2.2.1 Software specification

시스템에 요구되는 기능과 서비스를 을 한정하는 일련의 프로세스이다. 초기단계이므로, specification 단계에서의 실수는 이후의 문제를 야기하게 된다. 주된 목적은 required document를 작성하는 것이며, 사용자와 고객을 위한 높은 추상화 수준의 문서와 시스템 개발자를 위한 세부사항이 포함된 문서가 필요하다.

주된 프로세스 단계는 다음과 같다.

1) Requirements elicitation and analysis : 관찰, 토론, 분석 등으로 요구사항을 도출하고 시스템 모델과 프로토타입 생성

2) Requirements  specification : User requirement와 system requirement를 문서에 작성

3) Requirements validation : 현실성, 일관성, 완전성 검증

 

2.2.2 Software design and implementation

실행가능한 시스템을 개발하는 과정이다.

Design process는 시스템의 유형에 따라 다양하게 구성될 수 있다. 

Software design을 위한 input은 platform information(OS, DB, 미들웨어 등 정보), software requirement, data description(데이터를 처리할경우 필요) 등이 있다. 이러한  input을 활용하여 Architectural design, DB design, Interface design, Component selection and design 등 design activity를 수행한다. 이러한 각각의 design들은 서로 의존적이다. 

Software design의 output은 System architecture, DB design, Interface specification, Component descriptions 등이 있다. 

Plan-driven approach의 경우 이러한 output은 Design diagram이되고 이후 프로그래머에 의해 코드로서 작성된다. 하지만, Agile approach의 경우 output은 프로그램의 코드로서 바로 표현된다. 프로그래머는 코드를 작성하면서 테스트와 디버깅을 통해 오류나 결함이 존재하는지 확인한다.

 

2.2.3 Software validation

개발된 시스템이 실제로 Specification을 준수하고, 고객의 기대를 충족시키는지 검증하는 단계이다.

이러한 검증을 위한 테스트 단계는 다음과 같다.

1) Component testing : 시스템 개발자들이 독립적인 Component인 기능이나 클래스를 테스트

2) System testing : Component integration시에 interaction, interface 문제 발생여부 및 기능/비기능적 요구사항 검증

3) Customer testing : 실제 운영상의 사용을 위해 실제 데이터를 이용해 고객에 의해 진행되는 테스트

 

2.2.4 Software evolution

시스템 개발 이후 maintenance 하는 것이 전통적인 방법이였다면, 최근에는 Development와 Maintenance를 구분짓지 않고 변경된 요구사항에 따라 시스템을 변경하거나 새로 개발하는 방법을 사용한다.

 

2.3 Coping with change

 

소프트웨어 프로젝트에서, 변경은 불가피한 요소이다. 특정 단계에서의 변화의 요구는 그 단계 뿐만 아니라 이후의 단계까지도 재수행 해야한다는 비용적 문제를 발생시킨다. 이러한 비용을 줄이기 위한 접근법은 다음과 같다.

1) Change anticipation (ex) System prototyping) : 가능한 변경을 미리 예측하게 하는 활동을 통해, 조기에 요구사항 수정

2) Change tolerance (ex) Incremental delivery) : 변화가 시스템에 쉽게 적용될 수 있도록 프로세스나 시스템 디자인

 

2.3.1 Prototyping

 

Prototyping은 design 단계에서 미리 초기 소프트웨어 시스템을 개발하고 확인함으로서, 변경될 수 있는 시스템 요구사항을 조기에 재도출하고 검증 할 수 있고, 이후의 user interface의 개발에도 사용될 수 있다.

Prototyping 개발 과정은 다음과 같다.

1) 프로토타입 목적 확립(UI개발, 기능요구사항 유효성검증 등) 

2) 어떤 기능/비기능 적인 요소들을 넣고 뺄 것인지 결정 후 개발

3) 프로토타입 평가

프로토타입의 개발이 늦어질 경우, 실제 사용자가 충분히 사용방법을 숙지할 시간이 부족해져 제대로된 평가가 이루어지지 못할 수 있다는 문제점이 있음

 

2.3.2 Incremental delivery

 

우선순위에 따라 버전에 따른 각각 추가되는 Increment를 나누어 delivery함으로서, 변화에 대해 적절히 대응할 수 있도록 한다. 가장 중요한 요구사항만을 만족하는 첫번째 Increment를 생성하고 프로토타입으로 활용함으로서, 고객에게 빠르게 소프트웨어를 전달 할 수 있다.

문제점은 다음과 같다.

1) UI나 DB변경사항에 따라 새로운 시스템으로 변경될 때, 이전의 버전에 익숙해진 사용자의 반발을 불러일으킬 수 있다. 2) 이후의 모든 Increment에 대해 common facilities를 조기에 발견해내기 어렵다.

3) 계약사항에 완전한 System specification이 들어가있을 경우 적용하기 어렵다.  

 

2.4 Process improvement

 

Software engineering process를 개선하기 위한 다음과 같은 두가지 접근법이 존재한다.

1) Process maturity approach : 프로세스 및 프로젝트 관리를 개선하는 것에 초점을 맞추고, 좋은 engineer관습을 조직내에 확산시킴(Overhead를 증대시키는 경향), 

2) Agile approach : 소프트웨어 개발에서 발생하는 Overhead(문서화 등)을 줄이고 반복적이고 점진적인 개발로 빠르게 기능을 포함한 소프트웨어를 배포하는 접근법

 

Process maturity approach의 경우, 사이클을 가지고 지속되는 프로세스이며 다음과 같은 단계를 가진다.

1) Process measurement -> 2) Process analysis -> 3) Process change

이러한 과정을 통해 프로세스가 개선되며, 이러한 프로세스를 평가하기 위해 process maturity model이 개발되었고, 성숙도에 따라 level이 나뉘기도 한다.