1. 소프트웨어 프로젝트 계획 단계
- 노력 추정 : COCOMO, 기능점수(FD) 모델
- 일정 계획 : WBS, CPM, 간트 차트
- 조직 계획 : 책임프로그래머 팀, 분산형 팀, 혼합형 팀
2. 노력 추정 - 기능 점수(FD)
기능점수는 소프트웨어 시스템이 가지는 기능을 정량화 한 것이다.
기존의 COCOMO, LOC/MM 에서 사용했던 원시 코드 라인 수의 부정확함을 개선하기 위해
라인수에 의존하지 않고 입출력의 개수, 기능의 개수, 기능의 복잡도에 따라
점수를 매겨 노력(비용)을 추정한다.
소프트웨어 개발 생명주기의 전체 단계에서 사용 가능하다.
트랜잭션의 기능을 측정하기 위한 기준으로 외부입력, 외부출력, 외부 조회가 있다
3. CPM
프로젝트를 완료할 수 있는 가장 빠른 시간을 구할 수 있다.
C 작업의 착수일을 살펴보면...
| 소작업 | 선행 작업 | 소요 기간(일) |
| A | X | 15 |
| B | X | 10 |
| C | A,B | 10 |
| D | B | 25 |
| E | C | 15 |
가장 빠른 착수일은 A 작업이 끝나자마자 시작할 수 있으므로 15일이다.
가장 늦은 착수일은 전체 시간 40에서 C의 작업 시간과 E의 작업시간을 빼면 40-25=15일이다
여유 기간은 가장 늦은 착수일에서 가장 빠른 착수일을 뺀 값이므로 15-15=0일이다.
4. 소프트웨어 프로젝트 분석 단계
구조적 분석은 다음과 같은 세부 작업의 순서로 진행된다.
- 배경도 작성
- 상위 자료 흐름도 작성
- 하위 자료 흐름도 작성
- 자료 사전 작성
- 소단위 명세서 작성
- 자료 흐름도(DFD)는 기능 중심의 시스템 모델링에 적합하며, 프로세스 흐름, 자료 저장소, 자료 출처와 도착지의 네가지 요소로 구성된다.
- 자료사전은 자료 흐름도에 있는 자료 흐름이나 자료 저장소들의 의미를 서술한다.
- 소단위 명세서는 자료 흐름도의 최하위 프로세스가 어떤 기능을 하는가를 기술한 것이다. 의사 결정표, 구조적 영어, 전후 조건 등의 방법으로 명세화 한다.
자료흐름도(DFD)
자료사전(DD)
이미지 출처 https://blog.naver.com/kyong_b/221669939370
소프트웨어공학 - 구조적 분석도구(DFD, DD, ERD)
1. 자료흐름도(Data Flow Diagram, 자료 흐름 그래프, 버블 차트) 요구사항 분석에서 자료의 흐름 및 변...
blog.naver.com
구조적 분석에서는 자료흐름도, 자료사전, 소단위 명세서를 사용한다.
구조적 설계에서는 구조도, HIPO, NS-CHART를 사용한다
객체지향 분석에서는 사용사례 다이어그램을 사용한다(유스케이스)
객체지향 설계에서는 순서 다이어그램, 상태 다이어그램, 액티비티 다이어그램, 클래스 다이어그램을 사용한다.
5. 결합도(Coupling)와 응집도(Cohesion)
결합도와 응집도란 모듈의 독립성을 판단하는 요소이다.
결합도는 모듈 사이의, 응집도는 모듈 내부의 관련성을 의미하며
결합도는 낮을수록, 응집도는 높을수록 이상적인 모듈화이다.
- 이상적인 응집 : 기능적 응집
- 이상적인 결합 : 자료 결합
| 기능적 응집도 | 한 모듈이 작업 |
| 순차적 응집도 | 한 소작업에 대한 결과가 다른 작업의 입력 |
| 교환적 응집도 | 동일한 입력과 출력 |
| 절차적 응집도 | 작업들이 특정한 순서대로 수행 |
| 시간적 응집도 | 한 번만 수행 |
| 논리적 응집도 | 유사성격 작업을 한 모듈로 구성, 선택 수행 |
| 우연적 응집도 | 아무 관계없는 처리 요소들로 모듈 형성 |
| 자료 결합도 | 자료 요소로만 구성 |
| 스탬프 결합도 | 배열, 레코드 등 자료구조가 전달 |
| 제어 결합도 | 제어요소 전달(스위치, 태그 등) |
| 외부 결합도 | 외부에 있는 다른 모듈 참 |
| 공통 결합도 | 공동 자료 영역을 사용 |
| 내용 결합도 | 한 모듈이 다른 모듈의 일부분을 직접 참조 또는 수정 |
6. UP 프로세스
UP(Unified Process) 프로세스는 소프트웨어 개발 방법론 중 하나로,
객체지향 소프트웨어 개발을 위한 구조화된 프레임워크이다.
UP는 개발 과정을 반복적이고 점진적으로 진행하여 소프트웨어의 품질을 높이고, 리스크를 줄이는 것을 목표로 한다.
4단계의 생애주기
- 도입(Inception) 단계:
- 프로젝트의 목표와 범위를 정의하고, 초기 요구 사항을 수집합니다.
- 주요 리스크를 식별하고, 프로젝트가 실행 가능한지 평가합니다.
- 상세(Elaboration) 단계:
- 시스템의 아키텍처를 정의하고, 주요 요구 사항을 명확히 합니다.
- 리스크를 줄이기 위한 프로토타입 또는 핵심 기능을 개발합니다.
- 구축(Construction) 단계:
- 소프트웨어의 실제 개발이 이루어지며, 대부분의 기능이 구현됩니다.
- 반복적인 개발을 통해 완전한 시스템으로 발전시킵니다.
- 전이(Transition) 단계:
- 소프트웨어를 실제 사용자에게 배포하고, 테스트와 피드백을 통해 최종적으로 개선합니다.
7. 디자인 패턴
소프트웨어를 설계할 때 특정 상황에서 자주 사용하는 패턴을 정형화 한 것이며, 좋은 소프트웨어 설계를 위한
개발자들의 경험적 산물이다.
생성, 구조, 행위 중 한가지의 목적을 갖는다.
- 생성 패턴 : 객체의 생성과 변경이 전체 시스템에 미치는 영향을 최소화 한다
- 구조 패턴 : 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램 구조를 설계하는데 많이 활용된다
- 행위 패턴 : 반복적으로 사용되는 객체들의 상호작용을 패턴화 한 것이다
<생성>
| 팩토리 메소드 패턴 | 상위 클래스에서 객체 생성, 하위 클래스에서 인스턴스 생성 |
| 싱글톤 패턴 | 특정 클래스의 객체가 오직 한개만 존재하도록 보장 |
| 프로토타입 패턴 | 일반적인 원형을 만들어놓고 복사하여 필요한 부분만 수정 |
| 빌더 패턴 | 복잡한 인스턴스 조립 |
| abstract 패턴 | 클래스 집합의 종류를 지정하여 관련된 객체 집합 생성 |
<구조>
| composite 패턴 | 사용자가 단일 객체, 복합 객체 모두 동일하게 다룬다 |
| adapter 패턴 | 기존 클래스를 재사용할 수 있도록 중간에서 맞춰준다. 즉 호환성이 없는 기존 클래스의 인터페이스를 변환해 재사용할 수 있도록 해준다 |
| bridge 패턴 | 클래스 계층과 구현의 클래스 계층을 연결하고 구현부에서 추상 계층을 분리하여 각자 독립적으로 변형할 수 있게 해준다 |
| decorator 패턴 | 기존에 구현된 클래스에 그때 그때 필요한 기능 추가 |
| facade 패턴 | 클라이언트 사이에 facade라는 객체를 전면에 세워놓아서 단순한 인터페이스를 제공한다 |
| flyweight 패턴 | 메모리 사용량을 줄이기 위한 방법 |
| proxy 패턴 | 다른 무언가와 이어지는 인터페이스 역할 |
<행위>
| iterator 패턴 | 반복이 필요한 자료구조(배열, 리스트, map) |
| observer 패턴 | 어떤 클래스에 변화가 일어났을때 이를 감지하여 다른 클래스에 통보 |
| strategy 패턴 | 클라이언트와 무관하게 독립적으로 알고리즘 변경 |
| visitor 패턴 | 데이터 구조로부터 처리 기능을 분리해 별도의 visitor 클래스로 만들어놓는다 |
| chain of responsibility 패턴 | 내가 책임 못질것 같으면 다음 책임자에게 넘김 |
| mediator 패턴 | 중간에 통제하고 지시하는 중재자를 둔다 |
| state 패턴 | 동일한 동작을 객체에 따라 다르게 처리해야 할때 |
| command 패턴 | 함수 오버로딩과 같은 추상화 개념 |
| memento 패턴 | undo 기능을 개발할 때 |
8. UML 다이어그램
프로그램 설계를 표현하기 위해 사용하는 주로 그림으로 표시된 표기법이다.
- 유스케이스 다이어그램 : 시스템이 어떤 기능을 수행하고 어떤 것이 관련되어 있는지 *반드시 선행되어야.. -> 포함(include) 관계
- 순차(시퀀스) 다이어그램 : 객체 간의 메시지 통신
- collaboration 다이어그램 : 관련 객체 간의 연관성 분석
- 클래스 다이어그램 : 객체와 클래스 속성 오퍼레이션 및 연관관계를 이용, 정적인 구조
- 패키지 다이어그램
- 상태(state) 다이어그램 : 객체 내의 동적 행위를 모형, 객체 내부의 자세한 행동
- 액티비티 다이어그램 : 시스템의 흐름 전체 파악, 동적 특징
- 컴포넌트 다이어그램 : 각 컴포넌트와 그들 간의 의존성 관계
- 배치 다이어그램
상태 다이어그램, 시퀀스 다이어그램은 시스템의 동적인 측면을
클래스 다이어그램, 패키지 다이어그램, 배치 다이어그램은 시스템의 정적인 측면을 다룬다
기능 관점 : 자료흐름도 사용
동적 관점 : 상태변화도, 사건추적도, 페트리넷 사용
정보 관점 : ER 모델을 사용하여 시스템 DB 분석, 정적인 정보 구조 포착
9. 소프트웨어 테스트
단위 테스트 -> 통합 테스트 -> 시스템 테스트
- 단위 테스트는 개별적인 모듈에 대한 테스트이며 테스트 드라이버와 테스트 스텁을 사용한다.
- 통합 테스트는 모듈을 통합하는 방식에 따라 빅뱅 기법, 하향식 기법, 상향식 기법을 사용한다. 트리 구조의 모듈 구성도에서 아래로 통합하며 테스트하는 것은 깊이 우선, 행 우선으로 통합하는 것은 너비 우선 방식이라고 한다
- 빅뱅 통합은 모든 모듈을 한꺼번에 통합한 후 테스트, 결함 원인을 찾기 어렵다
- 상향식 통합은 최하위 모듈로부터 점차 상위 모듈 방향으로 통합하며 테스트, 드라이버 필요
- 하향식 통합은 점차 하위 모듈 방향으로 통합하며 테스트, 입출력을 대신해줄 스텁 필요
- 연쇄식 통합은 중요 모듈을 먼저 구현하고 통합한 뒤 보조적인 모듈을 점차 구현 후 통합하는 방식 (초기에 시스템의 골격을 보여준다)
- 시스템 테스트는 모든 모듈들은 하나의 시스템으로 작동하게 된다. 복구 테스트, 보안 테스트, 스트레스 테스트, 성능 테스트를 진행한다.
10. 소프트웨어 품질
소프트웨어 제품 품질 표준
ISO 9000, ISO 12207, CMMI, SPICE(ISO 15504)
CMMI 성숙도 모델
| 레벨 0(불완전) | 적용되는 소프트웨어 개발 프로세스가 없는 상태 |
| 레벨 1(초기) | 기본적 프로세스가 존재 |
| 레벨 2(관리) | 방침에 의해 계획되고 실행되는 수행 프로세스 |
| 레벨 3(정의) | 조직을 위한 표준 프로세스가 존재 |
| 레벨 4(정량적 관리) | 소프트웨어 프로세스와 품질에 대한 특성 정보가 정량적으로 수집되어 프로젝트의 계획 수립과 예측이 정량적으로 가능해진다 |
| 레벨 5(최적화) | 정량화된 프로세스 특정 정보를 이용하여 프로세스 개선 및 최적화 활동이 가능하다 |