[소프트웨어공학] SoftWare Process

ch 2_SoftWare Process

Software Process

개발에 필요한 구조화된 일련의 활동 소프트웨어 시스템

• Specification(사양) : 시스템이 수행해야 하는 작업을 정의
• Design and Inplementation(설계 및 구현) : 시스템의 조직을 정의하고 시스템을 구현
• Validation(유효성 검사) : 고객의 요구대로 작동하는지 확인
• Evolution : 변화하는 고객 요구에 대응하여 시스템 변경

software process description

프로세스를 설명하고 논의할 때 일반적으로 specifying data model, designing user interface 등의 활동과 순서에 대해 얘기한다

• Products : 프로세스 활동의 결과
• Roles : 관련된 사람들의 책임을 반영
• Pre/Post - condition : 프로세스 활동이 제정되거나 제품이 생산되기 전 후에 참인 진술

plan-driven and agile process

• Plan-driven process : 프로세스 활동을 미리 계획하고, 진행상황을 측정
• Agile process : 점진적이며 변화하는 고객의 요구사항을 반영하도록 프로세스를 변경하는것이 쉽다.

Software process models

Waterfall model

계획 중심 모델, 사양 및 개발의 분리되고 뚜렷한 단계

plan-diven

• 요구사항 분석 및 정의
• 시스템 및 소프트웨어 설계
• 구현 및 단위 테스트
• 통합 및 시스템 테스트
• 운영 및 유지보수

⇒ 폭포수 모델의 가장 큰 단점은 진행 후 변화를 수용하기 어렵다는점이다.

⇒ 원칙적으로 다음 단계로 넘어가기 전에 한 단계를 완료해야 한다.

폭포수 모델은 여러 사이트에서 시스템을 개발하는 대규모 시스템 엔지니어링 프로젝트에서 주로 사용된다.

Incremental development

사양, 개발 및 검증이 inter-leave

plan-driven or agile

• 요구사항이 변화하는 고객을 수용하는 비용이 줄어든다.
• 분석 및 문서화의 양이 폭포수 모델보다 훨씬 적다.
• 완료된 개발 작업에 대한 고객 피드백을 쉽게 얻을 수 있다.
• 고객은 소프트웨어가 얼마나 구현되었는지 확인하고 의견을 제시할 수 있다.
• 유용한 소프트웨어를 보다 신속하게 고객에게 제공하고 배포할 수 있다.
• 고객은 폭포수 모델보다 더 빨리 소프트웨어를 사용할 수 있다.

단점

• process 과정이 보이지 않음시스템이 빠르게 개발되기 때문에 시스템의 모든 버전을 반영하는 문서 작성하는것은 비효율적
• 진행상황을 측정하기 위한 정기적인 결과물이 필요하다.
• system structure 는 increments가 추가됨에 따라 저하되는 경향이 있다.추가적인 소프트웨어 변경사항을 통합하는 것이 점점 더 어렵고 비용이 많이 든다.
• 리펙토링 없는 정기적인 변경은 구조를 손상시키는 경향이 있다.

Integration and configuration(통합 및 구성)

시스템은 기존의 구성 가능한 요소들로 조립된다.

plan-driven or agile

• 시스템이 기존 구성요소에서 통합되는 소프트웨어 재사용을 기반으로 한다.
• 재사용된 요소는 사용자의 요구에 따라 동작과 기능을 조정
• 재사용(Reuse)는 다양한 유형의 비즈니스 시스템을 구축하기 위한 표준 접근방식이다.

reusable software

COTS : 특정 환경에서 사용하도록 구성된 독립 실행형 애플리케이션 시스템

서비스에 따라 개발된 웹 서비스 표준은 원격 호출로 사용할 수 있다.

• Requirements specification(요구 사양)
• Software discovery and evaluation(소프트웨어 검색 및 평가)
• Requiremets refinement(요구사항 개선)
• Application system configuration(애플리케이션 시스템 구성)
• Component adaptation and integration(컴포넌트 적응 및 통합)

장점

• 처음부터 개발되는 소프트웨어가 적어 비용 및 위험 감소
• 보다 빠른 시스템 딜리버리 및 구축

단점

• 사용자의 실제 요구를 충족하지 못할 수 있음
• 재사용 시스템 요소의 evolution에 대한 통제력 상실

Process activities

소프트웨어 시스템을 specifying, designing, implementing, testing하는 inter-leaved sequence

specification, development, validation, evolution은 다른 프로세스에서 다르게 구성된다.

(ex)폭포수는 순서대로 구성, incrementation 은 inter-leave처리

software specification

• 어떤 서비스가 필요한지, 시스템 운영 및 개발에 대한 제약을 설정
• Requirement engineering process
  • elicitaion(도출)
  • analysis(분석)
  • specification(사양) : 요구사항을 자세히 정의
  • validation(검증) : 유효성 확인

