소프트웨어 픔질 목표 설정에 따른 세부 계획 수립

품질목표설정 초기에 품질목표를 설정하기 위해서는 다음과 같이 품질목표를 설정한다.

 

• 수행될 기능, 요구하는 시스템의 성능 및 시스템의 기술적 요구사항 등에 기초하여적용할 다른 시스템 특성들을 추가한다. 
• 주어진 품질리스트를 사용하여 각 제품특성에 중요한 품질목표를 확정하여 품질목표 선정표에 기록한다. 
•  품질목표선정표의 결과를 이용하여 특정제품의 고려되어야 할 11개의 품질목표 각 | 각의 중요도를 품질목표양식에 기록한다. Very Important(V), Important(), Somewhat | Important(SI) 및 Not Important(NI) 등의 가능성이 있는데 이들의 판단은 주관적인 것이다.

목차

CMM에 의한 프로세스 품질평가

이상과 같은 요구회 가 소프트웨어 프로세 이 골격은 타스크를 전략변화를 추구하기 위해서 국방성의 요청을 받은 CMU의 SEI 근세스의 성숙도를 평가할 수 있는 골격을 연구하였다. 다섯 단계로 된 르 줄이고 생산성과 품질을 향상시키는 것을 목표로 하여 개발하였다.

초기수준(Initial)

개인의 능력에 의존하는 프로세스의 어떤 보증에 있어서 대체적으로 소프트 단계로서 ad hoc 및 chaostic process 단계라고 볼 수 있다. 프 부분은 애매하지만, 조직내에서 개별적으로 정의한 몇 개의 프로세스가 으로 소프트웨어 프로세스의 특성이 정의되어 있는 수준이다. 중요한 과제는 다음과 같다.

재사용수준(Repeatable) 

전반적인 절차나 문서양식은 표준화되어 있지는 않으나 부분적인 기준을 만들어 사용 - 단계이다. 기초적인 프로젝트관리를 위한 프로세스가 표준화되어 있어서 비용, 스 레즈 및 기능의 track이 가능하다. 유사한 프로젝트의 실행에서 일부 성공했던 과거의 경 험을 참조할 수 있다. 중요한 전략과제는 다음과 같다.

레벨 3 : 정의 수준(Defined)

정형적인 품질평가를 할 수 있는 기준과 절차가 마련되어 있다. 관리와 엔지니어링활 동에 관한 소프트웨어 프로세스가 문서화되고 표준화되어서 이것을 조직의 표준으로 통 합할 수 있는 수준이다. 모든 프로젝트는 이 표준에 맞추어서 계획을 세우고 결재하여 실행한다. 중요한 전략과제는 다음과 같다.

레벨 4 : 관리수준(Managed) 

측정결과를 양적으로 표현할 수 있고 해석하여 컨트롤할 수 있는 다 위해서 통계적 방법을 동원할 수 있고, 프로세스평가를 위한 데이터베이 수 있다. 중요한 전략과제는 다음과 같다.

 

• 기술전환
• 문제분석 
• 프로세스의 통계적 컨트롤

레벨 5 : 최적화수준(Optimized) | 취약한 프로세스요소를 식별하여 보완할 수 있고 원인분석을 통한 결합에 바이 있는 단계이다. 양적인 품질측정치를 토대로 품질수준을 분석하여 프로세스이 계속해서 실행할 수 있는 수준이다. 중요한 전략과제는 다음과 같다.

CMM의 특성

CMM은 5단계의 레벨로 구성되고 레벨별 특성은 다음과 같다.

(1) Initial - Maturity Level 1 - Indicators의 선정 - 선정한 Indicators를 13개의 Category로 분류 - Indicator Category • Progress - 프로젝트의 스케줄링 · Effort - 프로젝트에 대해서 다음과 같은 항목별 공헌도평가(비용, 스케줄, adherence, 제품의 품질) 1. Cost - 예상비용과 실제비용의 비교분석 - Quality • S/W Quality Assurance Audits - 제품의 품질평가와 감사 • Review - 생명주기리뷰에서 활동항목별 현상파악 | • Trouble Report - 시험효과, 프로세스와 제품의 품질 결함의 제공 • Peer Review Result - 제품 및 제공품의 상세한 리뷰결과 • Defect Pr이벤트ion - 결함의 원인, 영향 및 보완방법
 

1 Progress

제트 스케쥴상에 있는 activity의 완성도에 의해서 평가한다. progress indicator는 와성과 타스크출력의 완성도를 모니터링하는데 사용된다.

2 Effort

