Transcript The Software Process

Slide 3.1
Object-Oriented and
Classical Software
Engineering
Yoo haeyoung
[email protected]
Dankook.University, Yoo haeyoung, 2005
CHAPTER 3
SOFTWARE
LIFE-CYCLE
MODELS
Dankook.University, Yoo haeyoung, 2005
Slide 3.2
학습목표







Slide 3.3
2차원 생명주기 모델들의 중요성
Unified Process의 다섯 개 핵심 웍플로우
산출물들이 테스트 웍플로우에서 테스트되는 것을
목록화 할 수 있게 함
Unified Process의 네 개의 페이즈
웍플로우들과 Unified Process 페이즈들간의 차이점
소프트웨어 프로세스 개선의 중요성을 인식
CMM(capability maturity model)
Dankook.University, Yoo haeyoung, 2005
3.1 Unified Process

Slide 3.4
최근까지 객체지향 기법들 중 가장 성공적인 세가지
방법론
Booch’s method
Jacobson’s Objectory
Rumbaugh’s OMT

1999년 Booch, Jacobson, Rumbaugh는 그들의
세가지 다른 기법들을 통합시켜 객체지향 분석과
디자인 기법을 완성하여 발표함
Original name: Rational Unified Process (RUP)
Next name: Unified Software Development Process
(USDP)
Name used today: Unified Process (for brevity)
Dankook.University, Yoo haeyoung, 2005
3.1 The Unified Process (contd)

Slide 3.5
Unified Process는 소프트웨어 프로덕트를 만들기
위한 일련의 단계들이 없음
 단일 “one size fit all"방법론은 소프트웨어 프로덕트들의
다양한 유형들 때문에 존재하지 않음

Unified Process는 적응적 방법론으로 보아야 함
개발하려고 하는 특정 소프트웨어 프로덕트를 위해 수정

UML is graphical
Picture는 천 마디의 말보다 가치 있음

UML diagram은 소프트웨어 엔지니어들을 빨리
그리고 정확하게 커뮤니케이션 할 수 있게 함
Dankook.University, Yoo haeyoung, 2005
3.2 객체-지향 파라다임에서 반복과 점진
Slide 3.6

Unified Process는 모델링 기법임
모델(model)은 개발될 소프트웨어 프로덕트의 하나 또는
그 이상의 측면들을 표현하는 UML 다이어그램의 집합

UML은 Unified Modeling Language의 약어
UML은 우리가 대상 소프트웨어 프로덕트를 표현하는데
사용되는 툴(tool)
Dankook.University, Yoo haeyoung, 2005
3.2 객체-지향 파라다임에서 반복과 점진 (contd)
Slide 3.7

객체-지향 파라다임은 반복적이고 점진적인
방법론임.즉
UML다이어그램들이 정확하다고 만족할 때 까지 반복에
반복을 거듭함

이 교재에서 Unified Process 의 버전은
한 학기나 반 학기 동안 학생 3명으로 이루어진 팀에
의하여 개발될 정도로 작은 소프트웨어 프로덕트로 구성

그러나 대규모 소프트웨어 프로덕트를 개발하기
위한 Unified Process에 대한 변경도 논의 됨
Dankook.University, Yoo haeyoung, 2005
3.2 객체-지향 파라다임에서 반복과 점진 (contd)
Slide 3.8

이 교재의 목적은 다음을 포함:
작은 소프트웨어 프로덕트를 통해 어떻게 개발을
하는지에 대한 이해
더 큰 소프트웨어 프로덕트가 만들어질 때 필요한 이슈에
대한 이해

우리는 한 학기나 반 학기에 완전한 Unified
Process를 배울 수 없음
폭넓은 연구와 끝없는 연습이 필요
Unified Process는 매우 많은 특징을 가지고 있음
대규모의 소프트웨어 프로덕트 케이스 연구는 거대함
Dankook.University, Yoo haeyoung, 2005
3.2 객체-지향 파라다임에서 반복과 점진 (contd)
Slide 3.9

이 교재에서 우리는 전체적인 많은 것들을
살펴보지만 Unified Process의 모든 것을 다루진
않음
다루는 토픽은 더 작은 프로덕트에 알맞음

더 큰 규모의 소프트웨어 프로덕트에 효과가 있기
위해서는 경험이 필요
Unified Process의 더 복잡한 기법에 대한 훈련이 따라야
함
Dankook.University, Yoo haeyoung, 2005
3.3 요구사항 웍플로우

Slide 3.10
Requirement workflow의 목표
client의 needs를 결정하기 위해

