수강 신청 시스템

소프트웨어 개발 계획

 

버전 1.0

 


개정 히스토리

날짜

버전

설명

작성자

1999년 1월 15일

1.0

초기 버전

Rick Bell

 

 

 

 

 

 

 

 

 

 

 

 

 


목차

1.          소개         

1.1      목적     

1.2      범위     

1.3      용어의 정의     

1.4      참조     

1.5      개요     

2.          프로젝트 개요      

2.1      프로젝트 목적, 범위 및 목표     

2.2      가정 및 제한조건     

2.3      프로젝트 중간 산출물     

2.4      소프트웨어 개발 계획 전개     

3.          프로젝트 조직  

3.1      조직 구조     

3.2      외부 인터페이스     

3.3      역할 및 책임     

4.          관리 프로세스

4.1      프로젝트 예상     

4.2      프로젝트 계획     

4.2.1       단계 계획      

4.2.2       반복 목표

4.2.3       릴리스      

4.2.4       프로젝트 스케줄 

4.2.5       프로젝트 자원 계획      

              4.2.5.1       인력 계획      

              4.2.5.2       자원 확보 계획      

              4.2.5.3       훈련 계획      

4.2.6       예산      

4.3      반복 계획     

4.4      프로젝트 모니터링 및 제어     

4.4.1       요구사항 관리 계획      

4.4.2       스케줄 제어 계획      

4.4.3       예산 제어 계획      

4.4.4       품질 제어 계획      

4.4.5       보고 계획      

4.4.6       측정 계획      

4.5      위험성 관리 계획     

4.6      완료 계획     

5.          기술 프로세스 계획 

5.1      개발 사례     

5.2      방법, 도구 및 기법     

5.3      하부 구조 계획     

5.4      제품 적합성 계획     

6.          지원 프로세스 계획 

7.          추가 계획 

8.          부록 

9.          색인     


소프트웨어 개발 계획

 

1.                  소개 

1.1               목적

이 소프트웨어 개발 계획의 목표는 컴퓨터를 사용하는 Wylie College의 수강 신청 시스템을 구현하는 데 필요한 단계 및 반복 관점에서 개발 활동을 정의하는 것입니다.

1.2               범위

이 소프트웨어 개발 계획은 Wylie College Information Systems에서 Wylie College의 수강 신청 시스템을 개발하기 위해 사용하는 전체 계획에 대해 설명합니다. 개별 반복에 대한 세부사항은 반복 계획에서 설명합니다.
이 문서에서 설명하는 계획은 비전 문서 [1]에 정의된 제품 요구사항을 기반으로 합니다.

1.3               용어의 정의

용어집 [4]를 참조하십시오.

1.4               참조

관련 참조 서적은 다음과 같습니다.

    1. 수강 신청 시스템 비전, WyIT387, V1.0, Wylie College IT.
    2. 수강 신청 시스템 비즈니스 사례, WyIT388, DRAFT, 1998, Wylie College IT.
    3. 수강 신청 시스템 이해 당사자(stakeholder) 요청 문서, WyIT389, V1.0, 1998, Wylie College IT.
    4. 수강 신청 시스템 용어집, WyIT406, V1.0, 1998, Wylie College IT.
    5. 수강 신청 시스템 상위 레벨 프로젝트 스케줄, V1.0, 1999, Wylie College IT.
    6. Rational Unified Process, 1999, Rational Software Corp.
    7. 수강 신청 시스템 비용 모델 및 분석 보고서, WylIT390, V1.0 Wylie College IT.
    8. 수강 신청 시스템 위험성 목록, WyIT389, V1.0, Wylie College IT.
    9. 수강 신청 시스템 개발 사례, WyIT390, V1.0, Wylie College IT.
    10. 수강 신청 시스템 반복 계획, 정제(Elaboration) 반복 #E1, WyIT391, V1.0, Wylie College IT

1.5               개요

이 소프트웨어 개발 계획에는 다음 정보가 포함됩니다.

프로젝트 개요 - 프로젝트의 목적, 범위 및 목표에 대한 설명을 제공합니다. 또한 프로젝트에서 제공할 예상 중간 산출물을 정의합니다.