관리자가 인적 자원에 대한 계획 대 실행을 추적하는데 사용한다.

3 Cost

프로젝트에 참여한 인력의 기능수준별로 Man-Hour 단가를 평가하여 비용예측하고 관리한다.

4 Quality S/W 

품질검증을 위한 감리, 고객과 함께 생명주기의 결과, 분석 그리고 시험결과의 보 고를 통해서 품질평가를 한다.

5 Stability

S/W의 요구와 크기의 최적화를 추구할 수 있도록 관리한다. Stability Indicator는 요구 변경의 수를 나타내는 trend chart와 코드의 크기에 관한 결정 사항을 포함한다.

6 Computer Resource Utilization 

계획 대 실행을 비교평가하여 프로젝트 개발자원을 효율적으로 사요. 한다.
로 사용했는가를 분석

The Definition Level - Maturity Level 3

S/W를 개발하고 유지보수하는 표준프로세스의 특성을 정의한다.  표준프로세스는 문서화하고 통합하여 S/W 공학과 S/W 관리프로세스의 이 합하는 목표로 추진한다. O Progress M.L.2와 같이 Gantt Chart와 계획 대 실행차트를 채용한다. Effort M.L.2와 같이 수행한다. Cost M.L.2에서 관리자는 예산에 대한 실행비용을 비교하는 것을 중점으로 하는 대신, M.L.3에서는 유사한 프로젝트 경험적 자료를 사용할 수 있어야 한다. Quality M.L.2에서와 같이 감리, 고객과 함께 분석 그리고 시험결과의 보고활동은 같지만 상 세한 보고서를 작성하는 것이 보완된다. 그러므로 동일한 활동을 보다 원숙한 차원에서 처리하게 된다.

Stability 요구변경의 수, 크기 및 프로세스를 조화시켜서 통합시키는 단계이다. 요구변경의 안 정성은 변경해야 될 요구의 수, 보류해도 좋은 요구의 수 그리고 변경하는데 소요되는 시간이 열려 있도록 하는 기능이다. 크기의 안정성은 코드의 크기와 그 추정이 안정되어 야 하고, 프로세스의 안정성은 변경해야 될 프로세스수와 보류해도 좋은 프로세스수에 관한 안정도이다. Computer Resource Utilization M.L.2와 같다. 다만 이들 indicator들이 S/W관리의 통합된 핵심프로세스 영역을 다룰 수 있어야 한다. dildo Training 훈련된 기술자가 관리를 위한 자산으로 평가할 수 있고, 관리할 수 있도록 훈련과정을 만들어야 한다.

성능평가를 계량적으로 측정하여 시정할 수 있는 단계를 정하고 히 대 실행을 비교평가할 수 있고 경험 데이터를 적용하여 현재의 제품과 프로세스의 서 다. M.L.3가 계획 대 실행 관 프로세스를 평가할 수 <직이 통계적 수단을 도 단계이다. 퍼가할 수 있는 단계라고 한다면, Managed Level에서는 프로젝트의 수행 수단을 동원하여 계획의 차질을 예측하고 그 대응책을 강구할 수 있는 프로젝트를 관리한다. Effort 3와 같지만 다음 항목들을 모니터링하다. . Man-Hour 컨트롤특별한 기능채용, 개발구조, 도구와 방법론을 효과적으로 도입할 수 있는 경험적 단계 및 경험연수에 대한 생산성측정

Cost Cost 대 schedule 현황을 분석하는 것은 M.L.3과 같으나 이 보고서를 SPC를 적용하여 기하 수 있는 능력을 갖는다. Cost는 process measurement와 분석 그리고 품질경영을 핵심영역으로 하여 관리하게 된다. Quality M.L.3과 같은 내용의 S/W 품질보증감리를 하게 되지만, S/W 환경에 준수하지 않아도 무방한 품질보증항목의 타입과 그 수를 파악함으로써 품질감리에 대한 융통성을 도입할 수 있는 능력을 갖게 된다. 소프트웨어 프로세스의 품질을 보증하기 위해서 제정하고 있는 표준안으로서 현재 요 구정의와 Trial 조직을 운영할 수 있도록 연구중이다. 다음절부터 설명하는 것은 SC7에 서 제안하고자 하는 Bootstrap ESPRIT 프로젝트로 개발하고 있고 소프트웨어의 생산성을 위해서 새시 트 전체를 사정할 수 있다. 소프트웨어 프로세스의 품질을 보증하기 위해서 제정하고 있는 표준안으로서 현재 요 구정의와 Trial 조직을 운영할 수 있도록 연구중이다. 다음절부터 설명하는 것은 SC7에 서 제안하고자 하는 규정을 중심으로 한다.

