[소프트웨어공학] Chapter 02 - Software Process Models

1. The Software Process

- 소프트웨어 프로세스는 소프트웨어 시스템을 개발하는데 필요한 구조화된 활동.

== 즉, 소프트웨어를 개발하려면 무엇을 해야하는가?

  - 명세 Specification: 시스템이 해야할 일을 명확하게 정의

  - 설계 및 개발 Design and implementation: 시스템의 구성 조직을 정의하고 구현

  - 검증 Validation: 고객이 원하는대로 잘 만들어졌는지

  - 발전 Evolution: 고객의 요구사항 변화에 맞춰 소프트웨어를 수정

=> 소프트웨어 프로세스 모델은 원하는 기능을 만들어내기 위한 일련의 흐름이다.

=> 소프트웨어 프로세스 모델은 추상적이다. 왜? -> 시간의 한계, 계획서의 복잡도 증가로 인해 모든 것을 표현할 수는 없음

 

2. Software process description

개발 과정, 프로세스를 설명할 때 일반적으로 과정에서의 활동(데이터 모델 구체화, UI 설계)과 활동의 순서에 관해 이야기한다. 즉, 개발 순서에 따라서 개발 계획서를 작성한다.

+ 개발 과정 설명에는 아래의 내용도 들어갈 수 있다.

- 활동의 결과물

- 해당 프로세스에 참여하는 사람들과 역할

- 개발 구현 전/후로 만족해야 할 조건: 이해관계자 선정(구현 전), 요구사항 명세서 기술(후)

 

3. Plan-driven and agile processes

• Plan-driven processes

- 프로세스 진행에 필요한 모든 활동들을 계획한다.

- 현재 진행 상황과 계획을 대비하면서 진행 정도를 측정한다.

- 프로세스 변경이 불가능하다.

• In agile processes

- 점진적으로 계획을 추가한다.

- 진행정도 측정이 어렵다.

- 고객의 요구사항 변화에 따라 프로세스를 쉽게 변경할 수 있다.

- 빠르다.

 

=> 실무에서는 위 두 가지를 혼합하여 사용한다.

=> 소프트웨어 프로세스에는 옳고 그름이 없다. --> 프로세스를 개선하여 사용하는 것이 중요하다!

 

4. Generic Proceess Model

- 소프트웨어 모델은 Software process, Process framework, Umbrella activities로 구성됨

 

5. Process Flow

• Lineear process flow

각각의 싱글 프로세스(Communication, Planning, Modeling, Construction, Deployment)가 단일 프로세스로!! 순차적으로 진행됨

 

• Iterative process flow

각각의 프로세스가 단일 프로세스로 이어지지만 프로세스가 반복될 수 있다.

Planning은 다시 Communication으로

Modeling은 다시 Modeling으로

Construction은 다시 Communication으로 반복된다.

 

• Evolutionary process flow

마지막 프로세스를 실행하고 다시 첫 번째 프로세스로 돌아가는 단일 프로세스 -> 원형 방식

• Parallel(병렬) process flow

동시에 하나 이상의 프레임워크 활동을 실행한다.

 

6. Identifying a Task Set

- a Task Set: 소프트웨어 엔지니어링 작업의 목표를 달성하기 위해 실제로 해야하는 일, 작업 -> 추상적X

- 작업 목록을 작성하고

- 작업하면서 생기는 products list를 작성하고

- QA필터 목록을 작성한다.

 

7. Process Assessment and Improvement

- 소프트웨어 프로세스가 있다고해서 소프트웨어가 제시간에 완성되고 고객의 requirement를 충족하리란 보장은 없다.

- 모든 소프트웨어 프로세스가 갖고 있는 기준에 맞춰 기능이 구현되었는지 평가받는다. -> 잘 구현되었다면 성공적이 소프트웨어 엔지니어링을 했다고 볼 수 있다!

 

8. Prescriptive Process Models

- 단계별로 쪼개어 진행하는 소프트웨어 엔지니어링 모델

+ 2가지 메인 질문

  - 프로세스 모델이 구조, 질서를 중요시한다면 프로젝트가 변화에 유연할까?

  - 기존의 프로세스 모델을 덜 구조화된 것으로 대체한다면 일관성 유지가 가능한가?

 