First,gain an understanding of the application
domain(간략하게 도메인이라고 부름)
즉 대상 소프트웨어 프로덕트가 운영될 특정 환경을 이해

Second, build business model
client의 business processes를 묘사하기 위해 UML를
사용
프로세스가 어느 단계에 있던지 client가 소프트웨어에
비용효과 면에서 믿을 수 가 없다면 개발은 즉시 종료
Dankook.University, Yoo haeyoung, 2005
3.3 요구사항 웍플로우 (contd)

Slide 3.11
Client의 제약(constraints)을 결정하는 것이 중요
데드라인 (Deadline)

오늘날의 software products는 종종 mission critical
병행 운행 (Parallel running)
이식성 (Portability)
신뢰성 (Reliability)
빠른 응답시간 (Rapid response time)
비용 (Cost)


고객은 개발자에게 얼마의 비용이 사용 가능한지를 거의 알려
주지 않음
입찰 절차(bidding procedure)가 그 대신 사용됨
Dankook.University, Yoo haeyoung, 2005
3.3 요구사항 웍플로우 (contd)

Slide 3.12
Client의 needs에 대한 예비조사를 주로 개념
조사(concept exploration)라고 부름. 이의 목적은
다음사항을 결정하는데 있음
client의 needs는 무엇인지
client가 원하지 않는지것은 무엇인지
Dankook.University, Yoo haeyoung, 2005
3.4 분석 웍플로우

Slide 3.13
Analysis workflow의 목표
요구사항들을 analyze하고 refine하기 위해

왜 requirements workflow 동안 analysis workflow를
하지 말아야 하는가?
client가 요구사항 workflow의 결과물들을 전체적으로
이해해야 한다는 점

Requirement workflow의 산출물들은 client의
언어로 표현되어야 함
모든 자연어들은 부정확
Dankook.University, Yoo haeyoung, 2005
3.4 분석 웍플로우 (contd)

Slide 3.14
Manufacturing information system의 예:
“A part record and a plant record are read from the
database. If it contains the letter A directly followed by
the letter Q, then calculate the cost of transporting that
part to that plant”

it은 무엇을 언급하는가?
The part record?
The plant record?
Or the database?
Dankook.University, Yoo haeyoung, 2005
3.4 분석 웍플로우 (contd)

Slide 3.15
두 개의 독립된 workflow가 필요
requirement artifact들은 클라이언트의 언어로
표현되어야 함
analysis artifact들은 설계자들을 위해, 즉 design 및
implementation workflow 을 담당할 사람들을 위해 아주
정밀하고 완벽한하게 표현 되어야 함
Dankook.University, Yoo haeyoung, 2005
The Specification Document

Slide 3.16
Specification document (“specifications”)
 계약을 구성
 “최적(optimal)” 혹은 “98 percent complete” 처럼 부정확한 어구를
사용하지 말아야 함

다음을 위해 완전하고 정확한 명세를 갖고 있는 것은 필수적
 Testing
 Maintenance

명세서가 가져선 안될 것들
 모순 (Contradictions)
 생략 (Omissions)
 불완전성 (Incompleteness)
Dankook.University, Yoo haeyoung, 2005
Software Project Management Plan

Client가 명세들에 동의하면 세부적인 계획수립
(detailed planning)과 추정(estimating)이 시작

SPMP (software project management plan)의
포함사항
소요비용추정 (Cost estimate)
소요기간추정 (Duration estimate)
인도시기 (Deliverables)
개발 이정표 (Milestones)
예산 (Budget)
# This is the earliest possible time for the SPMP
Dankook.University, Yoo haeyoung, 2005
Slide 3.17
3.5 설계 웍플로우

Slide 3.18
Design workflow의 목적은 자료가 프로그래머들이
구현할 수 있는 형태가 될 때 까지 분석 웍플로우의
산출물들을 정제(refine)시키는 것
많은 nonfunctional requirements은 이 단계에서 마무리
되어야 함(다음 사항들을 포함해서)



프로그래밍 언어의 선택
재사용 issues
이식성 (portability) issues
Dankook.University, Yoo haeyoung, 2005
고전적 설계

Architecture design
Decompose the product into modules

Detailed design
Design esch module:


Data structures
Algorithms
Dankook.University, Yoo haeyoung, 2005
Slide 3.19
객체-지향 설계

Slide 3.20
객체-지향 웍플로우 동안 클래스들을 추출
 design workflow 동안에 설계

Accordingly
 Classical architectural design corresponds to part of the objectoriented analysis workflow
 Classical detailed design corresponds to part of the object-oriented