software design and implementation

시스템 사양을 실행 가능한 시스템으로 변환하는 프로세스

• software design : 소프트웨어 구조 설계
• implementation : 구조를 실행 가능한 프로그램으로 변환

설계 및 구현 활동은 inter-leave 될 수 있다 .

general model of design process

Design activities

• Architectural design : 시스템의 전체 구조, 주요 구성 요소, 이들의 관계 빛 배포 방법을 식별
• Database design : 시스템 데이터 구조를 디자인하고, 데이터 베이스에 표현
• Interface design : 시스템 구성 요소 간의 인터페이스를 정의
• Component selection and design : 재사용 가능한 부품을 찾고, 사용할 수 없는 경우 작동 방식을 설계

system Implementation

• Design and implementation :
• Programming
• Debugging
• Verification and validation(V&V) : (검토 및 검증)시스템이 사양을 준수하고 요구사항을 충족하는지 확인
• involves checking and review
• system test : test case로 시스템을 실행, 테스트는 일반적으로 사용되는 V&V 활동이다.

Test Stages

test 하지 않은 프로그램은 bug를 포함한다.

• Componenet testing : component는 독립적으로 테스트
• component는 기능 또는 엔티티 개체, 일관된 그룹일 수도 있다.
• System testing : 전체 시스템 테스트, testing of emergent properties
• Customer testing : 고객 데이터로 테스트

V-model

plan-driven 소프트웨어 테스트 단계

Software evolution

• 소프트웨어는 요구사항이 변화하는 상황에 따라 비즈니스를 지원하는 소프트웨어도 evolution하고 변화해야한다.

Coping with Chage(변화에 대응)

• 비즈니스 변화로 인해 변경된 시스템 요구사항
• 신기술 구현
• 새로운 os를 지원하기 위한 소프트웨어 update

변경은 재 작업(rework)으로 이어지므로 변경 비용에는 재작업(요구사항 재분석)과 새로운 기능 구현 비용이 포함된다.

Reducing the costs of rework

• change anticipation(변화 예측)
• ex)프로토 타입은 시스템의 일부 주요 기능을 고객에게 제공하여 변화를 보여줄 수 있다.
• change tolerance(변경 허용 범위)상대적으로 저렴한 비용으로 변경 사항을 수용할 수 있도록 변경 허용 범위
• incremental development 포함됨

Coping with changing requirements

• system prototyping
• 시스템의 일부를 고객의 요구사항과 설계의 타당성을 확인하기 위해 신속하게 개발
• incremental delivery이 과정에서는 change avoidance와 change tolerance를 지원한다.
• system incrementation을 고객에게 전달하여 의견 및 test

ProtoType

초기 시안을 제작하여 사용자의 요구사항 파악 및 애플리케이션의 목적 설정

• 요구사항 엔지니어링 프로세스 도출 및 검증
• 디자인 프로세스에서 옵션을 탐색하고 UI디자인을 개발
• 연속적으로 back-to-back test를 실행

장점

• 시스템의 사용성 향상
• 사용자의 실제 요구 일치
• 디자인 품질 향상
• 유지보수성 향상
• 개발 노력 감소

Prototype development

• 수정/개선사항의 목적을 명확하게 해서 필요 없는 기능은 과감하게 생략 가능
• Error checking , recovery 기능을 포함하지 않아도 됨
• 기능적 요구사항에 중점을 둔다.

Throw-away prototypes

• 프로토 타입은 개발 후 폐기한다.
• non-functional requirements를 충족하도록 하는것이 불가능할 수도 있다.
• 문서화를 하지 않는다.
• 빠른 변화를 수용한다.
• 일반적인 회사의 품질 표준을 충족하지 못할 수도 있다.

Incremental delivery

• 시스템을 필요한 기능의 일부를 제공하는 incremental 로 단일 제공한다.
• 사용자의 요구사항이 우선 적용됨
• incremental development가 시작되면 이후 요구사항을 동결한다.

Incremental development and delivery

• incremental development
  • 시스템을 increments로 개발하고 다음 개발을 진행하기 전에 increments를 평가한다.
  • 애자일 방식에 사용되는 접근방식
  • 사용자/고객 proxy가 평가를 수행
• incremental delivery
  • 최종 사용자가 사용할 increments를 배포
  • 소프트웨어의 실제 사용에 대한 현실적인 평가
  • replacement system보다 기능이 적기 때문에 replavement system에 대해 구현 어려움

장점

• increments 마다 고객에게 시스템 기능을 먼저 보여줄 수 있다.
• 전체 프로젝트 실패 위험이 낮다.
• 우선순위가 가장 높은 기능이 가장 많은 테스트를 받는 경향이 있다.