9. Waterfall Process Model 폭포수 모델

- 요구사항 분석이 끝나기 전까지 설계가 시작되지 않는 순차적인 모델

- 이후 전체 규모의 개발을 수행하기 전에 프로토타입 활동을 추가함.

(프로토타입: 미리, 시험삼아 확인해보는 거, 시제품과 같은 개념)

- 단계 내 결함을 발견할 수 있도록 산출물의 확인과 검증 활동을 강조

- 구조적 프로그래밍

수학적 증명이나 계산으로 구현하면서 프로그램의 정확성을 높이는 정형 기법

정형 기법을 사용한 기술 + 관리 기법 = 하향식 구조적 프로그래밍 (Top-down)

- 여러 사이트에서 시스템을 개발하는 대규모 소프트웨어 시스템 프로젝트에 주로 사용된다.

 

장점

• 프로세스를 쉽게 이해할 수 있다. 계획이 간편하다.
• 복잡하지 않은 작은 프로젝트에 유용하다.
• 분석과 테스트가 간단하다.

단점

• 변화에 적합하지 않다.
• 프로세스에서 테스트 단계를 너무 늦게 진행한다.
• Customer의 평가가 마지막에 이루어진다.

The main drawback of the Waterfall Model

Waterfall Model은 한 단계를 완료해야 다음 단계로 넘어갈 수 있다. 또한 단계를 거슬러 작업할 수 없다. 즉, 이전 phase로 회귀하기 어렵기 때문에 변화에 유연하게 대처하기 어렵다.

=> 요구사항이 명확하고, 설계 도중 변경이 일어나지 않을 때 사용하는 게 적절하다.

 

- Waterfall Model의 계획중심적(plan-driven) 특성이 일을 조정할 때 도움이 된다.

-> 주로 대규모 시스템 엔지니어링 프로젝트에 사용된다.

 

* 정형성 Formality

- 수학을 근거로 수학적인 표현과 이의 증명이 가능한 것

- 소프트웨어 개발 도구 중 프로그래밍 언어가 정형화를 근거로 한 것임

- 분석 및 설계에서도 부분적인 정형화 기법을 사용

 

문제점

- 실제 프로젝트는 순차적으로 진행되는 경우가 드물다.

- Customer가 요구 사항을 명확히 말하기 어려운 경우가 많다.

- Customer는 프로젝트 기간의 후반부까지 프로그램을 사용할 수 없다.

 

10. Prototyping Process Model

- Customer가 중요시 여기는 기능을 우선으로 간단한 시제품을 만들고, Customer의 의견을 듣고 개선, 보완하는 모델

 

장점

• 요구사항 변화에 별로 영향을 받지 않는다.
• Customer의 평가가 비교적 빨리 일어나고 자주 개입한다.
• 규모가 작은 프로젝트에 적합하다.
• 프로젝트가 중단될 확률이 적다. (Waterfall에 비해 요구사항 반영이 쉬우니까)

단점

• Customer의 개입으로 일이 딜레이될 수 있다.
• Prototyping 과정을 계획, 관리하 어렵다.

 

11. Spiral Process Model

- 개발 시 위험을 최소화하기 위하여 점진적으로 완벽한 시스템을 개발하는 모델이다.

장점

• Customer가 지속적으로 관여하고 피드백한다. -> risk 감소
• 개발 리스크가 관리된다? 이게 뭔 말임 앞에 있는 애들은 위험관리 못함?
• 위험 관리에 용이하다. 위험 부담이 큰 대형 시스템에 적합하다.
• 크고 복잡한 프로젝트에 적합하다.
• 확장 가능한 제품에 적합하다.

단점

• 리스크 분석을 실패하면 프로젝트가 망할 수 있다.
• 프로젝트 관리가 어려울 수 있다.
• 전문가가 필요하다. ->왜???지???????????

 

12. Unified Process Model

- 반복적이고 점진적인 개발

- 작업들을 병렬로 진행한다.

 

장점

• 보조 단계들 덕분에 문서화 작업의 퀄리티가 높아진다.
• 지속적으로 Customer가 참여한다. (이것도 보조 단계 때문)
• 변경되는 요구사항을 반영할 수 있다.
• 유지 관리 프로젝트에 적합하다.

