1-5강. 요구사항 확인-요구사항 확인(2)

과목1. 소프트웨어 설계, 5강. 요구사항 확인-요구사항 확인(2)

 

[ 목차 ]

1. UML의 개념

2. UML의 특징

3. 통합 모델링 언어가 필요한 이유

4. UML의 구성요소

5. UML 다이어그램의 종류 - Use Case 

6. UML 다이어그램의 종류 - Class

7. UML 다이어그램의 종류 - Object(객체)

8. UML 다이어그램의 종류 - State

9. UML 다이어그램의 종류 - Sequence

10. UML 다이어그램의 종류 - Collaboration = Communication

11. UML 다이어그램의 종류 - Activity

12. UML 다이어그램의 종류 - Component

13. UML 다이어그램의 종류 - Deployment

14. 애자일 방법론의 개념

15. 애자일 선언문

16. 애자일 개발 프로세스

17. 에자일의 종류 - XP(eXtreame Programming)

18. 에자일의 종류 - SCRUM

19. 에자일의 종류 - Lean

20. 애자일 이전의 전통적 방법론 특징

21. 애자일 방법론 특징

 

1. UML의 개념

1) 객체 지향 소프트웨어 개발과정에서 산출물을 명세화, 시각화, 문서화 할 때 사용되는 모델링 기술과 방법론을 통합하

   여 만든 표준화된 범용 모델링 언어

2) 실시간 시스템 및 분산 시스템과 같은 시스템 분석과 설계에도 사용 가능

객체지향

1) 구조적 개발 방법의 문제점을 극복하고 인간이 사고하는 방식대로 프로그램을 개발하려는 노력으로부터 탄생

2) 현실세계 존재하는 실체, 개념들을 개체라는 독립된 단위로 구성하고 객체들이 메시지를 통해 상호작용함으로
     써 전체 시스템이 운영되는 개념

2. UML의 특징

1) 가시성 : 반복적/점진적으로 구체화하여 소프트웨어의 가시성을 제공한다.

2) 문서화 : 개발규모, 개발 프로세스 및 언어와 무관하게 개발자간 의사소통 도구를 제공

3) 명세화 : 단순 표기법이 아닌 구현에 필요한 개발적 요소 및 기능에 대한 명세를 제공

 

3. 통합 모델링 언어가 필요한 이유

1) 이해 관계자끼리 의사소통을 원활하게 하여 생산성을 늘리기 위함

2) 객체 지향 소프트웨어 개발 시 UML로 작성한 다이어그램으로 의사소통

 

4. UML의 구성요소

1) View : 개발 과정에 따라 서로 다른 다이어그램(모형)을 제공

2) Diagram : 기호, 선, 점 등을 사용해 각종 사상의 상호관계, 과정, 구조 등을 이해시키는 설명적 그림으로, View의 내용

                   을 타나내기 위한 9가지 다이어그램 제공

3) 모델요소 : 객체지향 개념을 표현하기 위해 사용되는 요소로 클래스, 속성, 오퍼레이션으로 구성

4) General Mechanism : 모델 요소에 대하여 주석 정보(설명)와 의미 제공

 

5. UML 다이어그램의 종류 - Use Case 

1) 사용자의 입장에서 본 시스템의 행동을 표현

2) Use Case들은 시스템의 기능적인 요구를 정의

3) 타원으로 표시하고 안쪽에 Use Case 명 기술

4) Use Case : 시스템이 제공해야 하는 서비스

5) 사람 모양 : 행위자, 시스템과 상호작용하는 사람/사물

6) 선 모양 : 연관, Use Case와 행위자의 관계를 표현

7) 시스템 : 전체 시스템의 영역을 표시

 

6. UML 다이어그램의 종류 - Class

1) 시스템 내 클래스들의 정적 구조를 표현

2) 클래스는 객체들의 집합으로 속성과 동작으로 구성

 

7. UML 다이어그램의 종류 - Object(객체)

1) 클래스의 여러 object 인스턴스를 나타내는 대신 실제 클래스를 사용

2) 관계 있는 모든 인스턴스를 표현

3) 객체 사이의 정적인 관계를 파악하기 위해 작성하며 클래스 다이어그램을 구체화시킨 것 

 

8. UML 다이어그램의 종류 - State

1) 클래스의 객체가 가질 수 있는 모든 가능한 상태와 상태간의 전이를 표현

2) 진입 조건, 탈출 조건, 상태전이에 필요한 사건 등 자세한 사항이 기술

3) 설계 단계에서 클래스 객체의 동적인 행동 방식을 표현하는 데 사용 

 

9. UML 다이어그램의 종류 - Sequence

1) 객체와 객체간의 상호작용을 메시지 흐름으로 표시

2) 오브젝트 사이에 메시지를 보내는 시간 or 순서를 보여주기 위해 사용 

 

10. UML 다이어그램의 종류 - Collaboration = Communication

1) 오브젝트간의 연관성을 표현하며, 내용이 중요한 경우 이용

