cse4006 software engineering agile development...• dsdm 컨소시엄 () 홍보 • 특징 :...

CSE4006: Software Engineering - Scott Lee

Scott Uk-Jin Lee

Division of Computer Science, College of Computing Hanyang University ERICA Campus

1st Semester 2018

Agile Development

CSE4006 Software Engineering


Background of Agile SW Development

90년대 후반까지의 소프트웨어 개발• 장기간에 걸쳐 많은 인력과 충분한 비용을 투입하여 진행

= 소프트웨어공학의 주된 대상 프로젝트

최근의 소프트웨어 개발• 짧은 개발기간, 적은 비용 투자, 매우 복잡하며 개방적 • 사회적 상황 및 시장 변동에 따라 변화가 심함 • 요구사항이 다양하고 시시각각 변함

객체지향 : 기술적 해결책• 객체지향 개발에 적합한 프로세스 필요

→ Agile 개발 프로세스

2


Agile vs. Traditional Methods

대규모 시스템 개발 프로세스의 문제점 (특징)• 오버헤드: 치밀한 계획 및 철저한 품질보증 필요 • 프로그램 개발 자체보다 다른 업무(문서화, 회의, 설계 등)에 더 많은 시간을 소비하게 됨

• 무거운 방법론

Agile 방법론• 설계와 문서화보다 소프트웨어 그 자체에 더 초점을 둠 • 사용자 요구사항의 빈번한 변경이 반영 가능한 환경 제공 • 빠른 피드백 e.g., eXtreme Programming, SCRUM, Crystal, Adaptive Software

Development, Feature Driven Development

3


Agile vs. Traditional Methods

• Agile 방법론: 일관된 디자인 부족 • 전통적 방법론: 미완료 프로젝트

4


Manifesto for Agile SW Development

애자일 소프트웨어 개발 선언 • 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.

• 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다: • 공정과 도구보다 개인과 상호작용을 • 포괄적인 문서보다 작동하는 소프트웨어를 • 계약 협상보다 고객과의 협력을 • 계획을 따르기보다 변화에 대응하기를

• 위는, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

2001년 Kent Beck외 16인

5


What is “Agility” ?• Agile = 빠르고 쉽게!

• 변화에 대한 효과적인 (신속하고 적응적인) 대응

• 모든 이해관계자 간의 효과적인 의사소통

• 팀에 고객을 포함 - 고객의 역할은 요구사항 제공, 우선 순위 부여, 평가하는데 중요

• 수행하는 작업을 제어할 수 있도록 팀 구성 - 프로세스보다 사람

Yielding …• 신속하고 점진적인 소프트웨어 배포

6


Agility & the Cost of Change

7


An Agile Process

• 고객이 기술한 요구사항(시나리오)에 기반 • 계획은 단기적(short-lived)으로 • 반복적 릴리즈: 구현에 중점을 두고 요구를 조금씩 개발하여 단계적으로 릴리즈 - 중요 부분 먼저, 반복적으로 - 다수의 '소프트웨어 점증(increments)’을 배포

• 변경을 포용 - 변경에 조화되도록 설계 - 단순함 유지: 가능하면 단순하게, 복잡한 것은 배제

8


Agility Principles

1. to satisfy the customer through early and continuous delivery of valuable software

• 고객 만족이 최우선 : 신속하고 지속적인 소프트웨어 배포

2. welcome changing requirements, even late in development • 요구사항 변경은 언제든지(개발 후반에라도) 적극 반영

3. deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

• 작동하는 소프트웨어를 자주 배포 (몇 주 ~ 몇 달 주기로)

4. business people and developers must work together daily • 모든 이해관계자와 개발자들은 프로젝트 내내 함께 협업

9


Agility Principles

5. build projects around motivated individuals • 개인 존중 : 동기부여 및 독려

6. the most efficient and effective communication is face-to-face conversation

• 대화가 가장 효과적 정보 전달 방법

7. working software is the primary measure of progress • 작동하는 소프트웨어는 일의 진척에 대한 가장 좋은 척도

8. Agile processes promote sustainable development • 지속가능 / 적절한 개발 환경 조성

10


