소프트웨어 공학 CH2. SW Process

Software Process Model

• 소프트웨어 시스템을 만들때 필요한 활동

1. Specification

• 시스템이 할것 정의
  

2. Design and Implementation

• 시스템 구현
  

3. Validation

• 고객의 요구에 대조해 시스템 확인
  

4. Evolution

• 고객의 필요 변화에 따라 시스템을 변경한다.
  

각각의 단계에 다음이 포함된다.

1. 결과물

2. 역할

3. 사전/사후 상황

Plan-driven process

• 모든 프로세스가 미리 계획대로 진행된다.

Agile process

• 계획이 고객의 요구를 쉽게 반영한다.

현실적으로는 두 방식을 섞어서 사용한다

The Waterfall model - Plan driven

1. Requirement definition : 요구사항 분석
   • 이 프로젝트의 착수 여부, 무엇을 제공할 것인가.
2. System and Software design : 디자인
3. Implementation and Unit test : 구현과 테스트
4. Integration and System testing : 통합
   • 설계가 잘 되어 있어야 한다.
5. Operation and Maintenance
   • Operation : 이 프로그램을 어떻게 쓰느냐

• 프로젝트가 Inflexible해서 사용자 요구의 변화에 대응하기 어렵다.
• 큰 시스템의 개발에 주로 사용된다.

Incremental development - Agile

잘게 쪼개서 하나하나 해 나가자

• 단계별로 결과물이 나온다.
  • 최초 : Initial version
  • 중간 : Intermediate version
  • 최종 : Final version
• 고객 요구에 맟춰 변경하기위한 cost가 적다.
• 고객의 요구를 다음버전에 적용하기 쉽다.
• 빠르게 개발하고 배포해야 하는 상황에 유리하다.

• Process가 없는것 처럼 보인다 : 설계가 거의 없는것 처럼 보인다.
  • 빨리 개발하는것이 주 목적, 비용이 적게 든다.
• 언젠가는 Refactoring을 해야 한다.

Integration and Configuration

• 기존 Component나 Application system을 재활용하는데 기인한다.

• 재사용된것 들은 유저 요구에 따라 기능이 변경될수 있다.
• 빠르고 싸게 개발 가능
• 고객의 요구에 미달하거나 재사용된 시스템의 제어를 잃어버릴수 있음

재사용 가능한 소프트웨어

• Stand-alone software for particular environment
• Framework
• Webservice

Requirement Refinement : 요구 재정의

장점

• 처음 개발하는것 보다는 비용과 위험성이 줄어든다.
• 개발 속도가 빠르다.
• 실제 필요엔 맞지 않을수 있다.

---

Requirements Engineering Process

1. Software Specification

• 서비스에 요구되는것과 작동및 개발의 제한에 대한 작성

Requirements Elicitation and Analyze

• 시스템 이해관계자들이 요구하는것.

Requirements Specification

• 요구사항의 자세한 부분 확인하기

Requirements Validation

• 요구사항의 가용성 확인하기

2. Software design and Implementation

• 시스템 사양서를 실행 가능한 시스템으로

• 디자인
  • 사양서에 맞게 소프트웨어 구조 디자인

1. Architectural Design
   • 시스템 전체의 구조 파악
2. Database Design
   • 시스템 전역 데이터 구조 디자인
3. Interface Design
   • 시스템 Component간 Interface 디자인
4. Component selection / Design
   • 재사용 가능한 컴포넌트를 찾거나 개발

• 구현
  • 구조를 실행 가능한 프로그램으로 번역
  • 프로그램 개발 or 프로그램 설정
  • 프로그래밍은 따로 정형적 프로세스가 없다.
  • 디버깅을 통해 프로그램의 문제를 찾고 수정한다.

• 위 두 과정은 동시에 가능하다

3. Software Validation

• 시스템이 사양서에 잘 맞는지, 고객 요구에 부합하는지
  테스트 케이스를 통해 확인한다.

Testing Stages

• Component testing
  • 개별 컴포넌트 테스트
• System testing
  • 전체 시스템 테스트
• Customer testing
  • 실제 고객 데이터로 테스트, 고객 요구 검증

Test in plan-driven software

---

Software Evolution

• 소프트웨어는 가변적이고 변경 가능하다.
• 사업 상황에 따라 요구사항이 바뀌면 소프트웨어도 바뀌어야 함

---

변화에 적응하기

• 변화는 필연적
• 변화를 예측할것
• 변화 가능하게 할것

System Prototyping

• 시스템이나 그 일부를 빠르게 개발해 소비자의 요구를 확인하고 디자인의 실현가능성 확인
• 컨셉 확인과 체험을 위한 초기 버전 시스템
  • 사용성 증대
  • 요구 부합
  • 디자인 좋아짐
  • 유지보수 좋아짐
• 프로토타입 전용 언어/툴 사용 가능
• 기능성은 없을수 있다.

Throw away prototyping

• 개발 이후 프로토타입은 버려진다.
  • 기능과 관련되지 않은 부분 최적화가 안되어 있거나
  • 문서가 없고
  • 구현이 조악하며
  • 품질 표준에 미치치 못함

Incremental development

• 시스템을 분할해 개발해 다음 증분 개발 전에 확인한다.

Incremental delivery

• 증분을 엔드유저에게 배포한다.

장점

• 각각의 증분이 빠르게 사용자에게 전달됨
• 증분이 프로토타입의 역할을 해 요구사항이 명확해짐
• 프로젝트 실패 리스크 줄어듦
• 가장 중요도가 높은 서비스가 테스트를 더 받음

단점

• 쉽게 증분을 할수 없는 경우도 있다. < 기반 시설을 요구하는 등 >
• 증분을 쉽사리 합칠수 없는 경우도 있다.

---

측정 >> 분석 >> 변화

Process Improvement

• 소프트웨어의 품질 향상 및 성능 향상
• 현재 프로세스를 이해하고 퀄리티를 높이면서 비용과 시간은 줄임

Approach

• 프로세스 향상과 프로젝트 관리에 초점을 둠
• Agile approach에 반복적-개발은 프로세스 개발의 오버헤드를 줄임
  • 고객의 요구 더 빠른 수용

1. Process Measurement

• 정량적인 데이터를 모아야 한다.
• 개선 과정의 기준점이 됨

2. Process Analysis

• 현재 프로세스가 평가되어 약점과 병목을 확인
• 프로세스 모델이 설명되고 개발됨

3. Process Change

• 확인된 약점들을 통해 변경점이 확인된다.

Process measurement

• 정량적인 데이터가 수집되어야 한다.
• 프로세스 측정은 개선을 위해 사용되어야 한다.

Process metrics

• 프로세스 활동이 성사되는데 걸리는 시간
• 프로세스 혹은 활동이 요구하는 자원
• 특정 이벤트가 발생하는 숫자
  • EX. 오류

---

• 위로 갈수록 좋다.
  - 초창기
  - 매니징 됨
  - 확연히 구분됨
  - 정량화
  - 최적화 시스템