Level의 KPA(Key Process Areas)

레벨2(반복)의 KPA의 목표

KPA	목표
요구사항관리 (RM: Requirements Management)	l  소프트웨어의 요구 사항은 소프트웨어 엔지니어링과 관리 활동을 위한 기준선을 제정하기 위해서 통제한다. l  소프트웨어 계획, 산출물, 액티비티 등은 요구 사항과 일관성을 유지한다.
소프트웨어 프로젝트 계획 (SPP: Software Project Planning	l  프로젝트 계획과 추적에서 사용하기 위해 평가를 문서화 한다. l  프로젝트 활동과 공약을 계획하고 문서화한다. l  관련 그룹과 개인은 프로젝트와 연관된 공약에 동의한다.
소프트웨어 프로젝트 추적과 감독(SPTO: Software Project Tracking and Oversight)	l  실제 결과와 수행 성능은 소프트웨어 계획을 기준으로 추적한다. l  실제 결과와 수행 성능이 소프트웨어 계획에서 많이 벗어났을 때는 사정 조치를 취하고, 종료 시까지 관리한다. l  관련 그룹과 개인은 공약이 변경되는 것을 동의한다.
소프트웨어 협력 업체 관리(SSM: Software Subcontract Management)	l  주 계약자와 협력 업체는 그들의 공약(commitment)에 동의한다. l  주 계약자는 공약 관련 협력 업체의 실제 결과를 추적한다. l  주 계약자와 협력 업체는 지속적인 의사 교환을 유지한다. l  주 계약자는 공약을 기준으로 협력 업체의 실제 수행 성능을 추적한다.
소프트웨어 품질보증 (SQA: Software Quality Assurance)	l  소프트웨어의 품질 보증 활동을 계획한다. l  적절한 표준, 절차, 그리고 요구 사항 등에 대한 소프트웨어 산출물과 활동의 충실도를 객관적으로 확인한다. l  관련 그룹과 개인에게 소프트웨어 품질 보증 활동과 결과를 통보한다. l  프로젝트 안에서 해결되지 못한 미준수(noncompliance) 문제들은 선임 관리자에게 보고한다.
소프트웨어 형상관리 (SCM: Software Configuration Management)	l  소프트웨어의 형상 관리 활동을 계획한다. l  선택된 소프트웨어의 작업 산출물을 확인, 통제, 이용한다. l  식별된 소프트웨어의 작업 산출물에 대한 변경을 통제한다. l  관련 그룹과 개인에게 소프트웨어 기준선의 상태와 내용을 통보한다.

레벨 3(정의)의 KPA의 목표

KPA	목표
조직 프로세스 초점(OPF: Organization Process Focus)	l  소프트웨어 프로세스의 개발과 개선 활동을 조직 전반에 걸쳐 조정한다. l  사용된 소프트웨어 프로세스의 장점과 단점을 식별한다. l  조직-레벨 프로세스 개발과 개선 활동을 계획한다.
조직 프로세스 정의 (OPD: Organization Process Definition)	l  조직을 위한 소프트웨어 프로세스의 표준을 개발하고 유지 관리한다. l  소프트웨어 프로젝트에서 조직의 표준 소프트웨어 프로세스 이용과 관련된 정보를 수집, 검토, 이용할 수 있게 한다.
교육 프로그램(TP: Traning Program)	l  교육 활동을 계획한다. l  소프트웨어 관리와 기술적인 역할을 수행하는 데 필요한 기술과 지식을 개발하는 교육을 제공한다. l  소프트웨어 엔지니어링 그룹과 소프트웨어 관련 그룹의 개인은 자신의 작업을 수행하는데 필요한 교육을 받는다.
통합된 소프트웨어 관리 (ISM: Integrated Software Management)	l  프로젝트를 위해 정의된 소프트웨어 프로세스는 조직의 표준 소프트웨어 프로세스로부터 변경된(tailored)버전이다. l  프로젝트는 정의된 소프트웨어 프로세스에 따라 계획하고 관리한다.
소프트웨어 제품 엔지니어링(SPE: Software Product engineering)	l  소프트웨어 생산을 위해 소프트웨어 엔지니어링 태스크를 정의하고, 통합하고, 일관되게 수행한다. l  소프트웨어 작업 산출물은 서로 일관성을 유지한다.
그룹 간의 조정(IC: Intergroup Coordination)	l 모든 관련 그룹은 고객의 요구 사항에 동의한다. l 모든 그룹은 다른 그룹과의 공약에 동의한다. l 그룹은 그룹 간의 문제를 식별하고, 추적하고, 해결한다.
동료 검토(PR: Peer Reviews)	l  동료 검토 활동을 계획한다. l  소프트웨어 작업 산출물의 결함을 식별하고 제거한다.

레벨4(관리)의 KPA 목표

KPA	목표
정량적인 프로세스 관리 (QPM: Quantitives Process Management)	l 정량적인 프로세스 관리 활동을 계획한다. l 프로젝트의 정의된 소프트웨어 프로세스의 수행 성능을 정량적으로 관리한다. l 조직의 표준 소프트웨어 프로세스에 대한 역량은 정량적인 용어로 표현한다.
소프트웨어 품질 관리 (SQM: Software Quality Management)	l 프로젝트의 소프트웨어 품질 관리 활동을 계획한다. l 소프트웨어 산출물 품질의 평가 목표와 그 우선 순위를 정의한다. l 소프트웨어 산출물의 품질 목표를 달성하기 위한 실제 진척을 평하고 관리한다.

레벨 5(최적화) KPA 목표

KPA	목표
결함 예방 (DP: Defect Prevention)	l  결함 예방 활동을 계획한다. l  결함의 공통 원인을 찾아 식별한다. l  결함의 공통 원인의 우선 순위를 정하고, 체계적으로 제거한다.
기술 변경 관리 (TCM: Technology Change Management)	l  변경된 기술의 편입을 계획한다. l  신기술은 품질과 생산성에 미칠 영향을 정하기 위해 평가한다. l  적절한 신기술은 조직 전체에 걸쳐 일반 실행 지침으로 바꾼다.
프로세스 변경 관리 (PCM: Process Change Management)	l  지속적인 프로세스 개선을 계획한다. l  조직 전체적으로 조직의 소프트웨어 프로세스 개선 활동에 참여해야 한다. l  조직의 표준 소프트웨어 프로세스와 프로젝트를 위해 정의된 소프트웨어 프로세스를 지속적으로 개선한다.

설명

나선형 모형은 Boehm이 제안한 것으로, 폭포수 모형과 프로토 타입 모형의 장점에 위험 분석 기능을 추가한 모형이다. 

• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 고정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것으로, 점진적 모형이라고도 한다.
• 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다.
• 프로젝트 총 예산이 1~5%정도 더 증가한다.
• 각각의 사이클 별로 지속기간이 한계가 있다.
  

개발 순서

Planning 
계획 및 정의 단계로 개발자가 고객을 만나 개발하고자 하는 제품의 요구사항을 듣는다. 이때 개발자는 고객의 의도를 파악하고 계획을 위한 자료로 활용한다. 여기서 제품의 성능, 기능, 시스템의 목표를 규명하고 제약조건을 파악한다.

Risk analysis
초기 요구사항을 가지고 위험을 규명한다. 개발하려는 시스템의 기술적 위험, 정보 부족, 프로젝트 관리, 자원관리등을 예측하고 위험관리를 통해 위험을 방지한다.

Software development
어떠한 모델을 적용하여 시스템을 개발할 것인가를 결정한다. 사용자가 UI를 중시여기면 Prototype model을, SI에 위험이 존재하거나 요구사항이 완벽한 경우 Waterfall model을 사용한다

User evaluation
앞 단계에서 구현된 소프트웨어를 고객이나 사용자가 평가한다. 이 단계에서 feedback을 얻는 데 요구되는 여러 작업를 포함하며 다음 단계에 고객의 평가를 반역할 수 있는 자료를 얻을 수 있다.

장점

• 가장 현실적인 모형으로, 대규모 프로젝트나 큰 시스템에 적합하다
• 점진적으로 개발 과정이 반복되므로 누락되거나 추가딘 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없다.
• 위험분석 단계에서 기술과 관리의 위험 요소들을 하나씩 제거해 나감으로써 완성도 높은 소프트웨어를 만들 수 있다.
• 각 단계에 적당한 테스팅이 이루어져 개발과정에 발생하는 여러 문제점의 해결방안을 찾기 때문에 테스팅 비용 및 개발지연등의 문제를 해결할 수 있다.

단점

• 위험성 평가에 크게 의존하기 때문에 이를 발견하지 않으면 반드시 문제가 된다.
• 위험요인을 추출하고 분석하는데 많은 비용이 소요되고 초기의 요구분석 결과 자체가 불완전한 경우, 위험분석의 의미가 없다.
• 위험분석 결과가 불완전한 경우, 사용자의 요구충족에 의미가 없고, 개발비용만 낭비하게 된다.
• 상대적으로 복잡하여 프로젝트 관리 자체가 어렵게 될 수도 있다.
  

 

설명
원형모델의 주목적은 원형을 가능한 빨리 개발한 후 고객과 검증하는 것이다. 고객으로부터 피듭백을 받은 후에는 원형을 폐기하는 경우도 있고 중요 부분만 구현하여 피드백을 얻은 후 지속적으로 발전시켜 완제품을 만들어 낼 수도 있다.

• 프로토 타입 모형은 사용자의 요구사항을 정확하게 파악하기 위해서 미리 실제로 개발할 소프트웨어의 시제품을 만들어서 최종 결과물을 예측하는 모형이다.
• 시스템의 모형을 만드는 과정으로 초기 요구사항에 대한 소프트웨어를을 구현하는데 이는 추후 구현단계에서 사용될 골격이 된다.
• 성능, 보안, 신뢰도와 같은 소프틍웨어의 특성을 무시한다.
• 변경이 체계적으로 이루어지지 않기 때문에 유지보수가 힘들다.
• 폭포수 모델에서 발견되는 개발이 완료된 시점에서 오류가 발견되거나 요구사항과 맞지 않는 단점을 해결하기 위한 모형이다.

개발 순서

Initial analysis
처음 개발할 시스템의 분석 작업, 고객의 일부 요구사항 또는 불안전 요구사항으로 부터 제품의 기본 골격을 잡는다. 

Define objectives
프로토타입을 정의해야할 부분을 고객과 상의하여 진행. 이부분을 잘해야 어떻게 프로토타입의 구조를 결정할지 정의할 수 있다.

Specify
순차적 디자인 원칙에 의거하여  모델을 정의하고 수정한다. 사용자 인터페이스에 초점을 맞춘다.

Construct
프로토타입으로 정해진 모델을 빠르게 개발한다. 고객이 요구하는 기능을 구현하고 필요한 요소를 파악하는데 중점을 둔다. 중요한 것은 프로그램의 신뢰도나 품질이 아니라 빨리 만드는 것이다.

Evaluate
가장 중요한 단계로 프로토타입을 고객과 같이 평가하고 고객이 원하는 요구사항과 맞는지 확인한 후 다시 정의 단계로 넘어간다.

장점

• 요구사항을 충실히 반영하며, 요구사항의 변경이 용이하다.
• 사용자 요구사항이 불명확할 때 사용하는 것이 좋다
• 제품의 추적성과 시험가능성이 확보된다.
• 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있다.
• 시스템의 이해와 품질향상에 도움이 된다.
• 고객과 개발자 모두에게 공동의 참조 모델을 제공한다.

단점

• 프로토 타입의 결과를 최종 결과물이라고 고객에게 혼란을 줄 수 있다.
• 단기간에 제작해야 하기 대문에 비효율적인 언어나 알고리즘을 사용할 수 있다.
• 소프트웨어 개발에 많은 시간이 소요되며 산출물이 많아진다.
• 중간과정을 점검할 수 있는 일정표와 산춤물이 없기 때문에 관리 통제가 어렵다.
• 실제 프로토타입을 검수하고 확인할 고객이 그리 많지 않다. (자기 업무도 많은데 어떻게 신경쓰냐..)

설명

폭포수 모형은 소프트웨어 개발에서 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하며 이전 단계로 넘어갈 수 없는 방식이다.

• 폭포수 모형은 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용하며 고전적 생명 주기 모형이라고도 한다.
• 소프트웨어 개발 과정의 앞 단계가 끝나야만 다음단계로 넘어갈 수 있는 선형 순차적 모형이다
• 각 단계별로 산출물이 나오며 단계별 평가서가 존재한다.
• 두개 이상의 과정이 병행하여 수행되지 않는다

개발 순서

System engineering
높은 수준의 구조 명세서를 작성한다. 모델에 사용할 각종 문서를 정의한다.

Requirements Analysis
요구사항을 수집하고 문제를 이해, 분석하는 단계이다. 분석가는 고객의 요구사항을 기능, 성능, 인터페이스 등으로 파악하고 문서화 한다. 이 단계에서 산출물은 요구사항 명세서, 기능 명세서, 인수 테스트 명세서등이 있다.

Disign
소프트웨어 아키텍처 명세서, 시스템 테스트 명세서, 디자인 명세서, 서브시스템 테스트 명세서, 단위 테스트 명세서등 모든 시스템 구조를 결정하게 된다.

Construction
설계명세서를 토대로 실제 프로그래밍을 하게 된다.

Testing
단위 테스트 레포트, 서브 시스템 테스트 레포트, 시스템 테스트 레포트, 인수테스트 레포트등의 산출물이 나오며 프로그램이 입력에 따라 제대로 작동하는지 여부와 오류를 발견하기 위해 수행된다.

Installation
시스템에 인스톨해야할 소프트웨어라면 인스톨 작업을 하게 된다.

Maintenance
요구사항 정의 변경에 따른 유지보수 및 산출물 변경을 하게 된다. 유지보수를 하게 되는 이유는 여러가지 인데 고객이 성능향상이나 기능 추가를 요구할 경우, 새로운 운영체제나 주변장치등이 바뀌는 경우, 테스팅 단계에서 미리 체크하지 못한 오류등을 수정할 경우가 있다. 실제 프로젝트 예산의 70%가 유지보수단계에 쓰일 정도로 시스템이 제대로 구축이 안되어있다면 엄청난 예산을 잡아먹는다.

장점

• 모형의 적용 경험과 성공사례가 많다.
• 단계별 정의가 분명하고, 각 단계별 평가가 확실하게 이루어진다.
• 각 프로세스 단계의 역할 이해가 용이하다.
• 단계별 산출물이 정확하여 개발공정의 기준점을 잘 제시한다.
• 프로젝트의 관리가 용이하다.

단점

• 프로젝트 초기, 요구사항을 정의할 때 정확한 요구사항을 제시하지 않을 경우 프로세스의 각 단계가 진행될 수록 요구사항의 변경, 추가가 매우 어렵다. (고객의 feedback 반영이 어려움)
• 각 단계별로 다음 단계로 진행될 때 오류 없이 진행되어야 하지만 현실적으로 오류없이 다음단계로 진행되기 어렵다.
• 만약 계획대로 진행되지 않을 경우 납기일 전 철야, 납기일 지연, 지연에 따른 비난과 스트레스가 개발자에게 향하여 에너지 소진, 고객의 요구를 충족하지 못하는 등의 부작용이 발생한다.
• 고객은 개발된 제품이 자신이 원하는 것인지 알기 위해서 프로젝트 후반까지 기다려야만 한다.
• 만약 고객이 요구한 시스템이 아니면 최악의 경우 프로젝트가 실패하게 될 수도 있다.