Agility Principles9. continuous attention to technical excellence and good

design • 기술적 우월성 및 좋은 설계에 대한 지속적 관심

10.simplicity is essential • 단순성

11.the best architectures, requirements, and designs emerge from self-organizing teams

• 최적 설계, 요구사항, 디자인은 모두 자기 조직 팀으로 부터

12.at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior

• 주기적으로 어떻게 해야 더욱 효율적일지 생각하고 조율

11


eXtreme Programming (XP)

12


eXtreme Programming (XP)• 1999년 Kent Beck이 제안한 가장 널리 사용되는 Agile 프로세스

• XP 계획(Planning)- 소프트웨어에 요구되는 특징 및 기능을 설명하는 “사용자 스토리(user

story)” 생성으로 시작 - 고객은 각 스토리에 가치(value) 할당 - Agile 팀은 각 스토리를 평가하고 비용 할당 (주단위) - 스토리는 배포 가능 증분(deliverable increment)으로 그룹화 - 수행은 배포일 (납품일)까지 - 첫 increment 수행 후, ‘프로젝트 속도’는 추후 increment의 배포일을 결정하는데 도움을 줌

(프로젝트 속도: 첫 릴리즈에서 구현된 사용자 스토리 수)

13


eXtreme Programming (XP)• 사용자 스토리 (User story)

14


eXtreme Programming (XP)• 사용자 스토리 (User story)

15


eXtreme Programming (XP)• XP 설계 (Design)

- KIS 원칙 고수 - CRC (Class-Relationship-Collaboration) 카드 사용 권장 - 복잡한 설계 문제에 대해서는 ‘spike solution’ (설계 프로토타입) 작성 - 리팩토링 (내부 프로그램 설계의 반복적 개선)을 권장

• XP 코딩 (Coding)- 코딩 시작전 각 스토리에 대한 단위 테스트 생성 권장 - pair programming 권장

• XP 테스트 (Testing)- 매일 모든 단위 테스트 실행 (코드가 수정 될 때마다) - 인수 (Acceptance) 테스트는 고객이 정의하고 고객이 볼 수 있는 기능을 평가하기 위해 실행

16


eXtreme Programming (XP)• CRC (Class-Relationship-Collaboration) 카드

17


eXtreme Programming (XP)• CRC 카드

18


eXtreme Programming (XP)

19

XP Programming의 원칙

세심한 피드백

지속적 테스트 개발과 동시에 단위 테스트 병행계획 세우기 우선순위와 기술사항을 고려하여 범위 결정현장 고객 고객이 개발 사이트에 상주하며 참여Pair programming 가장 좋은 구현 방법과 전략을 고민

지속적 개발

지속적 통합 개발한 것을 즉시 또는 매일 통합, 빌드리팩토링 코드의 품질을 지속적으로 개선작은 릴리스 짧은 사이클로 작은 릴리스를 반복 개발

상호이해

단순 설계 최대한 설계를 단순하게 유지메타포 시스템 전체에 대해 은유적 접근코드 공유 누구나 코드를 수정하고 집단적 소유로 간주코딩 표준 표준에 맞추어 코딩

복지 40시간 작업 초과 근무를 줄이고 계획적으로 작업


eXtreme Programming (XP)• Pair programming

- 두 사람이 쌍을 이루어 같은 컴퓨터를 사용하면서 개발 및 테스트 - 한 사람 코딩 시 다른 사람은 어떻게 테스트 할 것인지 궁리

- 장점: - 혼자 개발 시 보다 더욱 원칙에 충실 - 더 좋은 설계 및 코드 작성 가능 (혼자할때 보다) - 작업이 활기차고 분열 을 예방 - 더 낳은 문제 해결 및 견고한 설계 - 멘토링, 강한 응집력

- 단점 : - 개발자 능력에 큰 차이가 있다면, 싫증이 나고 부담/짐이 됨 - 생산성의 정확한 확인이 어려움

20


Adaptive Software Development• 원래 Jim Highsmith가 제안 • 인간 공동 작업 및 팀 자체 구성에 중점을 둠 • 특징 :

- 임무 중심 계획 - 컴포넌트 기반 - “Time boxing” → 위험관리 :

