1.1. Software Development Process | Software Development Life Cycle (SDLC)
Introduction
Why do we need a formal process model for software development?
- 자주 실패한다.
- 복잡한 것을 만드는 것은 힘들다.
- 계획대로 실행하기 힘들다.
- 협업을 위한 방법이 필요하다.
소프트웨어 엔지니어링의 궁극적인 목표는 저렴한 비용과 짧은 시간에 최종 사용자의 요구를 충족시키는 고품질 소프트웨어를 생산하는 것이다.
Software Development Life Cycle (SDLC)
위와 같이 여섯개의 단계가 있다. 각 단계는 몇몇 스텝이 있고, 전달할 수 있게 문서화된다.
이를 구현하기 위한 다양한 SDLC 모델이 있다.(이후에 다룸)
여기서는 각 단계에서 하는 일을 알아본다.
Planning Phase
Input: Client proposal / project idea
output: Feasibility study report, project plan (incl. requirements)
- 이 단계의 목표는 구체적인 프로젝트 계획(예: 목표, 일정, 재무, 인력 등)을 작성하는 것입니다.
- Requirement elicitation은 고객, 영업부, 시장조사 및 업계 도메인 전문가로부터 최대한 많은 의견을 수렴하는 것을 목표로 한다.
- 수집된 요구사항은 사업계획 및 feasibility study 등에 활용된다.
- 시스템을 구축하는 것이 기술적으로나 경제적으로 가능한가?
- quality assurance requirements과 계획 수립 및 사업과 관련된 리스크 파악도 이 단계에서 이루어진다.
Some types of feasibility studies
- Technical feasibility
- 우리가 가진 기술, 자원, 인력이 이 프로젝트를 할 수 있는 상황인가?
- 유지 보수의 난이도는 어떠할까?
- Economic feasibility
- 개발하고 런칭하는 데 드는 비용을 얼마인가?
- 이 프로젝트로 수익이 나는가?
- Schedule feasibility
- 얼마나 오랫동안 프로젝트를 진행할 것인가?
- 프로젝트 계획은 현실적인가?
Analysis Phase
Input: Feasibility study and list of customer requirements.
output: SRS (Software Requirement Specification)
- Requirement analysis: 고객 요구사항을 사용하여 제품 요구사항을 명확하게 정의하고 문서화하여 고객 또는 시장 분석가로부터 승인받습니다.
- SRS (Software Requirement Specification): 프로젝트 수명 주기 동안 설계 및 개발되어야 하는 모든 제품 요건/제품으로 구성된 문서다.
- Functional requirements: 시스템 기능을 정의하는 요구 사항.
- Non-functional requirements: 시스템 품질(성능, 안전, 보안, 확장성, 사용성 등)을 정의하는 요구사항
Requirements elicitation and analysis
소프트웨어 엔지니어는 최종 사용자 및 기타 이해 관계자들과 협력하여 애플리케이션 도메인, 시스템이 제공해야 하는 기능, 필요한 시스템 성능, 하드웨어 제약, 기타 시스템 등에 대해 알아본다.
- 다음과 같은 과정이 포함된다.
- Requirements discovery (planning phase)
- 예를 들어 인터뷰, 최종 사용자 관찰
- Requirements classification and organization (planning or analysis phase)
- Requirements prioritization and negotiation (analysis phase)
- Requirements specification (analysis phase)
- Requirements discovery (planning phase)
- 그리고 여기서에서 use-case diagram(UML)이 사용될 수 있다.
- Analysis에서는 보통 use-case -> class -> state chart 순으로 다이어그램을 그린다.
Some problems related to requirements
- 이해 당사자들은 종종 그들이 진정으로 원하는 것이 무엇인지 알지 못한다.
- 각 이해당사자는 각자의 용어로 요구사항을 표현할 수 있다.
- 일반 사용자는 일반적으로 시스템 비용을 지불하는 사용자가 아니다.
- 이해관계자마다 상충되는 요구사항이 있을 수 있다.
- 조직적, 정치적 요인이 시스템 요구사항에 영향을 미칠 수 있다.
- Ex) 회사에서 구식 기술을 다른 시스템에 사용하므로 회사 방침에 따라 이를 사용해야 한다.
- 분석단계(또는 그 이후) 동안 요구사항이 변경될 수 있다.
Design Phase
Input: SRS(Software Requirement Specification).
output: DD(Design Document)
- Project design: SRS의 요구사항에 따라, 일반적으로 제품에 대한 두 개 이상의 설계 접근 방식이 제안되고 Design Document에 문서화된다.
- 여기에는 아키텍처뿐만 아니라 인간과 컴퓨터의 상호 작용 설계 측면도 모두 포함된다.
- DD는 모든 주요 이해 관계자에 의해 검토되며 위험 평가, 제품 견고성, 설계 모듈화, 예산 및 시간 제약 등의 다양한 지표에 기초하여 제품에 대한 최선의 설계 접근 방식을 선택합니다.
- DD는 테스트 결과와 최종 사용자의 피드백을 바탕으로 프로젝트 진행 중에 여러 번 업데이트되는 경우가 많습니다.
Implementation Phase
Input: DD (Design Document)
output: Program/software, including source code, content and media assets
- 중요한 점들
- DD에 맞춰서 구현을 한다.
- 만약 DD가 상세하게 잘 정리되어 있다면, 구현은 쉬워진다.
- 회사의 가이드라인에 따라야한다.
- 툴이나 언어 같은 것들을 따라야한다.
- 버전 관리 소프트웨어(깃 같은 것)을 활용한다.
- DD에 맞춰서 구현을 한다.
Testing and integration phase
Input: Un-tested program/software
Output: tested program/software, test report(s).
- 테스트의 종류
- Unit testing: 각 코드 단위(예: 클래스)는 다른 단위와 독립적으로 테스트됩니다.
- Integration testing: 소프트웨어 모듈은 통합될 때, 올바른 작동을 확인하기 위해 함께 테스트됩니다(예: 클라이언트와 서버는 함께 테스트됨).
- Regression testing: 이미 승인된 모듈/기능이 업데이트되어 시스템이 파손되지 않는지 확인할 때 수행됩니다.
- 이것은 버그를 고치는 것과 관련이 있다.
- System testing: 소프트웨어가 준비되면 전체적으로 테스트하여 SRS 문서와 일치하는지 확인합니다.
- User acceptance testing : 소프트웨어가 준비되면 클라이언트는 소프트웨어를 테스트하여 사용자의 요구와 요구 사항을 충족하는지 확인합니다.
- Usability testing : 시스템의 사용가능성(학습 가능성, 효율성, 기억성, 사용자 오류, 사용자 만족도 등)을 검증한다.
- Bug tracking system이라는 것도 있다.
- 예시로는 bugzilla라는 것이 있다. 이것을 쓸 상황이 올까..?
Maintenance phase
Input: Tested program/software
Output: Released software and maintenance updates
- 경우에 따라 제품 배포가 단계적으로 수행된다.
- 제품이 먼저 제한된 그룹에 릴리스될 수 있다.(알파 테스트, 베타 테스트)
- 피드백을 받고 최종 버전을 시장에 내놓게 된다.
- 배포 후에도 계속해서 버그를 고치거나 새로운 기능을 추가해야 한다.