단점

• Use case가 항상 정확한 건 아니다.
• Tricky software increment integration. ?나만 이해가 안 되나
• 단계가 중복되면 문제가 발생할 수 있다. 이게 뭔 말이야????//
• 전문가가 필요하다. 왜???/지?????????????????

 

13. What is Agility?

- 변화에 효과적으로(신속하고 적절하게) 대응

- 모든 이해관계자들 간의 효과적인 커뮤니케이션

- Customer도 팀으로 끌어들임

- team은 작업을 수행할 수 있는 팀으로 구성

- 빠르게 소프트웨어를 만들어서 Customer에게 전달함

 

14. Rapid software development

- 빠른 개발과 제공은 소프트웨어 시스템에서 가장 중요한 요구사항이다.

- 요구사항은 빠르게 변화하기 때문에 안정적인 소프트웨어 요구사항 집합을 만드는 것은 사실상 불가능하다.

- 계획중심적인 개발은 몇몇 시스템에는 필수적이지만 비즈니스 요구사항을 충족하지 못한다.

- 1990년대 후반에 등장한 Agile 개발 방법은 작동 중인 소프트웨어 시스템의 delivery time을 획기적으로 단축하고자 한다.

 

15. Agile development

- 프로그램 사양, 설계, 구현은 서로 관계되어 있다.

- 시스템은 일련의 버전 관리를 통해 개발된다.

- 평가를 위해 새로운 버전을 자주 출시(delivery)한다.

- 개발을 support 하는 다양한 도구가 있다. (e.g. 테스트 자동화 기술)

- 최소한의 문서화로 작업 코드에 집중한다.

 

16. Plan-driven and Agile development

계획중심 개발 plan-driven development

- 별도의 개발 단계를 기반으로 개발이 진행된다.

- 각 개발 단계에서 생산할 결과물이 계획되어 있다.

- 반드시 Waterfall Model이 아니어도 계획 중심의 점진적(incremental)인 개발이 가능하다.

=> 계획, 프로세스, 문서 등 결과물에 중점을 둔다.

Agile 개발

- specification, 설계, 구현, 테스트 과정이 모두 얽혀 있다.

- 소프트웨어 개발 프로세스 중 협상 과정을 통해 개발의 결과물이 결정된다.

=> 고객과의 협업, 빠른 시간 안에 고객이 작동해볼 수 있는 소프트웨어, 환경과 고객의 변화에 능동적으로 대처하는 것을 강

 

17. Agile methods

- 1980, 1990년대의 소프트웨어 설계 방법과 관련된 오버헤드를 해결하기 위한 방법으로 Agile이 나옴

- 디자인 보다는 코드에 집중

- 반복적인 소프트웨어 개발 과정

- 소프트웨어를 신속하게 제공하고 변화하는 요구 사항을 충족시켜 빠르게 발전하기 위함

=> Agile의 목표는 소프트웨어 프로세스의 오버헤드를 줄이고(e.g. 과도한 문서화X) 불필요한 반복, 중복되는 반복 작업 없이 변화하는 요구사항에 빠르게 대응할 수 있도록 하는 것

 

18. What is an Agile Process?

- Customer의 요구사항이 영향을 미침. (시나리오)

- Customer의 피드백이 자주, 즉각적으로 작용함

- plan은 자주 변하기 때문에 수명이 짧음

- construction activities에 의존하여 반복적으로 소프트웨어를 버전 업

-  실행 가능한 프로토타입 제공

- 프로젝트, 기술이 변경되면 조정함 -> 변화에 잘 적응한다.

 

19. Agile manifesto

- 프로세스, 도구보다 개인, 상호작용을

- 포괄적인 문서보다 작동하는 소프트웨어를

- 계약 협상보다 Customer과의 협업을

- 계획을 따르기보다 변화에 대응하기를

=> 왼쪽의 항목도 가치가 있지만 우리는 오른쪽에 더 높은 가치를 둔다.

 

20. Agile method applicability

- rnlcskgdkrnlcksgdkrnlcksgdk

 

