I. 요구사항 확인_01. 소프트웨어 개발방법론

SDLC : Software Development Life Cycle, 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

요구사항 분석 - 설계 - 구현 - 테스트 - 유지보수

 

- 폭포수 모델 : Waterfall, 소프트웨어 개발시 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어가는 모델

가장 오래된 모델

선형 순차적 모형으로 고전적 생명주기 모형이라고 함

모형의 적용 경험과 성공 사례가 많음

단계별 정의와 산출물이 명확

요구사항 변경이 어려움

 

- 프로토타이핑 모델 : 고객이 요구한 주요 기능을 프로토타입(시제품)으로 구현하여 고객의 피드백을 반영하여 소프트웨어를 만들어 가는 모델

발주자나 개발자 모두에게 공동의 참조 모델 제공

구현 단계의 구현 골격

 

- 나선형 모델 : 시스템 개발시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델

계획 및 정의 -> 위험분석 - 개발 - 고객평가

 

- 반복적 모델 : 구축 대상을 나누어 병력적 개발후 통합, 반복적 개발후 점증완성시키는 SDLC 모델, 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델

 

= 구조적 방법론 : 전체시스템을 기능에 따라 나누어 개발하고 이를 통합하는 분할과 정복 접근 방식의 방법론, 프로세스 중심의 하향식 방법론, 구조적 프로그래밍 표현을 위한 나씨-슈나이더만 차트 사용

  나씨슈나이더만 : 논리의 기술에 중점을 둔 도형식 표현 방법, 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현, 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는데 적합, 순차처리구조, 선택구조, 반복구조가 있음

 

= 정보공학 방법론 : 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론, 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론

 

= 객체지향 방법론 : '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론, 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론, 객체, 클래스, 메시지 사용

 

= 컴포넌트 기반 방법론 : 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론, 개발 기간 단축으로 인한 생산성 향상, 새로운 기능추가 쉬움(확장성), 소프트웨어 재사용 가능

 

= 애자일(Agile) 방법론 : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응형 경량 개발방법론, 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론, 개발과 함께 즉시 피드백을 받아 유동적으로 개발

  구성도 : 

  등장배경 : 기존 개발방법론의 한계 극복

  특징 : 프로젝트의 요구사항은 기능중심으로 정의, 절차와 도구보다 개인과 소통 중시, 짧은 작업 계획으로 변화에 유연하고 신속하게 대응, 소프트웨어가 잘 실행되는데 가치를 둠, 고객과의 피드백 중시

 

= 제품계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론, 임베디드 소프트웨어를 작성하는데 유용한 방법론, 영역공학(Domain)과 응용과학(Application)으로 구분

 

= XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

  특징 : 1-3주의 반복(Iteration) 개발 주기, 5가지 가치와 12개의 실천 항목 존재

  5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존중

  12가지 기본원리

짝 프로그래밍	개발자 둘이서 짝으로 코딩하는 원리
공동 코드 소유	시스템에 있는 코드는 누구나 언제든 수정가능하다는 원리 git, svn
지속적 통합(CI)	매일 여러번씩 소프트웨어를 통합하고 빌드해야한다는 원리
계획 세우기	고객의 요구에 대한 비즈니스 가치 정의하여 개발자가 필요한 것과 어떤 부분에서 지연될 수 있는지 알려주어야 하는 원리
작은 릴리즈	작은 시스템을 먼저 만들고 짧은 단위로 업데이트하는 원리
메타포어	공통적인 이름체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활히 하는 원리
간단한 디자인	현재의 요구사항에 적합한 가장 단순한 시스템을 설계하는 원리
테스트기반 개발(TDD)	작성해야하는 프로그램에 대한 테스트를 먼저 수행, 이 테스트를 통과하도록 실제 프로그램의 코드를 작성하는 원리
리팩토링	프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템을 재구성하는 원리
40시간 작업	피곤으로 인해 실수하지 않도록 주 40시간 이상 일하지 않는 원리
고객 상주	개발자들의 질문에 즉각 답이 가능한 고객을 프로젝트에 풀타임으로 상주시켜야하는 원리
코드 표준	효과적인 공동작업을 위해서는 모든 코드에 대한 코딩 표준을 정의하는원리

 

스크럼 : 매일 정해진 시간과 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론, 백로그(요구사항), 스프린트(반복기간), 스크럼 미팅(데일리 미팅), 스크럼 마스터(리더), 스프린트 회고, 번다운 차트

 

린 : 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거, 품질을 향상시킨 방법론

 

	애자일 방법론	전통적 방법론
계획수립	유동적 범위 설정	확정적 범위 설정
업무수행	팀 중심 업무 수행	관리자 주도적 명령과 통제 개인 단위로 업무수행
개발/검증	반복 주기 단위로 소프트웨어를 개발/검증	본석/설계/구현/테스트를 순차적으로 수행
팀관리	업무 몰입, 팀 평가	경쟁, 개별 평가
문서화	문서보다는 코드 강조	상세한 문서화 강조
성공요소	고객 가치 전달	계획/일정 준수
유형	XP, 스크럼, 린	폭포수, 프로토타입, 나선형

 

