소프트웨어 공학 Chapter02

The software process

소프트웨어 프로세스에 공통적으로 포함되는 4가지

• Specification
  • 시스템이 무엇을 해야 하는지 정의
• Design and implementation
  • 시스템 구성을 정의하고 시스템을 개발
• Validation
  • 고객이 무엇을 원하는지 확인
• Evolution
  • 고객의 변화하는 요구사항에 시스템을 변경

Software process models

Waterfall

계획 중심 모델. 분리되고 뚜렷한 단계의 명세서와 개발을 가집니다.

Phase

1. 요구사항 분석 및 정의
2. 시스템과 소프트웨어 디자인
3. 개발과 유닛 테스트
4. 병합과 시스템 테스트

각 단계별 결과로 하나 이상의 문서가 산출됩니다. 각 단계는 다음 단계 시작 전에 끝나며 결과물을 점검해야 합니다. 필요 시엔 전 단계를 피드백합니다.

문제점

프로젝트를 뚜렷한 단계로 나누지 않으면 변화하는 고객 요구사항에 대응하기 어렵다

• 요구사항이 잘 정의되고 개발 기간 중 변화가 극적으로 적은것에 적합
• 매우 적은 비즈니스 시스템이 안정된 요구사항을 가짐

워터폴 모델은 대부분 여러 사이트에서 개발되는 대규모 시스템 엔지니어링 프로젝트에서 사용됨

• 이러한 환경에서, 계획 중심적 특성은 작업을 조정하는데 도움이 됩니다.

Incremental development

명세, 개발, 확인 과정이 인터리브함. 계획 중심이거나 애자일 기법

integration and configuration

시스템은 기존의 구성 가능한 요소로부터 조립됩니다. 계획 중심이거나 애자일 기법

V-model

뒤에 설명함

Prototyping

뒤에 설명함

Process Activities

Software Specification

시스템 작동 및 개발에 대한 제약조건과 어떤 서비스가 필요한지 수립하는 프로세스

요구사항 엔지니어링 프로세스

요구사항 도출 및 분석

시스템의 이해관계자가 시스템에 무엇을 필요로 하거나 기대하는가?

요구사항 명세

요구사항을 자세히 정의

요구사항 확인

요구사항의 유효성 검사

Software design and implementations

특징

시스템 사양을 실행 가능 시스템으로 변환하는 프로세스입니다.

Software design

소프트웨어 구조를 디자인하는 것은 명세를 실현하는 것입니다.

Implementation

해당 구조를 실행 가능한 프로그램으로 변환합니다.

디자인과 개발 활동 단계는 밀접하게 관련되어 있으며 인터리브 될 수 있습니다.

디자인 활동

아키텍쳐 설계

시스템의 전반적인 구조, 주 구성 요소, 관계 및 분배 방법을 식별합니다.

데이터베이스 디자인

시스템 데이터 구조와 그것들이 데이터베이스에서 어떻게 표현되는지 디자인합니다.

인터페이스 디자인

시스템 컴포넌트들 사이의 인터페이스들을 정의합니다.

컴포넌트 선택과 디자인

재사용 가능한 컴포넌트 검색, 사용할 수 없는 경우 작동 방법을 설계합니다.

시스템 구현

프로그램 또는 프로그램을 개발하거나 응용 프로그램 시스템을 구성하여 구현됩니다.

디자인과 구현

소프트웨어 시스템의 대부분의 형식에 대한 인터리브한 활동입니다.

프로그래밍

표준 프로세스가 없는 개인적인 활동입니다.

디버깅

프로그램의 오류를 찾고 수정하는 활동입니다.

소프트웨어 검증

확인과 검증(Verification and Validation)

시스템이 사양에 부합하고 시스템 고객의 요구사항을 충족함을 나타내기 위한 것 프로세스 확인과 리뷰와 시스템 테스트를 포함합니다.

시스템 테스트에는 시스템에서 처리 할 실제 데이터의 사양에서 파생 된 테스트 사례로 시스템을 실행하는 작업이 포함됩니다.

Testing

Component Test

