SW 프로젝트 계획서 - SW peulojegteu gyehoegseo

[소프트웨어공학]프로젝트 계획서

• 상세정보
• 자료후기 (0)
• 자료문의 (0)
• 판매자정보

소개글

의약품 데이터베이스를 주제로한 프로젝트 계획서입니다.
만점 받은 계획서입니다.

목차

프로젝트 계획서
요구 명세서
자료사전
자료 흐름도 (DFD (Data Flow Diagram))
시스템 제약사항
개체 관계도(E-R Diagram)
자료의 변환 흐름도
시스템 구조도
N-S Chart
Test

본문내용

위험관리 전략

위험 테이블
데이터 베이스의 구축 도중에 데이터가 손실되거나, 필요한 하드 디스크 용량이나 성능의 계산이 잘 못 될 위험성.
사용자가 시스템접근에 의한 DB손실위험

위험 관리 전략
데이터 베이스 구축 시에는 자주 백업을 받아 놓는다. 하드 디스크의 용량은 최대 필요 용량에 여유분을 계산하여 더한다.
사용자가 사용하기 편한 인터페이스와 정기적인 교육

프로젝트 자원
인적 자원
5명의 개발자가 4주간 개발한다.

개발 언어
PHP 5.0
DBMS MY-SQL 4.1
APACHE 2.0

개발 환경
컴퓨터사양 : Pentium IV 이상, RAM 512MB
운 영 체 제 : Linux Debian 2.6

개 요

목 적
의약품 데이터베이스를 구축하여 사용자에게 정확한 정보 즉, 의약품의 용법, 주의사항, 효능·효과 등을 제공하여 올바른 의약품 사용을 유도한다.

요 약
관리자는 로그인 후에 자신의 정보 수정할 수 있다. 관리자는 로그인 후에 또 DB를 관리할 수 있다. 관리 시에는 등록, 수정, 삭제를 할 수 있는데 등록, 수정, 삭제 시에 관리모드가 선택되어 관리테이블에 저장 된다. 이 관리테이블은 누가 관리를 하였는지 무슨 모드로 하였는지 어떤 제품을 관리하였는지 알 수가 없게 된다. 또한 이 관리 시에는 약효군, 성분정보, 제품코드, 회사코드 등을 테이블 별로 수정할 수 있다.

태그

이 자료와 함께 구매한 자료

[소프트웨어공학]프로젝트 계획서

• 상세정보
• 자료후기 (6)
• 자료문의 (0)
• 판매자정보

소개글

소프트웨어공학 수업을 진행하면서 작성한 프로젝트 계획서 입니다. 3명이서 한조를 이루어 프로젝트를 진행하였습니다. 프로젝트 내용은 수강신청 시스템입니다. 기본적인 구조는 교재로 사용한 소프트웨어공학론(최은만저)의 내용을 참고하였습니다.

목차