객체지향 : 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 방법

클래스 (Class)	특정 객체 내에 있는 변수와 메서드를 정의하는 일종의 틀 객체 지향 프로그래밍에서 데이터를 추상화하는 단위 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성 표현 속성은 변수형태, 행위는 메서드 형태로 선언
객체 (Object)	물리적, 추상적으로 자신과 다른것을 식별 가능한 대상 클래스에서 정의한 것을 토대로 메모리에 할당 객체마다 각각의 상태와 식별성을 가진
메서드 (Method)	클래스로부터 생성된 객체를 사용하는 방법 객체가 메시지를 받아 실행해야할 객체의 구체적인 연산 전통적 시스템의 함수(Function) 또는 프로시저(Procedure)에 해당하는 연산 기능
메시지 (Message)	객체간 상호작용을 위한 수단 객체에게 어떤 행위를 하도록 지시하는 방법 객체간의 상호작용은 메시지를 통해 이루어짐 메시지는 객체에서 객체로 전달
인스턴스 (Instance)	객체 지향 기법에서 클래스를 통해 만든 실제의 실형 객체 클래스에 속한 각각의 객체 실제로 메모리상에 할당
속성 (Property)	한 클래스내에 속한 객체들이 가진 데이터값을 단위별로 정의 성질, 분류, 식별, 수향, 현재 상태 등에 대한 표현 값

 

객체지향 기법

캡슐화 (Encapsulation)	서로 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로 드러내는 기법 결합도가 낮아지고 재사용 용이 정보 은닉과 관계가 깊음 변경 발생시 오류의 파급 효과가 적음
상속성 (Inheritance)	상위 클래스의 속성과 메서드를 하위 클래스에서 재정의없이 물려받아 사용하는 기법
다형성 (Polymorphism)	하나의 메시지에 대해 각 개체가 가진 고유한 방법으로 응답할 수 있는 능력 상속받은 여러개의 하위객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질
추상화 (Abstraction)	공통 성질을 추출하여 추상 클래스를 설정하는 기법
정보은닉 (Information Hiding)	코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근가능하게 하는 코드 보안 기술 불필요한 정보는 접근불가하도록 하여 한 모듈 또는 하부 시스템이 다른 모듈의 구현에 영향을 받지 않게 설계됨(고려되지 않은 영향인 side-effect 최소화)
관계성 (Relationship)	두개 이상의 엔티티형에서 데이터를 참조하는 관계를 나타내느 기법

 

객체지향 설계 원칙(SOLID)

단일 책임의 원칙 (SRP, Single Responsibility Principle)	하나의 클래스는 하나의 목적을 위해 생성, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는데 집중되어 있어야 한다는 원칙 객체 지향 프로그래밍의 5원칙 중 나머지 4원칙의 기초 원칙
개방 폐쇄 원칙 (OCP, Open Close Principle)	소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열리고 변경에는 닫혀야 한다는 원칙
리스코프 치환의 목적 (LSP)	서브타입(상속받은 하위 클래스)는 어디서나 자신의 기반 타입(상위 클래스)로 교체할 수 있어야 한다는 원칙
인터페이스 분리의 원칙 (ISP, Interface Segregation Principle)	한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙 객체 설계시 특정 기능에 대한 인터페이스는 그 기능과 상관없는 부분이 변해도 영향을 받지 않아야 한다는 원칙
의존성 역전의 원칙 (DIP, Dependency Inversion Principle)	실제 사용 관계는 바뀌지 않으며 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

 

객체지향 분석 : 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의하여 모델링 하는 기법, OOA(Object Oriented Analysis)

객체지향 방법론

OOSE (Obect Oriented software Engineering)	야콥슨, 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 사용
OMT (Object Modeling Technology)	럼바우, 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론 객체지향 분석 절차(객동기)
OOD (Object Oriented Design)	부치, 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론
Coad와 Yourdon 방법론	ER다이어그램을 사용하여 객체의 행위를 모델링, 객체식별, 구조식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등 과정으로 구성되는 객체지향 분석 방법
Wirfs-Brock 방법론	분석, 설계간의 구분업싱 고객명세서를 평가해서 설계작업까지 연속적으로 수행하는 분석 방법

 

OMT 분석절차

겍체 모델링 (Object Modeling)	정보 모델링(Information Modeling)이라고도 함 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링 객체 다이어그램을 활용하여 표현
동적 모델링 (Dynamic Modeling)	시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링 상태 다이어그램을 활용하여 표현
기능 모델링 (Functional Modeling)	프로세스들의 자료 흐름을 중심으로 처리 과정을 표현하는 모델링 자료흐름도(DFD)를 활용하여 표현

 

데이터 흐름도(DFD, Data Flow Diagram) : 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림, 시스템 분석과 설계에서 매우 유용하게 사용되는 다이어그램, 자료흐름 그래프 또는 버블(Bubble)차트라고도 함

