소프트웨어 생명 주기 (Software Life Cycle) c
소프트웨어 생명주기란 소프트웨어를 개발하기 위한 설계,운용,유지보수 등의 과정을 각 단계별로 나눈것
나선형 모형, 폭포수 모형, 프로토타입 모형, 애자일 모형 등.
나선형 모델 (Spiral Model) b
나선따라 돌아가며 점진적으로 완벽한 소프트웨어를 만든다. 보햄(Boehm)이 제안함.
4가지 주요활동
고객평가에서 수정사항등이 발생하면 다시 계획수립부터 반복
폭포수 모델 (Waterfall Model) b
가장 오래된 생명주기 모델.
폭포수가 한번 떨어지면 다시 올라가지 못하는 것 처럼,
한번 단계를 넘거가뿔면 이전 단계로 갈 수 없음.
철저하게 검토하고. 승인과정을 거쳐서 완벽하게 만든 다음 단계를 진행.
프로토타입 모형 (Prototype Model) c
고객의 요구사항을 알기위해서 견본품을 미리 만들어보는것.
애자일 모형 (Agile Model) a
빠르고 낭비없는 고객과의 소통 고객의 요구사항 변화에 유연하게 대응.
스크럼(Scrum) , 익스트림 프로그래밍 (XP, eXtreme Programming), 칸반(Kanban), Lean, 기능중심개발 (FDD:Features Driven Development)
에자일의 핵심가치 a
- 프로세스나 도구보다는 개인과 상호작용
- 문서보다는 실행되는 결과물(소프트웨어)
- 협상보다는 협업
- 계획보다는 변화에 반응
스크럼 (Scrum) c
하나의 팀을 구성하여 개발 효율을 높임
스크럼의 구성원
- 제품책임자 (PO : Product Owner)
- 요구사항이 담긴 Backlog를 작성
- 제품에 대한 이해도 높고. 요구사항 책임지고. 의사 결정할 사람.
- 스크럼마스터 (SM : Scrum Master)
- 개발팀 (DT : Development Team)
스크럼 개발 프로세스 c
스트린트 계획 회의→스프린트→일일 스크럼 회의→스프린트 검토 회의→스프린트 회고
| 프로세스 |
내용 |
| 스프린트 계획 회의 (Sprint Planning Metting) |
제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의 |
| 스프린트 (Sprint) |
실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행함 |
| 스프린트 검토 회의 (Sprint Review) |
부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅 하는 회의 |
| 스프린트 회고 (Sprint Retrospective) |
정해놓은 규칙 준수 여부 및 개선 할 점을 확인하고 기록하는 것 |
익스트림 프로그래밍(XP : eXtreme Programming) b
수시로 발생하는 고객의 요구사항에 유연하게 대응 하기 위해 고객의 참여와 개발과정의 반복 을 극대화 하여 개발 생산성을 향상시키는 방법
- 짧고 반복적인 개발주기
- 단순한 설계
- 고객의 적극적인 참여
를 통해 소프트웨어를 빠르게 개발하는 것이 목적.
XP의 주요 실천 방법(Practice) A
- Pair Programming(짝 프로그래밍)
- 다른사람과 함께 개발 진행. 책임도 공동으로 나눔.
- Collective Onership(공통 코드 소유)
- Test-Driven Development(테스트 주도 개발)
- 개발자는 코딩전에 테스트 케이스를 먼저 작성해서 개발 사항을 정확히 파악
- 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구를 사용
- Whole Team(전체 팀)
- 개발에 참여하는 모든 인원(고객 포함)은 각자 역할이 있고, 그 역할에 책임을 가져야 한다.
- Continous Intergration(계속적인 통합)
- 모듈단위로 개발된 코드는 작업 마무리 될 때마다 지속적으로 통합된다.
- Refactoring(리팩토링)
- 개발된 프로그램의 기능 변경없이 내부코드를 재구성
- 목적 : 다른 개발자가 코드를 쉽게 이해하고. 유지보수가 용이하게 만들기 위함
- Small Release(소규모 릴리즈)
- 릴리즈 기간을 짧게 반복함으로서 고객의 요구에 신속히 대응할 수 있다.
데이터베이스 관리 시스템 (DBMS : Database Management System b
사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해주는 소프트웨어
DBMS 관련 요구사항 식별시 고려해야 할 사항
- 소프트웨어가 제공하는 서비스에 대한 설명
- 소프트웨어가 정상적으로 운영되는데 핋요한 제약조건
기능 요구사항(Functional Requiremnts) a
- 시스템이 무었을 하는지 어떤 기능을 하는지
- 시스템의 입력이나 출력으로 무었이 포함되어야 하는지
- 시스템이 어떤 데이터를 저장하거나 연산을 수행하는지
- 시스템이 반드시 수행해야 하는 기능
- 사용자가 시스템을 통해 제공받기를 원하는 기능
비기능 요구사항(Non-Functional Requiremnts) a
품질이나 제약사항과 관련된 요구사항. 시스템의 장비구성, 성능, 인터페이스, 테스트, 보안 등의 요구사항.
- 품질, 제약사항과 관련된 요구사항
- 시스템 장비 구성 요구사항
- 성능 요구사항
- 인터페이스 요구사항
- 데이터를 구축하기 위해 필요한 요구사항
- 테스트 요구사항
- 보안 요구사항
- 품질 요구사항 가용성, 정합성, 상호호환성, 대응성, 이식성, 확장성, 보안성 등
- 제약사항
- 프로젝트 관리 요구사항
- 프로젝트 자원 요구사항
요구사항 개발 프로세스 b
- 도출 (Elicitation)
- 분석 (Analysis)
- 명세 (Specification)
- 확인 (Validation)
요구사항 명세 c
- 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는것
- 기능 요구사항은 빠짐없이
- 비기능 요구사항은 필요한 것만
요구사항 명세 기법 b
- 수학적 원리와 표기법 : 정형 명세기법
- 자연어 사용 : 비정형 명세기법
| 구분 |
정형 명세 기법 |
비정형 명세 기법 |
| 기법 |
수학적 원리기반, 모델 기반 |
상태/기능/객체 중심 |
| 작성방법 |
수학적 기호, 정형화된 표기법 |
일반명사,동사 등 자연어 기반 서술 또는 아이어그램 |
| 특징 |
- 요구사항을 정확하고 간결하게 표현
- 요구사항에 대한 결과가 작성자에 상관없이 일관성이 있으므로 완전성 검증 가능
- 표기업이 어려워 사용자가 이해하기 어려움
|
- 자연어 사용 : 요구사항에 대한 결과가 작성자에 따라 다를 수 있음 : 일관성 떨어짐. 해석이 달라질 수 있음
- 내용 이해가 쉬워 의사소통 용이
|
| 종류 |
VDM, Z, Petri-net, CSP |
FSM, Decision Table, ER모델링, State Chart(SADT) |
자료 흐름도 (DFD : Data Flow Diagram) b
- 자료의 흐름 및 변환과정과 기능을 도형 중심으로 기술하는 방법
- 자료 흐름 그래프, 버블차트라고도 함
자료 흐름도의 구성요소 a
| 기호 |
의미 |
| 프로세스 (Process) |
자료를 변환시키는 시스템의 한 부분(처리과정)을 나타냄. 처리, 기능, 변환, 버블이라고도 함 |
| 자료 흐름 (Data Flow) |
자료의 이동(흐름)이나 연관관계 |
| 자료 저장소 (Data Store) |
자료저장소 (파일, 데이터베이스) |
| 단말 (Terminator) |
시스템과 교신하는 외부개체. 입력 데이터 만들어지고 출력데이터 받음. |
자료 사전 (DD : Data Dictionary) a
자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한것
자료 사전에서 사용되는 표기기호
| 기호 |
의미 |
| = |
자료의 정의 : ~로 구성되어 있다 (is composed of) |
| + |
자료의 연결 : 그리고 (and) |
| () |
자료의 생략 : 생략 가능한 자료 (Optional) |
| [] |
자료의 선택 : 또는 (or) |
| {} |
자료의 반복 : Iteration of |
| ** |
자료의 설명 : 주석 (Comment) |
요구사항 분석용 CASE (자동화 도구) c
요구사항을 자동으로 분석하고, 요구사항 분석명세서를 기술하도록 개발된 도구
- SADT
- SREM(=RSL/REVS)
- PSL/PSA
- TAGS
SADT b
- 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구
- SoftTech 에서 개발
- 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화도구
HIPO (Hierarch Input Process Output) a
- 시스템의 분석 및 설계, 문서화에 사용되는 기법. 시스템의 실행과정인 입력, 처리, 출력의 기능을 표현
- 하향식 소프트웨어 개발을 위한 문서화도구
- 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들간의 인터페이스를 계층구조로 표현함
UML (Unified Modeling Language) a
- 시스템 분석, 설계, 구현등 시스템 개발 과정에서 개발자와 고객 또는 개발자 상호간의 의사소통 이 원활하게 이루어지도록
표준화한 대표적인 객체지향 모델링 언어
- Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합
- UML 의 구성요소
- 사물 (Things)
- 관계 (Relationships)
- 다이어그램 (Diagram)
사물과 사물 사이의 연관성을 표현
관계의 종류
- 연관 관계
- 집합 관계
- 포함 관계
- 일반화 관계
- 의존 관계
- 실체화 관계
연관 관계 (Association) c
- 2개이상의 사물이 서로 관련되어 있는 관계
- 사물 사이를 실선으로 연결하여 표현
- 방향성은 화살표로 표현
- 다중도를 선 위에 표기
사람⎯1⎯⎯⎯⎯1⎯>집
사람은 집을 소유한다. 사람은 집에 대하 알고 있지만 집은 자신의 소유자를 모른다.
사람 쪽의 다중도 1이므로 집은 한사람의 집주인만 가질 수 있다.
집 쪽의 다중도가 1이므로 사람은 집을 하나만 가질 수 있다.
집합 관계 (Aggregation) a
- 하나의 사물이 다른 사물에 포함되어 있는 관계
- 포함하는 쪽과 포함되는 쪽은 서로 독립적
- 포함하는 쪽으로 마름모를 연결하여 표현한다
컴퓨터◇⎯⎯⎯⎯프린터프린터는 컴퓨터에 연결 가능, 다른 컴퓨터 연결 가능.
포함 관계 (Composition) c
- 집합 관계의 특수한 형태. 포함하는 사물의 변화가 사물에게 영향을 미치는 관계
- 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고, 생명주기를 함께한다
- 속이 채워진 마름모를 연결하여 표현한다
문(Door)◆⎯⎯⎯⎯키(Key)문을 열 수 있는 키는 하나. 해당키로 다른 문 열수 없다. 문이 없어지면 키도 불필요.
일반화 관계 (Generalization) a
- 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
- 보다 일반적인 개념 : 상위(부모) 보다 구체적인 개념 : 하위(자식)
- 자식에서 부모로 속이 빈 화살표 연결
| 커피 |
◁⎯⎯에스프레소 |
| ◁⎯⎯⎯⎯⎯⎯⎯⎯아메리카노 |
의존관계 (Dependency) a
- 필요에 의해 서로에게 영향을 주는 특정 시간동안만 연관을 유지하는 관계
등급------->할인율
등급이 높으면 할인율 적용하고 낮으면 적용하지 않는다.
실체화 관계 a
- 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화 할 수 있는 관계
| 날 수 있다 |
◁--------새 |
| ◁----------------비행기 |