design workflow

Retain design decisions(설계결정사항들은 유지되어야함)
 막다른 곳에 몰렸을 때를 위해
 그 전 단계로 돌아가서 명확하게 설계했던 것까지 다시 설계하는 일이
발생할 수 있으므로
Dankook.University, Yoo haeyoung, 2005
3.6 구현 웍플로우

Implementation workflow의 목적은 대상 소프트웨어
프로덕트를 선택한 구현언어로 구현
 소규모 소프트웨어 프로덕트는 설계자가 구현하는
경우가 많음
대규모 소프트웨어 프로덕트는 코딩 팀들이 병렬로
구현할 수 있는 서브시스템(subsystem)들로 분할
서브시스템들은 개별 프로그래머들이 구현하는
컴포넌트(component)들이나 코드 산출물(code
artifact)들로 구성

Slide 3.21
설계의 정확성(다른 산출물들처럼)은 테스트
웍플로우의 부문으로 체크
Dankook.University, Yoo haeyoung, 2005
3.7 테스트 웍플로우

Slide 3.22
Test workflow 의 담당은 다음과 같음
모든 개발자와 유지보수자, 그리고
품질 보증 그룹

산출물의 추적성(traceability)은 성공적인 testing을
위한 중요한 요구사항임
Dankook.University, Yoo haeyoung, 2005
3.7.1 요구사항 산출물

Slide 3.23
분석 산출물들에 있는 모든 항목(item)은 요구사항
산출물에서 추적이 가능해야 함
설계와 구현의 산출물에 대해서도 유사함
Dankook.University, Yoo haeyoung, 2005
3.7.2 분석 산출물

분석 산출물들은 검토(review)를 통해 checking
되어야 함
client의 대표와 분석 팀은 반드시 참석
검토의 두 가지 유형 (6.2절 참고)



워크스루 (walkthrough)
인스펙션 (inspection)
SPMP 문서에 대해 우수한 체크 방법은 분석
산출물들의 검토와 유사하게 검토
 소요 비용과 기간 평가에 주의를 기울여야 함
개발기간과 비용추정들이 충족된 만족스럽다면
클라이언트는 프로젝트의 진행을 허용
Dankook.University, Yoo haeyoung, 2005
Slide 3.24
3.7.3 설계 산출물

Slide 3.25
설계 검토는 필수적임
설계 검토들은 명세들을 심의하는 검토와 유사
client 대표는 보통 참석하지 않음

적합한 상호참조 설계(cross-referenced design)
개발자들과 SQA그룹에게 설계가 명세들에 일치하는지
체킹 , 그리고
명세들의 모든 부분이 설계의 어느 부분에
반영되었는지를 체킹하는 강력한 도구

여기서 찾는 결함들의 유형
논리 결함들, 인터페이스 결함들, 예외처리의 결여(에러
조건들의 처리), 명세들과의 불일치
Dankook.University, Yoo haeyoung, 2005
3.7.4 구현 산출물

Slide 3.26
각 컴포넌트들은 구현 직후 테스트 되어야 함
 단위 테스팅 (Unit testing)

컴포넌트들이 해당 명세들을 만족시키는 프로덕트를
달성시키기 위해 정확하게 결합되었는지를 체크하는 것
 통합 테스팅 (Integration testing )

통합 테스팅이 완료되면 (즉 모든 컴포넌트들이 코딩되어
통합되었을 때)
 프로덕트 테스팅 (Product testing by SQA group)

프로덕트가 client의 컴퓨터에 설치된 후, 클라이언트는
그것을 테스트 함
 승인 테스팅 (Acceptance testing)
Dankook.University, Yoo haeyoung, 2005
3.7.4 구현 산출물 (contd)

COTS 소프트웨어는 테스팅 받기 위해 미래의
잠재적 client들을 선택하여 제공됨.이를 알파
릴리이즈라고 부르고,이의 수정된 알파 릴리이즈를
베타 릴리이즈라고 부름
Alpha release
Beta release

Slide 3.27
alpha 혹은 beta release site 는 장단점이 있음
무료이며 자유롭게 복사해서 사용할 수 있음
알파테스트 버전은 적지 않은 오류를 내포
데이터베이스에 악영향을 끼칠 수 있음
Dankook.University, Yoo haeyoung, 2005
3.8 인도 후 유지보수

Slide 3.28
인도 후 유지보수는 소프트웨어 개발의 필수 요소
 모든 소프트웨어 활동들을 합한 것 보다 인도 후 유지보수에 더 많은
비용이 투입

