Software Process
소프트웨어 프로세스
- 소프트웨어를 개발하거나 업그레이드를 목표로 진행하는 일련의 모든 활동들을 지칭한다.
Generic Software Process Activity (일반적 소프트웨어 프로세스 활동)
- S/W를 개발하는데 수행하는 Activity들의 집합을 의미하며, 일반적으론 아래와 같이 구성된다.
- Specification (기능 명세)
- 소프트웨어가 수행해야 될 기능들과 개발 제약조건을 분석하는 과정이다.
- Design & Implementation (설계 및 구현)
- 소프트웨어를 설계하고, 설계를 따라 구현한다.
- Validation (= Testing; 검증, 테스팅)
- 만들어진 소프트웨어가 고객이 원하는 기능을 정확히 수행하는지를 검증 및 테스트한다. - Evolution (= Maintenance; 버전업, 유지보수)
- 고객과 시장의 변화에 맞춰 소프트웨어를 수정한다.
Software Process Model (소프트웨어 프로세스 모델) (URL)
- S/W Process를 추상화하여 표현한 것으로, S/W Process Activity들의 진행 방법에 대한 여러 모델들을 의미한다.
Activity Cost Distribution (소프트웨어 개발 유형에 따른 단계별 개발 비용 분포)
- 각 개발 모델별 단계별 개발 비용 분포는 위 표와 같다.
- 특히, S/W 개발과 유지보수를 비교하면, 유지보수에 소요되는 비용이 개발 비용보다 큰 것을 확인할 수 있다.
(즉, 애초부터 유지보수가 용이하게 개발하는 것이 중요하다.)
- S/W가 Critical할 수록, Design과 Testing의 비중이 압도적으로 증가한다.
(금융 S/W, 자율주행 및 운전 관련 S/W 등)
Plan-Driven Software Process (계획적 소프트웨어 프로세스)
- 소프트웨어 프로세스의 처음부터 끝까지, 모든 절차를 미리 계획해놓고 진행하는 방식을 의미한다.
- Progress(프로세스의 진척도)는 계획이 진행된 정도를 보고 측정할 수 있다.
Agile Software Process (애자일 소프트웨어 프로세스) (URL)
- 고객의 요구사항 변화에 Agile(민첩한)하게 대응할 수 있는 소프트웨어 프로세스이다.
- 앞으로 해야할 일들을 조금씩 계획해나간다. (이때, 이 소계획의 단위를 Increment라 부른다.)
(그러므로, 계획한 Increment 이후에는 어떤 작업을 진행할지 모른다.)
- 즉, 완성된 S/W는 일련의 Increment들로 구성된다.
Plan-Driven Process vs Agile Process (계획적 프로세스와 애자일 프로세스)
- 아래 질문들의 답에 따라 계획적 프로세스 혹은 애자일 프로세스 중 하나를 선택할 수 있다.
- 아주 상세한 Specification이 필요한가?
- 상세한 명세가 필요한 경우 Plan-Driven Process,
그렇지 않은 경우 Agile Process가 적절하다. - 현실적으로 Incremental Delivery를 적용할 수 있는가?
- 적용가능한 경우 Agile Process,
그렇지 않은 경우 Plan-Driven Process가 적절하다. - 대규모 프로젝트인가?
- 대규모 프로젝트의 경우 Plan-Driven Process,
소규모 프로젝트의 경우 Agile Process가 적절하다. - 개발팀이 같은 공간에 있는가?
- Co-Located한 경우 Agile Process,
Distributed한 경우 Plan-Driven Process가 적절하다.
※ 현실에서는 전체 프로젝트를 하나의 프로세스로 진행하기 보다는
Subsystem 혹은 Component 단위로 그때그때 적절한 프로세스를 적용하여 개발하는 것이 일반적이다.
Software Specification (소프트웨어 기능 명세)
- 요구되는 서비스와 시스템 및 개발시 생길 수 있는 제약사항들을 수립해나가는 과정이다.
Requirements Engineering Process (요구사항 엔지니어링 절차)
- Requirements Elicitation and Analysis (요구사항 유도 및 분석)
- 시스템으로부터 요구되거나 기대되는것을 찾아낸다.
- 기존의 다른 시스템을 분석하거나 유저 인터뷰 등을 통해 요구사항을 이끌어낸다.
- Requirements Specification (요구사항 명세)
- 세부적인 요구사항들을 정의한다.
- Requirements Validation (요구사항 검증)
- 요구사항의 Feasibility(실현 가능성), Consistency(일관성), Completeness(완전성)를 확인한다.
- Consistency(일관성)는 기능들의 일관성을 의미하는데,
예를 들어 회원의 나이 정보를 입력받지 않은 상태에서 나이로 통계를 내는 기능은 일관성을 해치는 사례가 된다.
- 빠진 요구사항이 없는 경우, Completeness(완전성)가 확보된 상태이다.
Software Design and Implementatoin (소프트웨어 설계 및 구현)
※ 실제 개발현장에서는 Design과 Implementation이 서로 Interleave되는 일이 자주 일어난다.
- Specification을 실현하는 Software Structure를 설계하는 단계이다.
- OOP에서, Class Prototypingd을 수행하는 단계이다.
(Class를 구성하는 Data Member와 Public Method Prototyping, 즉 Class Interface Prototyping)
Design Process (설계 절차)
- Architectural Design (구조 설계)
- 가장 거시적인 구조를 설계하는 절차로, 시스템 전체 구조를 명확히하고
주요 Component(Subsystem 또는 Module)들을 정의하고 그것들 간의 관계를 정의하는 과정이다.
- Database Design (데이터베이스 설계)
- 데이터베이스내에서 사용될 System Data Structure를 설계하는 과정이다.
- ERD를 통해 Schema를 설계하는 과정이 여기에 해당된다.
- Interface Design (인터페이스 설계)
- System Component(Subsystem 또는 Module)들 간의 Interaction을 위한 인터페이스를 정의하는 과정이다.
- Component Selection and Design (재사용할 컴포넌트 선택 혹은 설계)
- 재사용할만한 Component를 찾거나, 직접 설계하는 과정이다.
Software Implementation (소프트웨어 구현)
※ 실제 개발현장에서는 Design과 Implementation이 서로 Interleave되는 일이 자주 일어난다.
- Software Structure를 Executable Program으로 만드는 단계이다.
- Prototype을 정의해놓은 Function 및 Method의 Body를 채우는 단계이다.
- Debugging을 수행하는 단계이다.
"Programming is an individual activity. There is no standard programming process."
(프로그래밍이란, 설계가 완전히 끝난 후 그 내용을 단순히 채워넣는 행위로, 그 중요도가 설계의 중요성보다 대단히 낮다.)
Debugging Process (디버깅 절차)
- Locate Error (에러 위치 파악)
- 4가지 절차 중 가장 어려운 절차로,
세밀한 Logging Mechanism을 통해 버그가 발생한 위치를 파악하기 쉽게 해놓는 것이 중요하다. - Design Error Repair (에러 수정방안 수립)
- Repair Error (에러 수정)
- Re-test Program (테스팅)
Software Verification and Validation (S/W V&V; 소프트웨어 검증 및 입증)
* Software Testing (소프트웨어 테스팅) (URL)
Software Evolution (소프트웨어 유지보수)
- 소프트웨어는 태생적으로 유연하고 변하기 쉽다.
- 환경이 변화함에 따라, 소프트웨어 또한 그 변화에 대응되어 개선되어야 한다.
Software Evolution Process (소프트웨어 유지보수 절차)
Reference: Software Engineering 10th Edition
(Ian Sommerville 저, Pearson, 2016)