소프트웨어 공학 (3), 소프트웨어 프로세스 1

소프트웨어 프로세스

0. 기본 개념

1) 소프트웨어 프로세스

- 여러가지 절차가 존재한다.

- 소프트웨어를 개발하기 위해선 여러 과정과 액티비티들이 필요한데 이를 정형화해야한다.

- 다양한 소프트웨어에 대한 프로세스가 존재하지만 일반적으로 아래의 과정을 거친다.

 

(1) Specification: 요구 사항에 대한 정의하는 단계

- 사용하고자 하는 데이터 모델을 정의하거나 유저 인터페이스 등을 정의하거나 하는 순서를 정의한다.

- 코드, 문서, 그림등의 output이 정해져야한다.

- 각 프로세스에 대한 역할 정의해야한다.

- 각 단계에 대한 선행/후행 단계를 정의하는 과정도 필요하다.

 

(2) Design and Implementation: 소프트웨어의 설계 및 구현하는 단계

 

(3) Validation: 제대로 구현됐는지 검사하는 단계

 

(4) Evolution: 바뀐 트렌드나 요구사항, 새로운 기술의 도입, 시장 출시 이후 개선이 필요한 경우 등에 대한 단계

 

 

 

2) Plan-driven and agile processes

대부분의 개발은 두 방법을 모두 사용하곤 한다.

 

(1) Plan-driven

- 공학에서 통상적으로 많이 사용하는 방법으로 하드웨어도 같이 개발하는 기업의 경우 해당 방법으로 많이 사용한다.

- 전통적인 방법으로 계획에 맞춰서 개발한다.

- 위의 과정을 명확히 설정하고 계획대로 개발을 진행한다.

- 비교적 안정성을 보장한다. (언제까지 개발이 되어야하는지 등)

- 소프트웨어 비즈니스의 규모가 큰 경우에는 거시적인 관점에서 Plan-driven으로 하는 경우가 많다.

- 엄격하게 단계를 구분하기에 처음에 정의를 잘 못한 경우에는 처음부터 다시 해야한다. 

 

(2) Agile processes

- 최근 웹 개발에서 등장한 방법으로 소프트웨어의 우선순위에 따라 가장 중요한 기능부터 단계별로 개발한다.

- incremental 구조로서 점점 기능이 추가된다.

- 개발 중에도 시장 트랜드 등 변화적인 요소를 반영할 수 있다.

- 변화를 받아들이는데 신속하다.

- 지금 당장 출시해서 시장의 반응을 볼 수 있다.

- 각 단계는 상호 유기적인 관계이다.

 

cf) Agile 개발의 원칙

모든 개발자는 본인의 역할에 충실, 공동의 목표 추진, 꾸준히 실력 향상을 위한 노력 등이 필요하다.

 

 

1. Software process models

- 본인의 소프트웨어에 맞는 개발 방법을 선택하는 것이 중요하다.

1) waterfall model(Plan-driven model)

- 각 단계가 구분되어있고, 순서대로 진행한다.

- 앞에서 실패하면 뒤로 가기 굉장히 어려워진다. 이에 따라 치밀한 설계가 필요하다.

- 프로세스를 진행 중에 시장 트렌드의 변화나 요구사항의 변화가 생기더라도 변화에 대응하기 어렵다. 하지만 그만큼 변화가 없는 시장이라면 사용하기 적합할 수 있다.

- 하드웨어가 들어가는 임베디드 시스템과 같은 것은 plan-driven으로 하는 경우가 많다.

- 개발하고자 하는 소프트웨어의 규모가 매우 큰 경우에는 큰 틀은 plan-driven으로 개발 프로세스를 만들고, 각 단계 내부에선 agile로 사용하는 경우가 많다.

 

waterfall model process

- unit test: 각자 개발한 소프트웨어를 테스트하는 것

- system test: 모든 소프트웨어를 모아 유기적으로 테스트하는 것

 

 

2) Incremental model

- 구현을 하기위한 규격화 개발, 검증이 밀결합되어있다.

- 단순히 데모를 출시하는 게 아니라 시장에 바로 출시할 수 있기에 비즈니스로 활용이 가능하다.

- 핵심기능을 가진 초기버전에서 계속 기능을 추가한다.

- agile이거나 plan-driven이 가능하다.