문제점의 원인
 문서 혹은 문서화의 부족

두 가지 유형의 테스팅이 필요
 postdelivery maintenance 동안에 가해진 변경들을 testing
 회귀 테스팅 (regression testing)

회귀 테스팅을 수행하는데 도움을 주기 위해 모든 선행 test
case (이전의 모든 테스트 케이스들이 실행한 결과들을 함께
보유 )를 보유하고 있어야 함
Dankook.University, Yoo haeyoung, 2005
3.9 폐기

Slide 3.29
Software를 더 이상 유지할 수 없을 경우
설계상 큰 변화가 일어났을 경우
프로덕트가 완전히 새로운 하드웨어나 오퍼레이팅
시스템 상에서 구현되어야 할 경우
문서가 적절히 유지보수 되지 않았을 경우
하드웨어의 교체 - 이 경우는 수정하기 보다는 처음부터
재 작성하는 것이 보다 경제적

True retirement is a rare event

Client가 속한 조직은 프로덕트가 제공하는
기능성을 더 이상 요구하지 않을 때 이 프로덕트를
컴퓨터에서 제거
Dankook.University, Yoo haeyoung, 2005
3.10 Unified Process의 페이즈

Slide 3.30
Increments는 단계별로 나타남
Dankook.University, Yoo haeyoung, 2005
Figure 3.1
3.10 Unified Process의 페이즈 (contd)

Slide 3.31
4개의 increment들은 다음과 같이 명명됨
개념정립 페이즈 (Inception phase)
전개 페이즈 (Elaboration phase)
구축 페이즈 (Construction phase)
전환 페이즈 (Transition phase)

Unified Process 의 페이즈는 점진적임(increments)
Dankook.University, Yoo haeyoung, 2005
3.10 Unified Process의 페이즈 (contd)

이론상, 소프트웨어 프로덕트의 개발이
많은 점진들에서 수행될지라도 실제 개발은
일반적으로 네 개의 점들로 구성된 것처럼 보임

Unified Process에서 수행되는 모든 단계는
다음것중에 하나임.
다섯 개의 핵심 워크플로우 중에 하나 ,그리고
네 개의 페이즈 중에 하나

각 단계가 왜 두 번 고려되어야 하는가?
Workflow

Technical context of a step
Phase

Business contextDankook.University,
of a step Yoo haeyoung, 2005
Slide 3.32
3.10.1 개념정립 페이즈
Slide 3.33

개념정립 페이즈(inception phase)의 목적은 대상 소프트웨어
프로덕트를 개발할 가치가 있는지를 결정하는 것

단계
1. 도메인을 이해하는 것
2. 비즈니스 모델을 구축하는 것
3. 제안된 프로젝트의 범위의 한계 정하기
 대상 소프트웨어 프로덕트가 통합해야 할 것을 결정하기 위해서
개발자들은 비즈니스 모델의 부분 집합(subset)에만 초점을 맞추어야
함
4. 개발자들은 초기 비즈니스 사례들을 만들기 시작
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈 : 초기 비즈니스 사례

Slide 3.34
프로젝트를 진행하기 전에 필요한 질문사항들 :
제안된 소프트웨어 프로덕트는 비용 면에서 효과적인가?
제안된 소프트웨어 프로덕트는 시간 내에 인도될 수 있는가?
소프트웨어 프로덕트를 개발하는데 무슨 위험들이 내포되어
있는가? 그리고 이들 위험들은 완화시킬 수 있는가?
제안된 소프트웨어 프로덕트를 개발하지 않기로 결정한다면
클라언트에게 무슨 비용이 드는가?
만약 소프트웨어 프로덕트가 시장에서 판매되어야 한다면 필요한
시장 연구는 수행했는가?
대안으로 만약 소프트웨어 프로덕트가 클라이언트 조직의
활동들(미션 중심의 활동들)을 지원하기 위해 개발되었다면
제안된 소프트웨어 프로덕트가 늦게 인도된 경우 무슨 영향을
미치겠는가?
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈: 초기 비지니스사례


Slide 3.35
What are the risks involved in developing the software
product, and
How can these risks be mitigated?
Does the team who will develop the proposed
software product have the necessary experience?
Is new hardware needed for this software product?
If so, is there a risk that it will not be delivered in time?
If so, is there a way to mitigate that risk,perhaps by
ordering back-up hardware from another supplier?
Are software tools(chapter 5) needed?
Are they currently available?
Do they have all the necessary fuctionality?
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈 : 초기 비즈니스 사례 (contd)
Slide 3.36

