서영환
2024. 7. 31. 16:02
2024. 7. 31. 16:02
- SRS(Software Requirements Standards, 요구사항명세서)
- 소프트웨어의 요구사항을 상세하게 명세한 문서
- 작성에 필요한 조건
- 이해관계자들(의뢰주체)이 반드시 참여
- 비전공자도 이해할 수 있도록 언어를 정의하고 부록을 포함
- 개발을 주도하는 기술진들도 반드시 참여
- 여러가지 비용이 현실적으로 고려
- 소프트웨어 개발방법론에 따라 문서는 항상 최신상태를 유지
- 국제 및 국내 표준을 따르도록 기획
- 문서 담겨야 할 내용 예시
- 소프트웨어 개요
- 개발하고자하는 소프트웨어의 전반적인 내용을 요약
- 유저 시나리오
- 사용자가 해당 소프트웨어를 사용하기 위한 일련의 과정
- 목표 시나리오 : 개발자의 의도대로 목표까지 사용되는 시나리오
- 경험 시나리오 : 사용자가 실제 소프트웨어를 사용하며 생성되는 여러가지 과정
- 와이어프레임
- UX를 고려하여 만든 UI로 각 인터페이스가 어떤 역할을 하는지, 대략적인 모양, 색깔, 위치 등 기준을 나타내는 문서
- 구동 환경
- 해당 소프트웨어가 구동되기 위한 물리적, 논리적 조건을 설명
- 요구 성능
- 해당 소프트웨어가 원할하게 처리해야하는 목표 요구치
- 제한 사항
- 소프트웨어가 원할하게 사용되기 위한 제한 사항
- 일반적인 사황이 아닌 예외 상황들도 있기에 최소한의 구동 조건 및 최대 구동 조건등을 설정
- 남극이나 사막 같은 지역에서 사용할 프로그램인 경우 해당 환경 조건을 맞게 개발 하여 하는데 아닌 경우 환경 요건을 빼거나 제한을 줄 수 있다
- 네트워크 트래픽에는 한계가 있고 이를 늘리기 위해서는 비용이 드는데 이를 비용은 고정된 상태에서는 트래픽 제한을 두어 최대 트래픽을 두어 그 만큼만 동작이 되게 제한
- 안드로이드 환경에서만 구동 가능한 어플리케이션을 개발 중에 있는 상태에서 IOS 환경에서 어플리케션을 동작 시키면 안되기에 실행 기기 환경을 제한
- SDS(Software Design Standards, 소프트웨어 설계 사양서)
- 소프트웨어의 전반적인 설계에 대해 상세하게 명세한 문서
- 작성에 필요한 조건
- 가장 적합한 핵심 기술진의 주도하에 SRS문서에 맞추어 SDS문서를 작성
- 최소 비용과 최대 효율을 적절하게 계산하여 설계
- 목표 개발 일정을 고려하여 절차에 따라 설계
- 반드시 유지보수성을 고려하여 설계
- 기술진이 아닌 사람들의 요구사항(SRS에 작성되지 않은 내용)을 최대한 줄인다
- 문서 담겨야 할 내용 예시
- 와이어프레임
- UX를 고려하여 만든 UI로 각 인터페이스가 어떤 역할을 하는지, 대략적인 모양, 색깔, 위치 등 기준을 나타내는 문서
- 최대한 개발자의 의도보다 SRS문서에 따른 와이어프레임의 내용을 적용
- 개발 환경
- 소프트웨어를 개발하기위한 물리적/논리적 환경
- 프로그래밍 언어는 python 3.10.8을 적용
- IDE는 vscode 또는 pycharm을 사용
- SQL은 SQLite 3.46을 적용
- 디자인 패턴
- 연계 기술
- 함께 연계되는 기술들은 어떤것들이 있는지 작성
- ChatGPT-4
- 주요 기술들과 함께 개발 언어와 SQL에 대한 내용도 함께 포함하여 작성
- 구동 환경
- 본 소프트웨어가 구동되기 위한 환경에 대해 설명
- API 명세서
- 사용되는 메소드에 대한 이름, 기능, url, end-point, 목적, 필요 매개변수 등 모든 사항을 표 형태로 기재
- 꼭 표 형태로 만들 필요는 없으나 가독성을 위하여 표를 사용하는게 좋다
- UML (Unified Modeling Language, 통합 모델링 언어)
- 그림과 관계도를 그려서 누구나 쉽게 알아볼 수 있도록 하는 다이어그램
- 클래스 다이어그램
- ERD(Entity Relationship Diagram, 개체 관계 다이어그램)
- 파일 구조
- 소프트웨어의 전반적인 파일 구조를 설명
- 반드시 각 폴더 및 파일이 어떤 역할을 하는지 설명
- SCS(Software Code Standards, 소프트웨어 코드 사양서)
- 소프트웨어를 개발하기 위한 작성할 코드에 대한 표준 문서
- 작성에 필요한 조건
- 철저하게 소프트웨어 개발진을 위한 문서
- 유지보수를 고려하며 작성
- 인수인계를 고려하며 작성
- 국제 표준을 준수하도록 작성
- 최대한 간단하지만 명료하게 작성
- 문서 담겨야 할 내용 예시
- 개발 환경, 프로그래밍 언어
- 개발 방식
- 보통 디자인 패턴과 파일 구조 등 개발 하기 위한 공통된 방식을 정의
- 코드 컨벤션
- 소스코드를 작성할 때 공통된 방식으로 작성하도록 정의
- 이슈 처리 방법
- 프로그램적인 문제가 발생하였을 때 어떻게 대응하는지에 대해 정의
- 형상 관리에 관한 전반적인 내용
- 형상 관리 주기, commit 컨벤션 등 전반적인 내용을 정의
- WBS(Work Breakdown Structure, 업무 분류 체계)
- 프로젝트를 수행하기 위한 업무를 분류하여 정리한 문서
- 작성에 필요한 조건
- 개발 목표 일정과 기한을 넘지 않도록 계획
- 개발 담당자를 통해 적절한 개발 기간을 확보
- 적절한 업무의 분배가 이뤄지도록 작성
- 문서 담겨야 할 내용 예시
- 개발 일정
- 개발 항목
- 기능단위로 대분류, 중분류, 소분류로 나누어 세분화
- KPI (핵심 성과 지표)
- Verification & Validation
- 소프트웨어의 신뢰성과 성능을 보장하기 위해 작성하는 문서들의 모음
- 문서 담겨야 할 내용
- TestPlan: 시험 계획
- TestCase: 시험 항목
- 사이버보안 check list: 사이버보안에 관련된 검증 및 확인 항목들
- 제한사항: 검증 및 확인을 하기 위한 제한 사항을 의미
- UX 관련된 피드백 보고서
- 강의 듣고 난후
- 이번 강의 듣고 난 후 생각보다 현업에서 문서작업을 많이 하는게 느낄 수 있었다
- 아직 까지 대단위 프로젝트를 하지 않아 문서작업을 할 필요성이 없었으며 단순 캠프내에서 작은 프로젝트르 한 것이기도 하며 기능들이 간단 하여 문서 작업을 하지 않았으나 취업을 한 상태였다면 작은 것이라도 문서화 하는게 어찌 보면 당연하다는 생각도 하게 되었다.
- 왜냐하면 취업후 문서는 당연히 돈과 바로 직결된 문제 이기에 책임에 대한 소지를 명확히 하는 것이 그 무엇보다 중요하다
- 또한 첫 문서를 제대로 작성하지 않았다면 그 후 문서들도 잘 못되는게 어찌 보다면 당연하다는 생각을 하게 되었다.
- 왜냐하면 문서가 하나씩 독립된게 아닌 처음 만든 SRS 문서를 기반은 SDS 문서를 만들고 또 그 문서를 통하여 SCS등을 만들어 가기 때문이다
- 대학교나 학원 같은데서 하는 문서는 귀찮기만 했었는데 앞으로는 귀찮음을 느끼기 보다는 최대한 잘 쓰기 위해 노력을 해야 할 겉다..