단점

• increments를 시행할 때까지 요구사항이 구체적으로 정의되지 않아 모든 공통 facilities를 파악하기 어려울 수 있다.
• 소프트웨어 개발과 함께 반복 프로세스를 진행하기 때문에 procurement model 과 충돌할 수 있다 .

Process improvement

• 소프트웨어 품질을 향상시키고 비용을 줄이거나 개발 프로세스를 가속화하는 방법으로 프로세스 개선
• 기존의 프로세스를 이해하고 변셩하여 제품 품질을 높이거나 비용 및 개발 시간을 줄이는것을 의미한다.

Approaches to improvement

• process maturity approach : 프로젝트 관리를 개선하고 우수한 소프트웨어 엔지니어링 방식을 도입하는데 중점
• process matyrity level은 회사의 우수한 technical 및 management practice가 채택된 정도를 말한다.
• agile approach : 반복적인 작업에 중점애자일 방법의 주요 특징은 기능의 신속한 제공과 변화하는 고객 요구 사항에 대한 응답성이다.
• 개발 및 소프트웨어 프로세스의 overhead 감소

Process improvement cycle

• Measurement
• : 소프트웨어 프로세스 또는 제품의 속성을 측정
• analysis
• : 현재 프로세스를 평가하고 프로세스의 약점 및 bottleneck 현상을 식별한다.
• changecycle을 반복하여 변경 효과에 대한 데이터를 수집
• : 식별된 프로세스 약점을 해결하기 위해 프로세스 변경이 제안됨

Process Measurement

• quantitative process data를 수집해야한다.
• 프로세스 표준을 정의하기 위해 가능한 한 정량적인 공정 데이터를 수집한다.
• process measurement는 공정 개선을 평가하는데 사용된다.

Process Metrics

• 프로세스 활동이 완료되는 데 걸리는 시간
• 프로세스나 활동에 필요한 자원
• 특정 이벤트의 발생 횟수

SEI capability maturity model(능력 성숙도 모델)

1. Initial : essentially uncontrolled
2. Repeatable : 제품 관리 절차 정의 및 사용
3. Defined : 프로세스 관리 절차, 전략 정의 및 사용
4. Managed : 품질 관리 전략 정의 및 사용
5. Optimising : 프로세스 개선 전략 정의 및 사용

Key point!

• Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes.소프트웨어 프로세스 모델은 이러한 프로세스의 추상적 표현이다.
• 소프트웨어 프로세스는 소프트웨어 시스템을 생산한다.
• General process models describe the organization of software processes.
• 일반적인 프로세스 모델은 회사의 소프트웨어 프로세스로 설명한다.
• Examples of these general models include the ‘waterfall’ model, incremental development, and reuse-oriented development.
• 일반 모델의 예로, 폭포형 모델, 점진적 개발 및 재사용 지향 개발이 있다.
• Requirements engineering is the process of developing a software specification.
• 요구사항 엔지니어링은 소프트웨어 사양을 개발하는 프로세스이다.
• Design and implementation processes are concerned with transforming a requirements specification into an executable software system.
• 설계 및 구현 프로세스는 요구 사항 사양을 실행 가능한 소프트웨어 시스템으로 변환하는것과 관련된다.
• Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.
• 소프트웨어 유효성 검사는 시스템이 사양을 준수하고 사용자의 실제 요구를 충족하는지 확인하는 프로세스이다.
• Software evolution takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful.
• 소프트웨어 진화는 새로운 요구 사항을 충족하기 위해 기존 소프트웨어 시스템을 변경할 때 발생합니다. 소프트웨어는 계속 유용하게 발전해야 합니다.
• Processes should include activities such as prototyping and incremental delivery to cope with change.
• 프로세스에는 변화에 대처하기 위한 프로토타이핑 및 점진적 전달과 같은 활동이 포함되어야 합니다.
• Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole.
• 프로세스는 시스템 전체를 방해하지 않고 변경이 이루어질 수 있도록 반복적인 개발 및 전달을 위해 구조화될 수 있습니다.
• The principal approaches to process improvement are agile approaches, geared to reducing process overheads, and maturity-based approaches based on better process management and the use of good software engineering practice.
• 프로세스 개선을 위한 주요 접근 방식은 프로세스 오버헤드를 줄이는 데 초점을 맞춘 민첩한 접근 방식과 더 나은 프로세스 관리 및 우수한 소프트웨어 엔지니어링 관행을 기반으로 하는 성숙도 기반 접근 방식입니다.
• The SEI process maturity framework identifies maturity levels that essentially correspond to the use of good software engineering practice.
• SEI 프로세스 성숙도 프레임워크는 기본적으로 우수한 소프트웨어 엔지니어링 관행의 사용에 해당하는 성숙도 수준을 식별합니다.