JANGUN


소프트웨어 공학


지음 : 김희천



목차

제1장 소프트웨어 공학 개요
제2장 소프트웨어 프로세스
제3장 프로젝트 관리
제4장 소프트웨어 품질
제5장 소프트웨어 테스트
제6장 사용자 요구 분석
제7장 소프트웨어 설계
제8장 소프트웨어 유지보수
제9장 객체지향 분석과 설계
제10장 유스케이스 다이어그램 및 명세
제11장 액티비티 다이어그램
제12장 상호작용 다이어그램
제13장 클래스 다이어그램과 객체 다이어그램
제14장 상태 머신 다이어그램
제15장 기타 다이어그램 (컴포넌트, 패키지, 배포 다이어그램)


제1장 소프트웨어 공학 개요

- 소프트웨어는 무형의 인공물로 다른 공학 제품에 비해 변경이 용이하다.
- 소프트웨어 위기 현상은 소프트웨어 공학 기술의 후진성에 기인한다.
- 소프트웨어 공학의 정의는 소프트웨어의 개발, 운영, 유지보수에 체계적이고 숙달되고 정량화된 접근 방법을 적용하는 것이다.
- 소프트웨어 공학 환경은 최하위 층부터 소프트웨어 공학 원리, 방법과 기술, 방법론, 그리고 도구로 구성된다.
- 소프트웨어 개발 방법론이란 문제 해결을 위해 여러 방법들과 기술들이 정해진 프로세스 안에서 함께 묶인 것이다.
- 좋은 소프트웨어인가를 판단하는 기준으로는 신뢰도, 정확성, 성능, 사용성, 상호운용성, 유지보수성, 이식성, 검증성, 추적성 등이 있다.



제2장 소프트웨어 프로세스

- 소프트웨어 프로세스는 소프트웨어의 개발 또는 유지보수를 위해 수행되는 활동들의 절차이다.
- 프로세스 모델은 실제 프로세스의 추상화된 요약 표현으로 실제 프로세스의 골격이다.
- 폭포수 모델은 전통적 개발 모델로 기본적으로 각 단계에서 수행되는 활동들이 거슬러 반복됨 없이 한 방향으로 진행된다.
- 점증적 모델에서 소프트웨어는 요구사항의 중요도에 따라 여러 개의 모듈들로 분해되어 계획되고, 각각은 점증적으로 개발되어 인도된다.
- 애자일 개발 방법은 품질의 저하 없이 변화를 수용하고, 협업을 강조하며, 제품의 빠른 인도를 강조하는 반복적 방법이다.
- 익스트림 프로그래밍은 개발 주기의 잦은 반복과 짧은 배포 주기, 빠른 피드백, 이를 통한 지속적인 개선 등을 주장하는 방법이다.
- 테스트 선행 개발은 테스트케이스를 먼저 작성한 다음, 이것을 통과하는 코드를 만드는 것이다.



제3장 프로젝트 관리

- 프로젝트 관리자는 프로젝트를 계획하고 계획된 시간과 예산에 맞춰 개발이 진행되는지 감독해야 한다.
- 이정표는 개별 활동의 종료 시점 또는 주요 단계의 종료 시점에서 얻어지는 중간 산출물로 프로젝트 관리를 위해 필요하다.
- WBS는 개발 단계나 개발 업무를 분할하여 계층적으로 표현한다.
- CPM을 사용하여 개발 일정을 수립하고 간트 차트로 도표화 한다.
- 기능 점수 방법은 소프트웨어가 제공하는 기능을 계량화한 소프트웨어 규모의 척도이다.
- 중급 COCOMO는 프로그램의 규모 외에 비용 승수를 고려하여 노력과 비용을 추정한다.
- 상세 COCOMO는 개발 단계와 서브시스템 별로 구분하여 노력을 추정한다.
- 발생 가능한 위험 요인들을 예측하고 영향력을 분석하여 대책을 계획하고 감독하는 것을 위험 관리라고 한다.



제4장 소프트웨어 품질

- 소프트웨어 제품의 외부 품질 특성은 사용자 관점의 품질 특성이며, 내부 품질 특성은 개발자 관점의 특성이다.
- ISO / IEC 9126은 사용자 관점에서 제품의 품질 특성을 여섯 개로 분류하며 각각은 다시 여러 부 특성들로 구성된다.
- CMMI는 조직의 개발 프로세스 역량과 성숙도를 평가하는 모델로 프로세스 개선을 위한 프레임워크를 제공한다.
- CMMI 모델은 프로세스 성숙도와 개선을 위한 평가 부분을 여러 프로세스 영역들로 구분하였다.
- 소프트웨어 품질 보증은 사용자가 원하는 품질 수준을 보증하기 위해 수행하는 품질 관리 활동을 말한다.
- 확인과 검증(V&V)을 위해 정적인 검토 방법과 동적인 소프트웨어 테스트가 보완적으로 사용된다.
- 인스펙션은 설계 문서나 코드를 요구사항이나 표준과 비교 검사하여 오류를 찾아내는 조직화되고 형식을 갖춘 검토 방법이다.