개념정립의 후반부에 개발자들이 이들 질문들에
대답할 수 있어야 초기 비즈니스 사례가 작성될 수
있음
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈: Risks

Slide 3.37
세 가지의 주요 위험 범주:
Technical risks

위험들의 예는 목록화되어 있음
요구사항들을 올바르게 얻지 못하는 경우

이 위험은 요구사항 웍플로우를 정확하게 수행하면 완화시킬 수
있음
아키텍처를 올바르게 얻지 못하는 경우


아키텍처는 충분히 강건하지 못함
이들 세부류의 위험들을 완화시키기 위해
위험들에 대한 순위를 메길 필요가 있음
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈: Analysis, Design Workflows
Slide 3.38

분석 웍플로우의 소수의 양만 개념정립 페이즈
동안에 수행
아키텍처의 설계에 필요한 정보만 추출함

따라서 설계 웍플로우의 소수의 양만이 수행함
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈: Implementation Workflow
Slide 3.39

개념 정립 단계 동안은 일반적으로 코딩을 수행하지
않음

그러나 때로는 제안된 소프트웨어 프로덕트의
구축부분의 타당성을 테스트하기 위해 proof-ofconcept 프로토타입이 구축될 필요가 있음
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈 : Test Workflow

Slide 3.40
테스트 웍플로우는 개념정립 페이즈의 시작때 거의
시작
주요 목적은 요구사항들이 정확하게 결정되었는지를 확인
하는 것
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈 : Planning

Slide 3.41
개념정립 페이즈인 경우에 개발자들은 페이즈의
초기에는 전체 개발을 계획하는데 필요한 충분한
정보를 갖고 있지 못함
프로젝트의 시작 때 수행되는 계획수립은 개념정립
페이즈 자체만을 위한 계획수립이 됨

정보부족과 같은 이유 때문에 개념정립의 후반부에
수행된 계획수립은 단지 다음 단계인 전개
페이즈(elaboration phase)을 위해 계획된 것임
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈: Documentation

Slide 3.42
개념정립 페이즈의 산출물들은 다음사항들을 포함:
도메인 모델의 초기 버전
비즈니스 모델의 초기 버전
요구사항 산출물들의 초기 버전
분석 산출물들의 초기 버전
아키텍처의 예비 버전
위험들의 초기 목록
초기 유스 케이스들 (Chapter 10)
전개 페이즈를 위한 계획
비즈니스 사례의 초기 버전
Dankook.University, Yoo haeyoung, 2005
개념정립 페이즈 : 초기 비즈니스 사례

비즈니스 사례의 초기 버전을 획득하는 것이
개념정립 페이즈의 전체 목적임

초기 버전이 포함하는 것들
Slide 3.43
소프트웨어 프로덕트의 범위 설정
재정적인 세부사항들
제안된 소프트웨어 프로덕트가 시장에 출시되면 비즈니스
사례는 다음사항들을 포함

고정수입 투영, 시장 추정, 그리고 초기비용
만약 소프트웨어 프로덕트가 인-하우스(in-house)로
사용된다면 비즈니스 사례는 다은사항을 포함

초기 비용-분석을 포함
Dankook.University, Yoo haeyoung, 2005
3.10.2 전개 페이즈

Slide 3.44
전개 페이즈(elaboration phase)의 목적은 초기
요구사항들을 구체화,즉 정제시키는것
아키텍처를 구체화
위험들을 모니터해서 그들의 우선순위들을 구체화
비지니스 사례를 구체화
소프트웨어 프로젝트 관리 계획(software project
management plan: SPMP)을 생성

이 페이즈의 주요 활동들은 이전 페이즈의 구체화
또는 전개화 하는 것
Dankook.University, Yoo haeyoung, 2005
전개 페이즈 : Documentation

Slide 3.45
전개 페이즈의 테스크들은 다음과 대응:
 태스크들이 요구사항 웍플로우를 거의 완료
 전체 분석 웍플로우를 실제로 수행
 아키텍처의 설계를 시작

전개 페이즈의 산출물
 완성된 도메인 모델
 완성된 비즈니스 모델
 완성된 요구사항 산출물들
 아키텍처의 갱신된 버전
 위험들의 갱신된 목록
 소프트웨어 프로젝트 관리 계획(프로젝트의 나머지부문에 대한)
 완성된 비즈니스 사례
Dankook.University, Yoo haeyoung, 2005
3.10.3 구축 페이즈

구축 페이즈(construction phase)의 목적은
소프트웨어 프로덕트의 첫 번째 운영 가능한 품질의
버전을 생성하는 것
이를 때로는 베타 릴리즈(beta release)라고 부름