1. 개요(Overview
1.1 프로젝트 개요(Project Overview)
1.2 프로젝트 산출물(Project Artifacts)
1.3 정의 및 약어(Definitions and Acronyms)
2. 자원 및 일정(Resource and Schedule)
2.1 자원(Resource)
2.1.1 인력(Human Resource)
2.1.2 비용(Costs)
가. 인건비(Labor Costs)
나. 제비용(Charge)
다. 총비용(Total Costs)
2.2 프로젝트 일정(Project Schedule)
2.2.1 CPM(Critical Path Method)
2.2.2 일정 계획표(Schedule Plan)
3. 조직 구성 및 인력 배치(Project Organization and Human Place)
3.1 조직 구성(Project Organization)
3.1.1 조직 구성도(Organizational Structure)
3.1.2 투입 인력 계획(Investment Human Plan)
3.2 직무 기술(Function Skill)
4. WBS(Work Breakdown Structure)
5. 기술 관리 방법(Technical Management Plan)
5.1 변경관리(Modification Control)
5.2 위험관리(Risk Control)
6. 개발 절차 및 품질 관리(Development Process and Quality Management)
6.1 개발 방법론(Development Process Model)
6.2 품질 관리(Quality Control)
7. 검토회의(Investigation Meeting)
7.1 검토회의 일정(Meeting Schedule)
7.2 검토회의 진행 방법(Meeting Progression Plan)
7.3 검토회의 후속 조치(Meeting Follow Plan)
8. 개발 환경(Development Environment)
9. 성능 시험 방법(Performance Testing)
10. 문서화(Documentation)
11. 유지 보수(Maintenance)
12. 설치 및 인수(Installation and Undertake)
13. 참고 문헌 및 부록(Reference and Appendix)

본문내용

1.1 프로젝트 개요(Project Overview)
한 학기를 시작할 때쯤이면 각 학기 시간표가 나오게 된다. 대부분 수강신청 기간이 아님에도 불구하고 시간표를 붙들고 예비 시간표를 짜는데 여념이 없다. 수강신청 당일이 되면 교내 미래관의 3층 전산실은 자리를 차지하려는 학생들로 붐비게 된다.
교내에서 접속을 하게 되면 접속 속도가 빠르기 때문이다. 수강신청 시간이 되면 수천의 트래픽이 발생하게 된다. 대부분의 인기강좌는 2분만에 승패가 결정된다. 이러한 현상은 비단 우리학교만의 문제가 아니라 대학가에서 연례행사처럼 치러지고 있다.
비싼 등록금을 내고도 정작 듣고 싶은 과목을 수강하지 못하는 현상이 발생하는 것이다. 수강신청 시스템이 매년 개선되고는 있지만 수강신청 당일의 트랙픽을 위해서 시스템에 무리한 투자를 하기는 어려울 것이다.
이러한 상황에서 수강신청을 하는데 불필요한 작업을 제거하고 보다 빠른 수강신청을 할 수 있도록 수강신청 시스템을 개선하는데 목표를 두고 있다.
트래픽 처리보다 현재 문제시 되고 있는 과목시간표 조회, 이미 수강한 과목에 대한 재수강 처리, 이수 학점에 대한 졸업학점 계산표 등을 추가하여 학생들이 수강신청 시스템을 이용하는데 편의를 제공하고자 한다.

1.2 프로젝트 산출물(Project Artifacts)
본 프로젝트를 진행함에 있어서 다음과 같은 산출물이 발생된다.

- 수강 신청 사용자 프로그램
- 관리용 서버 프로그램
- 데이터관리용 데이터베이스
- 통합 연동 모듈

참고 자료

[1] 소프트웨어 공학론, 정익사(최은만 저, 1995)
[2] Code Complete, 정보문화사(Steve McConnell, 서우석 역, 2005)
[3] 강원대학교학칙(강원대학교)
[4] 학칙운영규정(강원대학교)
[5] 한국정보통신기술협회 (http://www.tta.or.kr)
[6] 국제표준화기구(http://www.iso.org)
[7] 전기전자기술자협회 (http://www.ieee.org)

태그

이 자료와 함께 구매한 자료

Photo by Vadim Sherbakov on Unsplash

2019년 2학기 고려대학교 차성덕 교수님 소프트웨어 공학

요구 사항

교수님이 개강 첫날부터 질문거리를 던져주셨다.

“소프트웨어 개발 플랜을 생각해 봐라.”

“소프트웨어 계획서 쓸때 가장 중요한 세가지를 쓰라고 한다면 무엇을 쓸 것인가.”

소프트웨어란

흠.. 소프트웨어..소프트웨어라.. 갑자기 단어가 이상하게 느껴진다. 소프트웨어란 무엇일까? 우선 정의를 찾아보지 않고 생각해보자면.. 내가 맨날 개발하는거? 하드웨어랑 반대되는거? 컴퓨터 안에 있고.. OS에 의해 관리되는.. 이진수로 해석될 수 있는 프로그램…? 이제 정의를 찾아보자

컴퓨터 소프트웨어는 저장장치에 저장된 특정한 목적의 하나 또는 다수의 컴퓨터 프로그램을 뜻한다. 프로그램 소프트웨어는 컴퓨터 하드웨어에 직접 명령어를 주거나 다른 소프트웨어에 입력을 제공함으로써, 그것이 수행하도록 구현된 기능을 수행한다.

“소프트웨어”라는 용어는 1957년에 존 터키(John W. Tukey)가 처음 사용한 용어이다. 일상적으로 이 용어는 응용 소프트웨어의 의미로 자주 쓰인다. 컴퓨터 과학과 컴퓨터 공학에서 “컴퓨터 소프트웨어”는 컴퓨터 시스템, 프로그램, 데이터에 의해 처리된 모든 정보를 말한다.

컴퓨터 소프트웨어는 컴퓨터 하드웨어의 반대 의미로, 컴퓨터 하드웨어는 소프트웨어가 실행되고 저장되는 물리적 장치(물리 구조)이다.

오.. 얼추 이해하고 있던 것 같다. 목적을 가진 컴퓨터 프로그램! 오키!

내가 해왔던 개발 프로세스

그래 내가 항상 하고 있는게 소프트웨어 개발이었다. 그럼 사람들이랑 이걸 할때 어떤 식으로 진행해왔지..? 이걸 일단 떠올려 보면 소프트웨어 개발 플랜에 대한 대략적인 느낌이 올 것 같다.

기획. 디자인. 개발. 모든 프로젝트는 크게 이 세뭉텅이였다. 디자인을 하다가 기획이 바뀌기도 하고 개발을 하다가 디자인이 바뀌고 기획이 바뀌는 등 뒤죽박죽이 더 많긴 했지만 어쨌든 큰 프로세스는 이렇게 뭉텅뭉텅 세 뭉텅.

조금 더 자세히 생각해 보자면 이랬던 것 같다.

1. 아이디어를 낸다.
2. 헛소리와 함께 동료들과 함께 아이디어를 발전 시킨다.
3. 대략적인 틀이 잡히면 큰 기능을 명세한다.
4. 큰 기능을 바탕으로 목업 스케치등으로 화면을 그려본다.
5. 스케치 과정에서 더 필요한 것들이 보인다. 이를 바탕으로 자잘한 기능을 추가 해간다.
6. 기능과 화면의 우선순위를 정한다.
7. 개발 자원(기간, 인력 등)을 고려한 최소 기능과 화면을 설정한다.
8. 개발 스펙을 정한다.
9. 하드웨어가 껴있다면 블록 다이어그램을 그려본다.
10. 각 기능에 필요한 로직을 정리한다. (플로우 차트를 그린다.)
11. 기능 별로 통신을 위한 메시지 포맷을 정한다.
12. 각각 로직을 바탕으로 DB를 설계 / 서버 개발/ 클라이언트 개발을 한다.
13. 중간 중간 유저 테스트 등을 진행하면서 디자인, 기능 등을 수정한다.
14. 개발 완료 후 유지 보수와 함께 다음 마일스톤을 진행한다.

그럼 교수님이 생각해보라고 하신 개발 플랜은 뭘까. 그냥 내 프로세스에 빗대서 계획을 세우면 그게 개발 계획이 되는 걸까..? 아쉬웠던 점을 바탕으로 개선되었으면 하는 부분을 보충해서..?

사실 저 위의 순서대로 가기만 해도 완전히 완전 순조로운 방향이라고 생각한다. 프로젝트를 진행하다보면 처음의 기획의도와는 완전 다른 방향으로 가기도 하고, 개발하다가 갑자기 테스트유저 모드로 변신해서 불편한게 막 보이기도 하니까.. 그럼 뭐.. 화면이고 기능이고 중간에 뜯어고치는 수 밖에.. 이게..바로. 피보팅..? 이게 바로.. 애자일..?

여기서 나의 감은 끝나가니 검색을 할 시간인듯 하다.

소프트웨어 개발 계획이란

아. 지금 한이음 프로젝트에서 프로젝트 수행일정 틀이 있었는데. 한번 긁어와보자.

계획 — 분석 — 설계 — 개발 — 테스트 — 종료

오 비슷한거 같은데? 이게 개발 계획 맞는건가? software engineering plan 으로 구글링도 해보자. 우욱.. 영어 결과가 나왔지만 좋은 글 같으니 조금 번역을 해보자.. 갑자기 영어 공부..

소프트웨어 프로젝트 계획은 소프트웨어 엔지니어링과 프로젝트 관리를 위한 알맞은 계획을 세우기 위한 것이다. 이는 일의 수행에 필요한 추산치를 developing하는 것이나, 필수적인 책무(commitment)를 세우는것, 계획을 수립하는 것 등을 포함한다. 소프트웨어 계획은 진행될 일에 대한 서술과 소프트웨어 프로젝트를 규정하고 경계를 짓는 다른 제약이나 목표로 시작된다. 소프트웨어 계획 프로세스는 상품이나 자원이 얼만큼 필요할지를 측정하는 것, 스케쥴을 짜는 것, 소프트웨어 위험을 규정하고 가늠하는 것, 책무를 협상하는 것 등을 포함한다. 소프트웨어 프로젝트 계획을 수립하는데 이러한 과정을 반복하는 것이 필요할수도 있다. 이러한 계획은 소프트웨어 프로젝트의 활동을 수행하고 관리하는데 기초를 제공한다.

아래의 목적들이 소프트웨어 프로젝트 계획 프로세스를 통해 달성 된다.

1. 소프트웨어 추산치가 소프트웨어 프로젝트를 계획하고 트래킹할 수 있도록 문서화된다
2. 소프트웨어 프로젝트 활동과 책무(commitment)가 계획되고 문서화 된다.
3. 관련 그룹과 개인은 소프트웨어와 관련된 그들의 책무에 합의 한다.

다음의 기준은 반드시 소프트웨어 프로젝트 계획 프로세스 이전에 선행되어야 한다.

1. 프로젝트 번호가 부여되어야 한다
2. 프로젝트 매니저(PM)가 임명되어야 한다

다음의 절차들이 소프트웨어 계획 프로세스이다.

1. 팀에 참여한다.
2. 프로젝트 계획의 초기단계, 그리고 전반에 걸쳐 소프트웨어 프로젝트 계획을 착수한다.
3. 프로젝트에 걸쳐서 다른 관련 그룹과 함께 전반적 계획에 참여한다.
4. 조직 외 고위 관리직이 포함된 개인 / 그룹이 소프트웨어 프로젝트에 투입되는 것을 검토한다.
5. 이전에 정의된 상태를 이용해 관리할 수 있을 만한 사이즈의 소프트웨어의 라이프 사이클을 확인하고 정의한다. (Identify or define a software life cycle with predefined states of manageable size.)
6. 프로젝트의 소프트웨어 개발 계획을 발전시킨다.
7. 소프트웨어 프로젝트 계획을 문서화 한다.
8. 소프트웨어 프로젝트에 대한 제어를 수립하고 유지하는데 필요한 소프트웨어 work products 을 확인한다.
9. 소프트웨어 산출물의 사이즈 추산치나 변화 정도를 도출한다.
10. 소프트웨어 프로젝트의 노력과 비용 추산치를 도출한다.
11. 프로젝트의 중요한 컴퓨터 자원 추산치를 도출한다.
12. 프로젝트의 소프트웨어 스케쥴을 도출한다.
13. 프로젝트의 비용, 자원, 스케쥴, 기술적 측면과 관련된 소프트웨어 위험을 확인하고, 가늠하고, 문서화 한다.
14. 프로젝트의 소프트웨어 엔지니어링 설비와 지원도구에 대한 계획을 준비한다.
15. 소프트웨어 계획 데이터를 기록한다.

영어가 개똥이라 잘 해석이 안되는 부분도 있었지만 요약하자면

소프트웨어 개발에 필요한/할 여러 요소들을 고려하고 준비 하는 것. 이를 통해 프로젝트의 수행 및 관리를 돕는 것.

정도로 이해했다.

내가 이전에 쓴 개발 계획은 ‘6. 프로젝트의 소프트웨어 개발 계획을 발전시킨다.’ 의 일부분을 디테일하게 나열했던 듯 하다.

소프트웨어 계획서에서 가장 중요한 세가지

📌 중간고사 pick : 소프트웨어 개발 계획서에 중요한 세가지를 쓰고 그 이유를 한두문단으로 작성하라

그렇다면 소프트웨어 계획서에서 가장 중요한 세가지는 무엇일까. 물론 답은 없고 사람마다 생각이 다르겠지만 내가 계획서에 세가지만 쓸 수 있다면 아래와 같이 쓸 것이다.

1. 필요한 노력과 비용

자원이 무한하다면 완성 못할 프로젝트는 없다. 하지만 자원은 항상 한정되어 있고 우리는 이를 바탕으로 프로젝트를 진행해야한다. 우선 이것을 명확히 인지하는 것에서 부터 프로젝트의 전체 방향을 잡고 시작 할 수 있다고 생각한다.

2. 추진 일정

한정된 자원에서 빼놓을 수 없는 것 중 하나는 시간이다. 시간내에 완성해야하는 프로젝트에서 대략적인 추진 일정이 잡혀있지 않다면 업무가 연기되기 쉬울 뿐더러 프로젝트의 전체적인 일정을 관리하기에도 어려움이 있을 것이다.

3. 단계별 산출물

단계별 산출물과 같은 구체적인 결과를 제시함으로써 일원들은 추상적 개념에서 벗어나 무엇을 해야할 지에 대한 목표를 명확히 설정할 수 있다. 또한 다른 사람들에게도 보다 이해하기 쉽게 프로젝트의 방향이나 계획 등을 설명할 수 있다.

참고 자료

https://ko.wikipedia.org/wiki/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4

https://ppqc.net/assets/Example%20Project%20Planning%20Process.pdf