프로젝트 조직 - 프로젝트 팀의 조직 구조에 대해 설명합니다.

관리 프로세스 - 예상 비용 및 스케줄에 대해 설명하고 프로젝트의 주요 단계 및 이정표를 정의하며 프로젝트 모니터 방법에 대해 설명합니다.

기술 프로세스 계획 - 수행할 방법, 도구 및 기법을 포함하여 소프트웨어 개발 프로세스의 개요를 제공합니다.

지원 프로세스 계획 - 형상 관리 계획이 포함됩니다. 

2.                  프로젝트 개요

2.1               프로젝트 목적, 범위 및 목표

이 소프트웨어 개발 계획은 Wylie College Information Systems에서 Wylie College의 수강 신청 시스템을 개발하기 위해 사용하는 전체 계획에 대해 설명합니다. 개별 반복에 대한 세부사항은 반복 계획에서 설명합니다.

이 문서에서 설명하는 계획은 비전 [1]에 정의된 제품 요구사항을 기반으로 합니다.

2.2               가정 및 제한조건

이 시스템은 1999년 가을 학기의 수강 신청 기본 도구로 개발됩니다. 수강 신청은 1999년 8월 1일부터 시작되므로 이 날짜까지는 시스템을 완전히 사용할 수 있어야 합니다.

2.3               프로젝트 중간 산출물

프로젝트 과정에서 다음 중간 산출물이 생성되며 이 산출물은 유지보수 조직으로 전달됩니다.

프로젝트 개발 사례에서 설명하는 기타 중간 산출물이 생성되지만 유지보수 조직으로 전달되지는 않습니다.

2.4               소프트웨어 개발 계획 전개

소프트웨어 개발 계획은 각 반복 단계가 시작되기 전에 수정됩니다.

3.                  프로젝트 조직

3.1               조직 구조

3.2               외부 인터페이스

프로젝트 관리자는 이 계획의 스케줄에 따라 IT 책임자 이해 당사자(stakeholder)(비전 [1] 참조)에게 상태 평가 보고서를 제공합니다.

프로젝트 팀은 또한 다른 이해 당사자와 상호작용하여 관련 중간 산출물의 입력 및 검토를 요청합니다.

3.3               역할 및 책임

다음 표는 각 원칙, 활동 및 지원 프로세스를 담당할 조직 단위를 식별합니다.

역할

책임

프로젝트 관리자

Rational Unified Process [6]에 설명되어 있습니다. 전체 프로젝트 관리 원칙을 관리하며 확장 프로젝트 관리 팀을 리드합니다.

프로세스 엔지니어 프로젝트 환경을 담당하며, Rational Unified Process의 환경 원칙에 정의된 프로젝트 팀에 대한 프로세스 관련 지원을 제공합니다. 확장 프로젝트 관리 팀에 참여합니다.
형상 관리자/변경 제어 관리자 프로젝트에 대한 형상 제어와 프로젝트에서 Wylie College 변경 요청 프로세스 실행을 담당합니다. 확장 프로젝트 관리 팀에 참여합니다.

시스템 엔지니어링 팀 리더

비즈니스 모델링 및 요구사항 원칙 관리를 주로 담당하는 팀을 리드합니다. 확장 프로젝트 관리 팀에 참여합니다. 

소프트웨어 엔지니어링 팀 리더

주로 분석 및 디자인 원칙과 구현 원칙을 담당합니다. 확장 프로젝트 관리 팀에 참여합니다.

테스트 팀 리더

테스트 원칙 관리를 담당하는 팀을 리드합니다.확장 프로젝트 관리 팀에 참여합니다.  

개발 팀 리더 일반 사용자 환경에서 설치 활동 및 하부 구조를 담당하는 팀을 리드합니다.  확장 프로젝트 관리 팀에 참여합니다. 

 

4.                  관리 프로세스

4.1               프로젝트 예상

프로젝트 예상은 수강 신청 시스템 비용 모델 및 분석 보고서 [7]을 기반으로 합니다.

수강 신청 시스템은 복잡도 및 아키텍처 면에서 Wylie College가 1997년에 개발한 온라인 라이브러리 시스템과 유사합니다. 수강 신청 시스템 데이터베이스가 약 25% 정도 더 복잡하지만 유스 케이스 수의 복잡도를 고려할 때 시스템 전체적으로 약 20%가 더 복잡합니다. 이 보고서의 예상 시간 계획 및 노력은 프로젝트 예산 및 스케줄의 기반이 됩니다.