인증(certification)

▶ 기능기준선 - Pt(분서 단지 잘 되었나? 소프트웨어 체계명세서 혹은 개발명세서(소규모 사업인 경우)의 인증( 끝나면 공식적인 구성관리가 시작되고 인증된 명세서를 바탕으로 하여 것 위한 절차와 정부가 관여할 사항을 밝힌다. 기능기준선은 타당성 분석과 사요기 의가 끝난 단계에서 설정한 관리기준선이다. 분석명세 ▶ 할당기준선 - 각 moduless Perme의 당 되었나? 타이로 하여 검토와 배포를 서 부석과 사용자 요구정 모든 구성항목에 대한 성능요구사항을 정의하는 개발명세로 구성된다. 할당문서이 비, 검토 및 배포계획을 세운다. 그리고 개발방법(자체개발 또는 협력업체개발)을 양식 과 설계로 나누어서 결정한다.

(1) 양식

개발표준에 포함된 양식을 참고하여 채택된 개발문서양식을 고려하여 구성관리를 수 행하되 안내책자, 사용자설명서, 시험계획과 같은 문서를 지원할 수 있도록 한다.

(2) 설계 

하드웨어와 소프트웨어의 인터페이스 통제를 설계할 목록과 이들에 대한 준비, 검토 및 배포계획을 세운다.
▶ 제품기준선 제품기준선은 구성항목에 대한 상세설계문서에 의해서 설정된다. 각 항목별 최초품목 이 정부에 의해서 검토된 후 명세서의 요구사항을 만족하는 것으로 승인되면 제품기준 선에서는 구성항목별로 제품을 설치할 하드웨어의 구성규모와 방법 그리고 코딩을 위한 요구사항을 정한다. 이를 위한 제품의 양식, 설계내용을 준비, 검토, 배포하고 통제할 계 획을 세운다. 소프트웨어의 개발양식에 맞추어서 프로그램 및 관련된 문서에 관한 양식을 정한다.

구성관리 계획을 세우고 소프트웨어 요구정의를 한 후에 소프트웨어 제품의 요구에 맞 이고 프질보증과 함께 사업 초창기부터 추진되어야 한다. 왜냐하면 사업의 성격에 따라서 관리 자원의 양에 따리 구성관리 표준(안)에서 1 이를 바탕으로 해서 구서에 가서 관리항목이 다르고 관리의 정도도 차이가 나며, 구성관리에 투입되는 이 양에 따라서 관리의 한계가 정해지기 때문이다. . 주(안)에서 구성관리의 원리 및 절차에 관해서 설명할 것이며 여기에서는 으로 해서 구성관리계획을 수립할 개념을 정리한다.

개발과 같은 성격과 수준으로 수행한다.

전체사업의 관리 개념 행한다. 바자, 품질보증자와 함께 구성관리자의 자질을 높여야 한다.  개발과는 별도의 그룹으로 운영한다. 5 전과정에서 일관성(consistency)을 갖도록 해야 한다. 5 수명주기와 관련하여 관리점을 기준선으로 정하고 관리해 나간다. 1 기준선을 중심으로 하여 기본문서를 작성한다. 2 기준선 중심의 문서와 구성항목의 변경은 구성관리에서 통합시키고, 필요한 시점 에서 버전의 기준선을 확정한다. 9 감리기능은 기준선 중심의 문서와 매체에 기록된 소프트웨어의 통합을 확인하는 수단으로 사용된다.

(8) 협력업체 및 공급업체의 통제

나. 조직 구성관리를 위한 정부의 프로그램 및 사업관리기능을 통합하고 그 관련성을 정의하여 1) 조직의 구성계획
회사의 marketin 구성관리를 위한 조직은 두 가지 형태로 구성될 수 있다. 첫째는 개발 및 전략
리고 통합해서 구성하는 방법이고, 둘째는 개발 및 품질보증팀과는 별도로 구 바법이다. 그러나 조직의 기능은 어떤 형태든지 동일한 기능을 수행할 수 있어야 한다.

1 통합된 기능

SE 에어 개발위원회 밑에 품질관리자와 구성관리자를 두고 사업관리자 밑에서 사
즈, 기술보증 및 품질보증팀의 기능을 보완하고 통제하는 방법이다.

2 독립기능

개발위원회, 품질보증위원회와 같은 수준에서 구성관리위원회를 두고 구 | 성관리 전담부서를 조직하는 방법이다.
(2) 정책 결정 - 구성관리와 관련된 모든 정책적 의사결정사항을 계획서에 포함시킨다.
(3) 구성 통제위원회 사업관리위원회 밑에 구성통제위원회, 소프트웨어개발팀 및 품질보증팀을 구성하고 상호보완적인 임무를 수행한다. 개발팀은 사업관리자의 관리를 받으며 정해진 절차와 문서양식을 사용하여 소프트웨어를 개발하고, 사업관리자는 사용자보증, 기술보증 및 품질보증을 수행하는 전담기능을 두고 관리한다. 사용자 보증 : 사용자요구 반영확인 기술보증 : 품질과 생산성을 위한 기술적용여부 확인 품질보증 : 개발중의 모든 품질보증기능 구성통제위원회는 개발과 유지보수 및 품질보증 기능이 정해진 규정대로 수행되었는 가를 확인한다.
(4) 참고문헌 구성관리계획에 관련된 참고문헌을 기록한다.

기준선 식별 기준선의 식별은 소프트웨어 제품의 수명주기에 따라서 3가지 기준선, 기능기준선, 할 당기준선 및 제품기준선을 정한다. 상세한 내용은 4장 1절에서 설명한다. 자가에 또는 각 조직 안에구성항목을 통제할 절차와 책임을 정한다. 특히 정부와 협약자간에 대 서 일어나는 인터페이스를 수행할 방법을 계획한다.

(1) 책임

적용할 구성통제의 수준과 정도 다 구성통제에 참여할 사람과 처리과정, 다 구성통제위원회 결재권자에 대한 책임과 한계 문서검토위원회의 전문성과 기능 절차가 공학변경 제안서(ECP, Engineering Change Proposal),  가치공학 변경 제안서 (0 | Value Engineering Change Proposal)에 대한 절차와 처리과정의 승인방법을 ... 공학변경은 제품생산과정에서 절차의 변경을 의미하고, 가치공학변경은 제프 이 가치를 변경하기 위한 제안을 의미한다. Q 공학변경 제안서, 가치공학 변경제안서 승인 후 구성식별문서와 구성항목을 낸거 하기 위한 절차와 처리과정을 계획한다. 공학변경제안서와 가치공학 변경제안서를 사용하기 위한 특정한 조건. 인터페이스 관리. 하드웨어, 소프트웨어 및 필요한 장비의 물리적 및 기능적인 인터페이스를 통제할 것 과 문서를 설명할 계획을 세운다.

 

인터페이스 프로그램에 의해서 작성될 문서를 작성할 계획을 세운다. 그 문서는 종류 별 즉, 설계문서, 양식 등으로 나누어서 설명한다.   인터페이스 통제문서를 고치고, 배포할 절차와 책임 및 권한(authority)을 나열한다. 바 구성상태 관리를 지원할 구성상태정보를 검증하고 승인하며, 처리하여 저장할 계획을 세운다.   구성상태보고를 위한 자료은행을 구성할 계획을 세운다. 자료은행은 자료를 저장하 는 데이터베이스나 파일로서 구성상태에 관한 내용을 보관한다.

구성관리의 구성

소프트웨어 구성항목(SCI, S/W Configuration Item)은 개발과정에서 산출되는 모든 문 서와 프로그램을 소프트웨어 체계(제품)의 요소로 식별하여 구성항목이라고 말한다. 소 프트웨어 구성항목은 문서, 테이프나 디스크 같은 물리적 매체 그리고 프로그램이나 작 업통제언어(JLC)와 같이 컴퓨터가 읽을 수 있는 매체에 기록하여 보관한다.

소프트웨어 구성항목의 문서를 작성하기 위해서는 트리구조에 따른 번호의 부여가 필 요하다. 소프트웨어 구성항목의 트리구조를 정해 나가는 데는 동일한 소프트웨어 구성 항목들에 관한 버전(version)들을 구별하기 위해서 그림과 같은 번호부여스킴이 필요하 다. 번호부여스킴은 소프트웨어 구성항목의 변경과정을 설명해 주는데 보통포버 + 버전 + 배포일자와 같이 정해준다. | 구성식별은 다음과 같은 3단계의 기준선을 정하고 구성 관리를 수행하는 기준으로 삼 는다. 기능기준선 사용자 요구, 기술 및 비용의 타당성 평가와 같은 기능 요구가 정의되고 관련된 소프트 웨어 구성항목들이 식별되었을 때 기능 기준선이 설정된다.