각각의 컴포넌트는 독립적으로 테스트 컴포넌트는 기능 또는 객체이거나 이러한 개체에 일관된 그룹

System Test

컴포넌트들 사이의 의도하지 않은 상호 작용 또는 컴포넌트 인터페이스 문제로 인한 오류 탐색 대규모 시스템의 경우에는 서브시스템 별 다단계 프로세스로 진행

Customer Test

판매용 소프트웨어의 경우 beta testing이 사용자 테스트 Customized product인 경우 요구사항 명세의 오류를 발견할 수 있습니다.

Software Evolution

• 소프트웨어는 본질적으로 변화 가능하고 유연함
• 변화하는 비즈니스 상황을 통해 요구사항이 변함에 따라 비즈니스를 지원하는 소프트웨어 또한 발전하고 변화해야 함
• 완전히 새로운 소프트웨어 개발이 거의 없기에 개발과 유지보수는 연속적인 활동으로 받아들이고 있음

계획 중심 소프트웨어 프로세스에서의 테스트 단계(V-모델)

• 기본적으로 워터폴 모델의 구조
• V-모델은 오류를 줄임
• 고객 요구사항의 변화에 대응하기 힘듦

테스트 활동을 개발 단계가 아니라 명세 단계에서 함께 시작합니다.

Imcremental Development

장점

• 변화하는 고객 요구사항을 수용하는 비용 절감
• 완료된 개발 작업에 대한 고객의 피드백을 얻기 더 쉬움
• 고객에게 효율적인 소프트웨어를 보다 신속하게 제공하고 배포

문제점

• 프로세스가 명확하지 않음
  • 관리자는 진행 상황을 측정하기 위해 정기적인 결과물이 필요합니다. 만약 시스템이 빨리 개발된다면 시스템의 모든 버전에 대응되는 서류를 만들어야 하기에 비용 효율적이지 않습니다.
• 새로운 Increments가 추가될 때 시스템 구조가 감소하는 경향이 있음
  • 소프트웨어를 개선하기 위해 리팩토링에 시간과 돈을 소비하지 않는 한 정기적인 변경은 구조를 손상시킵니다. 추가 소프트웨어 변경 사항 통합은 점점 더 어려워지고 비용이 많이 듭니다.

Integration and configuration

특성

• 시스템이 기존의 컴포넌트 또는 응용 프로그램 시스템에서 통합되는 소프트웨어 재사용을 기반으로 함
• 재사용된 요소는 사용자의 요구사항에 맞게 동작 및 기능을 조정할 수 있음
• 자사용은 이제 많은 형식의 비즈니스 시스템을 만드는 것에 표준적인 접근 방식

재사용 가능한 소프트웨어 형식

• 특정 환경에서 사용하도록 구성된 독립 실행 형 응용 프로그램 시스템
• .NET Framework 또는 J2EE와 같은 구성 요소 프레임 워크와 통합 될 패키지로 개발 된 객체의 컬렉션
• 서비스 표준에 따라 개발되고 원격 호출에 사용할 수 있는 웹서비스

장점 및 단점

• 적은 소프트웨어가 처음부터 개발되므로 비용과 위험이 줄어든다.
• 시스템의 빠른 배포가 가능하다.
• 요구사항 절충은 필연적이므로 시스템이 사용자의 실제 요구를 충족시키지 못할 수 있다.
• 재사용된 시스템 요소의 진화에 대한 통제력 상실

Coping with change(변화에 대처)

변화는 모든 거대한 소프트웨어 프로젝트에서 필연적

• 사업적인 변화는 새롭고 변화된 시스템 요구사항을 이끈다.
• 새로운 기술은 구현 개선을 위한 새로운 가능성을 연다.
• 플랫폼의 변화는 응용 프로그램 변화를 필요로 한다.

변경 비용에는 새로운 기능 구현 비용뿐만 아니라 재작업도 포함

Reducing the costs of the rework

소프트웨어 프로세스에는 상당한 재작업이 요구되기 전에 가능한 변경을 예측할 수 있는 활동이 포함된 경우 변경 예상 상대적으로 낮은 비용으로 변경사항을 수용할 수 있도록 프로세스가 설계되는 경우 허용오차를 변경