Slide 3.46
구축 페이즈에서 강조하는 것
구현, 그리고
테스팅



모듈들의 단위 테스팅
서브시스템들의 통합 테스팅
전체 시스템의 프로덕트 테스팅
Dankook.University, Yoo haeyoung, 2005
구축 페이즈 : Documentation

Slide 3.47
구축 페이즈의 산출물들은 다음사항들을 포함함:
초기 사용자 메뉴얼과 다른 메뉴얼들
모든 산출물들 (베타 릴리즈 버전등)
완성된 아키텍처
갱신된 위험 목록
소프트웨어 프로젝트 관리 계획(프로젝트의 나머지를
위한 SPMP)
만약 필요하다면 갱신된 비즈니스 사례
Dankook.University, Yoo haeyoung, 2005
3.10.4 전환 페이즈

Slide 3.48
전환 페이즈(transition phase)의 목적은 클라이언트의
요구사항들이 정말 충족되는지를 확인하는 것 ,즉
 소프트웨어 프로덕트에 있는 결함들이 수정되었는지
 모든 메뉴얼들이 완성되었는지
 이 페이즈 동안에 어떤 이전에 식별되지 않은 위험들을 발견하려고
노력하였는지

이 페이즈는 베타 버전이 설치된 사이트로부터 피드백에
의해서 나옴

전환 페이즈의 산출물들은 다음을 포함함
 모든 산출물들(최종 버전들)
 완성된 매뉴얼들
Dankook.University, Yoo haeyoung, 2005
3.11 1차원 대 2차원 생명주기 모델
Slide 3.49
Figure 3.2
Dankook.University, Yoo haeyoung, 2005
3.11 1차원 대 2차원 생명주기 모델 (contd)

고전적 생명주기 모델은 1차원 모델
단일 축으로 표현 (앞의 슬라이드 참고)


Example: Waterfall model
Unified Process 는 2차원 모델
두 개의 축으로 표현 (앞의 슬라이드 참고)

2차원 형태는 다음을 나타냄
workflows (technical contexts)
phases (business contexts)
Dankook.University, Yoo haeyoung, 2005
Slide 3.50
3.11 1차원 대 2차원 생명주기 모델 (contd)

폭포수 모델

1차원
Dankook.University, Yoo haeyoung, 2005
Figure 2.3 (again)
Slide 3.51
3.11 1차원 대 2차원 생명주기 모델 (contd)


Slide 3.52
진화-트리 모델
2차원
Dankook.University, Yoo haeyoung, 2005
Figure 2.2 (again)
3.11 1차원 대 2차원 생명주기 모델 (contd)
Slide 3.53

2차원 모델의 추가 복잡한 요소들이 필요한가?

실세계에서, 각각의 웍플로우는 다음 웍플로우가
시작되기 전에 완료됨

실제로, 개발 태스크는 너무 큼

따라서 Miller’s Law에 의해
태스크는 점진들(페이즈들)로 분할
각 점진 내에서 개발자들은 그들이 구축중인 태스크를
완료할 때 까지 반복함
Dankook.University, Yoo haeyoung, 2005
3.11 1차원 대 2차원 생명주기 모델 (contd)

Slide 3.54
프로세스를 처음 시작할 때는 요구사항 웍플로우를
실행할 소프트웨어 프로덕트에 관한 충분한 정보가
없음
다른 코어 웍플로우들도 유사함

소프트웨어 프로덕트는 서브시스템으로 분할

심지어 서브시스템도 가끔 너무 클 수 있음
컴포넌트들은 소프트웨어 프로덕트를 전체적으로 보다
깊게 이해할때까지 처리할 수 있는 모든 것
Dankook.University, Yoo haeyoung, 2005
3.11 1차원 대 2차원 생명주기 모델 (contd)

Slide 3.55
Unified Process을 잘 처리하는데 또 다른 난제는
피할 수 없는 변경들
moving target problem이라고 부르는 클라이언트의
요구사항들이 변경되는 경우
피할 수 없는 실수

Unified Process는 작고 크게 독립된 서브프로그램
들의 집합으로 대규모 문제를 취급하는데 최적의
솔루션
점진과 반복을 위한 프레임워크 제공
미래에는 Unified Process가 더 우수한 새로운 방법론이
출현할 것
Dankook.University, Yoo haeyoung, 2005
3.12 소프트웨어 프로세스 개선하기
Slide 3.56

Example: 미 국방성 태스크포스 팀 (U.S. Department of
Defense initiative)