21. Scrum Framework, Scrum Details

• Backlog Refinement Meeting 백로그 개선 회의

백로그: 완료되지 않은 작업 항목들의 리스트나 목록

개발자와 이해관계자가 협력하여 제품의 백로그를 만든다. 

• Sprint Planning Meeting 스프린트 계획 회의

스프린트: 짧은 시간 안에 빠르게 개발하는 것

백로그를 스프린트로 분할한다.

• Daily Scrum Meeting 일일 스크럼 회의

팀원들이 각자의 활동을 말하고 하루 일정을 계획한다. (최대 15)

• Sprint Review 스프린트 검토

프로토타입(데모)를 stakeholders에게 전달하여 승인/거부를 요청한다.

• Sprint Retrospective 스프린트 회고

스프린트를 완료하고 잘된 점, 개선이 필요한 점을 정리한다.

 

장점

• 제품 소유자가 우선순위를 설정하고 팀이 의사결정권을 소유한다. -> 프로젝트 관리자가 따로 없어서 책임감 증가
• 잦은 업데이트

단점

• 변경으로 인한 cost를 제어하기 어렵다.
• 대규모 팀에는 적합하지 않을 수 있다.
• 전문 팀원이 필요하다. 왜?!?!?!?!?!?!?!!?!??!???

 

22. XP(Extreme Programming) Framework, Details

- 애자일 방법론의 대표 주자

장점

• Customer의 참여를 강조
• 합리적인 계획, 일정을 수립
• 프로젝트를 할 때 개발자가 갈리는 편 (헌신도가 높다)
• 개발이 중단될 가능성이 적다.

단점

• cost 증가에 대한 잦은 회의가 필요
• 무리한 변경을 허용
• 전문가 팀원에게 의존하게 됨

23. Kanban Framework, Details

- 칸반 보드를 활용하여 워크플로우 시각화

- 특정 작업 단계(시간)에 진행 중인 작업의 양을 조절, 제한할 수 있음

- 현재 작업의 흐름을 이해하고 낭비를 줄일 수 있도록 워크플로우를 관리할 수 있다.

- 각 단계의 기준을 명시하고 작업이 완료되는 기준을 명확히 한다.

- 변경 사항이 도입되는 피드백 루프를 만들어서 지속적인 개선이 가능케 함

- 프로세스를 공동으로 관리하고 변경한다. 모든 stakeholder를 참여시킬 수 있다.

 

장점

• 예산 축소, 개발 시간 단축
• 빠른 delivery
• 프로세스 정책 기록 가능
• 지속적인 프로세스 개선

단점

• 팀 협업이 성공을 결정함
• 잘못된 비즈니스 분석으로 프로젝트가 망할 수 있음
• 유연한 대처가 불가능하면 개발자가 집중하지 못할 수 있음
• Developer reluctance to use measurement 이해가 안 됨 왜????꺼림?왜?????????

24. DevOps

- 지속적인 개발: 소프트웨어를 여러 스프린트로 나눔

- 지속적인 테스트: 자동화된 테스트 도구

- 지속적인 통합: 존재하던 실행코드에 새로운 기능 추가

- 지속적인 배포: 통합된 코드를 프로덕션 환경에 배포

- 지속적인 모니터링: 팀 운영 담당자가 프로덕션 환경의 소프트웨어 성능을 사전에 모니터링

장점

• 코드 배포 시간 단축
• 팀에 개발자와 운영 직원이 따로 존재
• 팀에 End-to-End(E2E) 프로젝트 소유권 있음
• 배포된 제품을 사전 모니터링 할 수 있음

단점

• 기존 코드와 새 코드를 모두 작업해야함
• 자동화 도구에 대한 높은 의존도
• 배포가 프로덕션 환경에 영향을 미칠 수 있음
• 전문 개발팀이 필요함

25. 12 Agile Principles

• Principle 1. 
• s아 너무 많다 나중에 정리하자

 

레퍼런스

https://krapoi.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B3%B5%ED%95%99-%EC%95%A0%EC%9E%90%EC%9D%BC-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%AA%A8%EB%8D%B8scrum

소프트웨어 공학 - 애자일 프로세스 모델(scrum)