chapter 01. 소프트웨어 개발 방법론 (1)

애자일(Agile)

 

① 애자일(Agile) 방법론의 개념 [2020년 2회]

• 애자일 방법론은 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
• 개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아서 유동적으로 개발할 수 있음

② 애자일 방법론 등장 배경

애자일 방법론은 기존 개발 방법론의 한계를 극복하기 위해 등장했다.

등장 배경	설명
소프트웨어 개발 환경의 변화	- 소프트웨어 개발 트렌드가 모바일 환경으로 변화 - 시장 적시성과 잦은 배포의 중요성 부각
기존 개발 방법론의 한계	- 전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어려움 - 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성 증가

③ 애자일 방법론의 유형 [2020년 3회]

애자일 방법론은 대표적으로 XP, 린(Lean), 스크럼(SCRUM) 등이 있다.

 

---

XP(eXtreme Programming)

• 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
• 1~3주의 반복(Iteration) 개발주기
• 5가지 가치와 12개의 실천항목이 존재

가치	설명
용기 (Courage)	용기를 가지고 자신감 있게 개발(코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드를 리팩토링할 수 있는 용기)
단순성 (Simplicity)	필요한 것만 하고 그 이상의 것들은 하지 않음
의사소통 (Communication)	개발자, 관리자, 고객 간의 원활한 소통
피드백 (Feedback)	의사소통에 대한 빠른 피드백
존중 (Respect)	팀원 간의 상호 존중

기본원리	설명
짝 프로그래밍 (Pair Programming)	개발자 둘이서 짝으로 코딩하는 원리
공동 코드 소유 (Collective Ownership)	시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리
지속적인 통합 (CI; Continuous Intergration)	매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
계획 세우기 (Planning Process)	고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리
작은 릴리즈 (Small Release)	작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리
메타포어 (Metaphor)	공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리
간단한 디자인 (Simple Design)	현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
테스트 기반 개발 (TDD; Test Driven Develop)	작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
리팩토링 (Refactoring)	프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리
40시간 작업 (40-Hour Work)	개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리
고객 상주 (On Site Customer)	개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
코드 표준 (Coding Standard)	효과적인 공동 작접을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리

---

스크럼(SCRUM)

• 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

주요 개념	설명
백로그 (Backlog)	제품과 프로젝트에 대한 요구사항
스프린트 (Sprint)	2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상
스크럼 미팅 (Scrum Meeting)	- 매일 15분 정도 미팅으로 To-Do List 계획수립 - 데일리 미팅(Daily Meeting)이라고도 함
스크럼 마스터 (Scrum Master)	프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
스프린트 회고 (Sprint Retrospective)	- 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록 - 해당 스프린트가 끝난 시점이나 일정 주기로 시행
번 다운 차트 (Burn Down Chart)	- 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트 - 백로그는 보통 수직축에 위치하며 시간은 수평축에 위치

---

린(Lean)

• 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세서에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
• JIT(Just In Time), 칸반(Kanban) 보드 사용

7가지 원칙

낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

---

④ 애자일과 전통적 방법론 비교

비교 대상	애자일 방법론	전통적 방법론
계획수립	유동적 범위 설정	확정적 범위 설정
업무수행	팀 중심 업무 수행	관리자 주도적 명령과 통제 개인 단위로 업무수행
개발/검증	반복 주기 단위로 소프트웨어를 개발 / 검증	분석 / 설계 / 구현 / 테스트를 순차적으로 수행
팀관리	업무 몰입, 팀 평가	경쟁, 개별 평가
문서화	문서화보다는 코드를 강조	상세한 문서화를 강조
성공요소	고객 가치 전달	계획 / 일정 준수
유형	XP, 스크럼, 린	폭포수, 프로토타입, 나선형

 

---

 

객체 지향 분석 방법론

 

① 객체 지향 분석의 개념

객체 지향 분석은 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산. 관계를 정의하여 모델링하는 기법

 

② 객체 지향 분석 방법론의 종료 [2021년 2회]

종류	만든 이	설명
OOSE (Object Oriented Software Engineering)	야콥슨 (Jacobson)	- 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용하는 방법론 - 분석, 설계, 구현 단계로 구성 - 기능적 요구사항 중심의 시스템
OMT (Object Modeling Technology)	럼바우 (Rumbaugh)	- 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론 - 분석 절차는 객체 모델링 -> 동적 모델링 -> 기능 모델링 순서로 진행 객체 모델링(Object Modeling) - 정보 모델링이라고도 함 - 시스템에서 요구하는 객체를 찾고 객체들 간의관계를 정의하여 ER다이어그램을 만드는 과정까지의 모델링 - 객체 다이어그램을 활용하여 표현 동적 모델링(Dynamic Modeling) - 시간의 흐름에 따라 객체들 사이에 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링 - 상태 다이어그램을 활용하여 표현 기능 모델링(Functional Modeling) - 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링 - 자료흐름도(DFD)를 활용하여 표현
OOD (Object Oriented Design)	부치 (Booch)	- 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론 - 분석과 설계의 분리가 불가능 - 분석하는 데 이용된 객체 모델의 설계 시 적용

 

---

 

비용산성 모형

① 비용산정 모형 개념

비용산정 모형은 소프트웨어 규모파악을 통한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용하는 산정하는 방식

 

② 비용산정 모형 분류

비용산정 모형은 하향식 산정방법과 상향식 산정방법이 있음

분류	설명	종류
하향식 산정방법	경험이 많은 전문가에게 비용 산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식	- 전문가 판단 - 델파이 기법
상향식 산정방법	세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식	- 코드 라인 수(Loc) - Man Month - COCOMO 모형 - 푸트남 모형 - 기능점수(FP) 모형

 

③ 비용산정 모형 종류

 

Loc(Lines of Code) 모형

- Loc모형은 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식

- 측정이 쉽고 이해하기 쉬워 많이 사용

- 예측치를 이용하여 생산성, 노력, 개발 기간 등으 ㅣ비용을 산정

 

Man Month 모형 [2020년 1회]

Man Month 모형은 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식

(Man Month) = (Loc)/(프로그래머의 월간 생산성)

(프로젝트 기간)=(Man Month)/(프로젝트 인력)

 

COCOMO(COnstructive COst MOdel) 모형

- COCOMO 모형은 보헴(Boehm)이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식

- 비용산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 산정

- 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용

- 규모에 따라 유형이 조직형(= 기본형, 단순형), 반 분리형, 임베디드형으로 나뉜다.

 

푸트남(Putnam) 모형

- 푸트남 모형은 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식

- 푸트남이 제안한 것으로 생명주기 예측 모형

- 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함

 

기능점수(FP; Function Point) 모형

- 기능 점수 모형은 요구 기능을 증가시키는 인자별로 가중치를 붕하고, 요인별 가중치를 합산하여 총 기능의 점수를 계싼하여 비용을 산정하는 방식

- 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여

 

 

[참고 : 수제비 2022]