데이터 흐름도 특징 : 구조적 분석 기법에 이용, 데이터(Data)의흐름에 중심을 두는 분석용 도구, 제어(Control)의 흐름은 중요하지 않음, 시간 흐름을 명환하게 표현할 수 없음

 

자료사전(DD, Data Dictionary) : 자료요소, 자료요소들의집합, 자료의흐름, 자료 저장소의 의미와 그들 간의 관계, 관계값, 범위, 단위들을 구체적으로 명시하는 사전, 파일 혹은 데이터베이스에 있는 자료에 대한 자료 또는 각 자료 항목에 주어진 이름과 길이, 서술과 같은 데이터를 포함하는 참조를 위한 작업 

자료사전의 작성 목적 : 조직에 속해있는 다른 사람들에게 특정한 자료 용어가 무엇을 의미하는지를 알려주기 위해 용어의 정의를 조정, 취합하여 문서로 명화깋 하는 목적, 자료 흐름도에 나타나는 어떤 자료의흐름도 자료 사전에 정의되어 있어야 함

 

프로젝트 관리 : 주어진 기간내 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기위한 전반적인 활동

프로젝트 관리 대상

계획 관리	프로젝트 계획, 비용산정, 일정계획, 조직계획에 대한 관리
품질 관리	품질 통제 및 품질 보증
범위 관리	이해관계자가 요청한 모든 요구사항이 프로젝트 범위에 포험되었는지 보장하고 필요한 작업만 수행될수 있도록 관리 범위 관리 프로세스에는 범위 관리 계획 수립, 요구사항 수립, 범위 정의, 작업 분류체계(WBS)작성, 범우확인, 범위 통제가 있음

 

3대요소(3P)

사람, People	프로젝트 관리에서 가장 기본이 되는 인적자원
문제, Problem	사용자의 입장에서 문제를 분석하여 인식함
프로세스, Process	소프트웨어 개발에 필요한 전체적인 작업 계획 및 구조

 

비용산정 모델 : 소프트웨어 규모파악을 위한 투입자원, 소요시간을 파악하여 실행가능한 계획을 수립하기 위해 비용을 산청하는 기법

하향식 산정방법	경험이 많은 전문가에게 비용 산정을 의뢰하거나 요러 전문가와 조정자를 통해 산정하는 방식	전문가 판단 델파이 기법
사향식 산정방법	세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식	코드라인 수(LOC, Lines of Code) Man Month COCOMO 모형 Putnam 모형 FP(Function Point) 모형

 

LOC :  소프트웨어 각 기능의 원시 코드라인수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용 산정, 측정이 쉽고 이해하기 쉬워 많이 사용, 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용 산정

Man Month : 한사람이 1개월동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 기법

Man Month = LOC/프로그래머의 월간 생산성
프로젝트 기간 = Man Month/프로젝트 인력

COCOMO(Constructive Cost Model) : 보헴이 제안한 모형으로 프로그램 규모에 따라 비용 산정, 비용산정 결과는 프로젝트를 완성하는데 필요한 노력(Man-Month)로 산정, 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용

조직형(단순형, 기본형)	반분리형(중간형)	임베디드 형
Organic Mode	Semi-Detached Mode	Embedded Mode
과학기술 계산용 자료 처리 개발	트랜잭션 처리 시스템, DBMS, 컴파일러/인터프리터	초대형 규모 트랜잭션 처리 시스템, 운영체제, 시스템 프로그램 개발

 푸트남 모형 : 소프트웨어 개발 주기의 각 단계별로 요구할 인력의 분포를 가정하는 모형, 푸트남이 제안한 것으로 생명주기 예측모형, 시간에 따른 함수로 표현되는 Rayleigh-Norden의 노력분포도를 기초로 함

기능점수(FP, Function Point) : 요구기능을 증가시키는 인자별로 가중치를 부여하고 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식, 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치 부여

기능점수(FP) = 총 기능점수 * [0.65 + (0.1 * 총영향도)]

일정관리 모델 : 프로젝트가 일저익한내 적절하게 완료되도록 관리하는 모델

주 공정법 (CPM, Critical Path Method)	여러 작업의 수행 순서가 얽혀있는 프로젝트의 일정을 계산하는 기법 모든 자원 제약사항을 배제한 상태로 프로젝트의 시작과 끝을 나타내는 노드와 노드간을 연결하여 공정을 계산하기 위한 액티비티 표현법
PERT (Program Evaluation & Review Technique)	일의 순서를 계획적으로 정리하기 위한 수렴기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법
중요 연쇄 프로젝트 관리	주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법

 

위험관리 : 프로젝트에 내재된 요소를 인식하고 그 영향을 분석하여 이를 관리하는 활동, 프로젝트를 성공시키지 위해 위험 요소를 사전에 예측, 대비하는 모든 기술과 활동

알려진 위험	프로젝트 계획서, 기술적 환경, 정보 등에 의해 발견될 수 있는 위험
예측가능한 위험	과거 경험으로부터 예측할 수 있는 위험
예측불가능한 위험	사전 예측이 매우 어려운 위험

위험 대응 전략 : 회피, 전가, 완화, 수용