4.2               프로젝트 계획

4.2.1          단계 계획

작업분류체계(WBS)가 준비되며 이 문서의 다음 버전에서 제공됩니다.

수강 신청 시스템 개발은 여러 반복이 한 단계에서 발생하는 단계식 접근 방식을 사용하여 수행됩니다. 이 계획의 단계와 반복은 중복되지 않습니다. 관련 시간 계획에 대한 요약 정보는 다음 표를 참조하십시오.

단계

반복 수

종료

도입/인식(Inception) 단계

1

제 7 주

정제(Elaboration) 단계

1

제 14 주

구현/구축(Construction) 단계

1

제 19 주

전이(Transition) 단계

4

제 32 주

표 4.2.1 관련 시간 계획 요약

다음 표 4.2.2는 각 단계와 단계 완료를 표시하는 주요 이정표에 대해 설명합니다.

 

단계

설명

이정표

도입/인식(Inception) 단계

도입/인식 단계에서는 제품 요구사항을 개발하고 수강 신청 시스템에 대한 비즈니스 사례를 설정합니다. 주요 유스 케이스 뿐만 아니라 상위 레벨 소프트웨어 계획이 개발됩니다. 도입/인식 단계 종료 시점에서 Wylie College가 자금 확보 여부를 결정하고 비즈니스 사례에 따라 프로젝트를 실행합니다.

단계 종료 시점의 비즈니스 사례 검토 이정표는 프로젝트에 대한 진행/중단 결정을 표시합니다.

정제(Elaboration) 단계

정제 단계에서는 요구사항을 분석하고 아키텍처 프로토타입을 개발합니다. 정제 단계 완료 시점에서는 릴리스 1.0에 대해 선택된 모든 유스 케이스에서는 분석 및 디자인을 완료하게 됩니다. 또한 릴리스 2.0에 대한 위험성이 높은 유스 케이스가 분석되고 디자인됩니다. 아키텍처 프로토타입이 릴리스 1.0에 필요한 아키텍처의 타당성 및 성능을 테스트합니다.

아키텍처 프로토타입 이정표이 정제 단계 종료를 표시합니다. 이 프로토타입은 R1.0 릴리스를 구성하는 주요 아키텍처 컴포넌트의 검증을 알립니다.

구현/구축(Construction) 단계

구현/구축 단계에서는 나머지 유스 케이스를 분석하고 디자인합니다. 릴리스 1.0의 베타 버전이 개발되고 평가를 위해 분배됩니다. 또한 R1.0 및 R2.0 릴리스를 지원하기 위한 구현 및 테스트 활동이 완료됩니다.

초기 오퍼레이션 기능 이정표(베타 완료)는 구현/구축 단계 종료를 표시합니다.

전이(Transition) 단계

릴리스 1.0의 베타 버전이 분배되고 평가됩니다. 전이 단계에서는 R1.0 및 R2.0 릴리스 분배를 준비합니다. 이 단계는 또한 사용자 훈련을 포함하여 올바른 설치를 위한 필수 지원을 제공합니다.

R2.0 릴리스 이정표는 전이 단계 종료를 표시합니다. 이 단계에서는 사용자가 비전 문서 [1]에 정의된 모든 기능을 사용할 수 있도록 설치됩니다.

표 4.2.2 프로젝트 단계 및 주요 이정표

각 단계는 섹션 4.3에서 설명하는 개발 반복으로 분할됩니다.

섹션 4.2.4에서는 단계, 반복 및 주요 이정표를 표시하는 상위 레벨 프로젝트 스케줄을 보여줍니다.

4.2.2          반복 목표

각 단계는 시스템 서브세트가 개발되는 개발 반복으로 구성됩니다. 이러한 반복은 일반적으로 다음과 같은 기능을 제공합니다.

다음 표는 연관된 이정표 및 처리된 위험성과 함께 반복에 대해 설명합니다.

단계

반복

설명

연관 이정표

처리된 위험성

도입/인식(Inception) 단계

