이 문서들은 내가 예전에 소프트웨어 설계 프로젝트를 할 때 초안으로 만든 문서이다.
프로젝트의 주제는 파일 관리 시스템을 만드는 것으로 시스템 구축에 필요한 요구사항 정의 및 설계까지가 목표였다.
대략 내용들의 흐름이 잘 이어지지 않지만 프로젝트 수행 중 문서화에 대하여 익숙치 않은 분들을 위해 나름 대학을 다닐 때 만들었던 문서들을 공유하려고 이렇게 올린다. 문서의 목차만 봐도 소프트웨어 공학을 공부하는데 도움이 될 것이라 생각된다.
(문서는 프로젝트 정의, 설계까지이고 구현한 구현물은 어따뒀는지 사라져 버렸다..--;; 문서 초안만 남아서 있는 것만 모아서 올린다..;;)
아래 번호는 대략적인 순서에 맞게 작성한거라 프로젝트 진행에 순서가 다른 경우도 있다. 순서에 너무 신경쓰지 말 것!
프로젝트 정의단계
1.가이드라인정의서_ver1.1.pdf2. 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
요구사항에 따른 프로젝트의 세부 컴포넌트를 설계하는 단계이다.
(문서에 있는 설계는 잘못 설계되었다..ㅡ.ㅡ;; 그냥 참고만 부탁..)
프로젝트가 수행되기 위한 각종 계획 및 기간을 설정한다. 수행 단계마다 나와야 하는 문서들도 정의하고
시스템구축의 초기모형도 설정한다.
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과 같이 클래스와 메소드에 대한 주석들을
모아놓은 문서라고 생각하면 쉬울 것 같다.
실제 코드를 개발하기 위한 인터페이스를 기술하는 문서로 Java Doc과 같이 클래스와 메소드에 대한 주석들을
모아놓은 문서라고 생각하면 쉬울 것 같다.
11. Screen Design
이건 UI 기술서인데 요구사항에 대한 스토리보드라고 생각하면 된다. 미리 프로토타입을 만드는 경우도 있고
디자인만해서 개발의 UI를 가시화 시키려는 경우도 있다.
12. DataBase Design
말 그대로 데이터베이스를 기술한 문서이다. 물리설계 및 논리설계를 ERD로 표기하고 각 테이블에 대한 정보를
기술한다. 그리고 해당 테이블이 어떤 유스케이스과 관계가 있는지(혹은 시퀀스와 관계가 있는지) 표기한다.
대략 12개의 파일로 구성되었고 원래 잘 만들어진 소프트웨어 프로젝트는 각 프로젝트 문서가 서로 연결이 되어야 한다. 즉 설계 문서를 보다가 해당 내용이 어디서 나온 건지 모르면 요구사항 정의 문서에서 찾을 수 있게 되어 있어야 하는 것이다. 문서화의 목적이 프로젝트 수행에 이루어지는 다양한 변화를 반영하여 이를 문서화 하므로 후에 유지보수가 쉽도록 하기 위한 것이기 때문이다. 너무 어렵거나 난해한 말로만 기술하여 이해를 하는 사람이 적거나 결과물과 차이를 보인다면 그 문서는 어딘가 잘못된 것이다.
위의 12개 문서의 경우 사실 연결관계가 잘 설정되지는 않았다. 해당 문서의 요구사항 코드 및 분류 번호가 제대로 들어가지 못했기 때문이다. 만약 이 글을 보는 유저는 충분히 저 문서들 보다 나은 문서를 만들 것이라 생각하며 마치겠다.
말 그대로 데이터베이스를 기술한 문서이다. 물리설계 및 논리설계를 ERD로 표기하고 각 테이블에 대한 정보를
기술한다. 그리고 해당 테이블이 어떤 유스케이스과 관계가 있는지(혹은 시퀀스와 관계가 있는지) 표기한다.
대략 12개의 파일로 구성되었고 원래 잘 만들어진 소프트웨어 프로젝트는 각 프로젝트 문서가 서로 연결이 되어야 한다. 즉 설계 문서를 보다가 해당 내용이 어디서 나온 건지 모르면 요구사항 정의 문서에서 찾을 수 있게 되어 있어야 하는 것이다. 문서화의 목적이 프로젝트 수행에 이루어지는 다양한 변화를 반영하여 이를 문서화 하므로 후에 유지보수가 쉽도록 하기 위한 것이기 때문이다. 너무 어렵거나 난해한 말로만 기술하여 이해를 하는 사람이 적거나 결과물과 차이를 보인다면 그 문서는 어딘가 잘못된 것이다.
위의 12개 문서의 경우 사실 연결관계가 잘 설정되지는 않았다. 해당 문서의 요구사항 코드 및 분류 번호가 제대로 들어가지 못했기 때문이다. 만약 이 글을 보는 유저는 충분히 저 문서들 보다 나은 문서를 만들 것이라 생각하며 마치겠다.
'소프트웨어공학 > 산출물 정리' 카테고리의 다른 글
| AIRCIS Project (0) | 2009.04.03 |
|---|---|
| Food website Project SPMP (Software Project Management Plan) (0) | 2008.10.26 |
| Food website Project SRS (Software Requirements Specification) - IEEE standard (1) | 2008.10.26 |
| Food website Project (Proposal) (0) | 2008.10.26 |
| Library Project SPDD (Software Project Database Design) (0) | 2008.10.26 |