- Time-box: 여러개의 별도 기간 (보통 2~6주) - 각 부분에는 자체 산출물, 기한, 예산이 있음

- 위험에 대한 명백한 고려 - 요구사항 수집을 위한 협력 강조 - 프로세스 전체에 걸쳐 ‘학습’을 강조

21


Adaptive Software Development

22


Dynamic Systems Development Method

• DSDM 컨소시엄 (wwwdsdm.org) 홍보 • 특징 :

- 대부분의 면에서 XP 또는 ASD와 유사 - 9가지 기본 원칙

- 적극적인 사용자 참여 필수 - DSDM 팀은 결정을 내릴 수 있도록 권한 부여 필요 - 제품을 잦은 배포에 초점을 둠 - 비즈니스 목적의 적합성은 결과물 수락에 있어 필수적 기준 - 정확한 비지니스 솔루션 수렴을 위해서는 반복 및 점진적 개발이 필요 - 개발 중 모든 변경 사항은 되돌릴 수 있음 - 요구 사항은 높은 수준에서 기준을 설정 - 테스트는 수명주기 전체에 걸쳐 통합됩니다.

23

http://wwwdsdm.org


Dynamic Systems Development Method

• DSDM 컨소시엄 (wwwdsdm.org) 홍보 • 특징 :

- 대부분의 면에서 XP 또는 ASD와 유사 - 9가지 기본 원칙

- 적극적인 사용자 참여 필수 - DSDM 팀은 결정을 내릴 수 있도록 권한 부여 필요 - 제품을 잦은 배포에 초점을 둠 - 비즈니스 목적의 적합성은 결과물 수락에 있어 필수적 기준 - 정확한 비지니스 솔루션 수렴을 위해서는 반복 및 점진적 개발이 필요 - 개발 중 모든 변경 사항은 되돌릴 수 있음 - 요구 사항은 높은 수준에서 기준을 설정 - 테스트는 수명주기 전체에 걸쳐 통합됩니다.

24

http://wwwdsdm.org


Scrum• 원래 Schwaber과 Beedle이 제안 • 소규모 작업 팀 → 소통 최대화, 오버해드 최소화, 정보 공유 최대화 • 특징 :

- 개발 작업을 ‘패킷(packet)’으로 분할 - 소프트웨어 구현 시 테스트 및 문서작성은 항상 진행 중 - 작업은 스프린트 (sprint)에서 진행 되며 기존 요구사항의 백로그

(backlog)에서 파생됨 - Backlog : 프로젝트 요구사항 또는 기능의 우선 순위 목록 - Sprint : 프로세스 패턴 내 업무 (30일 개발 주기)

- 회의는 매우 짧고 의자 없이 진행 (15분) - Time-box에 맞추어 고객에게 ‘데모’ 제공

25


Scrum

26


Feature Driven Development• 원래 Peter Coat 제안 • 특징 :

- ‘feature’ 정의가 주요 요소 - 2주 이내에 구현될 수 있는 고객 가치 함수 - 사용자가 더 쉽게 설명 가능

- ‘feature’ 템플렛 사용 - < action > the < result >< by j for j of j to > a(n) < object > e.g., add the product to a shopping cart e.g., store the shipping information for a customer

- ’’feature’ 세트 템플렛 - < action > < -ing > a(n) < object > e.g., making a product sale

- feature list 생성 & plan by feature 수행 - FDD에선 설계 및 구축이 병함됨

27


Feature Driven Development

• 설계 / 구현 중 6 마일스톤 - design walkthrough, design, design inspection,

code, code inspection, promote to build

28


Agile Modeling

• 원래 Scott Ambler가 제안 • 대형 업무 필수 시스템 구축 시 필수적인 agile 모델링 원칙 제안

- 목적을 가진 모델 - 여러 모델 사용 - 가볍게 진행 - 표현은 내용보다 중요 - 모델 및 모델을 만드는 데 사용하는 도구를 알아야함 - 로컬 적응 - 애플리케이션의 프로토타이핑

29

cse4006 software engineering agile development...• dsdm 컨소시엄 () 홍보 • 특징 :...

Documents