예비적 반복

비즈니스 모델, 제품 요구사항, 소프트웨어 개발 계획 및 비즈니스 사례를 정의합니다.

비즈니스 사례 검토

사용자 요구사항을 명확히 규정합니다.

실제 소프트웨어 개발 계획 및 범위를 개발합니다.

비즈니스 관점에서 프로젝트 타당성을 판별합니다.

정제(Elaboration) 단계

E1 반복 - 아키텍처 프로토타입 개발

모든 위험성이 높은 요구사항에 대한 분석 및 디자인을 완료합니다. 아키텍처 프로토타입을 개발합니다.

 

아키텍처 프로토타입

아키텍처 문제가 규정되었습니다.

기술 위험성이 완화되었습니다.

사용자 검토를 위한 초기 프로토타입

구현/구축(Construction) 단계

C1 반복 - R1 베타 개발

중요 R1 요구사항을 구현하고 테스트하여 R1 베타 버전을 제공합니다.

 

해당 릴리스에 대한 베타 테스트를 수행할 준비가 되었는지 여부를 평가합니다.

초기 오퍼레이션 기능(R1 베타 코드 완료)

사용자 및 아키텍처 관점의 모든 중요 기능이 베타에서 구현되었습니다.

 

 

전이(Transition) 단계

T1 반복 - R1 릴리스 개발/배치

R1 베타를 배치합니다.

베타 결함을 수정하고 베타에 대한 피드백을 수집합니다.

 

나머지 R1 요구사항을 구현하고 테스트합니다.

R1 릴리스의 패키지를 작성하고 분배 및 설치합니다.

나머지 위험성이 낮은 R2 유스 케이스를 자세히 분석합니다.

R1 베타 테스트 완료

 

R1 코드 완료

 

R1 제품 릴리스

R1 릴리스 이전의 사용자 피드백

 

제품 품질 수준이 높아야 합니다.

결함이 최소화되었습니다.

품질 비용이 감소했습니다.

2 단계 릴리스에서 결함이 최소화됩니다.

2 단계 릴리스는 사용자에 대한 보다 쉬운 전이 기능을 제공합니다.

사용자 커뮤니티에서 R1을 모두 검토했습니다.

 

T2 반복 - R2 내부 1 개발

R2 내부 1 요구사항을 디자인, 구현 및 테스트합니다.

R1의 결함 및 개선사항을 통합합니다.

R2 내부 1을 배치합니다.

R2 내부 1 테스트 완료

필요한 경우, R2 내부 1을 릴리스하여 R1 결함과 고객 만족사항을 처리할 수 있습니다.

 

T3 반복 - R2 내부 2 개발

R2 내부 2 요구사항을 디자인, 구현 및 테스트합니다.

R2의 결함 및 개선사항을 통합합니다.

R2 내부 2를 배치합니다.

R2 내부 2 테스트 완료

사용자 커뮤니티에서 R2 내부 1을 비공식적으로 검토했습니다.

 

필요한 경우, R2 내부 1을 릴리스하여 R1 결함과 고객 만족사항을 처리할 수 있습니다.

 

T4 반복 - R2 릴리스 개발/배치

R2 릴리스의 패키지를 작성하고 분배 및 설치합니다.

R2 코드 완료

 

R2 제품 릴리스

사용자 커뮤니티에서 R2 내부 2를 비공식적으로 검토했습니다.

2 단계 릴리스는 사용자에 대한 보다 쉬운 전이 기능을 제공합니다.

 

4.2.3          릴리스

이 소프트웨어 개발 계획은 수강 신청 시스템의 처음 두 릴리스에 대해 설명합니다. 비전 문서 [1]에 정의된 중요 기능이 처음 두 릴리스의 대상이 됩니다. 학생 수강 신청에 중요한 모든 기능이 첫 번째 릴리스(R1.0)에 대해 계획되었습니다.

계획된 릴리스 컨텐츠는 프로젝트 진행에 따라 변경될 수 있습니다. 이유는 비즈니스 및 기술 요인이 다양하기 때문입니다. 해당 변경사항을 수용하기 위해 Rational RequisitePro를 사용하여 제품 요구사항을 관리하고 릴리스 컨텐츠를 추적합니다. 특히, 제품 요구사항과 대상 릴리스의 우선순위를 결정하기 위해 이점, 노력 및 위험성 속성이 사용됩니다.

