'소프트웨어 공학'에 해당되는 글 2건

  1. 2009.02.01 File Management Program Project
  2. 2008.10.26 Food website Project SPMP (Software Project Management Plan)

이 문서들은 내가 예전에 소프트웨어 설계 프로젝트를 할 때 초안으로 만든 문서이다.

프로젝트의 주제는 파일 관리 시스템을 만드는 것으로 시스템 구축에 필요한 요구사항 정의 및 설계까지가 목표였다.

대략 내용들의 흐름이 잘 이어지지 않지만 프로젝트 수행 중 문서화에 대하여 익숙치 않은 분들을 위해 나름 대학을 다닐 때 만들었던 문서들을 공유하려고 이렇게 올린다. 문서의 목차만 봐도 소프트웨어 공학을 공부하는데 도움이 될 것이라 생각된다.
(문서는 프로젝트 정의, 설계까지이고 구현한 구현물은 어따뒀는지 사라져 버렸다..--;; 문서 초안만 남아서 있는 것만 모아서 올린다..;;)

아래 번호는 대략적인 순서에 맞게 작성한거라 프로젝트 진행에 순서가 다른 경우도 있다. 순서에 너무 신경쓰지 말 것!


프로젝트 정의단계

1.  Software Guide Line 
     프로젝트 수행을 위한 가이드라인을 제시한 문서이다.(코딩표준은 제외)

2.  Software Project Management Plan 
    프로젝트가 수행되기 위한 각종 계획 및 기간을 설정한다. 수행 단계마다 나와야 하는 문서들도 정의하고
    시스템구축의 초기모형도 설정한다.
3.  Software Requirement Specification (SRS)
     프로젝트가 시작이 되면 고객(Client)로부터 해당 프로젝트가 가져야할 다양한 기능들에 대하여 요구사항을
     뽑아내어야 한다. 이때 요구사항은 잘 정리해서 문서화해야만 설계 및 구현 단계에서 문제가 발생하지 않는다.
     요구사항정의서는 해당 내용이 방대한 경우 Sub 문서로 분류하기도 하는데 해당 문서의 경우 Glossary 및 상세
     요구사항정의서를 Sub 문서로 만들었고 간략한 유스케이스 기술서를 요구사항정의서에 포함시켰다. 
     본 문서는 EEE standard의 SRS 표준을 따르고 있다.
4. Glossary
   SRS Sub의 문서로 문서에 사용되는 각종 단어를 정의한 문서이다. 단어사전 같은 것이다.

5. Use Case Modeling 
   요구사항을 분석하여 해당 기능을 유스케이스로 나타낸다. 유스케이스는 starUML로 그렸고 규모가 작아서
   시퀀스 다이어그램을 포함 시켰다. 규모가 큰 프로젝트의 경우 시퀀스 다이어그램만 따로 빼내서 문서화 한다.
 
프로젝트 설계 단계

6. Architecture Specification 
   시스템이 구축되기 전에 시스템 전체의 구성을 정의한다. 서버 구성 및 Layer 구성들을 표기한다.
7. Statement Designed
    상태다이어그램이라고 시퀀스 다이어그램을 그리면서 작성하는 문서가 있는데 파일이 초안도 안남아 있어서
    올리지는 못했다.;;

8. Component Design
   요구사항에 따른 프로젝트의 세부 컴포넌트를 설계하는 단계이다.
   (문서에 있는 설계는 잘못 설계되었다..ㅡ.ㅡ;; 그냥 참고만 부탁..)
 
10. Class Design
     실제 코드를 개발하기 위한 인터페이스를 기술하는 문서로 Java Doc과 같이 클래스와 메소드에 대한 주석들을
     모아놓은 문서라고 생각하면 쉬울 것 같다.

11. Screen Design
    이건 UI 기술서인데 요구사항에 대한 스토리보드라고 생각하면 된다. 미리 프로토타입을 만드는 경우도 있고
    디자인만해서 개발의 UI를 가시화 시키려는 경우도 있다.
 
12. DataBase Design
   말 그대로 데이터베이스를 기술한 문서이다. 물리설계 및 논리설계를 ERD로 표기하고 각 테이블에 대한 정보를
   기술한다. 그리고 해당 테이블이 어떤 유스케이스과 관계가 있는지(혹은 시퀀스와 관계가 있는지) 표기한다.


