훈수/저작권 관련 지적 환영합니다 - 댓글 또는 audgnssweet@naver.com
Process
| Process in software engineering |
| In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management. - wikipedia - |
소프트웨어 공학에서 Process란,
소프트웨어 개발을 각 단계로 나누어, 디자인, 제품 관리, 프로젝트 관리를 용이하게 해 주는 것입니다.
즉 소프트웨어 개발의 방법론이라는 것이죠.
소프트웨어 개발은 그 역사가 꽤 되었기 때문에 대표적인 Processing model들이 이미 존재하고 있습니다.
우리는 이런 Processing model에 대해 이해하고, 프로젝트에 적용한다면
질 높은 소프트웨어를 제작할 수 있겠죠?
Engineering 구성요소
이런 Process model에 대해 알기 전에 먼저 Software Engineering은 어떤 phase 들로 구성되는지에 대해 알아야 합니다.
대표적으로 요구사항 분석, 디자인, 개발, 테스트, 배포, 유지보수의 phases가 존재합니다.
대표적인 Process models
| Representative process models |
| Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, ... - wikipedia - |
Process model들은 여러 가지가 있지만
우리는 가장 대표적인 agile과 waterfall, 그리고 둘의 비교를 해보겠습니다.
Waterfall model
폭포 모델? 네 그렇습니다. 물이 떨어지는 것처럼 한 방향으로만 개발이 진행되는 것을 의미합니다. (단계적 접근)
그림을 통하면 더 쉽게 이해할 수 있습니다.
위 그림을 보시면 화살표가 한쪽 방향으로만 이어져 있는 것을 보실 수 있습니다.
요구사항 분석 -> 디자인 -> 개발 -> 테스팅 -> 배포 -> 유지보수 순서대로 개발이 이루어지는 것입니다.
개발 방법론을 접해보지 않은 분들이라면, 당연히 이렇게 하는 거 아니야?라고 생각하실 수 있습니다.
그러나 이 방법론대로 개발을 진행하려면 제약조건이 있습니다.
- 클라이언트의 요구사항이 매우 명확하고, 자세하며, 변하지 않아야 한다.
개발 중간에 다시 돌아가서 요구사항 분석, 디자인을 할 수 없기 때문에
요구사항이 명확하고 변하지 않아야 하는 것이죠.
물론 클라이언트들은 이런 요구사항, 도메인 등을 구체적으로 생각하고 있는 경우가 대부분입니다.
그러나 모든 자세한 사항까지 처음부터 문서화하는 경우는 없을 것입니다.
또한 개발 중간에 요구사항이 바뀌는 일들은 매우 흔한 일이기 때문에
waterfall 모델대로 개발을 진행한다면 대처하기가 힘든 것입니다.
또한 클라이언트들은 개발이 모두 끝난 후에야 결과물을 받아보고, 피드백을 할 수 있게 됩니다.
피드백 사항이 많을수록 한꺼번에 모두 바꾸기가 매우 어렵겠죠?
이런 단점들 때문에 waterfall 방법론은 잘 사용되지 않습니다.
프로젝트의 규모가 매우 작고 요구사항의 complexity가 매우 낮다면 사용을 고려해볼 수 있을 것 같습니다.
Agile model
Agile model은 Spiral model의 한 종류입니다.
Spiral model은 요구사항을 여러 단위로 나누어, 요구사항별로 개발의 lifecycle을 돌려
빠른 피드백과 점진적 개발을 할 수 있게 해주는 것입니다.
그럼 Agile model에 대해서 알아보겠습니다.
| 에자일 소프트웨어 개발 |
| 애자일 소프트웨어 개발은 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다. - 위키백과 - |
Agile model 중 유명한 scrum에 대한 그림입니다.
위 그림을 보겠습니다.
1. Product backlog
모든 요구사항을 정리한 것. 중요도에 따라서 우선순위를 갖게 된다.
2. Sprint
한 개발 주기
3. Sprint backlog
한 개발 주기에 어떤 요구사항들을 충족할지, 그 요구사항들은 각각 어떻게 작은 task단위로 나뉠지 정의
4. Daily Scrum
한 Sprint 내에서 매일 진행된 task들을 점검하고, 오늘 충족해야 할 task를 점검하는 것.
5. Sprint review
이번 Sprint에서 충족된 요구 사항들에 대한 점검 (Product적 측면) - 클라이언트와 함께함(즉각 피드백 가능)
6. Sprint retrospective
이번 Sprint 자체가 어땠는지 점검 (Process적 측면)
이런 단계를 거치는 Sprint가 개발 완료시까지 계속 반복되는 것입니다.
반복될 때마다 product backlog는 줄어들고, 전부 없어지면 프로젝트가 끝나는 것입니다.
이런 Agile 방법론은 waterfall 방법론 등과 비교했을 때
- 변화 대처에 유연
- 이해 관계자들간 소통에 유리
- 한 Sprint마다 클라이언트의 피드백을 받을 수 있음
- 중요도가 높은 것부터 점진적으로 점검하며 개발
- 비용 감소
와 같은 장점이 있습니다.
'소프트웨어 공학' 카테고리의 다른 글
| (UML) Activity Diagram & State Machine Diagram (0) | 2021.04.09 |
|---|---|
| (UML) Sequence Diagram (0) | 2021.04.09 |
| (UML) Class Diagram (0) | 2021.04.02 |
| (요구사항 분석) Data Flow Diagram & Use Case Diagram (0) | 2021.03.19 |
| 소프트웨어 공학 (0) | 2021.03.05 |
