[요구사항확인] 01. 소프트웨어 개발방법론

 

 

 

01. 소프트웨어 개발방법론

---

 

 

 

 

 

1. SDLC 

 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

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

 

2. 폭포수 모델(waterfall)

 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델

 - 가장 오래된 모델

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

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

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

 - 요구사항 변경이 어려움

 

3. 프로토타이핑 모델(prototyping)

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

 - 프로토타입은 발주자나 개발자 모두에게 공동의 참조 모델을 제공

 - 프로토타입은 구현 단계의 구현 골격

 

4. 나선형 모델(spiral)

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

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

 

5. 반복적 모델(interation)

 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델

 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델

 

6. 소프트웨어 생명주기 모델 종류

 - 폭프나반(폭포수 모델 / 프로토타이핑 모델 / 나선형 모델 / 반복적 모델)

 

7. 구조적 방법론 개념

 - 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론

 - 프로세스 중심의 하향식 방법론

 - 구조적 프로그래밍 표현을 위해 나씨- 슈나이더만 차트 사용

 

8. 나씨 슈나이더만

 - 논리의 기술에 중점을 둔 도형식 표현 방법

 - 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현

 - 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합

 

9. 정보공학 방법론

 - 정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론

 - 개발 주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론

 

10. 객체지향 방법론

 - '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론

 - 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론

 - 객체, 클래스, 메시지를 사용

 

11. 컴포넌트 기반 방법론 개념

 - 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론

 - 개발 기간 단축으로 인한 생산성 향상

 - 새로운 기능 추가 쉬운(확장성)

 - 소프트웨어 재사용이 가능

 

12. 애자일(Agile) 방법론

 소프트웨어 개발방법론의 하나로서 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법

 - 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발방법론

 - 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론

 애자일 방법론 등장 배경

 - 기존 개발방법론의 한계를 극복하기 위해 등장

 

 애자일 방법론 특징

 - 프로젝트의 요구사항은 기능 중심으로 정의한다.

 - 절차와 도구보다 개인과 소통을 중요하게 생각한다.

 - 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응할 수 있다.

 - 소프트웨어가 잘 실행되는데 가치를 둔다.

 - 고객과의 피드백을 중요하게 생각한다.

 

13. 제품 계열 방법론 개념

 - 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론

 - 임베디드 소프트웨어를 작성하는데 유용한 방법론

 - 영역 공학(Domain)과 응용 공학(Application)으로 구분

 

14. XP

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

 - 1~3주의 반복(Iteration) 개발 주기

 - 5가지 가치와 12개의 실천 항목이 존재

 - 용단의 피존(용기 / 단순성 / 의사소통 / 피드백 / 존중)

 

15. XP 12가지 기본 원리

 1) 짝 프로그래밍

   - 개발자 둘이서 짝으로 코딩하는 원리

 2) 공동 코드 소유

   - 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리

 3) 지속적인 통합(CI)

   - 매일 여러 번씩 소프트웨어를 통합하고 빌드해야한다는 원리

 4) 계획 세우기

   - 고객이 요구하는 비즈니스 가치를 정의하고 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리

 5) 작은 릴리즈

   - 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리

 6) 메타포어

   - 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리

 7) 간단한 디자인

   - 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리

 8) 테스트 기반 개발(TDD)

   - 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리

 9) 리팩토링

   - 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리

 10) 40시간 작업

   - 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리

 11) 고객 상주

   - 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리

 12) 코드 표준

   - 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리

 

16. 스크럼

 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

 스크럼 주요요소 - 백로그(요구사항), 스프린트(반복기간), 스크럼 미팅(데일리 미팅),

                           스크럼 마스터(리더), 스프린트 회고, 번다운 차트

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

 

17. 애자일과 전통적 방법론 비교

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

 

18. 객체지향

 실세계의 개체를 속성(값)과 메서드(연산)가 결합한 형태의 객체로 표현하는 기법

 객체지향 구성요소

 - 클객 메메 인속

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

 

19. 객체지향기법

 캡상다추정관

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

 

20. 객체 지향 설계 원칙(SOLID)

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

 

21. 객체 지향 분석 개념(OOA; Object Oriented Analysis)