대략 12개의 파일로 구성되었고 원래 잘 만들어진 소프트웨어 프로젝트는 각 프로젝트 문서가 서로 연결이 되어야 한다. 즉 설계 문서를 보다가 해당 내용이 어디서 나온 건지 모르면 요구사항 정의 문서에서 찾을 수 있게 되어 있어야 하는 것이다. 문서화의 목적이 프로젝트 수행에 이루어지는 다양한 변화를 반영하여 이를 문서화 하므로 후에 유지보수가 쉽도록 하기 위한 것이기 때문이다. 너무 어렵거나 난해한 말로만 기술하여 이해를 하는 사람이 적거나 결과물과 차이를 보인다면 그 문서는 어딘가 잘못된 것이다.
 위의 12개 문서의 경우 사실 연결관계가 잘 설정되지는 않았다. 해당 문서의 요구사항 코드 및 분류 번호가 제대로 들어가지 못했기 때문이다. 만약 이 글을 보는 유저는 충분히 저 문서들 보다 나은 문서를 만들 것이라 생각하며 마치겠다.  




 

 
Posted by 서오석
,

이건 소프트웨어 공학에서 말하는 계획단계에 있는 녀석이다.

요구사항을 정의 한 후 프로젝트르 어떻게 수행할 것인지 리스크는 어떻게 관리할 것인지에 대한 정보가 적혀 있으며 수행 과제에 대한 기본적인 정보도 포함하고 있다.

별첨도 있는데 귀찮아서 안 올린다..--;;


목차는 아래와 같다.

1.0 Project purpose 7
1.1 Introduction 7
1.2 Definitions 7
1.3 Person 7
1.4 Plan 7
1.5 Project Productions 7
1.6 References 9
1.7 Glossary 9
2.0 Project Overview 10
2.1 Project purpose, scope 10
2.2 Assumptions and Dependencies 10
2.3 Functional requirements 10
3.0 Project Organization 10
3.1 Organizational Structure 10
3.1.1. System Architecture Guidelines 11
3.1.2 Hardware/Software Structure 12
3.2 Process Modeling 12
3.2.1 Delvelopment Process 12
3.2.2 Process Model 12
3.3 Development Environment 14
4.0 Management Process 14
4.1 Priority 14
4.1.1 Priority Standard 14
4.1.2 Priority Metrix 15
4.2 Configuration Management 15
4.2.1 Configuration Identifying Category 16
4.2.2 Version Management 16
4.3 Quality Control 17
4.3.1 Purpose 17
4.3.2 Scope 17
4.3.3 Quality Control Plan 17
4.3.4 Quality Control Activity 18
4.4 Risk Control 18
4.4.1 Core substance 18
4.4.2 Risk generalization table 18
4.4.3 Risk Detail Analysis Content 19
4.4.3.1 Risk Type – Resource 19
4.4.3.2 Risk Type – Scope 19
4.4.3.3 Risk Type – Plan 20
4.4.3.4 Risk Type – Cost 20
4.4.3.5 Risk Type – Quality 21
4.4.4 Risk Monitoring Cycle Plan 21
5. Functional Process 21
5.1 Methodology Tool 21
5.2 Repeat Gradual Development Procedure 21
5.3 Project Tool and Technique 22
5.4 Each Step Propulsion Procedure 22
6. Scheduling 23
6.1 Task 23
6.2 Task Dependence Relation 23
6.3 Resouce consumption Plan 24
6.3.1 Project formation 24
6.3.2 Project Execute Duty 24
6.3.3 Business Conference 25
6.3.4 Communication 25
6.4 Budget Plan 26
6.4.1 Event List 26
6.4.2 FP 26
6.5 Scheduling Plan 27
7.0 Test Plan 27
8.0 Maintenance Plan 28
8.1 Maintenance Summary 28
8.2 Application Software Maintenance 29
9.0 Education Training Plan And Technique Transform Plan 29
9.1 Education Training Plan 29
9.1.1 Education Scope 29
9.1.2 Education Training Plan 30
9.2 Technique Transform Plan 30
9.2.1 Technique Transform Substance 30
9.2.2 Technique Transform method 31

계획을 세우고 나서는 마일스톤과 WBS를 작성하게 되는데 아래 우리 프로젝트에 대한 WBS를 작성한 것을 올려놓겠다.

Posted by 서오석
,