수강 신청 시스템은 Wylie College에서의 일반 사용을 위해 2 - 4개의 기본 릴리스가 릴리스될 예정입니다.

릴리스 1에는 최소한 다음과 같은 기본 기능이 포함되어야 합니다.

릴리스 2에 포함될 내용은 다음과 같습니다.

릴리스 3의 기능은 아직 결정되지 않았지만 기존 기능에 대한 개선사항이 포함될 것으로 예상됩니다.

레거시 청구 시스템 및 과정 카탈로그 시스템에 대한 향후 대체는 2005년 릴리스 4를 목표로 하고 있습니다.

또한 R1.0 제품 릴리스 이전에 베타 릴리스가 출시되며 이 릴리스에는 R1의 중요 기능이 모두 포함되어 있습니다. 베타 릴리스는 기존 시스템을 방해하지 않도록 기존 레거시 시스템의 분리 사본과 상호작용하는 것을 제외하고는 실제 시스템과 같이 분배됩니다. 베타를 공식적으로 평가하기 위해 학생 및 교수 그룹을 선택해야 합니다.

또한 프로젝트를 추적하기 위해 일반 하트비트를 유지하고, 필요한 경우 초기 릴리스 후 추가 릴리스에 대한 가능성을 허용하기 위해 내부 릴리스가 제공됩니다. 내부 릴리스는 학생 및 교수가 비공식적으로 검토할 수 있습니다. 다음은 이러한 내부 릴리스 각각의 목표에 대한 간략한 설명을 제공합니다.

릴리스 3의 기능은 아직 결정되지 않았지만 기존 기능에 대한 개선사항이 포함될 것으로 예상됩니다.

레거시 청구 시스템 및 과정 카탈로그 시스템에 대한 향후 대체는 2005년 릴리스 4를 목표로 하고 있습니다.

4.2.4          프로젝트 스케줄

다음과 같이 프로젝트 단계, 반복 및 이정표를 보여주는 상위 레벨 스케줄이 수강 신청 상위 레벨 프로젝트 스케줄 [5]에 포함됩니다.

프로젝트 스케줄

날짜

도입/인식(Inception) 단계

 

예비적 반복(시작)

1998년 12월 1일 화요일

비즈니스 사례 검토 이정표(도입/인식 단계 종료)

1999년 1월 19일 화요일

정제(Elaboration) 단계

 

반복 E1 - 아키텍처 프로토타입 개발

 

아키텍처 프로토타입 이정표(정제(Elaboration) 단계 종료)

1999년 3월 9일 화요일

구현/구축(Construction) 단계

 

반복 C1 - 릴리스 1 베타 개발

 

초기 오퍼레이션 기능 이정표(R1 베타 코드 완료)

1999년 4월 9일 금요일

전이(Transition) 단계

 

반복 T1 - 릴리스 1 개발/배치

 

R1 베타 테스트 완료

1999년 4월 16일 금요일

R1 코드 완료

1999년 4월 30일 금요일

R1 제품 릴리스(T1 종료)

1999년 5월 7일 금요일

반복 T2 - 릴리스 2 베타 1 개발

 

R2 내부 1 테스트 완료(T2 종료)

1999년 5월 28일 금요일

반복 T3 - 릴리스 2 베타 2 개발

 

R2 내부 2 테스트 완료(T2 종료)

1999년 6월 18일 금요일

반복 T4 - 릴리스 2 개발/배치

 

R2 코드 완료

1999년 7월 2일 금요일

R2 제품 릴리스(프로젝트 완료)

1999년 7월 9일 금요일

4.2.5          프로젝트 자원 계획

4.2.5.1     인력 구성 계획

섹션 8.1의 조직도에서 식별된 IT 담당자가 프로젝트에 할당됩니다. 추가 자원은 도입/인식(Inception) 단계 종료 시점에서 비즈니스 사례를 검토하고 프로젝트에 대한 진행/중단 결정이 내려질 때까지 충원되지 않습니다.

테스트 조직은 조직도에 점선으로 표시되는 소프트웨어 엔지니어링 조직의 지원에 의존합니다.