Coping with changing requirements

시스템 프로토타입

• 고객의 요구사항과 설계 타당성을 확인하기 위해 빠르게 개발되어진 시스템의 버전 또는 시스템의 부분
• 전체 시스템에 대한 요구사항의 성급한 적용 방지
• 비교적 낮은 비용으로 소프트웨어 변경

Software prototype

프로토타입은 개념을 시연하고 설계 옵션을 시험해보는 데 사용되는 시스템의 초기 버전 다음과 같이 사용됩니다.

• 요구사항 도출 및 검증에 도움이 되는 요구사항 엔지니어링 프로세스
• 사용자 인터페이스 개발을 위해 사용 가능
• Back-to-back test
  • 동일 컴포넌트의 두 가지 이상의 버전에 대해서 유사한 입력을 가지고 결과의 유사도를 측정하는 테스트

프로토타입의 장점

1. 시스템 사용성 증가
2. 사용자의 진짜 요구와 근접
3. 디자인 품질 향상
4. 유지관리성 개선
5. 개발 작업 감소

프로토타입 개발

• 빠른 프로토타입 개발 언어 또는 도구를 기반으로 할 수 있다.
• 기능 이탈이 발생할 수 있다.
  • 프로토타입은 잘 이해되지 않은 제품이 초점을 맞춰야 함
  • 오류 확인과 복구는 프로토타입에 포함되지 않음
  • 기능적이지 않은 요구사항(신뢰성과 보안)보다는 기능에 초점

프로토타입 폐기

• 프로토타입은 생산 시스템에 적합하지 않으므로 개발 이후 제거되어야 함
  • 기능적이지 않은 요구사항을 충족시키기 위해 시스템을 조정하는 것은 불가능
  • 프로토타입은 일반적으로 문서화되지 않음
  • 프로토타입 구조는 일반적으로 빨느 변경을 통해 저하됨
  • 프로토타입은 아마 일반적인 조직 품질 표준을 충족시키지 못할 것

Incremental delivery

• 시스템을 단일 배포로 제공하는 대신 개발 및 배포는 필요한 기능의 일부를 제공하는 부분으로 분해됩니다.
• 사용자 요구사항은 우선적이고 가장 높은 우선 순위가 초기 증가분으로 포함됩니다.
• 일단 증분의 개발이 시작되면, 이후의 증분에 대한 요구사항은 계속 진화할 수 있지만 요구사항은 동결

동작 방식

1. 윤곽 요구사항 정의
2. 증분에 요구사항 할당
3. 시스템 아키텍쳐 디자인
4. 시스템 증분 개발
5. 증분 확인
6. 증분 통합
7. 시스템 확인
8. 증분 배포
   • 시스템이 완성이라면 종료
   • 미완성이라면 4번으로

증분 배포의 장점

• 고객의 가치는 각 단계별로 제공되므로 시스템 기능을 더 빨리 사용할 수 있음
• 초기 증분은 이후 증분에 대한 요구사항을 유도하는데 도움이 되는 프로토타입 역할을 함
• 전체적인 프로젝트 실패에 대한 적은 위험
• 가장 높은 우선순위를 가지는 시스템 서비스는 더 많은 테스트를 받는 경향이 있음

증분 배포의 문제점

• 증분 배포방식은 기존 시스템을 신규 시스템으로 대체 시 기능이 충분치 않아 적용하기 적절하지 않음
• 대부분의 시스템에는 시스템의 다른 부분에서 사용되는 일련의 기본 기능이 필요함
  • 증분을 구현할 때까지 요구 사항이 세부적으로 정의되어 있지 않기 때문에 모든 증분에 필요한 공통 시설을 식별하기가 어려울 수 있음
• 반복적 프로세스의 본질은 소프트웨어와 함께 스펙이 개발된다는 것
  • 그러나 이는 전체 시스템 사양이 시스템 개발 계약의 일부인 많은 조직의 조달 모델과 충돌함