- plan-driven도 이를 사용할 수 있는데 버전별로 기능을 추가할 수 있다. 

- 시장에 출시를 한 뒤, 고객의 피드백을 반영할 수 있다.

- '문서보다 코드가 우선이며, 코드가 잘 되어있으면 문서는 없을 수 있다'라는 말도 있다.

 

incremental model process

- 초기 버전이 존재하고 조금씩 변화하면서 버전을 바꿔간다.

- Outline description: 소프트웨어가 어느 방향으로 갈지와 핵심 기능을 정한다.

- 각 버전은 Specification, development, validation하는 것이 동시다발적으로 이루어질 수 있음

 

 

단점

- 결과는 존재하지만 프로세스가 보이지 않기에 관리자가 관리하기 어려울 수 있다.

- 수동적인 개발자들이 모였다면 개발 속도나 효율성이 떨어질 수 있다.

- 중구난방식의 개발이 되면 전체적인 조화가 없을 수 있기에 plan-driven에 비해 기능을 추가하다보면 확장성이 떨어진 소프트웨어가 나올 수 있다.

- 개발속도가 빠르기 때문에 관리자가 따라야할 regulation(법, 관례 등)을 지키지 못하는 경우가 존재할 수 있다.

 

 

3) Integration and Configuration

- 기존에 존재하는 모듈이나 api와 같은 것들을 연결하는 방법을 말한다.

- 최근에 많이 사용하고 점점 중요해지고 있다.

- plan-driven이거나 agile이 가능하다.

- 디자인, 개발 등에서 중요한 방법이다.

- COTS(commercial-off-the-shelf): 필요한 것에 대해 개발하지 않고 돈주고 사오는 방식

- reusable 소프트웨어라고도 한다.

- 필요한 내용을 잘 찾고 잘 사용하는 것이 중요하다.

 

(1) 종류

i) stand-alone application: COTS 방식으로 가져와서 사용하기에 configuration만 하면 된다.

ii) 라이브러리: 함수나 클래스가 소스코드나 기계어로 번역된 것을 사용한다.

iii) 웹서비스: api와 같이 호출하고 결과를 받는다. 이에 따라 내 컴퓨터로 코드를 가져오지 않는다. 요즘 점차 웹서비스가 점점 중요해지고 있다.

 

 

Integration and Configuration Process

- 소프트웨어를 찾고 짜고자하는 기능과 부합한지 확인해야한다.

- 고치지 않아도 되면 configuration 단계로 간다.

- 그렇지 않으면 현재 있는 모듈을 활용하고자 하는 목표에 맞춰서 모듈간에 통신할 수 있도록 한다. (adaptation)

- 일부 원하는 기능이 없다면 직접 개발한 뒤에 이를 모두 합친다. (integrate system)

 

(2) 장단점

장점

- 리스크와 비용이 줄어든다.

- 더 빠른 시간 안에 문제를 해결할 수 있다.

 

단점

- 내가 정의한 요구사항을 만족하는지 점검이 필요하다.

- 주요기능을 재사용했기 때문에 해당 기능이 내가 원하는 기능과는 다르게 발전하거나, 내가 원하는 방향대로 더 발전시키고자 할 때는 이를 반영하기 어렵다.

 

 

2. Process activities

각각의 프로세스에는 필요한 동작들이 있다.

1) Specification 단계

각 동작들의 아웃풋, 누가 어떤 역할을 가질지, 선행/후행단계 등을 정한다.

plan based로 접근한다.

 

(1) Requirements elicitation and analysis

- 아무것도 없는 상황에서 큰 그림을 그려 system description(아웃풋)을 명시화해야한다.

- system description 단계에서 내부적인 동작보단 소프트웨어에 대한 전체적인 내용을 기술한다.(아웃풋, 동작 등)

 

(2) Requirements specification

- 개발을 위해 필요한 요구사항을 명세화해야해 이후 user and system requirement을 내보내야한다.

- user and system requirement 단계에서 시나리오에 따른 요구사항을 항목별로 구체적으로 써낸다. 

 

(3) Requirements validation

- 요구사항을 점검한 뒤 system descriptions, user and system requirements를 종합해 requirements document을 내보낸다.

- requirement document: 구현을 위한 문서 작성으로 이후 개발팀에게 전달된다.