4.2.5.2     자원 확보 계획

Wylie College IT 부서에는 프로젝트 요구를 충족시킬 수 있는 개발자와 디자이너가 충분하지 않습니다. Wylie College 채용팀에서는 C++ 경력이 풍부한 간부급 개발자와 최소 1년의 C++ 경력을 보유한 시스템 통합자 및 두 명의 구현자/테스터(사원급)를 채용할 예정입니다.

4.2.5.3     훈련 계획

디자인 활동을 시작하기 전에 프로젝트 팀에 대해 다음과 같은 스킬 훈련이 수행됩니다.

4.2.6          예산

 

초기 예상을 기반으로 한 프로젝트 예산

4.3               반복 계획

수강 신청 시스템 E1 반복 계획 [11]을 참조하십시오.

4.4               프로젝트 모니터링 및 제어

4.4.1          요구사항 관리 계획

이 시스템에 대한 요구사항은 비전 [1] 및 이해 당사자(stakeholder) 요청 [3] 문서를 참조하십시오.

4.4.2          스케줄 제어 계획

프로젝트 관리자는 각 이정표의 예상 날짜를 보여주며 상태 평가 보고서(보고 계획 참조)의 일부인 요약 스케줄을 유지보수합니다. 상태 평가 보고서는 IT 책임자에게 제공되며 해당 책임자는 이 보고서를 사용하여 새 우선순위를 설정하거나 올바른 조치를 권장할 수 있습니다.

요약 스케줄은 팀 관리자가 유지보수하는 세부 스케줄에서 파생됩니다. 세부 스케줄의 라인 항목은 개인에게 지정되는 작업 패키지입니다. 작업 패키지가 지정되는 각 개인은 매주 해당 팀 관리자에게 완료율(%) 정보를 제공합니다.

4.4.3          예산 제어 계획

비용은 프로젝트 관리자가 모니터하며 상태 평가 보고서를 통해 보고되고 평가됩니다.

4.4.4          품질 제어 계획

모든 중간 산출물은 해당 검토 프로세스를 통과해야 합니다. 이러한 검토 작업은 Rational Unified Process [6] 검토 가이드라인 및 점검 목록에서 설명하는 가이드라인을 사용하여 각 중간 산출물의 품질이 올바른지 확인하기 위해 필요합니다.

또한 결함이 기록되고 추적되며 Wylie 소프트웨어 프로세스 웹 사이트 [10]에서 설명하는 대로 결함 메트릭을 수집합니다.

4.4.5          보고 계획

상태 평가 보고서는 적어도 한 달에 한 번 프로젝트 관리자가 준비하며 다음과 같은 내용이 포함됩니다.

    - 갱신된 비용 및 스케줄 예상

    - 메트릭 요약

4.4.6          측정 계획

Wylie College 소프트웨어 프로세스 웹 사이트 [10]에서 설명하는 표준 프로젝트 메트릭을 수집하여 상태 평가 보고서에 포함합니다.

4.5               위험성 관리 계획

수강 신청 시스템 위험성 목록 [8]을 참조하십시오.

4.6               완료 계획

이 스케줄에는 다른 프로젝트로의 점진적인 인력 이동이 표시됩니다. 제품 제공 후에도 IT 부서에서 최소한 한 명의 개발자를 임시로 배치하여 시스템 유지보수 기능을 제공합니다.

예상 비용 및 스케줄 대 실제 비용 및 스케줄 비교 평가를 포함하여 프로젝트 진행을 통해 얻은 교훈을 요약한 사후 검토 보고서가 IT 책임자에게 제출됩니다.

5.                  기술 프로세스 계획

5.1               개발 사례

수강 신청 시스템 개발 사례 [9]를 참조하십시오.

5.2               방법, 도구 및 기법

Wylie College 소프트웨어 프로세스 웹 사이트 [10]을 참조하십시오.

5.3               하부 구조 계획

없음

5.4               제품 적합성 계획

없음

6.                  지원 프로세스 계획

Wylie 소프트웨어 프로세스 웹 사이트 [10]을 참조하십시오.

7.                  추가 계획

없음

8.                  부록

없음

9.                  색인

없음