★[A+레포트]소프트웨어 계획서(테이크 아웃 고객관리)★

소개글

★[A+레포트]소프트웨어 계획서(테이크 아웃 고객관리)★에 대한 보고서 자료입니다.

목차

1 개요
1.1 프로젝트 개요
1.2 프로젝트의 산출물
1.3 참고문헌 및 정의, 약어
2 자원 및 일정 예측
2.1 자원
2.2 일정
3. 조직 구성 및 인력 배치
3.1 조직 구성
3.2 직무 기술
4. WBS
5. 기술관리 방법
5.1 변경 관리
5.2 위험 관리
5.3 비용 및 진도 관리
5.4 문제점 해결 방안
6. 표준 및 개발 절차
6.1 개발 방법론
7. 검토 회의
7.1 검토회 일정
7.2 검토회 진행 방법
7.3 검토회 후속 조치
8. 개발 환경
9. 성능 시험 방법
10. 문서화
11. 유지 보수
12. 설치, 인수
13. 참고문헌 및 부록

본문내용

테스트
J
12
W
client 문서화
N
15
X
client 테스트
O
12
Y
통합
P, Q, R, T, V, U, X, W
임계경로 S L M N O X S5 (72일)
◈2팀 CP/M 네트워크
소 작 업
선행 작업
소요기간(일)
A
홈페이지 제작 및 설계
-
30
B
데이터 요소 및 class 설계
A
15
C
알고리즘 설계
A
12
D
구현
B, C
21
E
문서화
B, C
18
F
적용 및 테스트
D
12
G
웹사이트 개발
-
30
H
데이터 요소 및 class 설계
G
12
I
알고리즘 설계
G
12
J
구현
H, I
15
K
문서화
H, I
18
L
적용 및 테스트
J
12
M
DB연동 부분 개발
-
27
N
데이터 요소 및 class 설계
M
12
O
알고리즘 설계
M
9
P
구현
N, O
18
Q
문서화
N, O
18
R
적용 및 테스트
P
15
T
작업 종료
E, F, K, L, Q, R
임계경로 S A B S1 D F S4 (78일)
◈3팀 CP/M 네트워크
소 작 업
선행 작업
소요 기간
A
카드리더기 연동 시스템
-
30
B
데이터 요소 및 class 설계
A
12
C
알고리즘 설계
A
9
D
구현
B, C
18
E
문서화
B, C
18
F
적용 및 테스트
D
12
G
터치스크린 시스템
-
30
H
데이터 요소 및 class 설계
G
12
I
알고리즘 설계
G
9
J
구현
H, I
15
K
문서화
H, I
18
L
적용 및 테스트
J
12
M
작업 종료
E, F, K, L
임계경로 S A B S1 D F S3 (72일)
고객 단말기
대리점단말기
시스템 구성도
5. 기술 관리 방법
5.1 변경 관리
개발 단계의 모든 산출물에 대하여 변경관리를 실시한다. 개발이 진행되면서 변경 관리 대상항목을 정하고 각 단계의 이정표를 만나게 되고 검토회가 완벽히 끝난 후에는 각 산출물의 모든 변경은 중지시킨다. 산출물의 변경이 동결된 후 일어나는 변경은 철저히 보고에 의하여 심사한 후 변경하고 통보한다.
변경 관리에서 사용하는 변경 요청서는 별도로 정하며 변경 심사 및 형상 관리 절차는 품질담당자가 추후 정한다.
5.2 위험 관리
위험 요소
위험 관리 기법
1. 인력 부족
.유눙한 인력을 모집: 팀 구성: 요원배치: 교차교육: 유능인력 사전 확보
2. 비현실적 일정 및 예산
.더 자세한 비용, 일정 예측: 원가 분석: 점증적 개발: 소프트웨어 재사용: 요구를 줄임
3. 잘못된 기능의 소프트웨어
개발
.사용자 회람: 프로토타이핑: 사용자 지침서를 조기에 작성: 조직 분석: 직능 분석
4. 잘못된 인터페이스의 개발
.프로토타이핑: 시나리오: 테스크 분석: 사용자 분류(기능, 스타일, 업무)
5. 과포장
.요구 삭감: 프로토타이핑: 비용-수익 분석: 원가 분석
6. 계속적인 요구 변경
.최대 변경 상한선: 정보 은닉: 점증적 개발(다음 버전까지 변경을 연기
7. 외부 모양의 빈약
.벤치마킹: 검사: 대조 확인: 성숙도 분석
8. 외부 기능의 빈약
.대조 확인: 사전 검증: 설계 경연: 팀 작업
9. 실시간 성능의 빈약
.시뮬레이션: 벤치마킹: 모델링: 프로토타이핑: 튜닝
10. 기술적 취약
.기술 분석: 비용-수익 분석; 프로토타이핑: 점검
6. 표준 및 개발 절차
6.1 개발 방법론
본 프로젝트에서는 절차적 중심의 프로그래밍 언어를 사용하므로 전통적인 폭포수형 개발모형을 따른다. 다만 사용자의 의견을 충분히 수렴하기 위하여 설계 단계에 사용자 인터페이스에 대한 프로토타입을 작성하고 사용자의 의견을 청취한다. 개발 과정에서 필요한 여러 가지 문서는 IEEE에서 정하는 다음과 같은 여러 가지 문서 표준을 따른다.
IEEE 표준 830-1984 Software Requiremaent Analysis
IEEE 표준 983-1986 Software Quality Assurance Planning
IEEE표준 1028-1988 Software Reviews and Audits
IEEE 표준 1012-1986 Software Verification and Validation Plans
7. 검토 회의
- 검토회 일정
요구분석 검토회의 : 25주차
분석서 검토희의 : 29주차
코딩 검토회의 : 31주차
- 검토회 진행 방법
검토회의는 총 매니저(A1) 주관하에 각 팀별 총 관리자가 참가하여 프로그램 작성의 일정별 개발사항 확인 및 check, 기술적 / 설계적인 문제 보완
요구분석 검토회의시 각각의 관리자 뿐만 아니라 프로그램을 사용하게 될 사용자 입회하에 회의 진행, 코딩 검토회의시 각 팀의 개발자 전원 참가
- 검토회 후속 조치
검토회의시 도출되는 문제에 대해서 총 매니저 입회하에 문제발생 팀의 팀원 회의를 통해 해결책 모색
8. 개발환경
- 서버 1대
- 클라이언트 당 각 1대(13대) - Pentium Ⅲ 120MHz
- 개발 툴 : visual C++ 6.0
- DBMS MS-SQL
9. 성능 시험 방법
각 상황별 시나리오에 따른 시뮬레이션 실시 및 check, 예기치 못한 상황발생시 신뢰성 평가
10. 문서화
각 시스템별 정의 및 요구분석 사항에 따른 해결방법 제시, 자료사전 및 소단위 명세서
작성, 유지보수를 위한 코드의 문서화, 주석 기입.
11. 유지보수
. 개발에 참여한 프로그래머를 지정하여 일정기간 간격으로 방문하여 프로그램 사용상의 문제점 및 사용자의 요구사항을 확인토록 한다.
. 프로그램의 오류가 발생할 경우 프로그래머를 파견하여 프로그램의 문제점을 확인하도록 하고 프로그램 복구 팀을 편성하여 오류 수정작업 및 오류사항 기록을 하게 한다.
12. 설치, 인수
. 프로그램의 전반적인 설치는 프로그램 개발 팀에서 맡고 재설치를 하게 될 경우 프로그래머를 파견하여 설치에 참여토록 한다.
. 프로그램 사용자에게 총 매니저 주관하에 프로그램에 대한 사용 방법 및 주의 사항을 교육하고, 개발에 참여한 프로그래머 중 한명을 3주간 교육시키도록 한다.
13. 참고문헌 및 부록
①한국정보과학회, 컴퓨터 용어사전,
정익사,1990.
②최은만, 소프트웨어 공학,
정익사, 1995.
③김동환 외 3인, 구조적 시스템 분석,
홍능 출판사, 1992.ddnr이

키워드

소프트웨어 계획서,   소프트웨어 개발서,   계획서,   요구 분석서,   소프트웨어 공학,   테이크 아웃,   고객관리,   프로젝트