.jpg)
Table of Content
2. 요구사항 확인
요구분석 기법
•
요구공학이란? : 소프트웨어의 요구사항을 식별, 분석, 문서화, 관리하는 과정(체계화)
요구공학의 필요성
1.
품질 개선
2.
리스크 감소
3.
비용 절감
4.
효율적인 프로젝트 관리
5.
사용자와 개발자간의 소통 개선
요구사항 개발 프로세스(순서)
1. 도출 : 사용자, 이해관계자로부터 요구사항 수집(인터뷰, 워크숍, 설문, 브레인스토밍 등)
2. 분석 : 실제 구현가능성 검토, 우선순위, 중복 또는 충돌되는 사항 수정
- 구조적 분석 도구
- DFD(Data Flow Diagram) 자료 흐름도
- Data Dictionary : 자료사전
- Mini-Spec : 소단위 명세서
- ERD(Entity Relationship Diagram) : 개체 관계도
- STD(State Transition Diagram) : 상태 전이도
- 객체지향 분석 도구
- UML(Unified Modeling Language) : 클래스 도식 같은것
- 모델링
- 도메인 분석 : 요구사항의 배경, 설계 모델링에 필요한 여러 개념과 비지니스 룰 파악
도메인 배경파악 3단계 - 도메인 개념 찾기, 도메인 사전 작성, 비지니스 규칙 정리
3. 명세 : 분석된 요구사항을 명세서 형태로 정리한다. 기능, 성능, 제약조건등을 포함
- 명세 기법
- 정형 명세 기법(수학 논리학) : 수학적 기호, 정형화된 표기
→ 명세 오류 쉽게 파악, 작성 어렵, 시간 많이 소모, VDM, Z, Petri-net, CSP
- 비정형 명세 기법(자연어, 그림) : 명사, 동사 등 자연어 서술 및 다이어그램
→ 사용자/개발자 커뮤니케이션 용이, 내용 모호, 완전 검증 어렵, FSM, Decision Table, ER 모델링, StataChart(SADT) 등
- 요구사항분류
- 기능 요구사항 : 시스템이 어떤 기능을 수행해야 하는지, 어떤 서비스를 제공하는지
(ex:웹사이트에서 사용자는 로그인해야한다, 사용자는 주문을 할 수 있어야 한다 ..)
- 비기능 요구사항 : 시스템이 어떻게 동작해야 하는지 요구사항, 성능, 보안, 가용성, 유지보수
4. 확인 및 검증 : 분석가가 요구사항 이해한지 확인, 요구사항 문서가 일관성있고 완전한지 검증
요구사항 분석 기법
- 인터뷰 : 인터뷰
- 브레인스토밍 : 아이디어 도출, 제시, 적합 선택
- 원인-효과 다이어그램 : 요구사항이나 문제,결과 등 시각화하는 다이어그램으로 분석, 복잡한것에 적합
- 프로토타이핑 : 실제 모습 프로토타입으로 피드백 유도
- 사용사례(Use Case) : 사용자의 시스템 사용 과정을 스토리보드 형태로 묘사, 가정
- 요구사항 검토 : 수집된 요구사항을 검토하여 중복, 충돌, 모호, 불안전 요소 찾기
UML(Unified Modeling Language)
•
소프트웨어 시스템을 시각화 및 문서화하고 구조와 동작을 명세하는 표준화된 모델링 언어
UML의 특징
1. 가시화 언어 : 다이어그램으로 시각적으로 이해를 도움
2. 명세화 언어 : 표준화된 언어로 명세하는데 사용
3. 구축 언어 : 설계-구현(개발)에 도움이되며 특히 객체지향 개발에서 중요함
4. 문서화 언어 : 표준 형태로 문서화되어 개발, 유지보수의 커뮤니케이션 됨
UML의 구성요소
1. 사물(Things) : 모델의 기본 요소
2. 관계(Relationship) : 사물간의 연관성
- 일반화 관계(Generalization : 한 클래스가 다른 클래스의 상위 개념 ‘부모’일때 = 상속)
- 연관관계(Association : 2개 이상 사물이 관련된 관계, 다른 클래스의 기능을 사용할 때 등 표시)
- 의존관계(Dependency : 다른 클래스 제공기능을 사용할때 표시, 연관과 차이점은 매우 짧은시간)
- 실체화관계(Realization : 추상 메서드를 오버라이딩하는것 의미, ‘인터페이스’ 와 구현체로 이해.
- 집합관계-집약관계(Aggregation : 불고기 = 간,다,미 처럼 has 관계 포함관계, 불 사라져도 다른재료 남음)
- 집합관계-합성관계(Composition : 책상 = 다리,몸,나사, 책상이 사라지면 같이 사라짐)
3. 다이어그램 : 사물과 관계를 도형으로 표현
4. 스테레오타입 : 추가적인 의미 부여
구조 다이어그램(정적)
•
클래스 다이어그램
•
객체 다이어그램
•
컴포넌트 다이어그램
•
배치 다이어그램
•
복합체 구조 다이어그램
•
패키지 다이어그램
행위 다이어그램(동적)
•
유스케이스 다이어그램
•
순차 다이어그램
•
커뮤니케이션 다이어그램
•
상태 다이어그램
•
활동 다이어그램
•
상호작용 다이어그램
•
타이밍 다이어그램
클래스 다이어그램에서
•
차 -버스,트럭,택시 처럼 상속으로 보일때
◦
실선으로 표현하면 일반화 관계
▪
A ——> B = Generalization
◦
점선으로 표현하면 추상화 관계
▪
한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계
▪
A - - > B = Realization (추상화 실체화 관계)
클래스 다이어그램 접근제한자 표기법
•
“-” private 해당 클래스 내에서만 접근 가능
•
“#” protected 상속, 동일 패키지 내에서만 접근 가능
•
“+” public 어디서든 접근가능
유스케이스 다이어그램
•
구성요소
◦
시스템 (ㅁ)
◦
액터 (사람)
◦
유스케이스 기능 (ㅇ)
◦
관계 (사람-ㅇ) 연결
▪
상호작용이 있음 (실선)
▪
포함관계 : 반드시 실행 (점선<<include>>) ex)로그인이 무조건 필요한 게시판 글쓰기 기능
▪
확장관계 : 특정 조건에 따라 확장기능 (점선<<extend>>) ex)글쓰기의 첨부파일이 선택일 경우
▪
일반화 관계 ex) 검색-1.글쓴이로 검색, 2.날짜로 검색 처럼 추상화한 유스케이스
시퀀스 다이어그램
•
구성요소
◦
객체와 생명선
▪
객체는 직사각형
▪
위에서 아래로 시간의 경과를 의미
◦
활성박스
▪
생면선상 기다란 직사각형
▪
객체가 어떤 활동을 하고 있음을 의미
◦
메시지
▪
인스턴스간 주고받은 데이터
▪
동기메시지, 비동기메시지, 자체메시지, 반환메시지
상태 다이어그램
한 객체의 상태 변화를 나타내는 다이어그램
애자일(Agile) 방법론
소프트웨어 개발에 대한 반복적이고 점진적인 접근 방식
경량 프로세스라고도 한다.
•
애자일 선언문
◦
공정과 도구보다 개인과 상호작용을
◦
포괄적인 문서보다 작동하는 소프트웨어를
◦
계약 협상 보다 고객과의 협력을
◦
계획을 따르기보다 변화에 대응하기를
◦
우리는 왼쪽 가치를 인정하면서 오른쪽 항목을 더 중요하게 여긴다.
•
애자일 특징
◦
고객 중심 : 요구사항과 만족도에 초점을 맞추며 빠른 피드백, 제품 품질향상
◦
점진적 개발 : 작은 반복주기로 프로젝트를 나누어 각 주기의 끝에 실행 가능한 제품 제공(버전처럼)
◦
융통성 : 요구사항 변화에 유연하게 대응하며 변경사항을 효과적으로 통합
◦
협력과 커뮤니케이션 강조 : 프로젝트 참여자들간의 밀접한 협력과 커뮤니케이션을 통한 문제를 신속하게 해결, 효율적인 결정
◦
자기 조직화 : 팀원들이 스스로의 역할과 책임을 정하고 팀의 효율적인 작동을 위해 능동적으로 참여
◦
지속적인 개선 : 반복 주기의 끝에서 피드백과 반성을 통해 프로세스와 제품을 지속적으로 개선하고 최적화
•
애자일 방법론 종류
◦
XP(extream programming)
▪
XP의 5가지 핵심 가치(의사님피존용기에단아주세요)
•
용기 : 요구사항 변화에 능동적인 대처
•
존중 : 개발자의 역량을 존중하고 충분한 권리를 부여
•
의사소통 : 개발자, 관리자, 고객간의 원활한 의사소통
•
피드백 : 의사소통에 따른 즉각적인 피드백
•
단순성 : 부가적 기능, 사용되지 않는 구조와 알고리즘 배제
▪
12실천사항
•
짝프로그래밍(페어프로그래밍)
•
계획세우기
•
테스트기반 개발
•
고객상주
•
지속적인 통합
•
코드개선
•
작은 릴리즈
•
코딩표준
•
공동코드소유
•
간단한디자인
•
시스템메타포어(최종시스템구조를보는것)
•
작업시간준수
◦
스크럼(Scrum)
▪
개발주기를 30일정도로 조절하여 실제 동작할 수 있는 결과를 제공
▪
주기마다 기능, 개선에 대한 목록 작성
▪
매일 15분정도의 회의
◦
그 외 종류
▪
크리스털 : 프로젝트 규모에 따라 여러 종류의 방법론 제공
▪
FDD : Feature 마다 2주 반복 개발, 신규 기능 단위 개발방법론
▪
ASD : 합동 애플리케이션 개발을 사용, 개발=혼란 혼란을 적응 할 수 있는 소프트웨어 방법 제시
▪
Lean : 도요타 린 시스템 품질기법, 낭비요소를 제거하여 품질 향상
Related Posts
Search
