소프트웨어 개발 계획
버전 1.0
개정 히스토리
날짜 |
버전 |
설명 |
작성자 |
---|---|---|---|
1999년 10월 5일 | 1.0 | 초기 릴리스 | Context Integration |
이 소프트웨어 개발 계획은 WebNewsOnLine의 대학 스포츠 페이징 서비스를 구현하는 데 필요한 단계(Phase) 및 반복 관점에서 개발 활동을 정의합니다.
이 소프트웨어 개발 계획은 시스템 개발 팀에서 사용하는 전체 계획에 대해 설명합니다. 개별 반복에 대한 세부사항은 반복 계획에서 설명합니다.
없음
이 프로젝트는 WebNewsOnline에 대해 사용자 정의된 시스템을 구현하며 호출기, 휴대용 전화 또는 전자 메일을 통해 등록자에게 갱신된 컨텐츠에 대해 알려줍니다. 그런 다음 등록자는 월드 와이드 웹(WWW)을 통해 자신에게 맞게 사용자 정의된 컨텐츠를 볼 수 있습니다.
시스템은 2000년 "대학 농구(March Madness)"(NCAA Championship Tournament) 때까지 사용 가능해야 합니다.
프로젝트에서 생성되는 인도물은 다음과 같습니다.
이 계획은 각 후속 단계(Phase) 또는 반복을 시작하기 전에 갱신됩니다. 각 단계의 목표 종료 날짜는 다음과 같습니다.
도입/인식(Inception) 및 정제(Elaboration) 단계(Phase)를 수행하는 프로젝트 팀은 다음과 같이 조직됩니다.
프로젝트 팀은 편집 인력, 광고 인력 및 현업 대표 인력과의 협력을 통해 요구사항을 수집하고 프로토타입을 검토하며 다양한 시스템 기능을 테스트 합니다. WebNewsOnLine의 프로젝트 책임자는 Donna Cram(비즈니스 오퍼레이션 디렉터)입니다.
다음 표에는 위의 프로젝트 다이어그램에 표시된 역할과 역할별 주요 책임이 표시됩니다.
역할 | 책임 |
---|---|
프로젝트 관리자 | 프로젝트 관리자는 자원을 할당하고 우선순위를 지정하며 고객 및 사용자와의 상호작용을 조정합니다. 일반적으로 프로젝트 팀이 올바른 목표에 집중할 수 있도록 유지합니다. 또한 프로젝트 관리자는 프로젝트 아티팩트의 무결성 및 품질을 보장하는 일련의 사례를 설정합니다. |
설계자 | 설계자는 프로젝트 전체에서 기술 활동 및 아티팩트를 지시하고 조정합니다. 설계자는 각 아키텍처 보기의 전체 구조(보기 분류, 요소 그룹화 및 주요 그룹 간 인터페이스)를 설정합니다. 따라서 다른 작업자와 달리 설계자의 보기는 깊이가 아닌 너비가 중요합니다. |
비즈니스 분석가 | 비즈니스 분석가는 모델링 대상 조직을 구성하고 해당 범위를 지정함으로써 비즈니스 유스 케이스 모델링을 지시하고 조정합니다. 예를 들어, 가능한 비즈니스 액터 및 비즈니스 유스 케이스와 상호작용 방법을 설정합니다. |
디자이너 | 디자이너는 하나 이상의 클래스의 책임, 오퍼레이션, 속성 및 관계를 정의하고 구현 환경에 맞게 조정하는 방법을 결정합니다. 또한 디자이너는 패키지 또는 서브시스템에서 소유하는 클래스를 포함하여, 하나 이상의 디자인 패키지 또는 디자인 서브시스템을 담당합니다. |
크리에이티브 디자이너 | 크리에이티브 디자이너는 사용성 요구사항과 같은 웹 인터페이스에 대한 요구사항을 캡처하고 웹 페이지 프로토타입을 빌드하며 일반 사용자 등 웹 인터페이스의 기타 이해 당사자(stakeholder)를 사용성 검토 및 사용 테스트 세션에 포함하고 웹 인터페이스의 최종 구현에 대한 올바른 피드백(디자이너 및 구현자 등 다른 개발자가 작성)을 제공하여 웹 인터페이스의 디자인 및 프로토타입을 지도하고 조정합니다. |
테스터 | 테스터는 테스트 설정 및 실행, 테스트 실행 평가 및 오류 복구 등 테스트를 실행하고 테스트 결과를 평가하며 식별된 결함을 로깅합니다. |
요구사항 전문가 | 요구사항 전문가는 하나 이상의 유스 케이스의 요구사항 측면과 기타 지원 소프트웨어 요구사항에 대한 설명으로 시스템의 일부 기능에 대한 스펙을 캡처합니다. 요구사항 전문가는 또한 유스 케이스 패키지를 담당하므로 해당 패키지의 무결성을 유지합니다. |
이 프로젝트의 도입/인식(Inception) 단계(Phase)는 3주가 소요됩니다. 후속 단계의 초기 예상은 위의 섹션 2.4를 참조하십시오.
프로젝트의 도입/인식(Inception) 단계(Phase)는 다음과 같이 구성됩니다.
타스크 |
시작 날짜 |
종료 날짜 |
---|---|---|
도입/인식 | 1999년 10월 1일 금요일 | 1999년 10월 25일 월요일 |
도입/인식 시작 | 1999년 10월 1일 금요일 | 1999년 10월 1일 금요일 |
도입/인식 개시 | 1999년 10월 4일 월요일 | 1999년 10월 6일 수요일 |
ContextWISE 카트리지를 사용하여 특정 프로젝트 기술에 대한 프로젝트 계획에 타스크 추가 | 1999년 10월 4일 월요일 | 1999년 10월 4일 월요일 |
변경 제어 위원회 구성 | 1999년 10월 4일 월요일 | 1999년 10월 5일 화요일 |
변경 제어 계획 작성 및 기준선 작성 | 1999년 10월 5일 화요일 | 1999년 10월 5일 화요일 |
승인 획득 | 1999년 10월 5일 화요일 | 1999년 10월 5일 화요일 |
도입/인식 개시 회의 | 1999년 10월 5일 화요일 | 1999년 10월 6일 수요일 |
도입/인식 개시 회의 준비 | 1999년 10월 5일 화요일 | 1999년 10월 6일 수요일 |
도입/인식 개시 회의 개최 | 1999년 10월 6일 수요일 | 1999년 10월 6일 수요일 |
도입/인식 개시 완료 | 1999년 10월 6일 수요일 | 1999년 10월 6일 수요일 |
도입/인식 인도물 | 1999년 10월 6일 수요일 | 1999년 10월 14일 목요일 |
요구사항 워크샵 개최 | 1999년 10월 6일 수요일 | 1999년 10월 7일 목요일 |
프로젝트 비전 작성, 검토 및 승인 | 1999년 10월 6일 수요일 | 1999년 10월 7일 목요일 |
예비 유스 케이스 모델(10 - 20% 완료) 작성 및 개정 제어 수행 | 1999년 10월 7일 목요일 | 1999년 10월 11일 월요일 |
예비 유스 케이스 조사 작성, 검토 및 승인 | 1999년 10월 11일 월요일 | 1999년 10월 12일 화요일 |
예비 보충 스펙 작성, 검토 및 승인 | 1999년 10월 12일 화요일 | 1999년 10월 12일 화요일 |
비즈니스 사례 작성, 검토 및 승인 | 1999년 10월 12일 화요일 | 1999년 10월 12일 화요일 |
예비 프로젝트 용어집 작성, 검토 및 승인 | 1999년 10월 12일 화요일 | 1999년 10월 12일 화요일 |
예비 크리에이티브 디자인 요약 작성, 검토 및 승인 | 1999년 10월 6일 수요일 | 1999년 10월 7일 목요일 |
예비 사이트 맵 및 유스 케이스 탐색 맵 작성, 검토 및 승인 | 1999년 10월 7일 목요일 | 1999년 10월 8일 금요일 |
크리에이티브 디자인 컴포지션 작성, 검토 및 승인 | 1999년 10월 8일 금요일 | 1999년 10월 11일 월요일 |
예비 컨텐츠 계획 작성, 검토 및 승인(해당되는 경우) | 1999년 10월 6일 수요일 | 1999년 10월 6일 수요일 |
사용자 인터페이스 프로토타입(선택사항) 작성, 검토 및 승인 | 1999년 10월 6일 수요일 | 1999년 10월 6일 수요일 |
보고서 프로토타입(선택사항) 작성, 검토 및 승인 | 1999년 10월 12일 화요일 | 1999년 10월 14일 목요일 |
예비 기술 대안 개발 | 1999년 10월 6일 수요일 | 1999년 10월 7일 목요일 |
해당 컨텍스트 조언자에게 문의 | 1999년 10월 12일 화요일 | 1999년 10월 13일 수요일 |
예비 지식 전달 계획 및 스케줄 작성, 검토 및 승인 | 1999년 10월 13일 수요일 | 1999년 10월 13일 수요일 |
도입/인식 제안의 가정에 대한 유효성 검증/무효화 | 1999년 10월 13일 수요일 | 1999년 10월 14일 목요일 |
승인 획득 | 1999년 10월 14일 목요일 | 1999년 10월 14일 목요일 |
도입/인식 인도물 완료 | 1999년 10월 14일 목요일 | 1999년 10월 14일 목요일 |
도입/인식 요약 | 1999년 10월 14일 목요일 | 1999년 10월 25일 월요일 |
클라이언트와의 품질 검사 회의 개최 | 1999년 10월 14일 목요일 | 1999년 10월 14일 목요일 |
품질 보증 수행 | 1999년 10월 14일 목요일 | 1999년 10월 15일 금요일 |
컨텍스트 교훈 회의 개최 | 1999년 10월 14일 목요일 | 1999년 10월 14일 목요일 |
첫 번째 프로젝트 예상 작성, 검토 및 승인(+75%, -60%) | 1999년 10월 14일 목요일 | 1999년 10월 18일 월요일 |
전체 프로젝트 반복 전달 계획 작성, 검토 및 승인 | 1999년 10월 18일 월요일 | 1999년 10월 19일 화요일 |
정제(Elaboration) 단계(Phase)에 대한 제안 작성 | 1999년 10월 14일 목요일 | 1999년 10월 15일 금요일 |
소프트웨어 프로젝트 로그 작성 | 1999년 10월 15일 금요일 | 1999년 10월 15일 금요일 |
도입/인식 체크포인트 준비 | 1999년 10월 15일 금요일 | 1999년 10월 18일 월요일 |
클라이언트 프로젝트 관리자가 포함된 팀에서 작업 릴리스 사인오프 양식 완료 | 1999년 10월 18일 월요일 | 1999년 10월 19일 화요일 |
정제 단계에 대한 제안 전달 | 1999년 10월 19일 화요일 | 1999년 10월 21일 목요일 |
도입/인식 체크포인트 검토 및 실행/중단 결정 | 1999년 10월 21일 목요일 | 1999년 10월 22일 금요일 |
프로젝트 홈 페이지의 해당 인도물을 IAN 아티팩트로 이동 | 1999년 10월 22일 금요일 | 1999년 10월 25일 월요일 |
도입/인식 완료 | 1999년 10월 25일 월요일 | 1999년 10월 25일 월요일 |
시스템 개발은 특정 단계에서 여러 반복이 발생하는 단계적 접근 방식을 사용하여 수행됩니다. 다음 표에는 해당 단계 및 관련 시간대가 표시됩니다.
단계 | 반복 수 | 시작 날짜 | 종료 날짜 |
---|---|---|---|
도입/인식(Inception) 단계 | 1 | 1주차 | 4주차 |
정제(Elaboration) 단계 | 1 | 5주차 | 11주차 |
구현/구축(Construction) 단계 | 3 | 12주차 | 27주차 |
전이(Transition) 단계 | 1 | 28주차 | 31주차 |
다음 표에는 각 단계의 종료를 나타내는 이정표가 표시됩니다.
설명 | 이정표 |
---|---|
도입/인식(Inception) 단계 | 도입/인식 단계에서는 프로젝트에 대한 제품 요구사항을 개발하고 해당 비즈니스 사례를 설정합니다. 주요 유스 케이스 뿐만 아니라 상위 레벨 프로젝트 계획이 개발됩니다. 도입/인식 단계의 종료 시점에서는 비즈니스 사례에 따라 프로젝트에 필요한 자금을 확보하고 계속 프로젝트를 수행할지 여부를 결정합니다. 단계 종료 시점의 비즈니스 사례 검토 이정표에서는 프로젝트에 대한 진행/중단 결정을 표시합니다. |
정제(Elaboration) 단계 | 정제 단계에서는 요구사항을 분석하고 아키텍처 프로토타입을 개발합니다. 정제 단계 완료 시점에서는 릴리스 1.0에 대해 선택된 모든 유스 케이스에서 분석 및 디자인을 완료합니다. 또한 릴리스 2.0에 대한 위험성이 높은 유스 케이스가 분석되고 디자인됩니다. 아키텍처 프로토타입이 릴리스 1.0에 필요한 아키텍처의 타당성 및 성능을 테스트합니다. 아키텍처 프로토타입 이정표는 정제 단계의 종료를 나타냅니다. 이 프로토타입은 R1.0 릴리스를 구성하는 주요 아키텍처 컴포넌트의 검증을 알립니다. |
구현/구축(Construction) 단계 | 구현/구축 단계에서는 나머지 유스 케이스를 분석하고 디자인합니다. 릴리스 1.0의 베타 버전이 개발되고 평가를 위해 분배됩니다. 또한 R1.0 및 R2.0 릴리스를 지원하기 위한 구현 및 테스트 활동이 완료됩니다. R2.0 운용 능력 이정표는 구현/구축 단계의 종료를 나타냅니다. 릴리스 2.0 소프트웨어는 패키징할 수 있습니다. |
전이(Transition) 단계 | 전이 단계에서는 R1.0 및 R2.0 릴리스 분배를 준비합니다. 이 단계는 또한 사용자 교육을 포함하여 올바른 설치를 위한 필수 지원을 제공합니다. R2.0 릴리스 이정표는 전이(Transition) 단계의 종료를 나타냅니다. 이 시점에서는 비전 문서에 정의된 모든 기능이 설치되어 사용자가 사용할 수 있습니다. |
단계 | 반복 | 설명 | 연관 이정표 | 처리된 위험성 |
---|---|---|---|---|
도입/인식(Inception) | 예비적 반복 | 비즈니스 모델, 제품 요구사항, 프로젝트 계획 및 비즈니스 사례를 정의합니다. | 비즈니스 사례 검토 | 사용자
요구사항을 명확히 규정합니다. 실제 프로젝트 계획 및 범위를 개발합니다. 비즈니스 관점에서 프로젝트의 실현 가능성을 판별합니다. |
정제(Elaboration) 단계 | 아키텍처 프로토타입 개발 | 모든 유스 케이스에 대한 분석 및 디자인을 완료합니다. 아키텍처 프로토타입을 개발합니다. | 테스트 평가 요약 | 아키텍처 문제가 규정되었습니다. 기술 위험성이 완화되었습니다. 사용자가 검토할 초기 프로토타입 |
구현/구축(Construction) 단계 | C1 반복 - 베타 개발 | 베타 버전을 제공하는 유스 케이스를 구현하고 테스트합니다. | 베타 | 사용자 및 아키텍처
관점의 모든 핵심 기능이 베타에서 구현되었습니다.
소프트웨어 릴리스 이전의 사용자 피드백 |
C2 반복 - 초기 릴리스 개발 | 나머지 유스 케이스를 구현 및
테스트하고 베타 결함을 수정하며 베타 피드백을 통합합니다.
초기 시스템을 개발합니다. |
소프트웨어 | 사용자 커뮤니티에서 소프트웨어를 모두 검토했습니다.
제품 품질 수준이 높아야 합니다. 결함이 최소화되었습니다. 품질 비용이 감소했습니다. |
|
C3 반복 - 전체 릴리스 개발 | 초기
릴리스의 결함과 개선사항을 통합합4다.
전체 시스템을 개발합니다. |
소프트웨어 | 빠른 릴리스로 고객 만족도가 향상됩니다.
완전한 릴리스로 시스템의 모든 핵심 기능이 제공되었습니다. |
|
전이(Transition) 단계 | 소프트웨어 릴리스 | 릴리스를 패키징, 분배 및 설치합니다. | 소프트웨어 릴리스 |
이 시점에서는 두 릴리스가 계획됩니다. 첫 번째 릴리스를 대학 농구(March Madness) 때까지 완료해야 하므로 정제(Elaboration) 단계(Phase)에서 해당 범위가 결정됩니다. 나머지 기능성은 필요한 경우 후속 릴리스에 포함됩니다.
예비 프로젝트 스케줄은 섹션 2.4를 참조하십시오. 갱신된 계획은 해당 섹션에 지정된 날짜에 사용할 수 있습니다.
이 프로젝트의 구성원은 Context Integration에서 제공하며 해당 이름은 섹션 3.1에 지정되어 있습니다.
해당 사항 없음
이 프로젝트에 지정된 인력은 이 시점에서 해당 스킬을 보유하게 됩니다. 도입/인식 (Inception) 단계(Phase)에서 지식 전달 계획이 개발되어 해당 인력이 전이(Transition) 단계 다음에 시스템을 지원하는 데 필요한 스킬을 얻을 수 있습니다.
도입/인식(Inception) 단계(Phase)의 예산은 $150,000이며 정제(Elaboration) 단계에 필요한 비용은 도입/인식 단계에서 확인할 수 있습니다.
이 문서에는 도입/인식(Inception)에 대한 반복 계획이 포함됩니다. 후속 단계에 대한 반복 계획은 이전 단계 또는 반복이 종료되면 전달됩니다.
참조 [1]을 참조하십시오.
프로젝트 상태 보고서는 매주 발행되며 올바른 프로젝트 수행을 위한 이정표 추적 세부사항이 포함됩니다. 스케줄 변경사항은 프로젝트 후원자에게 전달되며 프로젝트 후원자는 목표 완료 날짜를 준수하기 위해 범위를 변경할지 여부를 결정합니다.
프로젝트 상태 보고서는 매주 발행되며 올바른 프로젝트 수행을 위한 이정표 추적 세부사항이 포함됩니다. 스케줄 변경사항은 프로젝트 후원자에게 전달되며 프로젝트 후원자는 목표 완료 날짜를 준수하기 위해 범위를 변경할지 여부를 결정합니다.
정규 검토는 각 디자인 및 구현 서브시스템에 대해 실행되며 이를 통해 검토한 오브젝트는 지정된 요구사항을 충족시킬 수 있습니다.
주간 프로젝트 상태 보고서가 발행됩니다. 단계 및 반복 요약 보고서 또한 필요한 시점에 발행됩니다.
노력과 시간을 사용하여 프로젝트 진행상태를 추적합니다. 프로젝트 관리자는 계획 보고서 및 실제 보고서를 사용하여 진행상태를 측정합니다.
참조 [2]를 참조하십시오.
프로젝트가 종료되면 교훈 회의를 통해 새로운 기법, 도구 또는 방법을 캡처합니다. 또한 프로젝트 인도물이 지식 관리 저장소에 아카이브되어 다음에 참조할 수 있습니다.
참조 [3]을 참조하십시오.
RUP의 표준 가이드라인을 사용합니다.
이 프로젝트는 해당 서버와 소프트웨어가 이미 설치된 Context 솔루션 센터에서 개발됩니다.
개발될 예정입니다.
참조 [3]을 참조하십시오.
개발될 예정입니다.
개발될 문서는 참조 [3]에 나열됩니다.
참조 [3]을 참조하십시오.
개발될 예정입니다.
적용 안됨 - 하청업체를 사용하지 않습니다.
각 단계(Phase)가 완료되면 교훈
세션을 통해 프로세스 개선사항을 캡처합니다.
Copyright 1987 - 2003 Rational Software Corporation