Software Engineering Institute (SEI) 설립

소프트웨어의 기본적인 문제점
소프트웨어 프로세스를 관리하는 능력이 없어서
생긴 문제

소프트웨어 프로세스 개선 노력
Capability maturity model (CMM)
ISO 9000-series
ISO/IEC 15504
Dankook.University, Yoo haeyoung, 2005
3.13 Capability Maturity Models (CMM)

생명주기모델과 상관 없음

소프트웨어 프로세스를 개선하는데 관련된
전략들의 집합
Slide 3.57
소프트웨어를 위한 SW–CMM
인적 자원 관리를 위한 P–CMM
시스템 엔지니어링을 위한 SE–CMM
통합 프로덕트 개발을 위한 IPD–CMM
소프트웨어 획득을 위한 SA–CMM

다섯 개의 기존 모델을 통합시킨 CMMI (capability
maturity model integration)
Dankook.University, Yoo haeyoung, 2005
SW–CMM

소프트웨어 프로세스를 개선시키기 위한 전략

1986년 SEI 제안

Fundamental ideas:
Slide 3.58
소프트웨어 프로세스를 개선시킨 결과


소프트웨어 품질의 개선
시간과 비용 초과로 인해 고통 받는 소프트웨어 프로젝트를 줄여
줌,즉 on time,그리고 within budget에 인도됨
관리 개선 결과

개선된 기술들
Dankook.University, Yoo haeyoung, 2005
SW–CMM (contd)
Slide 3.59

성숙의 5단계

소프트웨어의 조직들은 상위수준의 프로세스
성숙으로 가기 위해 일련의 점진적인 단계로 천천히
발전
Dankook.University, Yoo haeyoung, 2005
Level 1. Initial Level
초기 단계
 Ad hoc 기반
전체 프로세스를 예측할 수 없음
관리는 위기에 대한 대처로 이루어짐

대다수의 소프트웨어 조직들은 단계 1
Dankook.University, Yoo haeyoung, 2005
Slide 3.60
Level 2. Repeatable Level

반복가능단계

기초적인 소프트웨어 관리
Slide 3.61
계획수립과 관리 기법들은 유사한 프로덕트들의 경험에
기반
단계 2에서 측정(measurement)은 적합한 프로세스를
달성하는 첫 단계로 시행
프로젝트 동안에 취한 측정들은 미래 프로젝트에 대한
실제 개발 기간과 비용 스케줄을 작성하는데 사용
문제가 확인되면, 즉시 수정조치를 취함
Dankook.University, Yoo haeyoung, 2005
Level 3. Defined Level

정의 단계

단계 3에서는 소프트웨어 프로덕션에 관한
프로세스가 완전하게 문서화 됨
Slide 3.62
프로세스의 관리적 그리고 기술적 측면이 모두 분명하게
정의 됨
프로세스를 개선시키기 위해 계속 노력이 가해 짐
검토(6.2절)들은 소프트웨어 품질 목표를 달성하는데 사용
이 단계에서는 품질과 생산성을 보다 증가시키기 위해서
CASE 환경(5.6절)과 같은 신기술이 도입
Dankook.University, Yoo haeyoung, 2005
Level 4. Managed Level
Slide 3.63

관리 단계

관리단계 조직은 각 프로젝트에 대한 품질과 생산성
목표들을 설정
끊임없이 품질과 생산성을 측정
통계적 품질 관리 (statistical quality control)
Dankook.University, Yoo haeyoung, 2005
Level 5. Optimizing Level

최적화 단계

지속적인 프로세스 개선
통계적 품질과 프로세스 관리
프로세스에는 생산성과 품질이 크게 개선 될 수 있게
긍정적인 피드백 루프들이 통합
Dankook.University, Yoo haeyoung, 2005
Slide 3.64
Summary
Slide 3.65
 CMM의 다섯 수준과
이들의 KPA
Dankook.University, Yoo haeyoung, 2005
Figure 3.3
Experiences with SW–CMM

Slide 3.66
It takes:
단계 1에서 단계 2로 가는데 3년 내지 5년이 소요
단계 2에서 단계 3로 가는데 1.5년 내지 3년이 소요
각 성숙도 단계에 대해 SEI는 조직이 다음 성숙도 단계에
도달하려는 노력의 대상으로 KPA(key process area)들의
시리즈를 강조
Dankook.University, Yoo haeyoung, 2005
Key Process Areas

각 레벨을 위한 KPAs (Key Process Areas)가
있음