2) Sequence 다이어그램(순서 강조)과 같은 내용을 나타내지만 모양이 네트워크 형태(관계 표현, 연관성 표현 강조)

3) 객체에 밑줄을 긋는 등 표기법이 다름

4) Collaboration 다이어그램에서 숫자를 보고 순서대로 그리면 Sequence 다이어그램이 됨

 

11. UML 다이어그램의 종류 - Activity

1) 행위의 순서적 흐름을 표시(시스템 내부의 활동 흐름 표현)

2) 순서도나 병렬적인 처리를 요하는 행위를 표현할 때 사용

 

12. UML 다이어그램의 종류 - Component

1) 독립적인 실행단위(소프트웨어 부품)

2) 코드 컴포넌트에 바탕을 둔 코드의 물리적 구조를 표현

3) 컴포넌트는 논리적 클래스 또는 클래스 자신의 구현에 대한 정보를 포함하고 실질적인 프로그래밍 작업에 사용

 

13. UML 다이어그램의 종류 - Deployment

1) 시스템 하드웨어와 소프트웨어 간의 물리적 구조를 표현하며, 실질적인 컴퓨터와 device간의 관계를 표현하는데 이용

2) 컴포넌트 사이의 종속성을 표현

 

14. 애자일 방법론의 개념

1) 전체 개발 단계에서 변화에 대한 신속한 대응으로 요구사항을 지속적으로 분석, 반영하여 배포 시간차를 최소화하는

    개발방법론

2) 소프트웨어 개발 방법에 있어 무계획 개발 방법과 다계획 개발 방법들 사이에서 타협점을 찾고하 하는 방법론

3) 계획이 없을 경우 미래 예측이 힘들고 효율적이지 못함

4) 계획에 의존할 경우 형식절 절차를 따르는데 드는 비용과 시간이 많이들며 전체적인 개발 흐름이 느려짐

5) 계획을 통해 주도해 나갔던 과거와 달리 앞을 예측하여 개발하지 않고 일정 주기를 가지고 계속 프로토타입을 만들어

    그때 그때 필요한 요구를 더하고 수정해여 하나의 커다란 소프트웨어를 개발해 나가는 방식

 

15. 애자일 선언문

1) 소프트웨어를 개발하고 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있으며 이를 통해 다음을 가치있게 여기게 되었다.

2) 공정과 도구보다 개인과 상호작용을

  1] 프로세스와 도구보다 개개인의 상호 소통이 더 중요

  2] 개발자들은 서로 간의 정보를 공유하기 위해 얼굴을 보고 대화

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

  1] 제대로 동작하는 소프트웨어가 더 중요

  2] 문서를 작성할 시간에 완성도 높은 소프트웨어를 개발하고 고객에게 짧은 기간에 주기적으로 제공

4) 계약 협상보다 고객과의 협력을

  1] 개발자들은 관련된 영역의 사람들과 함께 일해야 함

5) 계획을 따르기보다 변화에 대응하기를 가치있게 여긴다

  1] 게빌 후반부라 하더라도 고객의 요구사항을 적극적으로 검토 및 반영

 

16. 애자일 개발 프로세스

1) 어느 특정 개발 방법론을 가리키는 말은 아니며 애자일 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말

2) 과거에 경량 프로세스로 불림

3) 익스트림 프로그래밍이 애자일 개발 프로세스의 대표적인 방법

 

17. 에자일의 종류 - XP(eXtreame Programming)

1) 의사소통 개선과 즉각적인 피드백에 의한 단순한 코딩으로 s/w품질을 높이기 위한 방법론

2) 고객과 함께 1-3주 정도 반복 개발

3) 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존경(용단의 피존)

4) 12개 실천항목

XP

1) 고객 만족을 강조하며 고객의 요구 변화에 부응하는 소프트웨어 개발 방법
2) 팀워크, 관리자, 고객에 초점을 맞춰 각 개발자들이 전체적인 맥락에서 질적인 소프트웨어 개발에 전념
3) 고객, 동료와의 의사소통
4) 프로그램을 단순, 투명
5) 시험을 통해 피드백을 수행
6) 가능한 빨리 고객에게 시스템을 전달
7) 많은 퍼즐 조각처럼 개별적으로는 별 의미가 없지만 하나로 합쳐지면 완전한 그림을 볼 수 있다는 데서 시작
8) 요구 사항이 많거나 잦은 변화가 예상되는 프로젝트의 경우 소규모 개발팀으로 공간 공유의 높은 효과

18. 에자일의 종류 - SCRUM

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

2) 30일마다 동작 가능한 제품을 제공하는 스프린트를 중심

3) 백로그 : 제품과 프로젝트에 대한 요구사항

4) 스프린트 : 40일 단위의 짧은 개발기간으로 분리하여 반복수행 하는 것으로 과제가 진행되는 주기를 지칭

5) 스크럼미팅 : 매일 스크럼 미팅으로 오늘과 내일 할 일의 계획수립

6) 스크럼마스터 : 프로젝트 리더로서 스크럼 수행 시 문제 인지 및 이를 해결하는 사람

 