제5장 소프트웨어 테스트

- 소프트웨어 테스트는 단계별로 단위 테스트, 통합 테스트, 시스템 테스트로 구분된다.
- 통합 테스트는 개별 모듈들을 통합하여 테스트하면서 시스템을 구축해 나가는 기술이다.
- 화이트박스 테스트에서는 프로그램의 구조에 기초하여 테스트케이스를 개발한다.
- 화이트박스 테스트에서 테스트케이스 선정 기준으로는 문장 검증 기준, 분기 검증 기준, 조건 검증 기준, 경로 검증 기준 등이 있다.
- 블랙박스 테스트에서는 동치 분할, 경계 값 분석, 원인-결과 그래프 방법 등을 사용하여 테스트 데이터를 개발한다.
- 성능 테스트는 평균 응답 시간이나 처리율 등의 성능 요인들을 파악하기 위한 테스트이다.
- 시스템으로 통합된 후 성능, 신뢰성, 안전성, 사용성 등의 비기능적 요구사항을 테스트한다.



제6장 사용자 요구 분석

- 요구 공학은 시스템 요구사항 문서를 만들고 유지하기 위한 프로세스이다.
- JAD는 애플리케이션의 설계와 개발 과정에 고객과 사용자를 참여시키는 방법이다.
- 요구사항 검토 과정에서 요구사항의 완전성, 일관성, 명확성 등을 검증한다.
- 요구사항 관리는 요구사항의 변화를 이해하고 통제하는 프로세스이다.
- 유스케이스는 사전 조건, 사후 조건 및 예외 사항을 포함하여 시스템의 동작에 관한 시나리오들을 기술한 문서이다.
- 객체지향 분석은 시스템을 기능 모델, 분석 객체 모델, 동적 모델로 표현한다.
- 구조적 분석의 데이터 흐름도는 정보의 흐름과 정보의 변환을 표현하며 데이터 사전과 함께 시스템의 기능 측면을 모델링한다.



제7장 소프트웨어 설계

- 아키텍처 모델은 시스템의 구성 요소들과 이들 간의 관계를 표현한다.
- 소프트웨어 아키텍처는 비기능적 요구사항과 큰 관련을 가진다.
- 저장소 모델은 공유된 데이터베이스에 기초한 데이터 중심 아키텍처이다.
- 클라이언트 - 서버 아키텍처는 분산 시스템에 적용되는 아키텍처이다.
- 계층형 아키텍처는 추상화 원리를 적용한 구조이다.
- 구조적 설계는 변환 분석과 트랜잭션 분석에 의해 데이터 흐름도로부터 구조도를 유도한다.
- 높은 응집력을 가지고 다른 모듈과 느슨하게 결합되는 모듈을 설계해야 한다.



제8장 소프트웨어 유지보수

- 소프트웨어 유지보수 유형은 수정, 적응, 완전, 예방 유지보수로 구분된다.
- 소프트웨어 재공학은 아키텍처의 변화 없이 소프트웨어의 이해성과 유지보수성을 높이도록 시스템을 수정하는 것이다.
- 재구조화란 같은 추상 수준에서 코드나 문서의 형태를 바꾸는 작업이다.
- 역공학은 프로그램이나 사용자 매뉴얼로부터 초기 단계 생성물인 기능 명세나 설계 문서 등을 생성하는 과정을 의미한다.
- 코드 스멜은 설계나 코딩 작업이 잘못되었다는 징후이며 리팩토링이 필요한 이유이다.
- 소프트웨어 형상 관리는 소프트웨어에 가해지는 변경을 제어하고 관리하는 일이다.
- 사이클로매틱 수와 소프트웨어 사이언스는 소스 코드의 복잡도를 축정하는 척도이다.



제9장 객체지향 분석과 설계

- 객체지향 분석과 설계 과정에서 UML을 사용하여 모델을 작성한다.
- 유스케이스는 해당 기능의 여러 구체적 시나리오들을 일반화하여 명세한 것이다.
- 객체지향 분석의 동적 모델은 시퀀스 다이어그램과 상태 머신 다이어그램으로 표현된다.
- 유스케이스 간의 관계로는 확장, 포함, 상속 관계가 있다.
- 시스템 설계 과정에서 프로젝트의 설계 목표와 시스템 아키텍처를 정한다.
- 객체 설계 단계에서 문제 도메인의 객체를 솔루션 객체로 변환한다.
- UP는 유스케이스 기반의 아키텍처 중심적 프로세스로 위험 관리를 중요시 한다.



제10장 유스케이스 다이어그램 및 명세