Level-2 KPAs :
요구사항 관리
프로젝트 계획수립
프로젝트 추적
형상 관리
품질 보증

Compare
Level 2: 결함의 Detection 과 correction
Level 5: 결함 예방
Dankook.University, Yoo haeyoung, 2005
Slide 3.67
Goals

Slide 3.68
Original goal:
조직의 소프트웨어 프로세스에 있는 현재 결점에
집중해서 조직이 해당 프로세스를 개선할 수 있는 방법을
알려 줌

미 공군은 1998년에 만들어진 SW-CMM 수준3을
따라야 한다는 조건을 규정
후에 DoD 도 유사한 조건을 규정

SW-CMM 프로그램은 미국방성 소프트웨어를
개선하려는 목표를 능가하게 되었고 소프트웨어의
품질과 생산성을 개선하기를 바라는 다양한 많은
소프트웨어 조직들이 이를 수행 중
Dankook.University, Yoo haeyoung, 2005
3.14 다른 소프트웨어 프로세스 개선안

Slide 3.69
다른 software process improvement (SPI) 포함:
ISO 9000-series
ISO/IEC 15504
Dankook.University, Yoo haeyoung, 2005
ISO 9000

Slide 3.70
산업 활동의 기준안
시스템 품질을 위한 ISO 9001
ISO 9000-3, ISO 9001을 소프트웨어에 적용할 가이드
라인
CMM과 구별되는 많은 특성들을 가짐
프로세스 개선을 위한 것은 아님
글과 그림으로 프로세스를 문서화시키는 것을 강조
측정과 메트릭스의 강조
ISO 9000는 EU와 비즈니스 시 필요
GE를 포함한 많은 미국의 조직에서도 요구 됨
점점 더 많은 미국의 조직들은 ISO 9000 인증서를 요구
Dankook.University, Yoo haeyoung, 2005
ISO/IEC 15504

Original name: Software Process Improvement
Capability dEtermination (SPICE)
국제 프로세스 개선안
영국의 국방성 (Ministry of Defence (MOD))이 발의
프로세스 개선, 소프트웨어 획득을 포함
CMM, ISO 9000의 확장과 향상
framework지 method가 아님

CMM, ISO 9000 는 이 프레임워크와 일치
현재는 ISO/IEC 15504로 불려짐
혹은 간단히 15504 로 불려짐
Dankook.University, Yoo haeyoung, 2005
Slide 3.71
3.15 소프트웨어 프로세스 개선의 비용과 이익

Slide 3.72
Hughes Aircraft (Fullerton, CA)는 $500K 를 투자
(1987–90)
Savings: 연간 $2M 절약, 성숙도 단계는 2에서 3으로 갱신

Raytheon사의 Equipment Division은 1983년
성숙도 단계 1에서 1993년에는 단계가 3이 됨
생산성은 배가 됨
프로세스 개선 노력에 투자한 달러당 $7.70의 이익으로
반환된 것
Dankook.University, Yoo haeyoung, 2005
3.15 소프트웨어 프로세스 개선의 비용과 이익 (contd)Slide 3.73

India에 있는 Tata Consultancy Services는 자신의
프로세스를 개선하기 위해 ISO 9000 프레임워크와
CMM을 모두 사용
노력 추정에서 오류는 약 50%에서 단지 15%로 감소
검토들의 효율성(즉 검토들 동안에 발견된 결함들의
백분율)은 40%에서 80%로 증가

Motorola GED은 CMM을 사용 (1992–97)
결과는 다음 슬라이드
Dankook.University, Yoo haeyoung, 2005
Motorola Project의 결과
Slide 3.74
Figure 3.4



MEASL – 백만에 상당하는 어셈블러 코드 라인
품질은 증가된 성숙도 단계에 따라 증가
Motorola는 실재 생산성 수치를 발표하지 않음
단계 2 프로젝트의 생산성에 관련된 생산성을 반영
이 그림에는 단계 1프로젝트들을 위해 이용할 수 있는 품질이나
생산성 수치는 없음
Dankook.University, Yoo haeyoung, 2005
3.15 소프트웨어 프로세스 개선의 비용과 이익 (contd)Slide 3.75

상호작용
소프트웨어 프로세스 개선안들과 소프트웨어공학 표준들
간

ISO/IEC 12207 (1995)은 전체 생명주기
소프트웨어의 표준

1998년 미국버전(IEEE/EIA 12207)이
CMM으로부터 아이디어를 구체화 해 발간 됨

ISO 9000-3 은 현재 ISO/IEC 12207의 부문으로
통합
Dankook.University, Yoo haeyoung, 2005