1.1 요구사항 확인 폭포수 모형-소프트웨어 개발도 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실하게 마치고 그 결과를 철저히 검토하여 승인 과정을 거친 후 다음 단계를 진행하는 개발 방법론.-고전적인 라이프 사이클 모델/선형 순차 모델-제품의 일부가 되는 매뉴얼을 작성해야 한다.- 각 단계가 끝난 후 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 한다. – 타당성 검토 > 계획 > 설계 > 시험 > 유지보수 및 선형모형 – 점진적인 모델 : 보헴이 차례로 제안되었다.- 소프트웨어를 개발할 때 발생할 수 있는 리스크를 관리하고 최소한으로 억제하는 것을 목적으로 한다. – 점진적으로 개발 과정이 반복되기 때문에 누락되거나 추가된 요구사항을 첨가할 수 있어 유지보수 과정이 필요 없다. – 계획 및 정의 > 리스크 분석 > 공학적 개발 > 고객 평가에 자일 – 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정 주기를 반복하면서 개발과정을 진행한다. – 좋은 것을 신속하고 낭비하지 않게 하기 위해 고객과의 커뮤니케이션에 초점을 맞춘 방법론의 통칭. – 스프린트 또는 이터레이션이라고 불리는 짧은 개발 사이클에서 반복적으로 요구되는 결과물의 평가받는 소규모, 고도로 숙련된 개발자, 급변하는 요구사항에 적합. – 개발 모델 : 스크럼, XP, 캄방, Lean, 크리스탈, A-D, FDD, D-DM, DAD 스크럼팀이 중심이 되어 개발 효율성을 높인다. 팀원 스스로 스크럼팀을 구성하고 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 한다. – 구성 – 제품책임자 : 요구사항에 책임을 지고 의사결정하는 사람으로서 요구사항이 포함된 백로그를 작성하여 우선순위 지정. 정기적으로 요구사항 우선순위 갱신 – 스크럼마스터 : 스크럼을 잘 수행할 수 있도록 객관적인 관점에서 조언하는 가이드 역할. 매일 스크럼 회의를 주최하여 진행 상황을 점검. 개발과정에서 발생한 장애요소를 공론화하여 처리. – 개발팀-스크럼개발 프로세스- 제품백로그: 제품개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록. 지속적으로 업데이트 – 스프린트 계획 회의 : 단기 일정 수립. 개발자별로 태스크를 분할한 후 스프린트 백로그 작성. – 스프린트 : 실제 개발 작업을 진행하는 과정. – 일 스크럼 회의 : 매일 약속된 시간에 15분 정도로 진행 상황 점검. 나머지 작업시간 소멸차트에 표시. – 스프린트 검토회의 : 부분 또는 전체 완성제품이 요구사항에 잘 부합하는지 사용자가 포함된 참가자 앞에서 테스트를 진행한다. 주당 1시간 이내에 실시.제품 책임자는 개선해야 할 사항에 대한 피드백을 정리한 후 제품 백로그 갱신. – 스프린트 회고: 개선점, 규칙 준수 여부 확인 및 기록.XP(eXtreme Programming) – 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발과정 반복을 극대화하여 개발생산성을 향상시키는 방법. – 짧고 반복적인 개발주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 신속하게 개발하는 것을 목적으로 한다. – 비교적 소규모 인원 개발 프로젝트에 효과적. – 5가지 핵심 가치: 커뮤니케이션, 단순성, 용기, 존중, 피드백 – XP 개발 프로세스 – 사용자 스토리: 요구사항을 시나리오로 표현. 기능 단위로 구성.-릴리즈 계획 수립:릴리즈(몇 가지 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것) 일정 수립. -스파이크:요구사항의 신뢰성을 높이고 기술문제에 대한 리스크를 줄이기 위해 별도로 만드는 간단한 프로그램. -이터레이션:하나의 릴리스를 더 세분화한 단위. -승인검사:하나의 이터레이션 내에서 계획된 릴리스 단위의 부분 완료 제품이 구현되면 수행하는 테스트. -소규모 릴리스:고객 반응을 기능별로 확인할 수 있다.기능 요건 – 시스템이 무엇을 하고 있는지, 어떤 기능을 하고 있는지에 관한 사항. -시스템이 반드시 실행해야 하는 기능 사용자가 시스템을 통해서 제공되기를 희망하는 기능 비기능 요건-시스템 기기 요구 사항, 성능 요구 사항(처리 속도와 시간, 가용성), 인터페이스 요구 사항, 데이터 요구 사항, 보안 요구 사항, 품질 요건, 시험 요건, 제약 사항, 프로젝트 관리 요구 사항 개발 프로세스-요구 사항 도출-요건 분석:타당성 조사, 비용과 스케줄에 대한 제약 설정-요구 사항 명세:요구 사항 체계적으로 분석 문서화 요구 사항 확인:요구 사항 검증 프로토 타입-초기 유도된 요건에 근거한 프로토 타입을 작성한 뒤 대상 시스템의 개발이 진행 중에 도출되는 요건을 반영하면서 계속적으로 프로토 타입을 재 작성하는 과정 UML-UML의 구성 요소:사물 관계 그림-사물:구조물, 행동물그룹사물,주해물 -관계존재하지않는이미지입니다.UML 다이어그램 – 구조적 다이어그램(정적 모델링) – 클래스 다이어그램 : 클래스 간 관계 표현. 시스템 구조를 파악하여 구조상의 문제점을 도출할 수 있다.- 객체 다이어그램: 클래스에 속하는 인스턴스를 특정 시점에서의 객체와 객체와의 관계로 표현. – 컴포넌트 다이어그램: 실제 구현 모듈은 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스 구현. 구현 단계에서 사용. – 배치도: 결과물, 프로세스, 컴포넌트 등 물리적 요소의 위치를 표현. 구현 단계에서 사용. – 복합체 구조도: 클래스나 컴포넌트가 복합 구조를 가질 때 내부 구조를 표현. – 패키지 다이어그램: 모델 요소를 그룹화. – 행위 다이어그램(동적 모델링)-유스케이스 다이어그램: 사용자 요구를 분석하여 기능 모델링 작업에 사용.사용자와 사용 사례로 구성.- 시퀀스 다이어그램: 상호작용하는 시스템이나 객체가 주고받는 메시지 표현한다.- 커뮤니케이션 다이어그램: 시퀀스 다이어그램과 같이 동작에 참여하는 객체가 주고받는 메시지와 관련까지 표현. – 상태도: 자신이 속한 크레스의 상태 변화를 표현. – 활동 다이어그램: 어떤 기능을 수행하는지 흐름을 순서대로 표현. – 상호작용 개요 다이어그램: 상호작용 제어 플로우 표현-타이밍 다이어그램: 객체 상태 변화와 시간 제약을 명시적으로 표현. 1.2 화면설계 사용자인터페이스(UI) – 구분: CLI, GUI, NUI – 사용자인터페이스 기본원칙: 직관성, 유효성, 학습성, 유연성 – 설계지침: 사용자중심, 일관성, 단순성, 결과예측가능성, 가시성, 표준화, 접근성, 명확성 및 오류발생해결 네비게이션 – 사용자가 사이트에서 빠르게 검색할 수 있도록 필요한 정보를 찾을 수 있도록 함.와이어프레임 – 기획단계 초기에 제작하는 것으로 페이지의 개략 레이아웃이나 UI 요소 등에 대한 뼈대를 설계하는 단계. 각 페이지 구분을 화면 단위로 설계. – 대출자나 디자이너 등이 레이아웃을 협의하거나 현재 진행 상황 등을 공유하기 위해 사용.스토리보드 – 와이어 프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가하는 문서. – 디자이너와 개발자가 최종적으로 참고하는 작업 지침서.UI 요구사항 – UI 요구사항 확인절차: 목표정의 > 활동사항정의 > UI 요구사항 작성 – 요건요소: 데이터요구, 기능요구, 제품서비스 품질, 제약사항 품질요건 – 소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요건이 얼마나 충족되는지 보여주는 소프트웨어 특성. – 기능성(Functionality) – 적절성/적합성: 목적 달성을 위해 적절한 기능을 제공하는가?-정밀성/정확성:요구하는 결과를 정확하게 산출하는가. -상호운용성:다른 시스템과 연계하여 작업.-보안성: 정보 접근 허가/차단-호환성: 기능과 관련된 표준을 준수했는가?-신뢰성(Reliability)-성숙성: 결함으로 인한 고장을 회피할 수 있는 능력-고장 허용성: 결함시에도 규정된 성능레벨을 유지할 수 있는 능력-회복성: 고장시 규정된 성능레벨까지 회복하여 여러 가지를 할 수 있는 능력-사용성(U-ability): 이해력, 학습성, 운용성, 친밀도-효율성(Efficiency)-시간 효율: 특정 기능 수행 시 적절한 반응시간과 처리시간을 제공할 수 있는 능력. -자원효율: 특정 기능 수행 시 적합한 양과 종류. -유지보수성(Maintaintaintability) 또한- 변경성: 결함 제거 또는 환경 변화에 따른 수정 등을 쉽게 구현할 수 있는 능력-안정성: 변경으로 인한 예기치 못한 결과를 최소화하는 능력. – 시험성: 변경이 검증되는 능력-이식성(Portability): 적용성, 설치성, 대체성, 공존성 프로토타입 – 사용자와 같은 형태로 작성한 동적인 동작을 기반으로 작성한 것, 디지털 프로토타입 – 계획 시 고려사항 – 프로토타이핑 스케줄은 일반적으로 아키텍처가 확정된 후 프로젝트의 실제 분석 작업이 완료되기 전에 진행해야 한다. – 가장 많은 시간이 소요된 구간을 찾아 원인 분석하여 해결 방법을 제기.- 작성시 고려사항 – 작성계획을 세운다.목표를 확인하다. – 프로토타입으로 증감하는 범위가 너무 넓거나 기간이 길면 목표가 커져 문제가 될 수 있다. – 실제 개발에 참조할 수 있는지 확인.UI설계서 – 사용자의 요구사항에 따라 UI설계를 구체화하여 작성하는 문서. 상세설계 이전의 대표적인 화면설계. – 절차: UI 설계서 표지작성 > UI 설계서 개정 이력작성 > UI 요구사항 정의서 작성 > 시스템구조작성 > 사이트맵 작성 > 프로세스정의서 작성 > 화면설계 유용성평가 – 사용자가 시스템을 통해 원하는 목표를 얼마나 효과적으로 달성할 수 있는가 하는 척도.UI 시나리오 – UI 설계자 또는 인터랙션 디자이너가 UI 시나리오 문서를 작성하면 그래픽 디자이너가 시나리오에 따라 디자인하고 개발자가 UI 구현 – 사용자가 최종 목표를 달성하기 위한 방법
