1과목 소프트웨어설계 - 요구사항 확인

소프트웨어 생명 주기

 

소프트웨어 생명 주기는 소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다.

 

소프트웨어 개발단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물 표현(계획 - 과정 - 결과가 전부 내포)

 

 

폭포수 모형(Waterfall Model)	프로토타입 모형(Prototype Model)	나선형 모형(Spiral Model)  - 보헴
각 단계마다 확실하게 매듭짓고 넘어갈 수 있는 선형 순차적 모형 고전적 생명 주기 모형 매뉴얼 작성 결과물 산출이 명확해야댐 두 개 이상의 과정이 병행 수행 (x)	사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형 시제품을 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발 폭포수 모형의 단점 보완	폭포수와 프로토타입에 위험분석을 추가
타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현 -> 시험 -> 유지보수		계획 및 정의  -> 위험분석 -> 공학적 개발 -> 고객 평가

 

<프로토 타입>

 

애자일 모형(Agile Model) - 애자일(: 민첩한, 기민한)

고객의 다양한 요구 사항의 변화에 유연하게 대응하기 위해 일정한 개발 주기를 반복으로 하는 것   애자일 모형은 스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는 짧은 개발주기 반복 그 결과물에 대한 고객의 평가와 요구를 적극 수용한다.   요구 사항 적합 : 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항

관련 개발 모형 : XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM, DAD

 

용어 이해 후 정독

 

백로그 : 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여

스토리 : 백로그에 담겨질 요구사항은 단어 형태로 표현된 것이 아니라 '고객'은 상품 주문을 위해 로그인을 수행해야한다와 같은 이야기를 서술하는 형태를 표현 - 백로그에 작성되는 요구사항을 스토리 또는 사용자 스토리라고 합니다.

 

스크럼 기법

 

스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 양 팀의 선수들이 럭비공을 가운데 두고 상대팀을 밀치기 위해 서로 대치해 있는 대형 - 즉 팀워크를 가장 중요하게 인식하는 기법

 

요구사항 적합 : self-oraganizing - 팀 구성  cross-functional - 스스로 해결

 

스크럼팀 구성 : 제품 책임자, 스크럼 마스터, 개발팀

 

제품 책임자(PO: product owner)

 

• 이해관계자들 중 개발될 제품에 대한 이해도 높아야댐
• 요구사항이 담긴 백로그를 작성
• 팀원들도 백로그를 작성할 수 있지만 우선순위를 지정할 수 없다.

 

스크럼 마스터(SM : Scrum Master)

 

• 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할 
• 일일 스크럼 회의를 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소 공론화

 

개발팀(DT : Development Team)

 

• 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 된다.
• 보통 최대 인원은 7 - 8 명 적당

스크럼 개발 프로세스 

제품 백로그	제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여
스프린트 계획 회의	스프린트할 작업 대상으로 단기 일정 수립 요구 사항을 나눠서 작업할 수 있게 태스크(Task)라는 작업 단위로 분활 후 스프린트 백로그 작성
스프린트	실제 개발 진행 과정 : 보통 2주 - 4주 태스크 선정 시 개발자가 원하는 방향을 들어준다 개발 담당자에게 할당된 태스크는 보통 to do in progress done 상태로 갖는다.
일일 스크럼 회의	모든 팀원은 매일 약속된 시간에 약 15분 정도의 짧은 시간 내에 진행 상황 점검 소멸 차트 표시(Burn-down Chart) 스크럼 마스터는 발견된 장애 요소를 해결할 수 있게 도모
스프린트 검토 회의	부분 또는 전체 완성 제품이 요구 사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅 수행 주당 한시간 진행 제품 책임자는 피드백을 정리한 후 제품 백로그 업데이트
스프린트 회고	스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 확인

 

XP(eXtreme Prgramming)

 

XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

 

• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여
• 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성 높임
• 릴리즈 테스트마다 고객을 직접 참여 및 확인
• 비교적 소규모 인원의 개발프로젝트

릴리즈 : 몇 개의 요구사항이 적용되어 부분적으로 기능이 완료된 제품을 제공

 

XP의 5가지 핵심가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)

 

프로세스 과정 내용

사용자 스토리(user story)	고객의 요구 사항을 간단하게 시나리오 짜는 것 내용은 기능 단위
릴리즈 계획 수립	몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 합니다. 부분 혹은 전체 개발 완료 시점에 대한 일정 수립
스파이크	요구 사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램 처리할 문제 외의 것은 신경쓰지 말자
이터레이션	하나의 릴리즈를 더 세분화 한 단위를 이터레이션이라고 함 일반적으로 1 - 3 주 정도의 기간으로 진행 이 기간 중에 새로운 스토리가 작성 가능하며
승인검사	하나의 이터레이션 안에서 계획된 릴리즈 단위 부분 완료 제품이 구현되면 수행하는 테스트 고객이 직접 수행 가능 테스트 과정에서 발견한 오류사항은 다음 이터레이션에 포함
소규모 릴리즈	릴리즈를 소규모로 하게 되면, 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항을 유연하게 받아드릴 수 있음

 

XP의 주요 실천 방법

Pair Programming	다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성합니다.
Test-Driven Development	개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악합니다. 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 구조를 사용합니다.
Whole Team	개발에 참여하는 모든 구성원들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 합니다.
Continuous Intergration	모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리도리 때마다 지속적으로 통합
Design Improvement OR Refactoring	프로그램 기능의 변경 없이, 단순화, 유연성 강화 등을 통해 시스템 재구성
Small Releases	릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있습니다.

 

UML(Unified Modeling Language)

 

시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원할하게 이루어지도록 표준화한 대표적인 객체지향 모델링

 

객체 기술에 관한 국제표준화기구 OMG에서 표준 지정

 

사물(Things)

 

모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들

 

사물	내용
구조 사물	시스템의 개념적, 물리적 요소 표현 클래스, 유스케이스, 컴포넌트, 노드 등
행동 사물	시간과 공간에 따른 요소들의 행위를 표현 상호작용, 상태머신 등
그룹 사물	요소들을 그룹으로 묶어서 표현 패키지
주해 사물	부가적인 설명이나 제약조건 등을 표현 노트(Note)

 

관계(Relationships)

 

관계는 사물과 사물 사이의 연관성을 표현하는 것으로, 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등이 있음

 

 

다이어그램

 

정적 모델링 -> 구조적 다이어그램

동적 모델링 -> 행위적 다이어그램

 

 

구조적 다이어그램

 

클래스 다이어그램
객체 다이어그램
컴포넌트 다이어그램
배치 다이어그램
복합체 구조 다이어그램
패키지 다이어그램

 

행위적 다이어그램

 

 

유스케이스 다이어그램
시퀀스 다이어그램
커뮤니케이션 다이어그램
상태 다이어그램
활동 다이어그램
상호작용 개요 다이어그램
타이밍 다이어그램

 

<문제 풀때 기억이 안나는 용어 모음>

 

RAD 모델

소프트웨어 공학에서 가장 폭넓게 사용되고 있는 모형 : 폭포수 모형

Spiral 모델의 이점 : 대규모 시스템에 적합, 초기에 위험 요소를 발견하지 못할 경우 위험 요소를 제거하기 위해 많은 비용 소요

컴포넌트 기반 개발

정보 공학 개발

XP : 수시로 발생하는 고객의 요구 사항을 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

오픈소스 사용시 고려사항에는 라이선스 비용이 추가가 안댐