OOSE (Object Oriented Sofrware Engineering)	· 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용 · 야콥슨이 만듬
OMT (Object Modeling Technology)	· 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론 · 객체지향 분석 절차(객동기) · 럼바우가 만듬
OOD (Object Oriented Design)	· 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론 · 부치가 만듬

 

22. OMT 분석 절차

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

 

23. 객체지향 방법론 종류

  Coad와 Yourdon 방법론은 E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석 방법

  Wirfs-Brock 방법론은 분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 분석 방법

 

24. 데이터 흐름도(DFD, Data Flow Diagram)

  데이터 흐름도 개념

   · 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림

   · 시스템 분석과 설계에서 매우 유용하게 사용되는 다이어그램

   · 자료 흐름 그래프 또는 버블(Bubble) 차트라고도 함  

  데이터 흐름도 특징

   · 구조적 분석 기법에 이용됨

   · 데이터(Data)의 흐름에 중심을 두는 분석용 도구

   · 제어(Control)의 흐름은 중요하지 않음

   · 시간 흐름을 명확하게 표현할 수는 없음

 

25. 자료 사전(DD; Data Dictionaty) 개념

  자료 사전 개념

   ·  자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들 간의 관계, 관계 값, 범위, 단위들을 구체적으로 명시하는 사전

   · 파일 혹은 데이터베이스에 있는 자료에 대한 자료 또는 각 항목에 주어진 이름과 길이 그리고 서술과 같은 데이터를 포함하는 참조를 위한 작업

  자료 사전의 작성 목적

   · 조직에 속해 있는 다른 사람들에게 특정한 자료 용어가 무엇을 의미하는지를 알려주기 위하여, 용어의 정의를 조정하고 취합하고 문서로 명확히 하는 목적이 있음

   · 자료 흐름도에 나타나는 어떤 자료의 흐름도 자료 사전에 정의되어 있어야 함

 

26. 프로젝트 관리 개념

 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시슽메을 개발하기 위한 전반적인 활동

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

 

27. 3대 요소(3P)

 1) 사람(People)

   프로젝트 관리에서 가장 기본이 되는 인적 자원

 2) 문제(Problem)

   사용자의 입장에서 문제를 분석하여 인식함

 3) 프로세스(Process)

   소프트웨어 개발에 필요한 전체적인 작업 계획 및 구조

 

28. 비용 산정 모델

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

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

 

29. LOC; Lines Of Code개념

 - 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정

 - 측정이 쉽고 이해하기 쉬워 많이 사용

 - 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정

• 예측치 = ( 낙관치 + 4 * 기대치 + 비관치 ) / 6

 - 낙관치(O) : 가장 적게 측정된 코드 라인 수

 - 중간치(M) : 측정된 모든 코드 라인 수의 평균

 - 비관치(P) : 가장 많이 측정된 코드 라인 수

 

 

30. Man Month 

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

 Man Month = LoC / 프로그래머의 월간 생산성

 프로젝트 기간 = Man Month / 프로젝트 인력

 

31. COCOMO(Constructive Cost Model)

 - 보헴이 제안한 모형으로 프로그램 규모에 따라 비용을 산정

 - 비용 산정 결과는 프로젝트를 완성하는데 필요한 노력(Man-Month)으로 산정

 - 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용

 - 규모에 따라 유형이 조직형(단순형,기본형), 반분리형(중간형), 임베디드형으로 나뉨

 

32. 푸트남 모형 개념

 - 소프트웨어 개발 주기의 각 단계별로 요구할 인력의 분포를 가정하는 모형

 - 푸트남이 제안한 것으로 생명주기 예측 모형이라고 함

 - 시간에 따른 함수로 표현되는 Rayleigh - Norden의 노력 분포도를 기초로 함

 

33. 기능 점수 개념

 - 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식

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

 - 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여

 

34. 일정관리 모델 개념

 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델

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

 

35. 위험 관리 개념

 프로젝트에 내재된 위험 요소를 인식하고 그 영향을 분석하여 이를 관리하는 활동

 프로젝트를 성공시키기 위하여 위험 요소를 사전에 예측, 대비하는 모든 기술과 활동을 포함

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

위험 대응 전략

   회전 완수 - 회피 / 전가 / 완화 / 수용