* Process activities
- 기술적 행동(technical activities), 관리적 행동(managerial activities), 통합적 행동(collaborative activities)
함께일어난다.
- 4가지의 기본적 프로세스 엑티비티가 존재한다.
> specification, development, validation, evolution
- 4가지의 기본 프로세스 엑티비티는 다음과 같은 두가지 방법으로 이뤄진다.
ⓐ waterfall : 연속적 형태로 발생한다.
ⓑ incremental : Interleaved(다음 과정이 이전 과정과 겹침)형태로 발생한다.
ex)
* Software specification(소프트웨어 명세)
- 무슨 서비스를 할 것인가? 이에 필요한 기능이 무엇인가?
- 이 서비스를 실행할 때 제한되는 사항은 무엇인가? (기능을 만족시킬 제약사항은 무엇인가?)
- 소프트웨어 명세하는 분야도 하나의 공학으로 "요구사항 공학"으로 존재한다.
- 요구사항 공학(Requirements engineering) 과정
> 적합성 검토(Feasibility study)
: 개발의 가능성이 있는가? 필요한 것인가?
: 산출물 : Feasibility Report
> 요구사항 추출 및 분석(Requirements elicitation and analysis)
: 인터뷰와 설문지를 사용하여 만들며, 서로의 기능이 충돌하는가 여부를 분석한다
: 산출물 : System models
> 요구사항 명세(Requirements specification)
: 산출물 : user(일반 고객들 상대) and system(개발자만 이해가능한 명세) requirements
> 요구사항 검토(Requirements validation)
: 검토를 통해서 완벽한 Requirements document를 만든다.
: Requirements document는 Feasibility Report, System model, requirements가 모두 포함되어야한다.
* Software design and implementation
- 이 과정은 명세화 부분에서 나온 문서를 설계 및 구현을 하여 하나의 프로그램으로 만드는 과정이다.
- Software Design Input : 환경 정보, 요구사항, 데이터 표현
- Design Activities : 아키텍쳐 설계, 인터페이서 명세, 컴포넌트 설계, DB설계, 알고리즘 설계
- Design output : 시스템 아키텍쳐, 데이터베이스, 인터페이스, 컴포넌트
- Software Design activities
ⓐ Architectural Design
> 시스템의 큰 그림 모형을 만듬(주요 컴포넌트, 컴포넌트 간의 관계, 컴포넌트 분산관계를 만듬)
ⓑ Interface Design
> 컴퓨터간의 Input, Output등을 정의
ⓒ Component Design
> 각각의 컴포넌트 명세
ⓓ Database Design
> Database 설계
ⓔ Data structure design
>데이터 구조및 알고리즘 설계
* Software validation
- Verification and Validation(V&V) : 요구사항을 만족하는지 보이는 작업
> Verification : 시스템이 Error를 발생하는지 여부를 검사
> Validation : 고객이 원하는 것인가를 점검
- Check List를 사용 또는 관련자를 통해서 Feed를 받거나, test case를 이용하여 시스템을 직접 테스트하여 점검
- 테스트 진행 과정
ⓐ Component Testing = Unit testing = 단위 테스트
> 단위 테스트는 컴포넌트를 개발하면서 바로바로 실행된다.
> 컴포넌트 끼리 묶어서 테스트도 가능하다.
ⓑ System testing
> 컴포넌트가 통합되어 하나의 시스템이 되었을 때의 테스트
> 하나의 System으로 합칠때 발생하는 성격(수행시간, 신뢰성, 보안성 ... 등)의 테스트가 중요하다.
(참발적 특성, emergent properties)
ⓒ Acceptance testing = 인수 테스트
> 고객과 함께 하는 Test(고객이 만든 data를 이용하여 테스트를 진행한다)
> 컴퓨터를 전문적으로 하는 사람이 아니기 때문에 불필요한 입력으로 인한 예상치 못한 결과를 얻을 수 있다.
- Plan-driven software process의 테스팅 과정
ⓐ 각 단계별을 걸치면서 Testing할 계획이 산출된다.
> 기능 명세화, 시스템 명세화(인수 테스트 계획) / 시스템 명세화, 시스템 디자인(시스템 통합 테스트 계획)
시스템 디자인, 새부 디자인(서브 시스템 통합 테스트 계획)
ⓑ 하나의 시스템이 나오면, 각 문서에 의거하여 테스트를 진행한다.
* Software evolution
- 비지니스 환경이 변화되고, 이에 따라서 요구사항이 변화한다. 이에따라 소프트웨어도 변화해야한다.
> 플랫폼의 변화, 비지니스 변화, 새로운 기술등.
- 새로운 시스템 개발이 점점 사라지기 때문에, 개발과 유지보수/진화의 구분이 모호 해지고 있다.
- 진화로 인해서 변환 비용이 발생한다.
> 변환 비용 : Re-analysing requirements + implementing new functionality
- 변환 비용을 줄이기 위한 노력
ⓐ Change avoidance / 변화를 피할 수 있으면 피해라.
> 가능한 모든 변화에 대한 결과의 가능성을 미리 보여주어서 선택하게 한다.
> prototype system : 보고 제품에 대한 느낌을 느낄 수 있는 시연 가능한 겉 껍데기를 만든다.
ⓑ Change tolerance / 변화에 의한 파급효과가 적게 하라.
> 변화가 작은 비용으로 일어 날수 있게 프로세스를 설계(프로세스를 세세하게 나눠서 설계한다.)
- 기술적 행동(technical activities), 관리적 행동(managerial activities), 통합적 행동(collaborative activities)
함께일어난다.
- 4가지의 기본적 프로세스 엑티비티가 존재한다.
> specification, development, validation, evolution
- 4가지의 기본 프로세스 엑티비티는 다음과 같은 두가지 방법으로 이뤄진다.
ⓐ waterfall : 연속적 형태로 발생한다.
ⓑ incremental : Interleaved(다음 과정이 이전 과정과 겹침)형태로 발생한다.
ex)
* Software specification(소프트웨어 명세)
- 무슨 서비스를 할 것인가? 이에 필요한 기능이 무엇인가?
- 이 서비스를 실행할 때 제한되는 사항은 무엇인가? (기능을 만족시킬 제약사항은 무엇인가?)
- 소프트웨어 명세하는 분야도 하나의 공학으로 "요구사항 공학"으로 존재한다.
- 요구사항 공학(Requirements engineering) 과정
> 적합성 검토(Feasibility study)
: 개발의 가능성이 있는가? 필요한 것인가?
: 산출물 : Feasibility Report
> 요구사항 추출 및 분석(Requirements elicitation and analysis)
: 인터뷰와 설문지를 사용하여 만들며, 서로의 기능이 충돌하는가 여부를 분석한다
: 산출물 : System models
> 요구사항 명세(Requirements specification)
: 산출물 : user(일반 고객들 상대) and system(개발자만 이해가능한 명세) requirements
> 요구사항 검토(Requirements validation)
: 검토를 통해서 완벽한 Requirements document를 만든다.
: Requirements document는 Feasibility Report, System model, requirements가 모두 포함되어야한다.
* Software design and implementation
- 이 과정은 명세화 부분에서 나온 문서를 설계 및 구현을 하여 하나의 프로그램으로 만드는 과정이다.
- Software Design Input : 환경 정보, 요구사항, 데이터 표현
- Design Activities : 아키텍쳐 설계, 인터페이서 명세, 컴포넌트 설계, DB설계, 알고리즘 설계
- Design output : 시스템 아키텍쳐, 데이터베이스, 인터페이스, 컴포넌트
- Software Design activities
ⓐ Architectural Design
> 시스템의 큰 그림 모형을 만듬(주요 컴포넌트, 컴포넌트 간의 관계, 컴포넌트 분산관계를 만듬)
ⓑ Interface Design
> 컴퓨터간의 Input, Output등을 정의
ⓒ Component Design
> 각각의 컴포넌트 명세
ⓓ Database Design
> Database 설계
ⓔ Data structure design
>데이터 구조및 알고리즘 설계
* Software validation
- Verification and Validation(V&V) : 요구사항을 만족하는지 보이는 작업
> Verification : 시스템이 Error를 발생하는지 여부를 검사
> Validation : 고객이 원하는 것인가를 점검
- Check List를 사용 또는 관련자를 통해서 Feed를 받거나, test case를 이용하여 시스템을 직접 테스트하여 점검
- 테스트 진행 과정
ⓐ Component Testing = Unit testing = 단위 테스트
> 단위 테스트는 컴포넌트를 개발하면서 바로바로 실행된다.
> 컴포넌트 끼리 묶어서 테스트도 가능하다.
ⓑ System testing
> 컴포넌트가 통합되어 하나의 시스템이 되었을 때의 테스트
> 하나의 System으로 합칠때 발생하는 성격(수행시간, 신뢰성, 보안성 ... 등)의 테스트가 중요하다.
(참발적 특성, emergent properties)
ⓒ Acceptance testing = 인수 테스트
> 고객과 함께 하는 Test(고객이 만든 data를 이용하여 테스트를 진행한다)
> 컴퓨터를 전문적으로 하는 사람이 아니기 때문에 불필요한 입력으로 인한 예상치 못한 결과를 얻을 수 있다.
- Plan-driven software process의 테스팅 과정
ⓐ 각 단계별을 걸치면서 Testing할 계획이 산출된다.
> 기능 명세화, 시스템 명세화(인수 테스트 계획) / 시스템 명세화, 시스템 디자인(시스템 통합 테스트 계획)
시스템 디자인, 새부 디자인(서브 시스템 통합 테스트 계획)
ⓑ 하나의 시스템이 나오면, 각 문서에 의거하여 테스트를 진행한다.
* Software evolution
- 비지니스 환경이 변화되고, 이에 따라서 요구사항이 변화한다. 이에따라 소프트웨어도 변화해야한다.
> 플랫폼의 변화, 비지니스 변화, 새로운 기술등.
- 새로운 시스템 개발이 점점 사라지기 때문에, 개발과 유지보수/진화의 구분이 모호 해지고 있다.
- 진화로 인해서 변환 비용이 발생한다.
> 변환 비용 : Re-analysing requirements + implementing new functionality
- 변환 비용을 줄이기 위한 노력
ⓐ Change avoidance / 변화를 피할 수 있으면 피해라.
> 가능한 모든 변화에 대한 결과의 가능성을 미리 보여주어서 선택하게 한다.
> prototype system : 보고 제품에 대한 느낌을 느낄 수 있는 시연 가능한 겉 껍데기를 만든다.
ⓑ Change tolerance / 변화에 의한 파급효과가 적게 하라.
> 변화가 작은 비용으로 일어 날수 있게 프로세스를 설계(프로세스를 세세하게 나눠서 설계한다.)