19. 에자일의 종류 - Lean

1) 린시스템의 품질 기법을 소프트웨어 개발 프로세스에 적용하여 프로세스의 낭비요소를 제거 후 결과를 측정, 성과를

    분석하여 소프트웨어의 품질을 향상시키는 개발방법론

2) 7가지 원칙 : 낭비제거, 품질내재화, 지식창출, 늦은확정, 빠른인도, 사람존중, 전체최적화 (낭품지늦빠사전)

3) 도요타의 생산방식(낭비를 발견하여 제거하고 고객에게 빠른 가치 제공)을 소프트웨어 개발에 적용한 방법론

4) 구체적인 개발 프로세스를 정의하지 않고 철학적인 접근 방식을 정의

5) 낭비는 곧 결함이기 때문에 경함을 줄이는 것이 좋은 방법이라는 사고방식

낭비제거 : 80%의 가치를 제공하는 20%기능 구현에 모든 초점을 맞추어 집중하고 낭비되는 요소 제거

품질내재화 : 개발 중 검증단계에 이르러서야 결함을 발견한다면 그 프로세스는 결함이 존재

지식 창출 : 과학적 방법 사용하여 모든 사람들이 따라 하고 잘 알려진 실천법을 표준에 포함하되 누구든지 표준
                 에 도전하고 변경하도록 장려

늦은확정 : 마지막까지 변화를 수용할 수 있도록 코드 작성

빠른인도 : 신속판 배포, 고품질, 저비용은 동시에 가능

사람존중 : 효과적인 리더십 제공과 팀은 자부심, 책임관, 신뢰, 칭찬으로 번성

전체최적화 : 고객요구에서 sw배포까지 전체 가치흐름에 초점

20. 애자일 이전의 전통적 방법론 특징

1) 폭포수 기법 : 요구분석 - 설계 - 개발 - 테스트 - 출시

2) 대규모 기능 팀

3) 순차적 진행

4) 예측에 기반한 계획

5) 사전에 정의된 과제 고수(변경 불가)

6) 초기 요구사항에 대한 베이스라인을 설정

7) 상세한 계획 수립

8) 계획 기반 프로세스

9) 다음 단계에 이르기까지 상세한 계획 수립

10) 초기 요구사항 수집 및 엄격한 변경관리

11) 요구사항 정의 단계에서 모든 요구사항을 정하는 것을 강조

12) 모델과 사양을 모다 상세화하는 과정을 통해 어플리케이션과 데이터 아키텍처를 초기에 정의하고자

13) 특정 기능이 구현된 이후 단위-통합-시스템 테스트로 확장해 나가는 방식

14) 개발 착수 전에 표준화된 프로세스 제정이 중요(고정)

15) bigbang 릴리즈

16) 계획중심

아키텍처 : 결과물이 가져야 할 속성들기 시스템에 문제없이 포함되기 위한 계획이자 설명서

아키텍처 설계 : 요구사항을 만족시키는 구조를 만들어내는 과정으로, 모듈간의 관계와 프로그램 구조 정의

단위테스트 : 시스템 구성 기본 단위를 테스트하는 것으로, 결함 발견을 위해 개별적 모듈을 독립적으로 확인
                   개발자나 개발 부서에서 각 모듈에 논리적인 로직이나 인터페이스의 기능을 테스트

통합테스트 : 개발된 모듈들을 통합해 가면서 테스트 하는 것으로, 하향식, 상향식, 혼합식이 존재
                   프로그램 단위별로 디버깅이 끝난 것을 모아 연관된 프로그램군을 계통적으로 감시하는 테스트

시스템 테스트 : 요구사항 만족 여부 테스트

bigbang 릴리즈 : 일괄배포로, 프로젝트가 종료되는 시점에 한꺼번에 모든 기능 릴리즈

21. 애자일 방법론 특징

1) 설계 - 개발 - 테스트 - 출시 - 요구분석의 반복

2) 소규모 다기능 팀

3) 순환적 진행

4) 과제의 모둠화와 우선순위화

5) 유연하고 지속적인 변화

6) 프로젝트 전 과정에 걸쳐 진화하는 요구사항

7) 잦은 계획 수립 및 갱신

8) 경험 기반 프로세스

9) 바로 다음 반복주기에 대해서만 상세한 계획을 수립하며, 구현 위주

10) 지속적인 요구사항 개발 및 변경 수용

11) 요구사항에 대한 베이스라인 설정 강조x

12) 실제 기능 구현을 통해 빠른 시간 내에 아키텍처의 실현 가능성을 증명하고자

13) 빈번한 개발-테스트 주기를 통해 많은 시간과 비용이 투입되기 전 기능을 검증

14) 잦은 inspection을 토대로 프로세스를 유연하게 개발에 적용

15) 빠른 릴리즈

16) 학습중심

Inspection : 표준이나 명세서에 대한 편차와 에러를 포함한 결함을 발견하고 식별하기 위해 작업 산출물에 대한
                    수행 검사