일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 커다랗게 살을 붙이면서 개발하는 프로세스 모델 방식이다.미리 정해진 몇 개의 단계에 따라 엄격한 순서대로 이루어지는 일직선의 과정인 폭포수의 프로세스와는 비교가 많이 되는 반대의 개념이다.이 소프트웨어 개발 방법론을 쓰시오.
애자일 방법론, Agile
3. 애자일(Agile) 방법론
(1) 애자일 방법의 개념
‘날렵한, 재빠른’이라는 사전적 의미
소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항을 수용할 수 있다.
절차와 도구보다 개인과 소통을 중요시하고 고객과의 피드백을 중요하게 생각한다.
특징 : 짧은 릴리즈와 반복, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적인 커뮤니케이션, 변화
종류 : 익스트림프로그래밍(eXtremeProgramming), 스크럼(SCRUM), 린, DSDM, FDD, Crystal
(2)Agile 선언문
프로세스나 도구보다 개인과의 소통이 더 중요하다.
완벽한 문서보다 실행되는 소프트웨어가 더 중요하다.
계약 협상보다 고객과의 협업이 더 중요하다.
계획을 따르는 것보다 변경에 대한 응답이 더 중요하다.
4.XP(eXtremeProgramming)
(1) XP의 정의
1999년 Kent Beck이 제안하였으며, 개발 단계 중 요구사항의 변동이 심한 경우 적합한 방법론
요구에 맞는 양질의 소프트웨어를 신속하게 제공하는 것이 목표
요구사항이 변경되는 것을 적용하는 방식으로 예측성보다는 적응성에 더 높은 가치를 부여한 방법
고객의 참여와 개발 과정의 반복을 극대화하여 생산성을 향상하는 방법
(2) XP의 5가지 핵심가치
소통(Communication) : 개발자, 관리자, 고객 간의 원활한 소통을 지향
단순성(Simplicity) : 부가적 기능 또는 미사용 구조와 알고리즘은 배제
피드백(Feedback) : 소프트웨어 개발에서 변화는 불가피하다. 이러한 변화는 지속적인 테스트와 통합, 반복적 결함 수정 등을 빠르게 피드백
용기(Courage) : 고객 요구사항 변화에 능동적 대응
존중(Respact) : 개발 팀원 간의 상호 존중이 기본
5. XP의 12가지 실천사항(Practice)
구분
실천사항
내용
Fine scale feedback
Pair Programming
하나의 컴퓨터에 2명의 프로그래머가 모든 코드에 대해서 코딩과 리뷰 역할을 바꿔가며 공동 작업을 진행한다.
Planning Game
게임처럼 선수와 규칙, 목표를 두고 기획에 임한다.
Test Driven Development
실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드를 작성한다.
Whole Team
개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킨다.
Continuous process
Continuous Integration
상시 빌드 및 배포를 할 수 있는 상태로 유지한다.
Design Improvement
기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성을 수행한다.
Small Releases
짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 한다.
Shared understanding
Coding Standards
소스코드 작성 포맷과 규칙들을 표준화된 관계에 따라 작성한다.
Collective Code Ownership
시스템에 있는 소스코드는 팀의 모든 프로그래머가 언제라도 수정할 수 있다.
Simple Design
가능한 가장 간결한 디자인상태를 유지한다.
System Metaphor
최종적으로 개발되어야 할 시스템의 구조를 기술한다.
Programmer welfare
Sustainable Pace
일주일에 40시간 이상 작업 금지, 2주 연속 오버타임을 금지한다.
6. SCRUM
(1) SCRUM의 개념
반복적이고 점진적인 소규모 팀 중심의 소프트웨어 개발 방법론
팀원 간 활발한 소통과 협동심이 필요
요구사항 변경에 신속하게 대처할 수 있음
(2)SCRUM의 특징
기능 개선점에 우선순위를 부여하고, 개발 주기 동안 실제 동작 가능한 결과를 제공
개발 주기마다 적용된 기능이나 개선점의 리스트 제공
커뮤니케이션을 위하여 팀은 개방된 공간에서 개발하고, 매일 15분 정도 회의를 함
(3) SCRUM의 기본 원리
스프린트(Sprint)는 고정된 30일의 반복이며, 스프린트 시 행하는 작업은 고정
Sprint : ‘전력 질주’라는 의미로, 반복 주기(2~4주)마다 일의 진척도를 보고
요구사항, 아키텍처, 설계가 프로젝트 전반에 걸쳐 잘 드러나야 함
section03. 현행 시스템 파악
1. 현행 시스템 분석
(1) 현행 시스템 분석의 정의와 목적
현행 시스템이 어떤 하위 시스템으로 구성되어 있는지 파악하는 절차를 의미
개발 시스템의 개발 범위를 확인하고 이행 방향성을 설정하는 것이 목적
(2) 현행 시스템 파악 절차
1단계 : 시스템 구성 파악 → 시스템 기능 파악 → 시스템 인터페이스 현황 파악
2단계 : 아키텍처 파악 → 소프트웨어 구성 파악
3단계 : 시스템 하드웨어 현황 파악 → 네트워크 구성 파악
(3) 시스템 아키텍처
시스템 내의 상위 시스템과 하위 시스템들이 어떠한 관계로 상호작용하는지 각각의 동작 원리와 구성을 표현한 것
2. 시스템 및 인터페이스 현황 파악
3. 소프트웨어, 하드웨어, 네트워크 구성 파악
section04. 개발 기술 환경 분석
1. 플랫폼(Platform)
2. 현행 시스템의 OS 분석
3. 현행 시스템 DBMS 분석
4. 네트워크 구성도
5. 미들웨어 현행 시 시스템 분석
(1) 미들웨어(Middleware)
운영체제와 소프트웨어 애플리케이션 사이에 위치
애플리케이션에 운영체제가 제공하는 서비스를 추가 및 확장하여 제공하는 컴퓨터 소프트웨어이다.
6. 오픈 소스 라이선스
(1) 오픈 소스 라이선스의 개념
소스코드가 공개되어 누구나 특별히 제한 없이 소스를 사용할 수 있도록 한다.
대표적으로 Linux가 있음
(2) 오픈소스 사용 시 고려사항
오픈 소스의 경우 해당 소스의 기술이 지속 가능한지 우선으로 고려하고 라이선스의 종류, 사용자 수 등을 고려해야 한다.
오픈 소스 레벨에 따라서 허용하는 범위를 파악하여 라이선스를 위반하지 않도록 주의한다.
(3) GNU(GNU’s Not Unix)
유닉스(Unix)의 상업적 확산에 반발하여 리처드 스톨먼과 그의 팀이 무료로 개발·배포하고 있는 유닉스 호환 운영체제
Chapter02. 요구사항 확인하기
section01. 요구사항 개발
1. 요구사항
2. 요구사항 도출
3. 요구사항 분석(Requirement Analysis)
시스템 요구사항을 정제하여 소프트웨어 요구사항을 도출
소프트웨어가 환경과 어떻게 상호작용하는지 이해하고, 명확하지 못하거나 모호한 부분을 걸러내기 위한 과정
( ① ) 요구사항은 제품을 구현하기 위해 소프트웨어가 가져야 할 기능적 속성 ( ② ) 요구사항은 제품 품질 기준 등의 만족을 위해 소프트웨어가 가져야 할 특성
① 기능적 , ② 비기능적
기능적 요구사항 (Functional Requirements)
- 제품 구현을 위해 소프트웨어가 가져야 할 기능적 속성 ex) 파일 저장 기능, 편집 기능, 보기 기능 등 / 관리자와 승객이 DB에 접근할 때 어떤 정보를 얻을 수 있는지 결정 차운행, 탑승객, 예약을 입력하는 방법 결정 / 기차표와 예약 정보에 어떤 정보가 포함되어야 할 지 결정
비기능적 요구사항 (Non-Functional Requirements)
- 제품 품질 기준 등의 만족을 위해 소프트웨어가 가져야 할 특성 - 고객의 새로운 요구사항을 추가하기 위하여 시스템을 확장할 수 있도록 설계 ex) 성능, 사용의 용이성, 신뢰도, 보안성, 안전선 등
4. 요구사항 명세
5. 요구사항 확인
section02. 요구사항 관리
1. 요구사항 관리의 개념
2. SDLC(Software Development Life Cycle) 요구사항 관리 절차
3. CMMi(Capability Maturity Model Integration)
4. 요구사항 관리 프로세스
5. 인수 테스트
사용자 측 관점에서 소프트웨어가 요구사항을 충족시키는지 평가하는 절차
소프트웨어가 고객의 합리적인 기대에 따라 제 기능을 발휘하는지를 테스트
종류 : 계약 인수 테스트, 규정 인수 테스트, 알파 테스트, 베타 테스트, 사용자 인수 테스트, 운영 인수 테스트
알파/베타 테스트
알파 테스트
- 개발사 내에서 진행하는 테스트 - 개발자 관점에서 수행 - 개발자는 사용상의 문제를 기록하여 반영되도록 하는 테스트
베타 테스트
- 선정된 다수의 사용자가 자신들의 사용 환경에서 일정 기간 사용하면서 테스트 - 문제점이나 개선 사항 등을 기록하고 개발 조직에 통보하여 반영되도록 하는 테스트
6.모델 품질 검증(Model Certification)
(1) 정적 분석(Static Analysis)
객체 모델에서 객체들 사이에 존재하는 의사소통 경로를 검증하기 위해 사용
명세의 일관성과 정확성을 확인, 분석하는 도구
(2) 동적 분석(Dynamic Analysis)
직접 실행을 통하여 모델을 검증하는 방식
7. 테스트 레벨
애플리케이션 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트, 설치 테스트로 분류한다.
Chapter03. 분석 모델 확인하기
section01.분석(참고)모델
1. 분석(참고)모델의 개념
2. 구조적 분석 모델
사용자의 요구분석 사항을 파악하기 위하여 자료의 흐름과 가공 절차를 그림 중심으로 표현하는 방법
(1) 자료 흐름도(DFD, Data Flow Diagram)
시스템 내의 모든 자료 흐름을 4가지의 기본 기호(처리, 자료 흐름, 자료 저장소, 단말)로 기술하는 방법
(2) 자료 흐름도의 구성 요소
처리 공정 (Process)
자료를 변환시키는 과정을 나타냄
자료 흐름 (Data Flow)
자료의 흐름을 나타냄
자료 저장소 (Data Store)
파일,데이터베이스를 나타냄
단말 (Teminator)
자료의 출처와 도착지를 나타냄
3. 객체지향 분석 모델
section02. 객체지향 분석 모델
1. 객체지향(Object Oriented) 분석
2. 객체지향 프로그래밍
3. 객체지향 구성요소
Class, Object, Message
4. 객체지향의 5가지 특징
캡슐화 (Encapsulation)
-서로 관련성이 높은 데이터(속성)와 그와 관련된 기능(메소드, 함수)을 묶는 기법 - 결합도가 낮아져 소프트웨어 개발에 있어 재사용성이 높아짐 - 정보은닉을 통하여 타 객체와 메시지 교환 시 인터페이스가 단순해짐 - 변경 발생 시 오류의 파급 효과가 적음
정보은닉 (Information Hiding)
- 객체 내부의 속성과 메소드를 숨기고 공개된 인터페이스를 통해서만 메시지를 주고 받을 수 있도록 하는 것을 의미 - 예기치 못한 Side Effect를 줄이기 위해 사용
추상화 (Absraction)
- 시스템 내의 공통 성질을 추출한 뒤 추상 클래스를 설정하는 기법 - 현실 세계를 컴퓨터 시스템에 자연스럽게 표현할 수 있음
상속성 (Inheritance)
- 상위 클래스의 모든 속성, 연산을 하위 클래스가 재정의 없이 물려받아 사용하는 것 - 상위 클래스는 추상적 성질을,자식 클래스는 구체적 성질을 가진다. - 하위 클래스는 상속받은 속성과 연산에 새로운 속성과 연산을 추가하여 사용할 수 있음 - 다중 상속 : 다수 상위 클래스에서 속성과 연산을 물려받는 것
다형성 (Polymorphism)
- 객체가 다양한 모양을 가지는 성질을 뜻한다. - 오퍼레이션이나 속성의 이름이 하나 이상의 클래스에서 정의되고 각 클래스에서 다른 형태로 구현될 수 있는 개념 - 속성이나 변수가 서로 다른 클래스에 속하는 객체를 지칭할 수 있는 성질 - 오버로딩(같은 이름순서 재사용)과 오버라이딩(재정의)이 있다.
UML은 컴퓨터 애플리케이션을 모델링 할 수 있는 통합 언어이다. 구성요소로는 사물, ( ① ), 다이어그램으로 이루어져 있고, 구조 다이어그램 중 ( ② ) 다이어그램은, 객체들의 타입을 정의하고, 객체들간의 관계를 도식화하여 시스템의 특정 모듈이나 일부 및 전체를 구조화한다. UML 모델링에서 ( ③ )는 클래스와 같은 기타 모델 요소 또는 컴포넌트가 구현해야 하는 오퍼레이션 세트를 정의하는 모델요소이다.
① 관계 , ② 클래스 , ③ 인터페이스
2. UML(Unified Modeling Language)
(1) UML의 개념
객체지향 소프트웨어 개발 과정에서 시스템 분석, 설계, 구현 등의 산출물을 명세화, 시각화, 문서화할 때 사용하는 모- 델링 기술과 방법론을 통합하여 만든 범용 모델링언어
Rumbaugh(OMT)와 Booch가 두 방법을 통합하기 위하여 IBM Rational Software에 같이 일하면서 만들어졌다.
(2) UML의 특성
비주얼화, 문서화, 명세화, 구축
(3) UML 소프트웨어에 대한 관점
기능적 관점 : 사용자 측면에서 본 소프트웨어의 기능을 나타냄. 요구분석 단계에서 사용
정적 관점 : 소프트웨어 내부의 구성요소 사이의 구조적 관계를 나타냄
동적 관점 : 소프트웨어의 내부 활동을 나타냄
(4) UML의 구성
사물
- 객체지향 모델을 구성하는 기본 요소 - 객체 간의 관계 형성 대상
관계
- 객체 간의 연관성을 표현하는 것 - 종류 : 연관, 집합, 포함, 일반화,의존, 실체화
다이어그램
- 객체의 관계를 도식화한 것 - 다양한 관점에서 의사소통할 수 있도록 View 제공 - 정적 모델: 구조 다이어그램 - 동적 모델 : 행위 다이어그램
( ) 다이어그램은 시스템을 구성하는 객체 간의 관계를 추상화한 모델을 논리적 구조로 표현한다. ( ) 다이어그램은 클래스, 속성, 오퍼레이션, 연관 관계를 이용하여 시스템을 정적인 관점으로 나타낸 것이다. ( ) 다이어그램을 통해 해당 시스템에서 사용되는 데이터를 발견할 수 있다.
클래스 다이어그램
(1) 구조적 다이어그램(Structure Diagram)
정적이고, 구조적인 표현을 위한 다이어그램이다.
클래스 다이어그램 (Class Diagram)
시스템을 구성하는 클래스들 사이의 관계를 표현
패키지 다이어그램 (Package Diagram)
클래스나 유스케이스 등을 포함한 여러 모델 요소들을 그룹화하여 패키지를 구성하고 패키지들 사이의 관계를 표현
복합체 구조 다이어그램 (Composite Structure Diagram)
복합 구조의 클래스와 컴포넌트 내부 구조를 표현
객체 다이어그램 (Object Diagram)
객체 정보를 보여줌
컴포넌트 다이어그램 (Component Diagram)
컴포넌트 구조 사이의 관계를 표현
배치 다이어그램 (Deployment Diagram)
소프트웨어, 하드웨어, 네트워크를 포함한 실행 시스템의 물리 구조를 표현
(2) 행위 다이어그램(Behavior Diagram)
동적이고, 순차적인 표현을 위한 다이어그램이다.
상호작용 다이어그램(Interaction Diagram) 의 종류 : 순차, 통신, 상호작용 개요, 타이밍 다이어그램
유스 케이스 다이어그램 (Use case Diagram)
사용자 관점에서 시스템 행위를 표현한다.
활동 다이어그램 (Activity Diagram)
업무 처리 과정이나 연산이 수행되는 과정을 표현한다.
콜라보레이션 다이어그램 (Collaboration Diagram)
순차 다이어그램(Sequence Diagram)과 같으며 모델링 공간에 제약이 없어 구조적인 면을 중시한다.
상태 머신 다이어그램 (State Machine Diagram)
객체의 생명주기를 표현한다.
순차 다이어그램 (Sequence Diagram)
시간 흐름에 따른 객체 사이의 상호작용을 표현한다.
통신 다이어그램 (Communication Diagram)
객체 사이의 관계를 중심으로 상호작용을 표현한다.
상호작용 개요 다이어그램 (Interaction Overview Diagram)
여러 상호작용 다이어그램 사이의 제어 흐름을 표현한다.
타이밍 다이어그램 (Timing Diagram)
객체 상태 변화와 시간 제약을 명시적으로 표현한다.
section05.디자인 패턴
1. 디자인 패턴
소프트웨어 개발 중 나타나는 과제를 해결하기 위한 방법 중 한가지
자주 사용하는 설계 형태를 정형화하여 유형별로 설계 템플릿을 만들어 둔 것을 의미
2. GoF(Gang of Four) 디자인 패턴
에릭 감마(Eric Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 브리시데스(John Vlissides)가 제안
객체지향 설계 단계 중 재사용에 관한 유용한 설계를 디자인 패턴화하였다.
생성패턴, 구조패턴, 행위패턴으로 분류
(1) 생성 패턴
객체를 생성하는 것과 관련된 패턴
객체의 생성과 변경이 전체 시스템에 미치는 영향을 최소화하도록 만들어주어 유연성을 높일 수 있고 코드를 유지하기 쉬운 편
- ( ① )은 구현부에서 추상층을 분리하여 각자 독립적으로 변형이 가능하고 확장이 가능하도록 합니다. 즉 기능과 구현에 대해서 두 개를 별도의 클래스로 구현을 합니다. - ( ② ) 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고, 자동으로 내용이 갱신되는 방식의 패턴이다.
- 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴 - 요청을 처리할 수 있는 각 객체들이 고리(chain)로 묶여 있어 요청이 해결될 때까지 고리를 따라 책임이 넘어감
Iterator (반복자)
- 자료 구조와 같이접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴 - 내부 표현 방법의 노출 없이 복합 객체의 원소를 순차적으로 접근할 수 있는 방법 제공
Command (명령)
- 요청을 객체의 형태로 캡슐화하여재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴 - 요청에 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화함
Interpreter (해석자)
-언어의 문법 표현을 정의하는 패턴 - SQL 이나 통신 프로토콜과 같은 것을 개발할 때 문법 규칙을 클래스화한 구조
Memento (기록)
- 특정 시점에서의객체 내부 상태를 객체화함으로써 이후 요청에 따라객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴 - Ctrl+Z와 같은 되돌리기 기능을 개발할 때 주로 이용
Observer (감시자)
-한 객체의 상태가 변하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴 - 객체 사이에 일대다의 존속성을 정의
State (상태)
-객체의 내부 상태에 따라동일한 동작을 다르게 처리해야 할 때 사용하는 패턴,행위를 변경할 수 있게 함 - 이렇게 하면 객체는 마치 클래스를 바꾸는 것처럼 보인다.
Strategy (전략)
-동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴 - 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향 없이 알고리즘의 변경이 가능함 - 즉, 클라이언트에게 알고리즘이 사용하는 데이터나 그 구조를 숨겨주는 역할을 한다.
Visitor (방문자)
- 각 클래스들의 데이터 구조에서처리 기능을 분리하여 별도의 클래스로 구성하는 패턴 - 즉, 객체 구조의 요소들에 수행할 오퍼레이션을 표현한 패턴 - 분리된 처리 기능은 각 클래스를 방문(visit)하여 수행함 - 오퍼레이션이 처리할 요소의 클래스를 변경하지 않고도 새로운 오퍼레이션을 정의할 수 있게 함
Template Method
-상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴 - 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드의 양 축소, 유지보수 용이
Mediator (중재자)
-수많은 객체들 간의 복잡한 상호작용(interface)을 캡슐화 하여 객체로 정의하는 패턴 - 객체 간의 통제와 지시의 역할을 하는 중재자를 두어 객체지향의 목표를 달성하게 해줌 - 객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있음