- 유스케이스는 완성될 목표 시스템의 사용 시나리오이며 기능 요구사항에 해당한다.
- 유스케이스는 사용자의 관점에서 기술해야 하고, 어떻게(How) 보다는 무엇(What)에 초점을 맞추어야 한다.
- 액터는 구현 대상은 아니며, 시스템과 상호작용하는 사람이나 외부의 시스템을 의미한다.
- 액터는 유스케이스를 시작시키거나 정보를 제공할 수 있으며 또 결과를 제공 받을 수 있다.
- 유스케이스 간의 주요 관계에는 《include》, 《extend》, 《generalize》 등이 있다.
- 시스템 경계를 이용하여 분석 대상을 외부 요소와 구별지을 수 있다.
- 유스케이스 명세는 각 유스케이스 별로 구체적인 시나리오를 담고 있는 문서이다.



제11장 액티비티 다이어그램

- 액티비티 다이어그램은 작업 수행에 필요한 일련의 액션들과 그들의 제어 흐름을 표현하는 다이어그램이다.
- 액티비티는 일련의 액션들과 제어 흐름 및 여러 요소들을 포함하는 것으로 액션의 상위 개념이다.
- 액션은 액티비티 수행을 위한 단일 작업을 의미하여 더 이상 분해할 수 없는 작업 단위이다.
- 제어 흐름은 앞선 액션이 완료된 후 다음 액션이 시작되는 것이며, 객체 흐름은 앞선 액션의 출력이 다음 액션의 입력으로 사용된다는 의미이다.
- 포크로부터 둘 이상의 작업 흐름이 진행될 수 있으며 이것들은 동시에 수행된다. 동시 수행되었던 둘 이상의 작업들은 동기화를 위해 조인으로 합쳐진다.
- 확장 영역은 배열과 같은 것에 포함된 모든 요소들에 대해서, 반복적으로 각각 처리하는 액션들을 하나의 영역으로 묶은 것이다.
- 액션의 행위 주체를 구분하기 위해 파티션(또는 스윔레인)을 사용한다.



제12장 상호작용 다이어그램

- 시퀀스 다이어그램과 통신 다이어그램은 대표적 상호작용 다이어그램이다.
- 시퀀스 다이어그램은 메시지의 흐름과 순서에 초점을 두어 상호작용을 표현한다.
- 통신 다이어그램은 메시지를 주고받는 객체들 간의 관계 즉, 상호작용이 있는 객체들의 연결과 구성을 보여준다.
- 메시지의 종류로는 동기, 비동기, 리턴, 생성 및 삭제 메시지가 있다.
- 시퀀스 다이어그램에서 참여 요소는 생명선의 아래를 향해 가면서 메시지를 주고받는다.
- 통신 다이어그램은 참여 요소, 통신 링크와 메시지로 구성된다.



제13장 클래스 다이어그램과 객체 다이어그램

- 클래스는 객체의 설계도이며 객체는 클래스의 인스턴스이다.
- 클래스는 상태를 나타내는 속성과 동작을 표현하는 메소드로 구성된다.
- 클래스 간의 관계로 의존, 연관, 집합체 연관, 구성 집합체 연관, 일반화가 있다.
- 클래스 다이어그램을 사용하여 클래스를 명세하고 클래스 간의 관계를 보여줄 수 있다.
- 템플릿은 타입 파라미터를 가지는 클래스이다.
- 객체 다이어그램은 객체의 상태와 링크를 이용하여 실행 중의 시스템 상황을 보여준다.



제14장 상태 머신 다이어그램

- 객체의 상태는 특정 시점에서 객체가 가지는 속성들의 값으로 표현된다.
- 상태 머신 다이어그램을 사용하여 단일 객체의 상태 변화를 모델링할 수 있다.
- 상태 전이 화살표와 함께 ‘트리거[조건] / 효과’를 명세할 수 있다.
- 트리거는 상태 전이를 야기하는 이벤트이며 조건이 만족될 때만 전이가 일어난다.
- 선택 노드는 조건에 따른 여러 전이를 명료하게 표현하기 위한 것이다.
- 트리거는 시그널 수신 노드로, 전이 효과는 시그널 송신 노드로 표현할 수 있다.
- 복합 상태는 하나의 상태를 세분화하여 복수 개의 상태로 표현한 것이다.



제15장 기타 다이어그램 (컴포넌트, 패키지, 배포 다이어그램)

- 컴포넌트는 재사용될 수 있는 캡슐화된 소프트웨어 부품이다.
- 컴포넌트는 jar 파일이나 dll 파일과 같은 물리적 바이너리 파일이다.
- 컴포넌트는 제공 인터페이스와 요구 인터페이스를 가진다.
- 배포 다이어그램은 하드웨어 구성과 소프트웨어 요소의 배치에 관한 시스템의 물리적 뷰를 보여준다.
- 배포 다이어그램에서 노드는 대개 하드웨어이나 구성 요소의 실행 환경을 제공하는 소프트웨어도 노드로 표현된다.
- 소프트웨어 구성 요소(artifact)는 노드 상에 존재하는 물리적 소프트웨어 요소로 실행 파일, 라이브러리, 소스, 문서 파일 등을 말한다.
- 패키지는 요소를 그룹화하기 위한 것이며 패키지 간에는 의존 관계가 존재할 수 있다.