동그리동동닷컴

· 소프트웨어 위기

- 소프트웨어 개발 속도가 하드웨어 개발 속도를 따라가지 못함

- 소프트웨어 개발 기술에 대한 교육 부족

- 성능 및 신뢰성 부족

- 개발 기간의 지연 및 개발 비용의 증가(개발비용감소X)

- 유지보수가 어렵고, 이에 따른 비용 증가

- 소프트웨어의 생산성 저하, 소프트웨어의 품질 저하

(소프트웨어의 개발 도구 부족X / 개발 인력의 급증X / 소프트웨어 수요의 감소X)

· COCOMO 

- 개발할 소프트웨어의 규모를 예측한 후 이를 소프트웨어의 종류에 따라 비용을 다르게 책정

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

(COCOMO 방법은 가정과 제약조건이 없어 모든 시스템에 동일하게 적용할 수 있다X)

· 형상 관리

- 소프트웨어 개발 과정에서 소프트웨어의 생산물을 확인하고 소프트웨어 통제, 변경 상태를 기록하고 보관하는 일련의 관리 직업

- 개발과정의 변경사항을 관리하는 것

· 품질 평가 기준 항목

- 정확성 Correctness : 사용자의 요구 기능을 충족시키는 정도

- 신뢰성 Reliability : 요구된 기능을 오류없이 수행하는 정도

- 효율성 Efficiency : 요구된 기능을 수행하기 위한 시스템의 능력. 필요한 자원의 소요 정도

- 무결성 Integrity : 허용되지 않는 사용이나 자료의 변경을 제어하는 정도

- 사용 용이성 Usability : 쉽게 사용할 수 있는 정도

- 유연성 Flexibility : 새로운 요구사항에 맞게 얼마만큼 쉽게 수정할 수 있는가하는 정도

- 이식성 Portability : 다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정할 수 있는 정도

- 재사용성 : 이미 만들어진 프로그램을 다른 목적으로 사용할 수 있는가 하는 정도

- 상호 운용성 : 다른 소프트웨어와 정보 교환할 수 있는 정도

(최적화X / 중복성X / 간결성X / 종속성X / 복잡성X)

· 결합도(Coupling) : 의존하는 정도. 결합도가 약할수록 좋음

- 자료(데이터) 결합도 : 데이터에 대한 처리 결과를 돌려줌. 제일 약한 결합도. 제일 좋음

- 스탬프 결합도 : 자료구조 공유 정도

- 제어 결합도

- 외부 결합도

- 공통 결합도

- 내용 결합도 Content Coupling : 내부 기능 공유 정도

· 응집도(Cohesion) : 모듈 내부의 처리 요소들 간의 기능적 연관도. 독립적인 기능으로 정의. 응집도가 강할수록 좋음

- 기능적 응집도(Functional) : 제일 강한 응집도. 제일 좋음

- 순차적 응집도(Sequential)

- 교환(통신적) 응집도(Communication)

- 절차적 응집도(Procedural)

- 시간적 응집도(Temporal)

- 논리적 응집도(Logical)

- 우연적 응집도(Coincidental) : 처리상의 연관이 없는 서로 다른 기능을 수행하는 경우

· 하향식 통합 검사

- 일시적으로 필요한 조건만을 가지는 임시로 제공되는 시험용 모듈 스터브가 필요(상향식 통합 검사는 스터브 필요X)

· 상향식 통합 검사(Bottom-Up Integration Test)

- 낮은 수준의 모듈들을 Cluster로 결합→Driver라는 제어 프로그램의 작성→Cluster 검사→ Driver를 제거하고 Cluster를 상위로 결합

Q. 상향식 통합 검사에 대한 설명으로 틀린 것은? 가

A. 가. 깊이 우선 통합법 또는 넓이 우선 통합법에 따라 스터브를 실제 모듈로 대치함

    나. 검사를 위해 드라이버를 생성

    다. 하위 모듈을 클러스터로 결합

    라. 하위 모듈에서 상위 모듈 방향으로 통합하면서 검사함

Q. 객체지향 기법 중 다음 설명이 의미하는 것은?

객체의 성질을 분해하여 공통된 성질을 추출하여 슈퍼클래스를 선정하는 것이다. 즉, 불필요한 부분을 생략학 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화, 모델화 하는 것이다. 예를 들면, 자동차와 말이란 클래스에서 "타는 것"이란 클래스를 만드는 것이다.

A. Abstraction 추상화

Q. 소프트웨어 공학에서 CASE의 효과에 해당하지 않는 것은? 라

A. 가. 소프트웨어 개발 주기의 표준안 확립

   나. 소프트웨어 개발 기법의 실용화

   다. 문서화의 용이성 제공

   라. 시스템 수정 및 유지보수 확대

Q. 소프트웨어 재공학의 중 활동 중 다음 설명에 해당하는 것은?

기존 소프트웨어를 분석하여 소프트웨어 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를 재발견하거나 다시 만들어내는 작업

A. Reverse Engineering

정보처리기사 필기 - 4과목 소프트웨어 공학

5장 S/W 공학의 발전적 추세

142 소프트웨어 재사용

① 재사용의 개요

소프트웨어 재사용(Software Reuse)은 이미 개발되어 인정받은 소프트웨어의 전체 혹은 일부분을 다른 소프트웨어 개발이나 유지에 사용하는 것

· 소프트웨어 개발의 품질과 생산성을 높이기 위한 방법으로, 기존에 개발된 소프트웨어와 경험, 지식 등을 새로운 소프트웨어에 적용

· 클래스, 잭체 등의 소프트웨어 요소는 소프트웨어 재사용성을 크게 향상 시킴

· 소프트웨어 재사요에 가장 많이 이용되는 것은 소스 코드(Source Code)

· 재사용이 가능한 요소 : 전체 프로그램, 부분 코드, 응용 분야에 관한 지식, 논리적인 데이터 모형, 프로세스 구조, 시험 계획, 설계에 관한 결정, 시스템 구조에 관한 지식, 요구 분석 사항, 문서화, 전문적인 기술과 개발 경험, 품질 보증, 응용 분야 지식 등

· 소프트웨어 부품(모듈)의 크기가 작고 일반적인 설계일수록 재사용률이 높다

② 재사용의 이점

· 개발 시간과 비용 단축

· 소프트웨어 품질 향상

· 소프트웨어 개발의 생산성 향상

· 프로젝트 실패의 위험 감소

· 시스템 구축 방법에 대한 지식 공유

· 시스템 명세, 설계, 코드 등 문서를 공유

③ 재사용 도입이 문제점

· 어떤 것을 재사용할 것인지 선정해야함

· 시스템에 공통적으로 사용되는 요소들을 발견해야 함

· 프로그램의 표준화가 부족

· 새로운 개발 방법론을 도입하기 어려움

· 재사용을 위한 관리 및 지원이 부족함

· 기존 소프트웨어에 재사용 소프트웨어를 추가하기 어려움

· 프로그램 언어 종속적

· 소프트웨어 요소의 내부뿐만 아니라 인터페이스 요구사항의 이해 필요

· 라이브러리 안에 포함시킬 재사용 요소의 명확한 결정 기준 없음

④ 재사용 방법

143 소프트웨어 재공학

① 재공학의 개요

소프트웨어 재공학(Software Reengineering)은 새로운 요구에 맞도록 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 ㅜ가하여 소프트웨어 성능을 향상시키는 것

· 유지보수 비용이 소프트웨어 개발 비용의 대부분을 차지하는 문제를 염두에 두어 기존 소프트웨어의 데이터와 기능들의 개조 및 개선을 통해 유지보수성과 품질을 향상시키려는 기술

· 유지보수 생산성 향상을 통해 소프트웨어 위기를 해결하는 방법

· 기존 소프트웨어의 기능을 개조하거나 개선하므로, 예방 유지보수 측면에서 소프트웨어 위기를 해결하는 방법

· 소프트웨어 재공학도 자동화된 도구를 이용하여 소프트웨어를 분석하고 수정하는 과정을 포함

· 스프트웨어에서 발생할 수 있는 오류가 줄어 들고, 비용이 절감 됨

② 재공학의 등장 배경

· 기존 소프트웨어가 노후되어 새로운 소프트웨어로 대치해야할 경우 현재 시스템보다 훨씬 더 좋은 시스템을 만들 수 있다는 보장 없음

· 현재 소프트웨어 품질이 더 좋은 소프트웨어로 교체된다고 해도 사용상의 문제점이 없다고 장담할 수 없음

· 새로운 소프트웨어를 개발해도 기존 시스템과의 호환성이 100% 이루어질 수도 없을 뿐만 아니라, 사용자의 교육에도 많은 영향을 줄 수 있음

③ 재공학의 목표

소프트웨어 재공학은 유지보수성 및 기술 향상, 유지보수의 생산성 향상, 소프트웨어 수명 연장, 소프트웨어 요소들을 추출하여 정보 저장소에 저장하는 것을 주된 목적으로 하며, 다음과 같은 목표를 가지고 있음

· 복잡한 시스템을 다루는 방법 구현 : 시스템이 복잡해질수록 시스템을 다루는 방법이 필요하여 이를 위해 자동화 도구 사용 가능

· 다른 뷰의 생성 : 기존 시스템 개발에 대한 관점 외에 다른 방향의 관점 생성

· 잃어버린 정보의 복구 및 제거 : 시스템이 계속적인 개발을 거치면서 잃어버린 정보를 복구하거나 필요없는 정보 제거

· 부작용의 발견 : 의도되지 않았던 내용이 구현될 경우 이를 발견

· 고수준의 추상 : 추상화된 어려운 내요을 여러 형태로 추출하여 이해에 도움 줌

· 재사용 용이 : 재사용이 가능한 모듈을 추출하여 재사용이 용이하도록 함

④ 소프트웨어 재공학의 주요 활동

144 클라이언트/서버/ S/W 공학

① 클라이언트/서버 시스템의 개요

· 클라이언트/서버 시스템은 분산 시스템의 가장 대표적인 모델로, 정보를 제공하는 서버와 정보를 요구하는 클라이언트로 구성된 방식

· LAN을 통하여 클라이언트(워크스테이션, PC)와 서버가 하나의 작업을 분산, 협동 처리

· 중대형 컴퓨터보다 훨씬 적은 비용으로 지원 가능

· 처리햘 자료가 발생한 그 지역에서 처리 가능

· 고성능 워크스테이션에서 가능한 그래픽 사용자 인터페이스를 쉽게 지원

· 서버는 공유된 다양한 시스템 기능과 자원을 클라이언트에게 제공

· 서비스 기능에 따른 서버의 종류

② 클라이언트/서버 시스템의 소프트웨어 요소

· 애플리케이션(응용 프로그램) 요소 : 응용 프로그램에 의해 정의된 요구사항을 구현하는 것으로, 서버와 클라이언트에 위치 가능

· 데이터베이스 요소 : 응용 프로그램에서 요구하는 데이터 조작과 관리를 수행하는 것으로 서버에 위치

· 프레젠테이션/상호작용 요소 : 그래픽 사용자 인터페이스(GUI)와 관련된 모든 기능을 구현하는 것으로, 클라이언틍에 위치

③ 미들웨어

미들웨어(Middleware)는 클라이언트가 서버 측에 어떠한 처리를 요구하고, 또 서버가 그 처리한 결과를 클라이언트에게 돌려주는 과정을 효율적으로 수행하도록 도와주는 소프트웨어로 클라이언트와 서버 사이에 존재

· 미들웨어가 정상적으로 수행되기 위해서는 클라이언트와 서버에 각각의 미들웨어 있어야 함

· 클라이언트와 서버 간의 데이터 통로 제공, 작업 처리 서비스 검색, 프로그램 보안 및 감시 등의 기능 수행

· 미들웨어의 종류

※ 객체 요청 브로커 / CORBA

· 객체 요청 브로커(ORB; Object Request Broker)

- 객체 요청 브로커는 분산 객체 미들웨어의 일종으로 기존의 미들웨어보다 기능이 강화되었으며 클라이언트의 객체가 서버 객체의 캡슐화된 메소드에게 메시지를 보낼 수 있게 하는 것

· CORBA(Common Object Request Broker Architecture)

- 가장 많이 사용되는 객체 요청 브로커의 표준이며, OMG(Object Management Group)라는 개발자 연합에서 인기했음

- CORBA가 클라이언트/서버 시스템에서 구현될 때 클라이언트와 서버 간에 정보를 송·수신하는 데 필요한 인터페이스 언어는 IDL(Interface Description Language)

145 CASE

① CASE의 개요

CASE(Computer Aided Software Engineering)는 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것

· 소프트웨어 생명 주기의 전체 단계를 연결해주고 자동화해주는 통합된 도구를 제공해주는 기술

· 소프트웨어 개발 도구와 방법론이 결합된 것으로, 정형화된 구조 및 방법(메커니즘)을 소프트웨어 개발에 적용하여 생산성 향상을 구현하는 공학 기법

· 소프트웨어 개바르이 모든 단계에 걸쳐 일관된 방법론을 제공하는 자동화 도구(CASE Tool)들을 지원하고, 개발자들은 이 도구를 사용하겨 소프트웨어 개발의 표준화를 지향하며, 자동화의 이점을 얻을 수 있게 해줌

· CASE의 주요 기능 : 소프트웨어 생명주기 전 단계의 연결, 다양한 소프트웨어 개발 모형 지원, 그래픽 지원 등

② CASE 사용의 이점

· 소프트웨어 개발 기간을 단축하고 개발 비용 절감 가능

· 자동화된 기법을 통해 소프트웨어 품질 향상

· 소프트웨어의 유지보수를 간편하게 수행 가능

· 소프트웨어의 생산성이 향상되고 생산, 운용 활동을 효과적으로 관리·통제 가능

· 품질과 일관성을 효과적으로 제어 가능

· 소프트웨어 개발의 모든 단계에 걸친 표준 확립 가능

· 소프트웨어 모듈의 재사용성 향상됨

· 소프트웨어의 개발 기법을 실용화할 수 있고, 문서화를 쉽게 작성 가능

③ CASE 분류

CASE는 소프트웨어 생명 주기의 어느 부분을 지원하느냐에 다라 다음과 같이 분류 가능

상위(Upper) CASE

· 소프트웨어 생명 주기의 전반부에서 사용되는 것으로, 문제를 기술하고 계획하며 요구 분석과 설계 단계를 지원하는 CASE

· 여러 가지 명세와 문서를 작성하는 데 사용됨

· 상위 CASE 도구에는 SREM, PSL/PSA, SERA, FOUNDATION

하위(Lower) CASE

· 소프트웨어 생명 주기의 하반부에서 사용되는 것으로 코드의 작성과 테스트, 문서화하는 과정을 지원하는 CASE

· 하위 CASE 도구에는 구문 중심 편집기, 코드 생성기

통합(Integrate) CASE

· 소프트웨어 생명 주기에 포함되는 전체 과정을 지원하기 위한 CASE로, 공통의 정보 저장 장소와 통일된 사용자 인터페이스를 사용하여 도구들을 통합

· 통합 CASE 도구에는 IEF, POWERTOOLS, TAGS/IORL, TEAMWORK

④ 정보 저장소

정보 저장소의 개요

정보 저장소는 소프트웨어를 개발하는 과정 동안에 모아진 정보를 보관하여 관리하는 곳으로 CASE 정보 저장소, CASE 데이터베이스, 요구사항 사전, 저장소

· 초기의 소프트 개발 환경에서는 사람이 정보 저장소 역할을 했지만 오늘날에는 데이터베이스가 정보 저장소 역할 담당

· 도구들의 통합, 소프트웨어 시스템의 표준화, 소프트웨어 시스템 정보의 공유, 소프트웨어 재사용성의 기본이 됨

정보 저장소 사용의 이점

· 도구들과 생명 주기 활동, 사용자들, 응용 소프트웨어들 사이의 통신과 소프트웨어 시스템의 정보 공유 향상

· 소프트웨어 시스템 구성 요소들과 시스템 정보 저장소에 의해 관리되므로 유지 보수성 향상됨

· CASE 도구들 간에 정보를 쉽게 교환하고, 사용자가 쉽게 새로운 도구를 추가 가능하도록 해줌

· CASE 도구들을 통합하여 통합 CASE 도구 사용 가능

· 중복된 공통 정보를 통합하며 불필요한 정보 제거

· 생명 주기 정보를 재사용할 수 있도록 함

· 소프트웨어 시스템의 이식과 변환을 용이하게 함

출처 : 2017 시나공 정보처리기사 필기

정보처리기사 필기 - 4과목 소프트웨어 공학

4장 객체지향 S/W 공학

138 객체지향 소프트웨어 공학

① 객체지향 기법의 개요

객체지향 기법은 현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체로 만들어, 기계적인 부품들을 조립하여 제품을 만들 듯이 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있도록 하는 기법

· 객체지향 기법은 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용중

· 소프트웨어의 재사용 및 확장을 용이하게 함으로서 고품질의 소프트웨어를 빠르게 개발할 수 있으며 유지보수 쉬움

· 복잡한 구조를 단계적·계층적으로 표현하고, 멀티미디어 데이터 및 병렬 처리를 지원

· 현실 세계를 모형화하여 사용자와 개발자가 쉽게 이해 가능

· 객체지향 기법의 구성 요소 : 객체, 클래스,  메시지

② 객체(Object)

· 객체는 데이터와 데이터를 처리하는 함수를 묶어 놓은 (캡슐화한) 하나의 소프트웨어 모듈

· 객체는 상태와 행위를 가지고 있음

· 객체는 다른 객체들과 구별될 수 있는 이름을 갖고 있으며, 일정한 기억 장소를 가지고 있음

· 객체의 메소드는 다른 객체로부터 메시지를 받았을 때 수행

③ 클래스(Class)

· 클래스는 공통된 속성과 연산(행위)을 갖는 객체의 집합으로 객체의 일반적인 타입을 의미

· 클래스는 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀

· 클래스에 속한 각각의 객체를 인스턴스라 하며, 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화 라고 함

· 동일 클래스에 속한 각가그이 객체(인스턴스)들은 공통된 속성과 행위를 가지고 있으면서, 그 속성에 대한 정보가 ㅓ로 달라서 동일 기능을 하는 여러 가지 객체를 나타내게 됨

· 최상위 클래스는 상위 클래스를 갖지 않는 유일한 클래스를 의미

· 슈퍼 클래스는 특정 클래스의 상위(부모) 클래스이고, 서브클래스는 특정 클래스의 하위(자식) 클래스를 의미

④ 메시지(Message)

· 메시지는 객체들 간에 상호작용을 하는 데 사용되는 수단으로, 객체에게 어떤 행위를 하도록 지시하는 명령 또는 요구사항

· 메시지의 구성 요소 : 메시지를 받는 객체(수신자)의 이름, 객체가 수행할 메소드 이름, 메소드를 수행할 때 필요한 인자(속성값)

· 인자는 옵션, 즉 필요할 때만 사용

· 메시지를 받은 수신 객체는 요구된 메소드(동작, 연산)를 수행하여 결과를 반환하게 됨

139 객체지향 기법의 기본 원칙

객체지향 기법의 기본 원칙에는 캡슐화, 정보 은닉, 추상화, 상속성, 다형성 등이 있으며, 이 중 구조적 기법과 차별되는 개념은 캡슐화, 상속성, 다형성

① 캡슐화(Encapsulation) 

캡슐화는 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것

· 캡슐화된 객체의 세부 내용이 외부에 은폐(정보 은닉)되어, 변경이 발생할 때 오류의 파급 효과가 적음

· 캡슐화된 객체들은 재사용이 용이함

· 객체들 간의 메시지를 주고 받을 때 각 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고, 객체 간의 결합도가 낮아짐

② 정보 은닉

캡슐화에서 가장 중요한 개념으로, 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것

· 각 객체의 수정이 다른 객체에게 주는 영향을 최소화하는 기술

· 외부 객체가 특정 객체의 데이터와 함수를 직접 접근하여 사용하거나 변경하지 못하므로 유지보수와 소프트웨어 확장 시 오류 최소화 가능

③ 추상화(Abstraction)

추상화는 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화 하는 것, 즉 모델화 하는 것

· 인간이 복잡한 문제를 다루는데 가장 기본이 되는 방법으로, 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러 가지 요인들을 테스트할 수 있음

· 추상화는 최소의 비용으로 실제 상황에 대처 가능하고, 시스템의 구조 및 구성을 가시적으로 볼 수 있음

④ 상속성(Inheritance)

상속성은 이미 정의된 상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스가 물려받는 것

· 상속성을 이용하면 하위 클래스는 상위 클래스의 모든 속성과 연산을 자신의 클래스 내에서 다시 정의하지 않고서도 즉시 자신의 속성으로 사용 가능

· 하위 클래스는 상위 클래스로부터 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용 가능

· 상위 클래스의 속성과 연산을 하위 클래스가 공유할 수 있기 때문에 객체와 클래스의 재사용, 즉 소프트웨어 재사용을 증대시키는 중요한 개념

· 다중 상속성(Multiple Inheritance) : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것

⑤ 다형성(Polymorphism)

다형성은 메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메시지에 대해 각 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할 수 있는 능력

· 객체(클래스)들은 동일한 메소드명을 사용하며 같은 의미의 응답을 함

· 응용 프로그램 상에서 하나의 함수나 연산자가 두 개 이상의 서로 다른 클래스의 인스턴스들을 같은 클래스에 속한 인스턴스처럼 수행 가능하도록 하는 것

140 객체지향 기법의 생명 주기와 분석

① 객체지향 기법의 생명 주기

· 객체지향 기법을 사용하는 소프트웨어 개발 과정의 가장 큰 특징은 각 과정에서 사용되는 객체, 클래스, 메소드, 속성 등이 동일한 개념으로 사용된다는 것

· 개발 전 과정에 걸쳐 동일한 방법론과 표현 기법이 적용된다는 장점 갖고 있음

· 개발 과정 사이에서 같은 용어와 개념을 사용하여 분석, 설계, 구현 단계 사이의 전환이 쉬우므로 각 과정이 명확하게 순차적으로 이루어지지는 않음

· 객체지향 기법의 생명 주기 : (계획 및 분석) → (설계) → (구현) → (테스트 및 검증)

② 객체지향 분석의 개념

객체지향 분석(OOA; Object Oriented Analysis)은 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 이와 연관된 속성과 연산, 그들 간의 관계 등을 정의하여 모델링하는 작업

· 소프트웨어를 개발하기 위한 비즈니스(업무)를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석

· 분석가에게 주요한 모델링 구성 요소인 클래스, 객체, 속성, 연산 들을 표현해서 문제를 모형화 할 수 있게 해줌

· 객체는 클래스로부터 인스턴스화되고, 이 클래스를 식별하는 것이 객체지향 분석의 주요한 목적

③ 객체지향 분석의 방법론

객체지향 분석을 위한 여러 방법론이 제시되었으며 각 방법론은 다음과 같음

· Rumbaugh(럼바우) 방법 : 가장 일반적으로 사용되는 방법으로 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행하는 방법

· Booch(부치) 방법 : 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석 방법으로, 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산 정의

· Jacobson 방법 : Use Case를 강조하여 사용하는 분석 방법

· Coad와 Yourdon 방법 : E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주제 저으이, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성하는 기법

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

④ 럼바우(Rumbaugh)의 분석 기법

럼바우의 분석 기법은 모든 소프트웨어 구성 요소를 그래픽 표기법을 이요하여 모델링하는 기법으로, 객체 모델링 기법이라고도 함

분석활동은 객체 모델링, 동적 모델링, 기능 모델링을 통해 이루어짐

· 객체 모델링(Object Modeling)

- 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것

- 분석 활동의 세 가지 모델 중 가장 중요하며 선행되어야 할 모델링

- 객체 모델링의 순서

① 객체와 클래스 식별

② 클래스에 대한 자료 사전 작성

③ 클래스 간의 관계 정의

④ 객체 속성 및 연결 관계 정의

⑤ 클래스를 계층화하고 모듈로 정의

⑥ 생성된 모형을 반복적으로 검정

· 동적 모델링(Dynamic Modeling)

상태 다이어그램(상태도)을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링

- 동적 모델링에서는 객체나 클래스의 상태, 사건을 중심으로 다룸

- 동적 모델링 순서

① 사건의 상호 작용 순서에 대한 시나리오 작성

② 사건 시나리오를 역할과 시간에 따라 표기한 후 사건 추적도 작성

③ 사건 추적도를 사건 발생자의 관계로 설명하는 사건 흐름도 작성

④ 사건과 상태를 연겨시킨 상태도 작성

· 기능 모델링(Functional Modeling)

- 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링

- 어떤 데이터를 입력하여 어떤 결과를 구할 것인지를 표현하는 것

- 기능 모델링 순서

① 외부와 시스템 간의 입·출력 자료를 정의

② 자료 흐름도 상세화

③ 프로세스 기능에 대한 정의를 기능 명세서로 작성

④ 제약 조건 파악

⑤ 최적화 기준 명세화

141 객체지향 설계, 구현, 테스트

① 객체지향 설계의 개요

객체지향 설계(OOD; Object Oriented Design)는 객체지향 분석(OOA)을 사용해서 생성한 여러 가지 분석 모델을 설계 모델로 변환하는 작업으로, 시스템 설계와 객체 설계를 수행

· 최근 소프트웨어 제품의 전형적인 타입인 사용자 중심, 대화식 프로그램의 개발에 적합

· 객체지향 설계에서 가장 중요한 문제는 시스템을 구성하는 객체와 속성, 연산을 인식하는 것

· 객체지향 설계의 설계 개념은 추상화, 정보 은닉, 기능 독립성, 모듈화, 상속성을 바탕으로 하며 이 중 가장 중요한 개념은 모듈화

· 객체지향 설꼐를 위해 럼바우의 객체지향 설계, 부치의 객체지향 설꼐, 윌리엄 로렌스의 객체지향 설계 방법등이 제안되었으며, 이 중 일반적으로 럼바우의 객체지향 설계가 가장 많이 사용됨

· 일반적으로 객체지향 설꼐 단계의 순서 : '문제 정의→요구 명세화→객체 연산자 정의→객체 인터페이스 결정→객체 구현'

② 럼바우(Rumbaugh)의 객체지향 설계

· 시스템 설계

- 시스템 설계는 전체적인 시스템 구조를 설계하는 것으로 분석 단계의 분석 모델을 서브시스템으로 분할하고, 시스템의 계층을 정의하며 분할 과정 중에서 성능의 최적 방안, 문제 해결 전략, 자원 분해 등을 확정하는 것

- 상세 설계를 위한 중요한 개념과 전략을 결정하고, 서브 시스템과 이들이 할당될 하드웨어를 결정

- 설계 절차

① 시스템을 서브시스템으로 분할

② 동적 모델링을 분석하여 객체들의 병행수행 가능성 파악

③ 서브시스템을 하드웨어와 태스크에 할당

④ 자원 관리 방법 및 공동 자원의 접근 방법 결정

⑤ 시스템의 제어 방식 결정

⑥ 경계 조건의 처리 방법 결정

⑦ 우선 순위 결정 

· 객체 설계

- 객체 설계는 분석 단계에서 만들어진 클래스, 속성, 관계, 메시지를 이용한 통신을 설계 모델로 제작하고 상세화하여 구체적인 자료 구조와 알고리즘 정의

- 정보와 처리를 모듈화하고 데이터 객체와 처리 조작을 연결하며, 추상화, 정보 은닉, 모듈화를 기본으로 하여 소프트웨어 생성

- 설계 절차

① 객체 모델링, 동적 모델링, 기능 모델링을 통합하고 연산 파악

② 연산을 구현하기 위해 알고리즘 설계

③ 자료에 대한 접근 경로 최적화

④ 외부와 상호작용 하기 이한 제어 방식 구현

⑤ 클래스 구조를 조정하여 상속성 향상

⑥ 관계를 설계하고, 객체의 표현 방법을 결정

⑦ 클래스와 관계를 단일 모듈로 생성

⑧ 문서화

③ 부치(Booch)의 객체지향 설계

· 자료 흐름도(DFD)를 사용해서 객체를 분해하고, 객체들 간의 인터페이스를 찾아 이것들을 Ada 프로그램으로 변환시키는 기법

· 설계 절차

① 문제를 정의(요구사항 분석)

② 실세계 문제 영역을 소프트웨어로 구현하기 위해 비정형적인 전략을 기술

③ 비정형적 전략을 정형화

④ 위의 ②, ③ 단계를 완전한 설계가 될 때까지 반복

⑤ 서브클래스와 메시지 특성을 세분화하여 세부 사항 정제화

⑥ 객체의 속성과 자료 구조 표현

⑦ 구체적인 절차 표현

④ 윌리엄 로렌슨(William Lorensen)의 객체지향 설계

· 추상화, 상속성, 메시지, 그리고 다른 모든 OOD 개념들을 직접 지원해주는 기능을 가주고 있는 Smalltalk와 같은 프로그래밍 언어로 소프트웨어를 개발하기 위한 기법

· 설계 절차

① 각 서브시스템에 대한 자료 추상화 식별

② 각 추상화에 대한 속성들을 식별

③ 각 추상화에 대한 연산들을 식별

④ 객체들 사이의 통신 메시지 식별

⑤ 시나리오 이용하여 설계 검사

⑥ 적절한 곳에 상속 적용

⑤ 객체지향 구현

· 구현은 설계 단계에서 생성된 설계 모델과 명세서를 근거로 하여 코딩하는 단계

· 객체지향 프로그래밍을 이용하면 용이하게 구현 가능

· 객체는 순차적으로 또는 동시적으로 구현 가능

객체지향 프로그래밍(OOP; Object Oriented Programing)

객체지향 프로그래밍은 새로운 개념의 모듈 단위, 즉 객체라는 단위를 중심으로 하여 프로그램을 개발하는 기법

· 객체라는 단위를 이용하여 현실 세계에 가가운 방식으로 프로그래밍함

· 현실 세계에 가까운 방식이므로 이해하기 쉽고 조작하기 쉬운 프로그램 개발 가능

· 유지보수 쉽고 재사용 가능한 프로그램 제작 가능

· 이미 개발된 프로그램을 이용해 빠르게 확장된 프로그램 개발 가능

· 객체지향 프로그래밍 언어 분류

⑥ 객체지향 테스트

· 클래스 테스트 : 구조적 기법에서의 단위 테스트와 같은 개념으로 가장 작은 단위, 즉 캡슐화된 클래스나 객체를 검사하는 것

· 통합 테스트 : 객체를 몇 개 결합하여 하나의 시스템으로 완성시키는 과정에서의 검사

· 확인 테스트 : 사용자 요구사항에 대한 만족 여부 검사

· 시스템 테스트 : 모든 요소들이 적합하게 통합되고 올바른 기능을 수행하는지 검사

출처 : 2017 시나공 정보처리기사 필기

정보처리기사 필기 - 4과목 소프트웨어 공학

3장 전통적 S/W 개발 방법론

128 요구사항 분석

① 전통적 소프트웨어 개발 방법의 개요

· 전통적(고전적) 소프트웨어개발 방법은 과거의 많은 소프트웨어 개발 경험을 토대로 하여 성공적으로 평가되는 소프트웨어 분석 및 설계 방법들을 집대성하여 하나의 개발 방법으로 정형화한 것

· 전통적(고전적) 소프트웨어 개발 방법을 구조적 소프트웨어 개발 방법이라고도 함

② 요구사항 분석의 개요

요구사항 분석은 소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동 의미

· 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약 설정

· 사용자의 요구 정확하게 추출하여 목표 정하고, 어떤 방식으로 해결할 것인지를 결정

· 요구사항 분석을 통한 결과는 소프트웨어 설계 단계에서 필요한 기본적인 자료가 되므로 사용자의 요구사항을 정확하고 일관성 있게 분석하여 문서화해야 함

· 소프트웨어 분석가에 의해 요구사항 분석이 수행되며, 이 작업 단계를 요구사항 분석 단계라고 함

③ 요구사항 분석 작업

요구사항 분석은 다음과 같은 작업으로 세분화되어 수해오딤

· 문제 인식 : 사용자와의 면담, 설문조사 및 협조, 각종 문서 검토 등을 통하여 사용자의 요구사항 찾아냄

· 모델 제작 : 평가와 종합을 바탕으로 자료와 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 등을 이해하기 쉽도록 모델로 작성

개발할 소프트웨어에 대한 추상적인 모형을 만드는 것

· 문서화와 검토 : 요구사항 분석 명세서를 작성 → 소프트웨어의 기능, 성능, 제약 조건 등에 대하여 기술 하고 검토

④ 요구사항 분석의 어려움

대화 장벽

· 사용자와 개발자의 지식 배경의 다양화, 용어 불일치 등으로 의사 소통 곤란

· 해결책 : 다이어그램 및 프로토타입 이용

시스템의 복잡도

· 소프트웨어 체계화를 위해 새로운 개념이 필요해지고, 시스템 규모와 대상이 광범위해짐에 따라 난이도 증가에 의한 소프트웨어의 복잡화

· 해결책 : 구조적 분석이나 객체지향 분석 이용

요구의 변경

· 사용자 생각의 부정확성, 생각의 반복된 변경

· 해결책 : 수정 요구와 상반된 요구들의 수용 기술 필요

요구 명세화의 어려움

· 중복 현상, 애매모호함, 시험의 어려움, 과거와 다른 현재 상황 등의 내포에 따라 요구 명세서 작성이 어려움

· 해결책 : 제도적인 요구 분석 기술 필요

⑤ 요구사항 분석가의 자질

요구사항 분석가는 요구사항의 효율적인 분석과 정확한 명세화를 위해 다음과 같은 자질을 갖추어야 함

· 소프트웨어 개발에 많은 경험을 가지고 있어야 함

· 사용자의 요구를 정확히 수용하고, 여러 환경을 이해해야 함

· 설계에 필요한 자료를 충분히 제공할 수 있어야 함

· 다방면에 대한 해박한 지식을 가지고 있어야 함

· 시간 배정과 계획 등을 빠른 시간 내에 파악할 수 있어야 함

· 하드웨어, 소프트웨어를 포함함 컴퓨터에 대한 기술을 이해하고 있어야 함

· 고객이 사용할 시스템을 만들어야 하므로 상대의 관점(고객 관점)에서 문제를 파악할 수 있어야 함

⑥ 구조적 분석 기법

구조적 분석 기법은 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법으로, 다음과 같은 특징이 있음

· 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화함

· 도형 중심의 도구를 사용하므로 분석가와 사용자 간의 대화가 용이

· 하향식 방법을 사용하여 시스템을 세분화할 수 있고, 분석의 중복을 배제할 수 있음

· 사용자의 요구사항을 논리적으로 표현하여 전체 시스템을 일관성 있게 이해할 수 있음

· 시스템 분석의 질이 향상되고, 시스템 개발의 모든 단계에서 필요한 명세서 작성이 가능

· 구조적 분석 기법에는 자료흐름도, 자료 사전, 소단위 명세서, 개체 관계도, 상태 전이도, 제어 명세서 등의 도구를 이용하여 모델링 함

129 구조적 분석 도구

① 자료 흐름도(DFD)의 개요

자료 흐름도(DFD, Data Flow Diagram)는 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법으로 자료 흐름 그래프, 버블 차트라고도 함

· 시스템 안의 프로세스와 자료 저장소 사이에 자료의 흐름을 나타내는 그래프로 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용됨

· 자료 흐름도는 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화됨

· 자료는 처리를 거쳐 변환될 때마다 새로운 이름이 부여되며, 처리는 입력 자료가 발생하면 기능을 수행한 후 출력 자료를 산출함

② 자료 흐름도 구성 요소 표기법

③ 자료 흐름도의 세분화(상세화)

자료 흐름도의 세분화는 요구사항 분석이 진행됨에 따라 하나의 자료 흐름도를 보다 자세히 표현하기 위해 또 다른 자료 흐름도를 생성하는 것

· 단계(Level) 0의 자료 흐름도는 기본 시스템 모델 또는 배경도라고 하며, 전체 소프트웨어 요소를 표시하는 하나의 프로세스(원)과 입·출력을 나타내는 화살표로 표현

· 각각의 프로세스에 대하여 개별적인 상세화 및 계층화가 가능

· 세분화 단계가 많아질수록 소프트웨어 설계와 구현 작업이 용이해짐

④ 자료 사전(DD)

자료 사전(DD, Data Dictionary)은 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이며, 이처럼 데이터를 설명하는 데이터를 데이터의 데이터 또는 메타 데이터라고 함

· 자료 흐름도에 시각적으로 표시된 자료에 대한 정보를 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게 사용 가능

자료 사전 표기법 및 작성 시 유의사항

· 자료 사전의 한 항목은 자료에 대한 정의 부분과 설명 부분으로 구성되며, 정의 부분에는 자료의 이름을, 설명 부분에는 자료에 대한 자세한 내용을 표현

· 이름으로 정의를 쉽게 찾을 수 있어야 하며, 이름이 중복되어서는 안됨

· 갱신하기 쉬워야 하며, 정의하는 방식이 명확해야 함

· 자료 사전에서 사용되는 표시 기호는 다음과 같음

⑤ 소단위 명세서(Mini-Spec.)

소단위 명세서는 세분화된 자료 흐름도에서 최하위 단계 버블(프로세스)의 처리 절차를 기술한 것으로 프로세스 명세서라고도 함

· 소단위 명세서는 분석가의 문서이며, 자료 흐름도(DFD)를 지원하기 위하여 작성

· 소단위 명세서는 서술문장, 구조적 언어, 의사결정나무, 의사 결정표(판단표), 그래프 등을 이용하여 기술

※ 최하위 단계 버블(프로세스)

더 이상 세분화할 수 없는 단계의 프로세스로, 원시 버블 또는 프리미티브 버블(Primitive Bubble)이라고도 함

※ 구조적 언어, 의사결정나무, 의사 결정표

· 구조적 언어 : 자연어의 일부분으로 한정된 단어와 문형, 제한된 구조를 사용하여 명세서를 작성하는 데 이용하는 명세 언어

· 의사결정나무 : 현재 상황과 목표와의 상호 관련성을 나무의 가지를 이용해 표현한 것으로 불확실한 상황에서의 의사결정을 위한 분석 방법

· 의사 결정표(Decision Table) : 복잡한 의사 결정 논리를 기술하는 데 사용하며, 주로 자료 처리 분야에서 이용됨

⑥ 개체 관계도(ERD)

개체 관계도(ERD, Entity Relationship Diagram)는 시스템에서 처리되는 개체(자료)와 개체의 구성과 속성, 개체 간의 관계를 표현하여 자료를 모델화하는데 사용

· 개체 관계도의 구성

· 개체는 사각형, 속성은 타원, 관계는 다이아몬드로 표시

· 개체 관계의도 작성 순서

① 주요키를 포함하여 개체의 속성을 모두 찾아냄

② 기본적인 개체와 주요키를 정의하며, 개체 사이의 관계 정의

③ 1:M 관계를 단순화하기 위해 속성 개체를 추가하며, 연관 관계를 정의하여 M:N 관계를 표현함

④ 각 개체를 정규화, 누락된 개체 점검 및 클라스 구조가 필요한지 결정

⑦ 상태 전이도(STD)

상태 전이도(STD, State Transition Diagram)는 시스템에 어떤 일이 발생할 경우 시스템의 상태와 상태 간의 전이를 모델화한 것으로, 상태 전이도를 통해 개발자는 시스템의 행위 정의 가능

· 상태 전이도에서 사각형은 시스템의 상태를, 화살표는 상태 전이를 나타냄

· 화살표의 시작 부분은 상태 전이를 일으키는 사건을 의미하며, 화살표의 끝은 사건의 결과로 발생하는 동작

130 요구사항 분석 CASE와 HIPO

① 요구사항 분석을 위한 CASE(자동화 도구)

· 요구사항 분석을 위한 자동화 도구는 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구

· 요구사항 분석을 위한 자동화 도구 사용의 이점

- 표준화와 보고를 통한 문서화 품질 개선

- 데이터베이스가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정

- 교차 참조도와 보고서를 통한 결함, 생략 불일치 등의 발견 용이성

- 변경이 주는 영향 추적의 용이성

- 명세에 대한 유지보수 비용의 축소

종류

요구사항 분석을 위한 자동화 도구에는 SADT, STEA, PSL/PSA, TAGS, EPOS 등이 있음

· SADT(Structed Analysis and Design Technique)

- SoftTech 사에서 개발한 것으로 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용되어 온 구조적 분석 및 설계 도구

- 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구

· SREM(Software Requirements Engineering Methodology) = RSL/REVS

- TRW 사가 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 것으로, RSL과 REVS를 사용하는 자동화 도구

- RSL(Requirement Statement Language) : 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어

- REVS(Requirement Engineering and Validation System) : RSL로 기술된 요구사항들을 자동으로 분석하여 요구사항 분석 명세서를 출력하는 요구사항 분석기

· PSL/PSA

-미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화 도구

- PSL(Problem Statement Language) : 문제(요구사항) 기술 언어

- PSA(Problem Statement Analyzer) : PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서를 출력하는 문제 분석기

· TAGS(Technology for Automated Generation of System)

- 시스템 공학 방법 응용에 대한 자동 접급 방법으로, 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

- 구성 : IORL, 요구사항 분석과 IORL 처리를 위한 도구, 기초적인 TAGS 방법론

- IORL :  요구사항 명세 언어

② HIPO

HIPO(Hierarchy Input Process Output)는 시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타냄

· 기본 시스템 모델은 입력, 처리, 출력으로 구성되며, 하향식 소프트웨어 개발을 위한 문서화 도구

· 체계적인 문서 관리 가능

· 기호, 도표등을 사용하므로 보기 쉽고 이해하기도 쉬움

· 기능과 자료의 의존 관계를 동시에 표현 가능

· 변경, 유지보수가 용이

· 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 함

HIPO Chart의 종류

131 설계

① 구조적 설계 기법

· 구조적 설계 기법은 구조적 분석 기법의 결과물인 자료 흐름도 등으로부터 소프트웨어의 기능(자료 구조)과 프로그램 구조, 모듈을 설계하기 위한 전략, 평가 지침 및 문서화 도구를 제공하는 체계화된 기법

· 자료의 흐름을 중심으로 하는 설계 기법이므로 자료 흐름 중심 설계 기법이라고도 함

· 자료 흐름도, 자료 사전, 개체 관계도, 소단위 명세서 등이 준비된 이후에 설계

② 설계의 개요

설계는 요구사항 분석 단계의 산출물인 요구사항 분석 명세서의 기능이 실현되도록 알고리즘과 그 알고리즘에 의해 처리될 자료 구조를 문서화하는 것

· 좋은 소프트웨어를 개발하기 위한 가장 핵심이 되는 기술로, 소프트웨어의 품질 평가를 위한 지침이 됨

· 소프트웨어 설계 모형의 구성

[그림 1] 소프트웨어 설계 모형

③ 설계의 기본 원리

소프트웨어 설계는 다음과 같은 기본 원리를 가지고 있으며 이는 소프트웨어 설계자에게 보다 더 효율적인 설계 방법을 제공함

모듈화(Modularity)

· 모듈화는 소프트웨어를 모듈 단위로 나누는 것

· 모듈은 서브루틴, 부(Sub) 시스템, 소프트웨어 내의 프로그램, 작업 단위 등을 의미함

· 모듈화를 이용하여 설계하면 확장성, 융통성, 경제성 등이 향상됨

추상화(Abstraction, 개념화)

· 문제의 세부 사항을 먼저 설계하기보다는 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 설계 방법

· 추상화의 유형

단계적 정제(Stepwise Refinement)

· Niklaus Wirth에 의해 제안된 하향식 설계 전략으로, 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법

· 추상화의 반복에 의해 세분화됨

· 소프트웨어 기능에서부터 시작하여 점차적으로 구체화하고, 상세한 내역(알고리즘, 자료 구조)은 가능한 한 뒤로 미루어 가면서 진행

정보 은닉(Information Hiding)

· 한 모듈 내부에 포함된 절차화 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

· 다른 모듈이 정보 은닉된 모듈과 인터페이스할 때는 소프트웨어 기능을 수행하는 데 반드시 필요한 정보만을 전달함

· 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이함

프로그램 구조(Program Structure)

· 소프트웨어의 구성 요소인 모듈의 계층적 구성을 나타내는 것으로, 제어 계층 구조라고도 함

· 프로그램의 순서, 선택, 반복과 같은 소프트웨어의 절차적인 처리 과정을 나타내지 않음

· 프로그램 구조는 일반적으로 트리 구조의 다이어그램으로 표기함(사각형은 모듈을 나타냄)

· 프로그램 구조에서 사용되는 용어

자료 구조

· 자료 구조는 자료 사이의 논리적인 관계를 표현한 것으로 자료의 구성, 결합 정도, 접근 방법 등을 나타냄

· 자료 구조의 종류에는 스칼라 항목, 벡터, 연결 리스트, 계층적 자료 구조 등이 있음

④ 바람직한 설계의 특징

· 설계는 소프트웨어 구조를 나타내야 함

· 설계는 독립적인 기능적 특성을 가진 요소(모듈)로 구성되어야 함

· 설계는 모듈 구조, 즉 특정 기능 또는 부기능을 수행하는 논리적 요소들로 분리되는 구조를 가져야 함

· 소프트웨어 요소(모듈) 간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 함

· 설계는 자료와 프로시저에 대한 분명하고 분리된 표현을 포함해야 함

· 설계는 모듈 간과 외부 개체 간의 연결 복잡성을 줄이는 인터페이스를 가져야 함

· 설계는 요구사항 분석에서 얻어진 정보를 이용하여 반복적인 방법으로 이루어져야 함

· 요구사항을 모두 구현해야 하고, 유지보수가 용이해야 함

· 모듈의 기능을 예측할 수 있도록 정의

· 적당한 모듈의 크기를 유지하고, 모듈 간의 상관성(결합도)은 낮추고, 응집도는 높임

· 전체적이고 포괄적인 개념을 설계한 후 차례대로 세분화하여 구체화시켜 나감

· 이식성을 고려함

132 모듈과 모듈화

①  모듈과 모듈화 개요

모듈화는 소프트웨어를 각 기능별로 분할하는 것을 의미하며, 각 기능별로 분할한 것을 모듈이라고 함

· 모듈화를 수행하면 소프트웨어의 복잡도가 감소하고, 변경이 쉬우며 프로그램 구현이 용이함

· 모듈의 속성과 구성

② 모듈의 기능적 독립성의 개요

모듈의 기능적 독립성은 소프트웨어를 구성하는 각 모듈의 기능이 독립됨을 의미하는 것으로 모듈화, 추상화, 정보 은닉의 부산물

· 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함으로써 이루어짐

· 기능적으로 독립된 모듈은 특정 기능을 수행하고, 다른 모듈과는 간단한 인터페이스만을 가지므로 개발이 쉽고 재사용이 가능

· 독립성이 높은 모듈일수록 모듈을 수정하더라도 다른 모듈에게는 거의 영향을 미치지 않으며, 오류가 발생해도 쉽게 발견하고 해결 가능

· 모듈의 독립성은 결합도와 응집도에 의해 측정되며, 독립성을 높이려면 모듈의 결합도를 약하게 하고 응집도를 강하게 하며 모듈의 크기를 작게 만들어야 함

· 결합도와 응집도는 소프트웨어 설계시 평가 지침이 됨

③ 결함도(Coupling)

· 결합도는 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미

· 독립적인 모듈이 되기 위해서는 각 모듈 간의 결합도가 약해야 하며 의존하는 모듈이 적어야 함

· 결합도가 강하면 시스템 구현 및 유지보수 작업이 어려움

· 결합도의 종류

 자료 결합도, 스탬프 결합도, 제어 결합도, 외부 결합도, 공통 결합도, 내용 결합도

결합도 약함                                 ↔                                 결합도 강함

④ 응집도(cohesion)

· 응집도는 정보 은닉 개념을 확장한 것으로, 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미

· 독립적인 모듈이 되기 위해서는 각 모듈의 응집도가 강해야 함

· 응집도의 종류

기능적 응집도, 순차적 응집도, 교환(통신)적 응집도, 절차적 응집도, 시간적 응집도, 논리적 응집도, 우연적 응집도

응집도 강함                                                 ↔                                                 응집도 약함

⑤ 효과적인 모듈화 설계 방안

· 결합도는 줄이고 응집도는 높여서 모듈의 독립성을 높임

· 모듈의 제어 영역 안에서 그 모듈의 영향 영역을 유지시킴

· 복잡도와 중복성을 줄이고 일관성을 유지시킴

· 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안됨

· 유지보수가 용이해야 함

· 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해

· 하나의 입구와 하나의 출구를 갖도록 해야 함

· 인덱스 번호나 기능 코드들이 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치지 않도록 모듈 인터페이스를 설계해야 함

133 설계 방법

① 자료 설계

· 자료 설계는 설계의 첫 번째 작업으로, 요구 사항 분석에서 생성된 여러 모델들을 소프트웨어를 구현하는 데 필요한 자료 구조로 변환하는 것

· 자료 구조가 프로그램 구조와 절차적 복잡성에 영향을 주므로 자료 설계는 소프트웨어 품질에 큰 영향을 줌

· 정보 은닉과 자료 추상화의 개념은 자료 설계를 위한 기초를 제공함

② 구조 설계

· 구조 설계는 프로그램의 구조를 개발하고, 소프트웨어 구성 요소들 간의 관계를 정의하는 것

· 프로그램이 처리하는 기능에 초점을 맞추어 모듈로 분해하고, 프로그램 전반에 걸친 자료의 흐름을 위한 인터페이스를 정의

구조적 설계 절차

구조적(자료 흐름 중심) 설계에서는 다음과 같은 설계 절차를 통해 구조를 설계함

① 정보 흐름의 유형을 설정

② 흐름의 경계 표시

③ 자료 흐름도를 프로그램 구조로 사상

④ 제어 계층을 분해시켜서 정의

⑤ 경험적 방법을 구체화시킴

DFD를 프로그램 구조로 사상시키는 방법

요구사항 분석에서 작성한 DFD를 프로그램 구조로 사상시키는 방법

· 변환 분해 접근법 : 요구 분석 단계의 DFD를 입력 흐름, 변환 흐름, 출력 흐름으로 구분하여 프로그램 구조 도표로 변환시키는 방법

· 거래 분해 접근법 : DFD에서 거래에 해당하는 부분을 찾아내어 이 거래 중심 자료 흐름도를 거래 중심 구조 도표로 변환하는 방법

구조 도표(Structure Chart, 설계 구조도)

· 구조 도표는 프로그램 구조를 설계할 대 사용되는 도구로, 소프트웨어 기능을 몇 개의 고유 기능으로 분할하여 블랙 박스로 나타내고 블랙 박스 간의 인터페이스를 계층 구조로 표현하는 것

· 소프트웨어의 기능을 모듈의 호출 관계와 인터페이스로 나타냄

③ 인터페이스 설계

인터페이스 설계는 소프트웨어와 상호 작용하는 시스템, 사용자 등과 어떻게 통신하는지를 기술하는 과정

· 소프트웨어와 모듈 사이, 소프트웨어와 정보 생산자·소비자 사이, 소프트웨어와 사용자 사이의 인터페이스 설계로 나눌 수 있음

· 변화 요인이 다양한 사용자와의 인터페이스에 중점을 두고 설계함

④ 절차(프로시저) 설계

· 절차(프로시저) 설계는 데이터 설계, 아키텍처 설계, 인터페이스 설계가 이루어진 후에 수행되는 설계 작업으로 모듈이 수행할 기능을 절차적 기술로 바꾸는 것

· 데이터 설계, 아키텍쳐 설계, 인터페이스 설계를 바탕으로 실제 운영되는 소프트웨어로 변환하기 위해 코드에 가까운 추상화 수준의 모듈 명세서를 작성하는 것

· 프로시저 설계는 그래픽 설계 표기법이나 프로그램 설계 언어 등을 사용하여 나타냄

그래픽 설계 표기법

그래픽 설계 표기법은 그림으로 프로시저를 상세히 설명하고 처리 절차를 기술하는 것으로 흐름도와 N-S 차트가 있음

· 흐름도(Flowchart)

· N-S 차트(Nassi-Schneiderman Chart)

- N-S차트는 논리의 기술에 중점을 둔 도형을 이용한 표현 방법으로 박스 다이어그램, Chapin Chart라고도 함

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

- GOTO나 화살표 사용하지 않음

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

- 선택과 반복 구조를 시각적으로 표현

- 이해하기 쉽고, 코드 변환이 용이

- 읽기는 쉽지만 작성 어려워, 임의로 제어를 전이하는 것은 불가능

- 총체적인 구조 표현과 인터페이스를 나타내기 어려움

- 단일 입구와 단일 출구로 표현

프로그램 설계 언어(PDL)

프로그램 설계 언어(PDL; Program Design Language)는 영어 단어를 이용하여 구조적 프로그래맹의 제어 구조를 기술하는 것이며 의사 코드 또는 구조적 영어(언어)라고 함

· 모듈의 논리를 설계할 때 사고 과정을 체계화해 가는 방법이며, 하향식 접근 방식으로 논리의 전체 흐름을 표현

· 현재 프로그래밍 언어와 유사한 서술적 표현에 의하여 프로그램, 설계, 시스템의 검토에 사용하고, 문서화 기법으로도 사용됨

· 순서도 대용으로 활용할 수 있으며 사용자와의 의사소통이 용이하게 함

· 모듈 내의 논리를 문법적 제한 없이 자유롭게 표현 가능

134 구현

① 구현 단계의 개요

구현 단계는 설계 단계에서 생성된 설계 명세서를 컴퓨터가 알 수 있는 모습으로 변환하는 과정으로, 프로그래밍 또는 코딩 단계라고도 함

· 각 모듈을 특정 프로그래밍 언어를 이용하여 원시 코드로 작성하고 문서화하는 작업

· 구현은 설계를 철저히 반영시키고, 원시 코드를 간단 명료하게 작성하며, 디버깅 및 변경, 검사가 용이하도록 해야 함

· 구현 단계에서는 사용할 프로그래밍 언어와 코딩 스타일 등을 결정해야 함

② 프로그래밍 언어

프로그래밍 언어의 분류

프로그래밍 언어의 선정 기준

③ 코딩 스타일 = 코딩의 표준화

프로그래머가 코딩하는 방법이 다르므로 이러한 코딩 방법의 일관성을 유지하고 좋은 코딩을 위해 제시된 표준을 코딩 스타일이라고 함

· 프로그램 논리를 명확하게 작성해야 함

· 지나치게 기교를 부리지 않음

· 수식은 간결하고 직접적으로 표현

· 임시 변수의 사용을 금함

· 혼동을 초래하는 변수명은 사용하지 말고, 일관성 있는 변수명 사용

· 블록 구조 사용

· 들여쓰기 사용

· 판단에 맞는 정확한 제어 구조 사용

· If뒤에 바로 If가 오지 않도록 하고, Else뒤에 Null이 되지 ㅇ낳게 함

· 모듈화와 서브루틴 사용

· 매개 변수가 5개 이상인 모듈은 유의

· 하나의 변수를 다목적으로 사용하지 않음

· 너무 깊은 중첩 구조는 피함

④ 구조적 프로그래밍

· 구조적 프로그래밍은 Dijkstra에 의해 제안된 것으로 신뢰성 있는 소프트웨어의 생산과 코딩의 표준화 등을 위해 개발된 방법

· 구조적 프로그래밍의 기본 제어 구조는 순차, 선택 반복

· 순차, 선택, 반복을 사용하면 프로그램의 복잡도를 줄여주고, 유지보수 용이

· 분기(GOTO) 없이 프로그래밍하여 읽고, 테스트하기 쉬움

· 오류 없는 프로그램 구성으로 품질 향상시킴

· 완전무결한 프로그래밍 규칙을 제공

· 생산성 증진을 통한 프로그래밍 경비를 감소시킴

· 프로그래밍 규칙

- 프로그램의 제어 흐름을 선형화

- 단일 입구와 단일 출구만을 가지게 함

- GORO문을 사용하지 않음

- 순차, 선택, 반복의 세 가지 기본 제어 구조 사용

135 검사 기법

① 검사의 개요

· 검사(Test)는 소프트웨어 품질 보증 활동의 하나로, 소프트웨어에 대한 요구사항의 만족도 및 예상 결과와 실제 결과의 차이점을 여러 방법으로 사용하여 검사하고 평가하는 일련의 과정을 의미

· 소프트웨어 품질을 평가하는 작업이며 분석이나 설계, 코딩 결과를 최종적으로 점검하는 과정

· 오류를 발견하기 위해 프로그램이나 시스템을 수행하는 과정

· 검사의 목적은 소프트웨어를 구성하는 요소들이 잘 조화를 이루며 정상적으로 동작하고 성능이 요구에 맞다는 것을 보장하기 위해서임

② 검사의 목적을 달성하기 위한 규칙

Glen Myers은 검사의 목적을 달성하기 위해 다음과 같은 규칙 제시

· 오류를 찾기 위해 프로그램을 실행시키는 절차를 검사하 함

· 오류 발견 확률을 높이기 위해 훌륭한 검사 사례를 이용

· 성공적인 검사는 아직 발견되지 않은 오류를 찾아내는 것

※ 검사 자료 : 검사 자료나 실행될 조건을 의미하는 것으로, 소프트웨어 오류를 찾아낼 수 있는 가능성이 가장 높은 테스트를 얻어내는 것

③ 검사 기법

· 검사 기법은 최소한의 시간과 노력으로 대부분의 오류를 찾아내기 위해 검사 사례를 설계하는 방법

· 검사 사례를 설계하는 검사 기법에는 화이트 박스 테스트와 블랙 박스 테스트가 있음

· 검사 사례 설계의 고려사항

- 모듈 내의 모든 독립적인 경로가 적어도 한 번은 수행되어야 함

- 가능한 한 복잡한 논리는 배제시킴

- 임의의 조건을 만족시켜야 함

- 내부 자료 구조를 사용하여 테스트를 수행함

④ 화이트 박스 테스트의 개요

화이트 박스 테스트(White Box Test)는 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 검사하여 검사 사례를 설계하는 방법

· 설계된 절차에 초점을 둔 구조적 테스트로, 프로시저(절차) 설계의 제어 구조를 사용하여 검사 사례를 설계하며, 테스트 과정의 초기에 적용됨

· 모듈 안의 작동을 직접 관찰

· 원시 코드(모듈)의 모든 문장을 한 번 이상 수행함으로써 수행됨

· 프로그램의 제어 구조에 따라 선택, 반복 등의 분기접 부분들을 수행함으로써 논리적 경로를 제어함

· 각 조건에서의 참과 거짓의 모든 논리적 결정이 적어도 한 번 이상 실행됨

· 논리 흐름도, 루프 구조, 순환 복잡도에 관한 오류를 찾을 수 있음

· 화이트 박스 테이트 기법에는 기초 경로 검사, 제어 구조 검사(조건 검사, 루프 검사, 데이터 흐름 검사) 등이 있음

⑤ 기초 경로 검사(Basic Path Testing)

· 기초 경로 검사는 Tom McCabe가 제안한 것으로 대표적인 화이트 박스 테스트 기법

· 검사 사례 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주고, 이 측정 결과는 실행 경로의 기초를 정의하는 데 지침으로 사용됨

· 기초 경로 검사 절차

① 설계나 원시 코드를 기초로 해서 흐름도를 작성

② 흐름도의 논리적 복잡도를 측정

③ 독립 경로들의 기초 집합을 결정

④ 기초 지합의 각 경로를 실행시키는 검사 사례를 선정

· 제어 흐름도

- 제어 흐름을 표현하기 위해 사용되는 그래프로 프로그램 그래프, 흐름 그래프라고 함

- 제어 흐름도는 각 제어마다 다음과 같은 기호를 사용하여 표시함

▶ 노드(원) : 절차적 명령문을 나타냄

▶ 화살표 : 제어의 흐름을 나타냄

▶ 영역 : 화살표와 노드(원)로 둘러싸인 구역으로, 외부 구역도 하나의 영역으로 포함

· 순환 복잡도

순환 복잡도는 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도로, 제어 흐름도 이론에 기초를 둠

- 순환 복잡도를 이용하여 계산된 값은 프로그램의 독립적인 경로의 수를 정의하고, 모든 경로가 한 번 이상 수행되었음을 보장하기 위해 행해지는 테스트 횟수의 상한선을 제공

- 제어 흐름도 G에서 순환 복잡도V(G)는 다음과 같은 방법으로 계산할 수 있음

▶ 순환 복잡도는 제어 흐름도의 영역 수와 일치하므로 영역 수를 계산함

▶ V(G) = E - N + 2 → E는 화살표 수, N은 노드의 수

⑥ 제어 구조 검사

· 조건 검사(Condition Testing)

- 프로그램 모듈 내에 있는 논리적 조건을 검사하는 검사 사례 설계 기법

- 프로그램에 있는 각 조건을 검사하는 데 초점을 맞추는 방법으로 조건 검사 범위 측정이 간단함

· 루프 검사(Loop Testing)

- 프로그램의 반복(Loop) 구조에 초점을 맞춰 실시하는 검사 사례 설계 기법

- 루프 검사는 단순 루프, 중첩 루프, 연결 루프, 비구조적 루프의 네 가지를 사용하여 정의할 수 있음

- 초기화 오류, 인덱싱 및 증가 오류, 경계값 오류 등을 발견할 수 있음

· 데이터 흐름 검사(Data Flow Testing)

- 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 검사 사례 설계 기법

⑦ 블랙 박스 테스트 개요

블랙 박스 테스트(Black Box Test)는 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 검사로서, 기능 검사

· 소프트웨어 인터페이스에서 실시되는 검사

· 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류, 행위나 성능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용되며 테스트 과정의 후반부에 적용됨

· 소프트웨어 산물의 각 기능별로 적절한 정보 영역(입·출력)을 정하여 적합한 입력에 대한 출력의 정확성을 점검함

· 블랙 박스 테스트의 종류에는 동치 분할 검사, 경계값 분석, 원인-효과 그래프 검사, 오류 예측 검사, 비교 검사 등이 있음

⑧ 동치 분할 검사(Equivalence Partitioning Testing)

· 동치 분할 검사는 입력 자료에 초점을 맞춰 검사 사례를 만들고 검사하는 방법으로 동등 분할 기법이라고도 함

· 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 검사 사례를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 방법

⑨ 경계값 분석(Boundary Value Analysis)

· 경계값 분석은 입력 자료에만 치중한 동치 분할 기법을 보완하기 위한 기법

· 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 검사 사례로 선정하여 검사

⑩ 원인-효과 그래프 검사(cause-effect graphing testing)

· 원인-효과 그래프 검사는 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성 높은 검사 사례를 선정하여 검사하는 기법

· 프로그램의 외부 명세에 의한 입력 조건과 입력으로부터 발생되는 출력을 논리적으로 연결시킨 그래프로 표현하여 검사함

⑪ 오류 예측 검사(fault based testing) = Mutation Testing

· 오류 예측 검사는 과거의 경험이나 확인자의 감각으로 검사하는 기법

· 다른 블랙 박스 테스트 기법으로는 찾아낼 수 없는 오류를 찾아내는 일련의 보충적 검사 기법이며, 데이터 확인 검사

⑫ 비교 검사(Comparison Testing)

여러 버전의 프로그램에 동일한 검사 자료를 제공하여 동일한 결과가 출력되는지 검사하는 기법

136 검사 전략

① 검사 전략의 개요

검사 전략은 설계된 검사 사례를 수행하는 것으로, 다음과 같은 순서에 의해 진행됨

① 단위(코드) 검사 : 검사는 프로그램의 기본 단위인 모듈(코드) 수준에서 시작

② 통합(설계) 검사 : 단위 검사 후 모듈을 겹합하여 저체 시스템에 대해 검사

③ 검증(요구사항) 검사 : 사용자의 요구사항을 충족시키는가를 검사

④ 시스템 검사 : 개발된 소프트웨어가 컴퓨터 시스템에서 오나벽하게 수행되는지를 검사 

② 단위 검사

· 단위 검사(Unit Test)는 코딩이 이루어진 후 소프트웨어 설계의 최소 단위인 모듈에 초점을 맞추어 검사하는 것

· 단위 검사는 화이트 박스 테스트 기법을 사용

· 단위 검사에서는 이터페이스, 외부적 I/O, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등을 검사

③ 통합 검사의 개요

· 통합 검사(Integration Test)는 단위 검사가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 검사를 의미

· 통합 검사는 모듈 간의 인터페이스와 연관된 오류를 밝히기 위한 검사 기법

· 통합 검사 방법에는 다음과 같이 비점진적 통합 방식과 점진적 통합 방식

④ 하향식 통합 검사(Top Down Integration Test)

하향식 통합 검사는 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 검사하는 기법

· 주요 제어 모듈(주요 프로그램)을 기준으로 하여 아래 단계로 이동하면서 통합되는데, 이때 깊이 우선 통합법이나 넓이 우선 통합법을 사용할 수 있음

· 하향식 통합 방법 수행 절차

① 주요 제어 모듈을 드라이버로 사용하고, 주요 제어 모듈의 종속 모듈들은 스터브(Stub)로 대체함

② 깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 종속 스터브들이 실제 모듈로 교체됨

③ 모듈이 통합될 때마다 검사를 실시함

④ 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 검사(전에 수행된 검사의 일부나 전체를 다시 검사하는 것)를 실시함

※ 하향식 통합 방법

· 깊이 우선 통합법 : 주요 제어 모듈을 중심으로 이 모듈에 종속된 모든 모듈을 통합하는 것

· 넓이 우선 통합법 : 구조의 수평을 중심으로 해당하는 모듈을 통합하는 것

· 드라이버(Driver) : 검사 사례 자료를 입력 받고, 검사를 위해 받은 자료를 모듈로 넘기며, 관련된 결과를 출력하는 제어 프로그램

· 스터브(Stub) : 일시적으로 필요한 조건만을 가지고 임시로 제공되는 가짜 모듈, 즉 시험용 모듈

· 스터브(Stub) 사용 이유 : 하향식 통합 방식에서는 먼저 상위의 주요 제어 모듈을 검사하게 되는데, 이 때 주요 제어 모듈은 이에 종속된 모듈이 모두 결합되어야 정상적으로 검사될 수 있음. 그러므로 주요 제어 모듈이 정상적으로 운용되도록 스터브를 사용하는 것

⑤ 상향식 통합 검사(Bottom up integration Test)

상향식 통합 검사는 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 검사하는 기법

· 가장 하위 단계의 모듈부터 통합 및 검사가 수행되므로 스터브는 필요하지 않지만, 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터가 필요함

· 상향식 통합 방법 수행 절차

① 하위 모듈들을 클러스터로 결합

② 검사 사례 입·출력을 조정하기 위해 드라이버 작성

(드라이버 작성 : 주요 제어 모듈이 있어야 프로그램이 동작하게 되는데, 상향식 통합 검사에서는 하위 모듈에서 상위 모듈로 통합·검사되므로 클러스터를 시험하기 위한 제어 프로그램이 필요)

③ 클러스터 검사

④ 드라이버 제거하고, 클러스터는 프로그램 구조의 상위로 이동하여 결합

⑥ 혼합식 통합 검사

혼합식 통합 검사는 하위 수준에서 상향식 통합, 상위 수준에서 하향식 통합을 사용하여 최적의 검사를 지원하는 방식으로 샌드위치식 통합 검사 방법

⑦ 검증 검사(확인 검사, 인수 검사)

· 검증 검사(Validation Test)는 소프트웨어가 사용자의 요구사항을 충족시키는가에 중점을 두고 검사하는 방법

· 통합 검사가 끝난 후 전체가 하나의 소프트웨어로 통합되어 요구사항 명세서를 토대로 진행하며, 블랙 박스 테스트를 이용하여 진행

· 검증 검사 기법

⑧ 시스템 검사

· 시스템 검사(System Test)는 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 검사하는 것

· 시스템 검사의 종류

⑨ 디버깅(Debugging)

디버깅은 검사 단계에서 검사 사례에 의해 오류를 찾은 후 그 오류를 수정하는 과정이며 검사 기법은 아님

· 디버깅은 성공적인 검사 결과로 발생함

· 디버깅은 인간의 심리적인 요소가 많이 관여하기 때문에 매우 어려움

디버깅 접근법

· 맹목적 강요 : 디버깅할 수 있는 모든 방법을 동원하여도 실패하게 된 경우에 사용되는 가장 비효율적인 방법

· 역추적(Backtracking) : 오류가 발견된 위치에서 원인이 발견될 때까지의 코딩 부분으로 거슬러 올라가면서 수정하는 가장 닐반적인 방법이며, 작은 프로그램에서 성공적으로 사용할 수 있음

· 원인 제거(Cause Elimination) : 오류 가능성이 있는 원인을 제거하여 버그를 분리하기 위해 사용

137 유지보수

① 유지보수의 개요

유지보수(Maintenance)는 개발된 소프트웨어의 품질을 항상 최상의 상태로 유지하기 위한 것으로, 소프트웨어 개발 단계 중 가장 많은 노력과 비용이 투입되는 단계

· 유지보수는 소프트웨어가 사용자에게 인수되어 설치된 후 발생하는 모든 공학적 작업

· 소프트웨어 유지보수를 용이하게 하려면 시험 용이성, 이해성, 수정 용이성, 이식성 등이 고려되어야 함

· 유지보수는 수리 보수, 적응 보수, 완전화 보수, 예방 보수 활동으로 구분 할 수 있고, 이 활동을 통해 소프트웨어의 수명은 연장시키는 작업

② 유지보수의 과정

① 유지보수 요구 : 유지보수 활동이 필요할 경우 이에 대한 요구를 수행

② 현 시스템에 대한 이해 : 요구된 유지보수 활동을 수행하기 위해서는 먼저 현재 시스템에 대한 이해를 필요로 하며, 현재 시스템에 대해 이해하지 못한 상태에서 유지보수 활동을 수행하면 오류가 발생할 수 있음

③ 수정 및 시험 : 유지보수 활동을 수행하고, 유지보수 활동을 수행한 후에도 정상적으로 기능이 수행되는지를 확인하기 위해 테스트

③ 유지보수의 비용

· 소프트웨어 유지보수 단계에서 사용되는 비용은 소프트웨어 개발에 필요한 비용 중 약 70%를 차지함

· 유지보수 비용은 분석, 평가, 설계 변경, 코딩 등의 생산적인 활동과 프로그램과 자료 구조의 이해, 인터페이스의 특성 파악, 성능 측정 등의 실험 활동에 따라 달라질 수 있음

· 유지보수 비용은 일반적으로 bl 방법에 의해 다음과 같은 산정함

④ 유지보수의 문제점

· 다른 사람이 개발한 소프트웨어는 이해하기가 어려울 뿐만 아니라 소프트웨어 개발자들의 이직률이 높기 때문에 개발된 소프트웨어에 대한 전문적인 설명을 들을 수가 없음

· 소프트웨어에 대한 변경이 자주 발생하므로 변경된 내용을 문서화하지 않을 경우 추적하기 어려움

· 소프트웨어에 대한 적절한 문서가 없거나 문서의 질이 형편없을 수도 있음

· 대부분의 소프트웨어는 변경 가능하도록 설계되지 않음

· 유지보수는 매혹적인 작업이 아니므로 기피하는 경향이 있음

※ 유지보수의 부작용 / 외계인 코드

유지보수의 부작용 : 유지보수 활동을 통해 예기치 못한 부작용이 발생될 수 있음

· 코딩 부작용 : 코딩 내용의 변경으로 인해 발생하는 부작용

· 자료 부작용 : 자료나 자료 구조의 변경으로 인해 발생하는 부작용

· 문서화 부작용 : 자료 코드에 대한 변경이 설계문서나 사용자가 사용하는 매뉴얼에 적용되지 않을 때에 발생하는 부작용

외계인 코드(Alien Code)

· 외계인 코드는 아주 오래 전에 개발되어 유지보수 작업이 매우 어려운 프로그램을 의미

· 일반적으로 15년 전 또는 그 전에 개발된 프로그램을 의미하며, 문서화를 철저하게 해 두면 외계인 코드 방지 가능

출처 : 2017 시나공 정보처리기사 필기

정보처리기사 필기 - 4과목 소프트웨어 공학

2장 소프트웨어 프로젝트 관리

117 프로젝트 관리의 개요

① 프로젝트 관리의 개념

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

· 프로젝트 관리는 소프트웨어 개발 계획을 세우고 분석, 설계, 구현 등의 작업을 통제하는 것으로 소프트웨어 생명 주기의 전 과정에 걸쳐 진행됨

· 소프트웨어 프로젝트를 성공적으로 수행하기 위해서는 수행할 작업의 범위, 필요한 자원, 수행 업무, 이정표, 비용 추진 일정들을 알아야 함

※ 프로젝트 관리는 제한된 시간과 비용으로 좋은 품질의 시스템을 개발하여 고객에게 제공함

② 프로젝트 관리 대상

· 계획 관리 : 프로젝트 계획, 비용 산정, 일정 계획, 조직 계획

· 품질 관리 : 품질 통제, 품질 보증

· 위험 관리 : 위험 식별, 위험 분석 및 평가, 위험 관리 계획, 위험 감시 및 조치

※ 효과적인 프로젝트 관리를 위한 3P(3대 요소)

· 사람(People) : 프로젝트 관리에서 가장 기본이 되는 인적 자원

· 문제(Problem) : 사용자 입장에서 문제를 분석하여 인식함

· 프로세스(Process) : 소프트웨어 개발에 필요한 전체적인 작업 계획 및 구조(Framework)

③ 프로젝트 관리의 구성 단계

[그림 1] 프로젝트 관리의 구성 단계

① 프로젝트 계획 수립

· 프로젝트의 목적을 기술하고, 이를 달성하기 위해 필요한 업무와 성취해야 할 일들을 결정

· 프로젝트를 정의하고 프로젝트 일정 계획, 소요 자원 예측, 위험 평가, 프로젝트에 대한 승인 얻어냄

② 프로젝트 가동

· 프로젝트가 수행될 환경을 구성학 프로젝트에 참여할 인력을 교육시킴

· 프로젝트를 진행할 조직을 구성하고 각 팀원을 선발함

③ 프로젝트 통제

· 계획 대비 프로젝트의 척도를 점검하고, 변경 사항을 승인하는 등의 작업 수행

(척도 : 시스템, 컴포넌트(구성 요소) 또는 프로세스가 요구된 속성을 어느 정도 만족하는 가에 대한 수량적인 측정치)

· 프로젝트 전 기간 동안 수행됨

④ 프로젝트 종료

· 수행 결과의 완전성을 점검하고 프로젝트 종료 

118 프로젝트 계획 수립

① 프로젝트 계획 수립의 개요

프로젝트 계획은 프로젝트가 수행되기 전에 소프트웨어 개발 영역 결정, 필요한 자원, 비용, 일정 등을 예측하는 작업

· 관리자가 자원, 비용, 일정 등을 합리적으로 예측할 수 있도록 프로젝트 틀(Framework)를 제공

· 프로젝트 계획 수립을 통해 소프트웨어 개발 과정에서 발생할 수 있는 여러 가지 위험성을 최소화할 수 있음

· 프로젝트 계획 수립 후에는 시스템 정의서와 프로젝트 계획서가 산출됨

· 프로젝트 계획에 따라 소프트웨어의 품질이 결정되므로, 계획 단계에서 프로젝트 관리자의 임무는 매우 중요함

※ 시스템 정의서에 포함되는 내용 : 문제 기술, 시스템 정당화, 프로젝트 목표, 제약 사항, 추진 전략 등

※ 프로젝트 계획서에 포함되는 내용 : 생명 주기 모델, 기본 일정, 예산, 팀의 구성, 관리 기준, 완료 조건 등

② 시스템 개발 영역(Scope, 범위) 결정

· 프로젝트 계획 수립의 첫 번째 임무로, 개발될 소프트웨어의 영역을 결정

· 소프트웨어의 개발 영역을 결정하는 주요 요소에는 처리될 데이터와 소프트웨어에 대한 기능, 성능, 제약 조건, 인터페이스 및 신뢰도 등

※ 제약 조건 : 외부 하드웨어, 가용 메모리, 다른 시스템들에 의해 소프트웨어에 가해진 제한 사항

※ 인터페이스에 포함되는 사항

· 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 프로세서나 하드웨어

· 운영체제, 서브루틴 패키지와 같이 새로운 소프트웨어에 연결되어야 하는 소프트웨어

· 키보드나 기타 I/O 장치들을 통하여 소프트웨어를 사용하는 사람

· 순서적인 연산에 의해 소프트웨어를 실행하는 절차 

③ 자원 추산

소프트웨어 개발에 필요한 자원을 예측하는 것

④ 소프트웨어 프로젝트 추산

소프트웨어 프로젝트 추산은 프로젝트 수행에 필요한 비용을 예측하는 것으로 신뢰할 만한 비용을 예측하기 위해서 다음과 같은 방법 사용

· 프로젝트 관리의 후반가지 프로젝트 예측을 가능한 한 연기함

· 이미 수행된 유사 프로젝트 참고

· 프로젝트를 상대적으로 잘게 분리하여 예측하는 분해 기법 사용

· 하나 이상의 경험적 예측(실험) 모델을 활용

· 자동화 도구를 도입하여 활용

⑤ 프로젝트 계획 수립 시 고려사항

· 프로젝트 복잡도

· 프로젝트 규모

· 구조적 불확실성의 정도

· 과거 정보의 가용성

· 위험성

119 소프트웨어 프로젝트 추산

① 소프트웨어 프로젝트 추산의 개요

소프프웨어 프로젝트 추산은 프로젝트를 수행하는 데 필요한 소프트웨어의 직·간접적인 비용을 예측하는 작업

· 소프트웨어 공학 분야 중에서 가장 어렵고 오차 발생이 심한 작업

· 소프트웨어 개발 단계에서 확인되지 않거나 고려하지 못한 요소들이 많기 때문에 정확한 비용을 예측하기는 어려움

· 소프트웨어의 측정 요소

② 프로젝트 비용 결정 요소

프로젝트 요소

어떤 소프트웨어를 개발할 것인가에 따라 비용이 달라질 수 있음

· 제품의 복잡도 : 소프트웨어의 종류(응용·유틸리티·시스템 소프트웨어 등)에 따라

· 시스템의 크기 : 소프트웨어의 규모(대형·소형 소프트웨어)에 따라

· 요구되는 신뢰도 : 신뢰도는 프로그램이 일정한 기간 내에 주어진 조건하에서 필요한 기능을 수행하는 정도를 의미

자원 요소

소프트웨어 개발에 필요한 각종 자원들의 투자정도에 따라 비용이 달라질 수 있음

· 인적 자원 : 관리자, 개발자의 능력 혹은 자질

· 하드웨어 자원 : 개발 장비나 워드프로세서, 프린터와 같은 보조 장비

· 소프트웨어 자원 : 언어 분석기, 문서화 도구, 요구 분석기 등과 같은 개발 지원 도구

생산성 요소

· 개발자의 능력: 전문 분야에 대한 지식, 유사 분야에 대한 경험, 응용 분야에 대한 이해도, 책임감, 창의력 등

· 개발 기간 : 소프트웨어를 개발하는 기간

120 비용 산정 기법

① 하향식 비용 산정 기법

과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법

· 프로젝트 전체 비용을 산정한 후 각 작업별로 비용을 세분화함

· 하향식 비용 산정 기법에는 전문가 감정 기법, 델파이 기법 등이 있음

전문가 감정 기법

조직 내에 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법

· 가장 편리하고 신속하게 비용 산정 가능, 의뢰자로부터 믿음을 얻을 수 있음

· 새로운 프로젝트에는 과거의 프로젝트와 다른 요소들이 있다는 것을 간과할 수 있음

· 새로운 프로젝트와 유사한 프로젝트에 대한 경험이 없을 수 있음

· 개인적이고 주관적일 수 있음

델파이 기법

전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법

· 전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성됨

· 비용 산정 순서

① 조정자는 각 비용 산정 요원에게 시스템 정의서와 산정한 비용 내역을 기록할 서식 제공

② 산정 요원들은 정의서를 분석하여 익명으로 그들 나름대로의 비용 산정

③ 조정자는 산정 요원들의 반응을 요약하여 배포함

④ 산정 요원들은 이전에 산정한 결과를 이용하여 다시 익명으로 산정

⑤ 요원들 간의 의견이 거의 일치할 때까지 이 과정을 반복

② 상향식 비용 산정 기법

상향식 비용 산정 기법은 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법

· 상향식 비용 산정 기법에는 LOC(원시 코드 라인 수) 기법, 개발 단계별 인월수 기법, 수학적 산정 기법

LOC(원시 코드 라인 수) 기법

LOC 기법은 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 작관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법

※ 비관치 : 가장 많이 측정된 코드 라인 수 / 낙관치 : 가장 적게 측정된 코드 라인 수 / 기대치 : 측정된 모든 코드 라인의 평균

· 측정이 용이하고 이해하기 쉬워 가장 많이 사용됨

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

예측치 = (a+4m+b)/6 (단, a:낙관치, b:비관치, c:기대치(중간치))

· 산정 공식

- 노력(인월) = 개발 기간 × 투입 인원

= LOC / 1인당 월 평균 생산 코드 라인 수

- 개발 비용 = 노력(인월) × 단위 비용(1인당 월평균 인권비)

- 개발 기간 = 노력(인월) / 투입 인원

- 생산성 = LOC / 노력(인월)

개발 단계별 인월수(Effort Per Tack)기법

· LOC 기법을 보완하기 위한 기법으로, 각 기능을 구현시키는 데 필요한 노력(인월)을 생명 주기의 각 단계별로 산정

· LOC 기법보다 더 정확함

121 수학적 산정 기법

① 수학적 산정 기법의 개요

· 수학적 산정 기법은 상향식 비용 산정 기법을 경험적 추정 모형, 실험적 추정 모형이라고도 하며, 개발 비용 산정의 자동화를 목표로 함

· 수학적 산정 기법에는 COCOMO 모형, Putnam 모형, 기능 점수(FP) 모형 등이 있으며 각 모형에서는 지정된 공식을 사용하여 비용 산정

· 비용을 자동으로 산정하기 위해 사용되는 공식은 과거 유사한 프로젝트를 기반으로하여 경험적으로 유도된 것

② COCOMO 모형 개요

COCOMO(COnstructive COst MOdel) 모형은 보헴(Boehm)이 제안한 것으로 원시 프로그램의 규모인 LOC에 의한 비용 산정 기법

· 개발할 소프트웨어의 규모(LOC)를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식(공식)에 대입하여 비용 산정

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

· 같은 규모의 프로그램이라도 그 성격에 따라 비용이 다르게 산정됨

· 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력으로 나타남

③ COCOMO의 소프트웨어 개발 유형

소프트웨어 개발 유형은 소프트웨어의 복잡도 혹은 원시 프로그램의 규모에 따라 조직형, 반분리형, 내장형으로 분류됨

· 조직형(Organic Model)

- 조직형은 기관 내부에서 개발된 중·소 규모의 소프트웨어로 일괄 자료 처리나 과학 기술 계산용, 비즈니스 자료 처리용으로 5만(50KDSI)라인 이하의 소프트웨어를 개발하는 유형

※ KDSI(Kilo Delivered Source Instruction) : 전체 라인 수를 1,000라인 단위로 묶은 것으로 KLOC(Kilo LOC)와 같은 의미

- 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합

- 비용 산정 공식

노력(MM) = 2.4 × (KDSI)1.05    개발기간(TDEV) = 2.5 × (MM)0.38

· 반분리형(Semi-Detached Model)

- 반분리형은 조직형과 내장형의 중간형으로 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형

- 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합

- 비용 산정 공식

노력(MM) = 3.0 × (KDSI)1.12    개발기간(TDEV) = 2.5 × (MM)0.35

· 내장형(Embedded Model)

- 내장형은 최대형 규모의 트랜잭션 처리 시스템이나 운영체제 등의 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형

- 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합

- 비용 산정 공식

노력(MM) = 3.6 × (KDSI)1.20     개발기간(TDEV) = 2.5 × (MM)0.32

④ COCOMO 모형의 종류

COCOMO는 비용 산정 단계 및 적용 변수의 구체화 정도에 따라 기본, 중간, 발전형으로 구분

· 기본(Basic)형 COCOMO

기본형 COCOMO는 소프트웨어의 크기(생산 코드 라인 수)와 개발 유형만을 이용하여 비용을 산정하는 모형

- 산정 공식

▶ 개발 노력(Effort, MM, PM) = a × (KDSI)b

▶ 개발 기간(TDEV) = c × (MM)d

▶ 적정 투입 인원(FPS) = MM / TDEV

▶ 인적 비용(COST) = MM × 1인당 월평균 급여

· 중간(Intermediate)형 COCOMO

중간형 COCOMO는 기본형의 공식을 토대로 사용하나, 다음 4가지 특성의 15가지 요인에 의해 비용을 산정하는 모형

- 제품의 특성 : 요구되는 신뢰도, 데이터베이스 크기, 제품의 복잡도

- 컴퓨터의 특성 : 수행 시간의 제한, 기억장소의 제한, 가상 기계의 안정성, Turn Around Time

- 개발 요원의 특성 : 분석가의 능력, 개발 분야의 경험, 가상 기계의 경험, 프로그래머의 능력, 프로그래밍 언어의 경험

- 프로젝트 특성 : 소프트웨어도구의 이용, 프로젝트 개발 일정, 최신 프로그래밍 기법의 이용

- 산정 공식

▶ 개발 노력(MM) = 기본 COCOMO의 MM × 요인별 노력 승수

▶ 개발 기간(TDEV) = c × (MM)d

▶ 적정 투입 인원(FPS) = MM / TDEV

▶ 인적 비용(COST) = MM × 1인당 월평균 급여

· 발전(Detailed)형 COCOMO

발전형 COCOMO는 중간형을 보완하여 만들어진 방법으로 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정하는 모형

- 소프트웨어 환경과 구성 요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 적용

- 산정 공식 : 중간형 산정 공식을 그대로 사용하되, 노력 승수를 다음과 같이 적용하여 산정

노력 승수 = 개발 공정별 노력 승수 × 개발 공정별 가중치

⑤ Putnam 모형

Putnam 모형은 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 가정해주는 모형

· Putnam이 제안한 것으로 생명 주기 예측 모형이라고도 함

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

· 대형 프로젝트의 노력 분포 산정에 이용되는 기법

· 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소

· 산정 공식

개발 노력(MM) = L3 / (CK3 · Td4)

(L : 원시 코드 라인 수, Td : 개발 기간, CK : 환경 상수(빈약 환경=2,000, 좋은 환경=8,000, 최적 환경=12,000))

⑥ 기능 점수(FP) 모형

· 기능 점수 모형은 Albrecht가 제안한 것으로, 소프트웨어 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며 총 기능 점수와 영향도를 이용하여 기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정하는 기법

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

· 최근에 유용성과 간편성으로 비용 산정 기법 가운데 최선의 평가 받고 있음

· 기능별 가중치

※ 자동화 추정 도구

· SLIM : Rayleigh - Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구

· ESTIMACS : 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구

122 프로젝트 일정 계획

① 개요

프로젝트 일정 계획은 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하며, 소작업의 순서와 일정을 정하는 것

· 소프트웨어 개발 기간의 지연을 방지하고 프로젝트가 계획대로 진행되도록 일정을 계획

· 계획된 일정은 프로젝트의 진행을 관리하는 데 기초 자료가 됨

· 계획된 일정과 프로젝트의 진행도를 비교하여 차질이 있을 경우 여러 조치를 통해 조정 가능

· 프로젝트 일정 계획을 위해서는 WBS, PERT/CPM, 간트 차트 등이 사용됨

② 기본 원칙

· 분할 : 프로젝트는 관리 가능한 여러 개의 작업들로 분할되어야 함

· 상호 의존성 : 분할된 각 작업들 간에 어떤 관계가 있는지 상호 의존성이 결정되어야 함

· 시간 할당 : 각 직업에 시간을 할당해야 함

· 노력 확인 : 소프트웨어 개발에 참여할 팀원들에 맞게 시간이 할당되었는지 확인해야 함

· 책임성 : 계획된 작업은 특정 팀에게 할당되어야 함

· 정의된 산출물·이정표 : 각 작업들은 정의된 산출물과 이정표를 가지고 있어야 함

③ 사람-노력 관계와 노력 분배

사람-노력 관계

· 소규모의 개발 프로젝트에서는 한 사람이 요구사항을 분석하고 설계, 코딩, 테스트까지 수행 가능

· 프로젝트 크기가 증가할수록 더 많은 사람들이 참여해야 함

· 프로젝트 진행중에 새로운 인력을 투입할 경우 작업 적응 기간과 부작용으로 인해 일정을 더욱 지연시키고, 프로젝트에 혼란을 가져오게 됨

※ Brooks의 법칙 : 프로젝트 진행주엥 새로운 인력을 투입하면 일정이 더 지연됨

노력 분배

· 예측된 노력을 각 개발 과정에 분배할 때는 40-20-40 규칙으 권장하며, 이는 분석과 설계에 40%, 코딩에 20%, 테스트에 40%를 분배

· 일반적으로 노력은 요구 분석이 10~25%, 설계가 20~25%, 코딩이 15~25%, 테스팅과 디버깅이 30~40%를 차지함

④ WBS(Work Breakdown Structure, 업무 분류 구조)

WBS는 개발 프로젝트를 여러 개의 작은 관리 단위로 분할하여 계층적으로 기술한 업무 구조

· 일정 계획의 첫 단계에서 작업을 분할할 때 사용되는 방법

· 계획 관리 단계에서 일정 계획과 인력 계획, 비용 산정의 기준이 됨

· 프로젝트 진행중에 발생하는 모든 작업을 알 수 있음

· 제품의 계층 구조 또는 프로세스의 계층 구조로 나타냄

⑤ PERT/CPM의 개요

PERT/CPM 네트워크는 프로젝트의 지연을 방지하고 계획대로 진행되게 하기 위한 일정을 계획하는 것으로, 대단위 계획의 조직적인 추진을 위해 자원의 제약하에 비용을 적게 사용하면서 초단시간 내 계획 완성을 위한 프로젝트 일정 방법

·  프로젝트 개발 기간을 결정하는 임계 경로를 제공(임계경로 : 하나의 제품을 개발하기 위한 여러 경로 중 제품이 완성되기까지, 가장 많은 기간을 소요하는 경로)

· 통계적 모델을 적용해서 개별 작업에 대한 가장 근접한 시간을 측정하는 기준이 됨

· 각 작업에 대한 시작 시간을 정의하여 작업들 간의 경계 시간을 계산할 수 있게 함

※ PERT와 CPM 모두 일정 관리를 위해 개발된 기법으로 PERT는 주로 소요 시간 예측이 어려운 경우, CPM은 소요 시간이 확실한 경우에 이용※ PERT/CPM 네트워크를 통해 계산될 수 있는 경계 시간들

· 모든 선행 작업들이 가능한 한 최단시간 내에 완성될 때 한 작업이 시작될 수 있는 가장 빠른 시간

· 최소의 프로젝트 완료 시간이 지연되기 전에 자업 개시를 위한 가장 늦은 시간

· 가장 빠른 완료 시간 : 가장 빠른 개시 시각과 작업 기간의 합

· 가장 늦은 완료 시간 : 가장 늦은 개시 시각과 작업 기간의 합

· 총 자유 시간 : 네트워크 임계 경로를 일정대로 유지하기 위해 작업에 허용된 잉여 시간의 양인 전체 여유 시간

⑥ PERT(Program Evaluation and Review Technique, 프로그램 평가 및 검토 기술)

PERT는 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크로 각 작업별로 낙관적인 경우, 가능성이 있는 경우, 비관적인 경우로 나누어 각 단계별 종료 시기를 결정하는 방법

· 과거에 경험이 없어서 소요 기간 예측이 어려운 소프트웨어에서 사용

· 노드와 간선으로 구성되며 원 노드에는 작업을, 간선(화살표)에는 낙관치, 기대치, 비관치를 표시

· 결정 경로, 작엄데 대한 경계 시간, 작업 간의 상호 관련성등을 알 수 있음

· 작업 예측치를 계산하는 PERT 공식

작업 예측치 = (비관치+4×기대치+낙관치/6)    평방 편차 = [(비관치-낙관치)/6]2

⑦ CPM(Criticla Path Method, 임계 경로 기법)

CPM은 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법

· CPM은 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타냄

· 원형 노드가 각 작업을 의미하며 각 작업 이름과 소요 기간을 표시하고, 박스 노드는 이정표를 의미하며 박스 노드 위에는 예상 완료 시간을 표시

· 간선을 나타내는 화살표의 흐름에 따라 각 작업이 진행되며, 전 작업이 완료된 후 다음 작업을 진행할 수 있음

· 각 작업의 순서와 의존 관계, 어느 작업이 동시에 수행될 수 있는지를 한눈에 볼 수 있음

· 경영층의 과학적인 의사 결정을 지원하며, 효과적인 프로젝트의 통제를 가능하게 해줌

※ CPM 네트워크를 사용한 일정 계획의 순서

① 프로젝트의 규모 추정

② 각 단계에서 필요한 작업들을 분할

③ 각 작업의 상호 의존 관계를 CPM 네트워크로 나타냄

④ 일정 계획을 간트 차트로 나타냄

⑧ 간트 차트(Gantt Chart)

간트 차트는 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로제트 일정표로, 시간선차트라고도 함

· 중간 목표 미달성시 그 이유과 기간을 예측할 수 있게 함

· 사용자와의 문제점이나 예산의 초과 지출 등도 관리 가능

· 자원 배치와 인원 계획에 유용하게 사용됨

· 다양한 형태로 변경하여 사용 가능

· 작업 경로는 표시할 수 없으며, 계획의 변화에 대한 적응성이 약함

· 계획 수립 또는 수정 때 주관적 수치에 기울어지기 쉬움

· 간트 차트는 이정표, 작업 일정, 작업 기간, 산출물로 구성되어 있음

· 수평 막대의 길이는 각 작업의 기간을 나타냄

123 프로젝트 조직 구성 계획

① 프로젝트 조직 구성 계획

· 프로젝트 조직 구성 계획은 프로젝트를 수행하기 위해 참여하는 각 구성원들의 역할을 할당하고 서로 어떤 방법을 통해 협력할 것인가를 정의하는 것

· 프로젝트를 완성하기 위해서는 프로젝트 단위로 팀을 구성하여 수행함

· 프로젝트 수행 기간, 작업의 특성, 팀 구성원 사이의 의사 교류 횟수에 의해팀 구성 방법이 달라질 수 있음

· 프로젝트 팀 구성은 의사 결정권이 누구에게 있느냐에 따라 분산형 팀 구성, 중앙 집중형 팀 구성, 계층적 팀 구성으로 나눌 수 있음

② 분산형 팀 구성

분산형 팀 구성은 팀원 모두가 의사 결정에 참여하는 비이기적인 구성 방식으로, 민주주의식 팀 구성이라고도 함

· 의사 결정을 민주주의식으로 하여 팀 구성원의 참여도와 작업 만족도를 높이고 이직률을 낮게 함

· 팀 구성원 각자가 서로의 일을 검토하고 다른 구성원이 일한 결과에 대하여 같은 그룹의 일원으로서 책임을 짐

· 여러 사람이 의사를 교류하므로 복잡하고 이해되지 않는 문제가 많은 장기 프로젝트 개발에 적합

· 링 모양의 구조를 가지며 이는 모든 구성원이 동등한 레벨에 있음을 보여줌

· 팀 구성 방법 중 가장 많은 의사 소통 경로를 갖는 구조

의사 소통 경로의 수 = n(n-1)/2

· 다양한 의사 교류오 인해 의사 결정 시간이 늦어지고, 개개인의 생산성 및 책임감이 낮아질 수 있음

③ 중앙 집중형 팀 구성

중앙 집중형 팀 구성은 한 관리자가 의사 결정을 하고 팀 구성원들은 그 결정에 따르는 구성 방식으로, 책임 프로그래머 팀 구성이라고 함

· 프로젝트 수행에 따른 모든 권한과 책임을 한 명의 관리자(책임(고급) 프로그래머)에게 위임하고, 기술 및 관리 지원을 위해 인력을 투입하는 형태

· 책임 프로그래머에 따라 의사 결정이 이루어지기 때문에 의사 결정이 빠르고, 의사 교환 경로를 줄일 수 있음

· 한 사람에 의해 통제할 수 있는 비교적 소규모 프로젝트에 적합

· 프로젝트의 성공은 책임 프로그래머의 능력에 달려 있음

· 중앙 집중형 팀 구성에서 각 구성원의 역할

④ 계층적 팀 구성

계층적 팀 구성은 분산형 팀 구성과 중앙 집중형 팀 구성을 혼합한 형태로, 혼합형 팀 구성이라고 함

· 5~7명의 초급 프로그래머를 작은 그룹으로 만들어 각 그룹을 고급 프로그래머가 관리하게 함

· 경험자와 초보자를 구별함

· 프로젝트 리더와 고급 프로그래머에게 지휘 권한을 부여하고, 의사 교환은 초급 프로그래머와 고급 프로그래머로 분산함

· 기술 인력이 관리를 담당하게 되어 좋은 기술력을 사장시킬 수 있으며, 기술 인력이 업무 관리 능력을 갖춰야 한다는 단점이 있음

124 소프트웨어 품질 보증

① 소프트웨어 품질과 품질 관리

· 소프트웨어 품질(Quality) : 주어진 요구사항을 만족시키는 능력을 갖추고 있는 소프트웨어의 측적 가능한 기능 및 특성을 의미

· 소프트웨어 품질 관리(Quality Control) : 주어진 요구사항에 맞는 소프트웨어를 개발하기 위해 소프트웨어 개발의 전 과정 동안에 이루어지는 모든 활동과 그 활동의 결과로 생산되는 산출물에 대한 품질을 통제하고 보증하기 위한 작업

② 품질 표준(목표)

· 품질 표준(목표)은 명확하게 정의된 소프트웨어의 특성을 의미하며, 소프트웨어의 품질을 평가하는 기준 항목으로 사용됨

③ 소프트웨어 품질 보증(SQA; Software Quality Assurance)

· 소프트웨어 품질 보증은 어떠한 소프트웨어가 이미 설정된 요구사항과 일치하는가를 확인하는 데 필요한 개발 단계 전체에 걸친 계획적이고 체계적인 작업

· 소프트웨어 품질 보증 활동은 소프트웨어 개발 초기에 소프트웨어의 특성과 요구사항을 철저히 파악하여 품질 목표를 설정하고, 개발 단계에서는 정형 기술 검토를 통하여 품질 목표의 충족 여부를 점검하며, 개발 후에는 디버깅과 시험 과정을 거침

④ 정형 기술 검토의 개요(FTR; Formal Technicla Review)

· 정형 기술 검토는 가장 일반적인 검토 방법으로 소프트웨어 기술자들에 의해 수행되는 소프트웨어 품질 보증 활동

· 정형 기술 검토 유형에는 검토 회의, 겸열 등이 있으며 이는 모두 회의 형태로 수행됨

목적

· 검토중인 소프트웨어가 해당 요구사항과 일치하는지를 검증

· 소프트웨어가 미리 정해진 표준에 따라 표현되고 있는지를 확인하고, 기능과 로직에 오류가 있는지 확인·발견

· 소프트웨어가 균일한 방식으로 개발되도록

· 프로젝트를 보다 용이하게 관리하도록

⑤ 정형 기술 검토의 지침 사항

· 제품의 검토에만 집중

· 의제를 제한하여 진행

· 논쟁과 반박을 제한

· 문제 영역을 명확히 표현

· 해결책이나 개선책에 대해서는 논하지 말라

· 참가자의 수를 제한하고 사전 준비를 강요

· 검토될 확률이 있는 각 제품에 대한 체크 리스트를 개발

· 자원과 시간 일정을 할당

· 모든 검토자들을 위해 의미있는 훈련을 행하라

· 검토자들은 사전에 작성한 메모를 공유

· 검토의 과정과 결과를 재검토

⑥ 정형 기술 검토 유형

검토 회의(Walkthrough)

· 소프트웨어 개발의 각 단계에서는 개척하는 기술 평가 회의로, 소프트웨어 구성 요소와 같은 작은 단위를 검토하는 것

· 오류의 조기 검출을 목적으로 하며 발견된 오류는 문서화

· 검출된 오류는 검토 회의 기간 동안에 해결하지 않고 미뤄 두었다가 검토 회의 후에 해결

· 3~5명이 검토에 참여해야 하며 검토 회의 시간은 두 시간 이내로 해야 함

· 검토를 위한 자료를 미리 배포하여 검토하도록 하며, 미리 검토하는 시간은 2시간 이내

검열(Inspections, 심사)

· 검토 회의를 발전시킨 형태로, 소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가하며 이를 개선시키는데 사용

· 검열 팀은 관련 분야에 대해 훈련을 받은 1~4명의 요원으로 구성되며, 검열자는 검열 항목에 대한 체크 리스트를 이용해 작업 수행

125 소프트웨어의 신뢰성과 가용성

① 소프트웨어의 신뢰성과 가용성

· 신뢰성 : 프로그램이 주어진 환경에서 주어진 시간 동안 오류 없이 작동활 확률

· 소프트웨어의 품질을 평가하는 다른 품질 표준과는 달리 과거의 자료와 개발상의 자료를 이용하여 측정과 예측 가능

· 하드웨어 신뢰성 측정의 기본 이론을 근거로 측정

· 가용성(신뢰도)는 한 프로그램이 주어진 시점에서 요구사항에 따라 운영되는 확률

② 신뢰성과 가용성 측정

· 소프트웨어의 간단한 신뢰성 측정은 MRBF 이용

· 가용성(신뢰도) 측정 : 시스템의 총 운용 시간 중 정상적으로 가동된 시간의 비율

126 위험 관리

① 위럼 관리(Risk Analysis)

위험 관리는 프로젝트 추진 과정에서 예상되는 각종 돌발 상황(위험)을 미리 예상하고 이에 적절한 대책을 수립하는 일련의 활동

· 위험은 불확실성과 손실을 내재하고 있는데, 위험 관리는 이러한 위험의 불확실성을 감소시키고 손실에 대비하는 작업

· 위험을 식별한 후 발생 확률을 산정하고, 그 영향을 추산하여 해당 위험에 대비하는 비상 계획을 마련

· 취험 관리의 절차는 위험 식별, 위험 분석 및 평가, 위험 관리 계획, 위험 감시 및 조치 순

② 위험의 범주

· 프로젝트 위험 : 프로젝트 계획을 위협하는 것으로, 일정이 지연되고 비용이 증가

· 기술 위험 : 소프트웨어의 품질이나 시기를 위협하는 것으로, 구현이 어려워지거나 불가능하게 됨

· 비즈니스 위험 : 소프트웨어의 생존 가능성을 위협하는 것으로, 원치 않는 제품이나 전략에 맞지 않는 제품 등을 개발

③ 위험의 종류

· 소프트웨어 개발 시 일반적인 위험 요소에는 인력 부족, 예산 관리, 일정 관리, 사용자 요구사항 변경등이 있으며, 이중 가장 대표적인 위험 요소는 사용자 요구사항 변경

위험의 종류(Charette에 의해 제안)

· 알려진 위험 : 프로젝트 계획서, 기술적 환경, 정보 등에 의해 발견될 수 있는 위험

· 예측 가능한 위험 : 과거 경험으로부터 예측할 수 있는 위험

· 예측 불가능한 위험 : 사전 예측이 매우 어려운 위험

④ 위험 식별(Risk Identification)

알려지거나 예측 가능한 위험 요소를 파악하는 작업으로, 위험 항목 점검 목록을 작성하여 활용

⑤ 위험 분석 및 평가

· 위험 분석은 프로젝트에 내재한 위험 요소를 인식하고 그 영향을 분석하는 활동으로, 위험 추산 작업을 통해 수행됨

· 가능한 모든 위험 요소와 영향을 분석하여 의사 결정에 반영

· 위험 요소에 대해 효과적이지 못한 관리는 프로젝트를 실패하는 결과도 가져올 수 있음

· 위험 추산을 위해 위험표를 작성하여 활용 

⑥ 위험 관리 계획

위험을 예방하고 위험 발생 시 대책을 준비하여 문서화하는 작업

⑦ 위험 감시 및 조치

위험 내용을 항상 감시하고 실제 발생 시 조치하는 것으로 다음과 같은 전략 사용

· 위험 회피 : 위험 관리에 대한 최상의 전략으로 위험이 발생될 것을 예상하고 회피하는 것

· 위험 감시 : 위험 요소 징후들에 대하여 계속적으로 인지하는 것

· 위험 관리 및 비상 계획 수립 : 위험 회피 전략이 실패할 경우 위험에 대해 관리하고 대비책과 비상 계획을 세움

127 소프트웨어 형상 관리

① 형상 관리

형상 관리(SCM; Software Configuration Management)는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동

· 소프트웨어 변경의 원인을 아아내고 제어하며 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보하는 작업

· 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동으로, 유지보수 단계에서도 수행됨

· 형상 관리는 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 함

② 소프트웨어 형상 항목(SCI; Software Configuration Item)

· 시스템 명세서

· 소프트웨어 프로젝트 계획서

· 소프트웨어 요구사항 명세와 실행 가능한 프로토타입

· 예비 사용자 매뉴얼

· 설계 명세서

· 원시 코드 목록

· 테스트 계획, 절차, 시험 사례, 결과

· 운영과 설피에 필요한 매뉴얼

· 실행 프로그램

· 데이터베이스 기술서 : 스키마, 파일 구조, 초기 내용

· 구축된 사용자 매뉴얼

· 유지 보수 문서 : 변경 요청서, 변경 처리 보고서

· 소프트웨어 공학을 위한 표준과 절차

③ 형상 관리 기능

· 형상 식별 : 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업

· 버전 제어 : 소프트웨어 처리 시 생성된 다른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구를 결합시키는 작업

· 변경 제어 : 식별된 형상 항목의 변경 요구를 검토하여 현재의 기준선이 잘 반영될 수 있도록 조정하는 작업

· 형상 감사 : 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업

· 형상 상태 보고 : 형상의 식별, 통제, 감사 자업의 결과를 기록·관리하고 보고서를 작성하는 작업

출처 : 2017 시나공 정보처리기사 필기

정보처리기사 필기 - 4과목 소프트웨어 공학

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

112 소프트웨어와 시스템

① 소프트웨어의 개요

· 소프트웨어는 하드웨어를 동작시켜 사용자가 작업을 편하게 수행하도록 하는 프로그램과 자료구조 등을 총칭

· 소프트웨어는 프로그램 자체뿐만 아니라 프로그램의 개발, 운용 및 유지보수에 관련된 모든 문서와 정보를 포함 

※ 프로그램 : 작업 실행 시 요구되는 기능과 성능을 제공해주는 명령어들의 집합

※ 자료구조 : 기억공간 내에서 자료 표현이나 처리 방법, 자료 간의 관계 등을 나타내는 것

② 소프트웨어의 특징

· 상품성 : 개발된 소프트웨어는 상품화되어 판매됨

· 견고성 : 일부 수정으로 소프트웨어 전체에 영향을 줄 수 있음

· 복잡성 : 개발 과정이 복잡하고 비표준화되어 이해와 관리가 어려움

· 순응성 : 사용자의 요구나 환경 변화에 적절히 변경할 수 있음

· 비가시성 : 소프트웨어의 구조가 외관으로 나타나지 않고, 코드 속에 숨어 있음

· 비마모성 : 사용에 의해 마모되거나 소멸되지 않음

· 비제조성 : 하드웨어처럼 제작되지 않고 논리적인 절차에 맞게 개발됨

· 비과학성 : 소프트웨어 개발 자체는 수학적이거나 과학적인 것이 아니라 조직, 인력, 시간, 비용, 절차 등이 중심이 됨

③ 소프트웨어의 분류

· 기능에 의한 분류 : 소프트웨어의 기능에 따라 분류 → 시스템 소프트웨어와 응용소프트웨어

· 사용 분야에 의한 분류 : 소프트웨어가 사용되는 분야에 따라 분류 → 프로그래밍용, 문서 작성용, 통신용, 분산 처리용, 멀티미디어용, 소프트웨어 개발용, 인공지능용

· 개발 과정의 성격에 따른 분류 : 소프트웨어가 개발되는 과정의 성격에 따라 분류 → 프로토타입, 프로젝트 산출물, 패키지

· 정보처리 방법에 따른 분류 : 정보를 처리하는 방법에 따라 분류 → 일괄 처리 소프트웨어, 온라인 소프트웨어, 실시간 소프트웨어

※ 개발 과정의 성격에 따른 분류

· 프로토타입(Prototype) : 사용자의 요구 사항을 정확히 분석하고 쉽게 이해할 수 있도록 지원하는 견본품, 시제품

· 프로젝트(Project) 산출물 : 아직 상품화되지 않은 연구 과정에서 생산된 소프트웨어

· 패키지(Package) : 소프트웨어 개발이나 업무 처리를 지원하기 위해서 개발된 상품형 소프트웨어

④ 시스템

시스템은 공통의 목적이나 목표를 달성하기 위하여 여러 가지 상호 관련된 요소들을 유기적으로 결합한 것

· 소프트웨어는 독립적으로 존재할 수 없으므로 컴퓨터를 기반으로 하는 여러 시스템과 관련을 맺어 상호 동작함

· 시스템의 구성 요소

[그림 1] 시스템 구성 요소

· 입력(Input) : 처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것

· 처리(Process) : 입력된 데이터를 처리 방법과 조건에 따라 처리하는 것

· 출력(Output) : 처리된 결과를 시스템에서 산출하는 것

· 제어(Control) : 자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것

· 피드백(FeedBack) : 출력된 결과가 예쩡된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리하는 것

⑤ 소프트웨어 위기의 원인

소프트웨어 위기는 여러 가지 원이에 의해 소프트웨어 개발 속도가 하드웨어 개발 속도를 따라가지 못해 소프트웨어에 대한 사용자들의 요구사항을 처리할 수 없는 문제가 발생함을 의미

· 소프트웨어의 특징에 대한 이해 부족 : 물리적이지 않고 논리적인 소프트웨어의 특징을 이해 못함

· 소프트웨어의 관리 부재 : 소프트웨어에 대한 관리를 소홀히 하여 효율적인 자원 통제가 이루어지지 못함

· 프로그래밍에만 치중 : 소프트웨어의 품질이나 유지보수는 고려하지 않고, 프로그래밍만 잘하려고 집착함으로써 다양하고 복잡해지는 소프트웨어의 요구사항을 처리하지 못함

⑥ 소프트웨어 위기의 결과

· 개발 인력의 부족과 그로 인한 인건비 상승

· 성능 및 신뢰성 부족

· 개발 기간 지연 및 개발 비용 증가

· 유지보수가 어렵고, 이에 따른 비용 증가

· 소프트웨어의 생산성 저하

· 소프트웨어의 품질 저하

113 소프트웨어 공학 

① 소프트웨어 공학의 개념

· 소프트웨어 공학은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문이며 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상이 목적

· 소프트웨어 공학은 다음과 같이 여러 형태로 정의 가능

- IEEE의 소프트웨어 공학 표준 용어사전 : 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안

- Fairley : 지정된 비용과 기간 내에 소프트웨어를 체계적으로 생산하고 유지보수하는 데 관려된 기술적이고 관리적인 원리

- Boehm : 과학적인 지식을 소프트웨어 설계와 제작에 응용하는 것이며 이를 개발, 운용, 유지보수하는 데 필요한 문서 작성 과정

· 소프트웨어 공학은 제품을 단지 생산하는 것이 아니라 가장 경제적인 방법으로 양질의 제품을 생산하는 것

· 소프트웨어 공학은 안정적이며 효율적으로 작동하는 소프트웨어를 생산하고, 유지보수 활동을 체계적이고 경제적으로 수행하기 위해 계층화 기술 사용

② 계층화 기술

계층화 기술은 관리자가 소프트웨어 개발 과정을 제어하고, 기술진이 고품질의 소프트웨어를 구축할 수 있도록 하는 기술을 의미하며, 계층화 기술에는 도구, 방법, 절차가 있음

[그림 2] 계층화 기술

· 도구(Tool) : 절차와 방법을 자동 또는 반자동으로 처리하는 기능을 제공하는 것으로, 대표적으로 CASE(Computer Aided Software Engineering)를 사용

· 방법(Method) : 소프트웨어를 구축하는 기술적인 방법을 제공

· 절차(Process) : 소프트웨어 공학의 기반이되는 것으로, 소프트웨어 개발에 사용되는 개발 방법과 도구가 사용되는 순서

계층화 기술들을 결합시켜 합리적이고 적절한 방법으로 소프트웨어를 개발하고 유지시키는 역할

③ 소프트웨어 공학의 기본 원치

· 현대적인 프로그래밍 기술을 계속적으로 적용해야 함

· 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 함

· 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 함

④ 소프트웨어 공학의 발전

⑤ 소프트웨어의 품질과 생산성

소프트웨어의 품질

소프트웨어의 품질은 주어진 요구사항을 만족시키는 능력을 갖추고 있는 소프트웨어의 측정 가능한 기능 및 특성을  의미하며, 좋은 품질의 소프트웨어는 다음과 같은 특성을 갖음

· 사용자가 요구하는 대로 동작해야 함

· 하드웨어 자원을 효율적으로 이용할 수 있어야 함

· 일정 시간 내에 주어진 조건하에서 원하는 기능을 실행할 수 있어야 함

· 애매모호함이 없이 처리 절차에 맞게 수행되어 정확하게 결과가 산출되어야 함

· 소프트웨어의 개발, 유지보수 등이 초기 예상 비용 이내에서 수행되어야 함

· 적당한 사용자 인터페이스 제공으로 사용하기가 편리해야 함

· 유지보수가 용이하고 신뢰성이 높아야 함

· 잠재적인 에러가 최소화되어야 함

· 소프트웨어의 사용법, 구조의 설명, 성능, 기능 등이 이해하기 쉬워야 함

· 실행 속도가 빠르고, 기억 용량을 적게 차지해야 함

소프트웨어의 생산성

소프트웨어의 생산성은 투입된 비용, 노력 등에 대한 생산량을 의미하는 것으로, 생산성에 영향을 미치는 요소는 다음과 같음

· 개발자의 능력

· 원할한 의사 전달

· 프로젝트의 복잡도와 성격

· 기술 수준

· 관리 기술

114 소프트웨어 생명 주기

① 소프트웨어 생명 주기의 개요

· 소프트웨어 생명 주기는 소프트웨어 개발 방법론의 바탕이 되는 것으로 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것

· 소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동, 활동의 결과에 대한 산출물로 표현하며, 소프트웨어 수명 주기라고도 함

· 소프트웨어 생명 주기의 역할

- 프로젝트 비용 산정과 개발 계획을 수립할 수 있는 기본 골격이 됨

- 프로젝트 진행 방향을 명확하게 파악하게 함

- 용어 및 기술의 표준화를 가능하게 함

- 프로젝트 관리를 용이하게 함

- 여러 소프트웨어 간에 상호 일관성을 유지하게 함

② 일반적인 소프트웨어 생명 주기

정의 단계 → 개발 단계 → 유지보수 단계

정의단계

· '무엇'을 처리하는 소프트웨어를 개발할 것인지를 정의하는 단계로,관리자와 사용자가 가장 많이 참여하는 단계

- 타당성 검토 단계 : 개발할 소프트웨어가 법적, 경제적, 기술적으로 실현 가능성이 있는지를 조사하는 단계

- 개발 계획 단계 : 소프트웨어 개발에 사용될 자원과 비용을 측정하는 단계

- 요구사항 분석 단계 : 사용자가 요구한 문제를 보다 상세하고 정확히 분석하는 단계

개발 단계

· '어떻게'에 초점을 두고 실제적으로 소프트웨어를 개발하는 단계

- 설계 단계 : 소프트웨어의 구조, 알고리즘, 자료 구조 등을 작성하는 단계로, 프로그램 설계용 언어나 자연 언어 또는 도표로 표현

에러가 가장 많이 발생하는 단계

- 구현 단계 : 설계 단계에서 작성된 문서를 기초로 하여 코딩하고 번역하는 단계

- 테스트 단계 : 구현된 소프트웨어에 내재되어 있는 오류를 찾아주는 단계

유지보수 단계

· 소프트웨어를 직접 운용하며, '변경'에 초점을 두고 여러 환경 변화에 따라 소프트웨어를 적응 및 유지시키는 단계

· 소프트웨어 생명 주기 단계 중에서 시간과 비용이 가장 많이 듬

115 소프트웨어 생명 주기 모형1

① 소프트웨어 생명 주기의 개요

· 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형이라고 하며, 소프트웨어 프로세스 모형 또는 소프트웨어 공학 패러다임

· 개발자는 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용할 수도 있고, 개별적인 모형을 사용할 수도 있음

· 일반적으로 사용되는 소프트웨어 생명 주기 모형에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 4세대 모형 등이 있음

② 폭포수 모형

폭포수 모형은 폭포에서 한번 떨어진 물은 거슬러 올라갈 수 없듯이 소프트웨어 개발도 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하며 이전 단계로 넘어갈 수 없는 방식

· 폭포수 모형은 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형으로, 고전적 생명 주기 모형이라고도 함

· 소프트웨어 개발 과정의 앞 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형

· 제품의 일부가 될 매뉴얼을 작성해야 함

· 다음 단계를 수행하기 위해 각 단계가 끝난 후에는 결과물이 정확하게 산출되어야 함

· 두 개 이상의 과정이 병행하여 수행되지 않음

개발 순서

타당성 검토 → 계획 → 요구 분석 → 설계 → 구현(코딩) → 시험(검사) → 유지보수

장점

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

· 단계별 정의가 분명하고, 전체 공조의 이해가 용이함

· 단계별 산출물이 정확하여 개발 공정의 기준점을 잘 제시함

단점

· 개발 과정중에 발생하는 새로운 요구나 경험을 반영하기 어려우므로 처음부터 사용자들이 모든 요구사항들을 명확하게 제시해야 함

· 단계별로 오류 없이 다음 단계로 진행해야 하는데 현실적으로 오류 없이 다음 단계로 진행하기는 어려움

· 개발된 프로그램을 업무에 운용할 대 검출되지 않은 오류로 인하여 사용자들이 큰 인내심을 가져야 함

③ 프로토타입 모형

프로토타입 모형은 사용자의 요구 사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형

· 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발

· 시스템의 일부 혹은 시스템의 모형을 만드는 과정으로서 요구된 소프트웨어를 구현하는데, 이는 추후 구현 단계에서 사용될 골격 코드가 됨

· 소프트웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형

· 프로토타입은 요구 분석 단계에서 사용하게 되며, 프로토타입의 평가가 끝나고 개발이 승인되면 다른 모형을 이용하여 본격적으로 개발이 이루어짐

· 소프트웨어 생명주기에서 유지보수가 없어지고, 개발 단계 안에서 유지보수가 이루어지는 것으로 볼 수 있음

개발 순서

[그림 3] 프로토타입 모형 개발 순서

장점

· 요구사항을 충실히 반영하며, 요구사항의 변경이 용이

· 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있음

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

단점

· 미리 제작된 소프트웨어를 사용할 경우 실제 소프트웨어와의 차이가 발생할 수 있어 사용자에게 혼란을 줄 수 있음

· 단기간에 제작해야 하기 때문에 비효율적인 언어나 알고리즘을 사용할 수 있음

116 소프트웨어 생명 주기2

① 나선형 모형

나선형 모형은 보헴이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형

· 나선형을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로(프로토타입을 지속적으로 발전시켜) 완벽한 최종 소프트웨어를 개발하는 것으로, 점진적 모델

· 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 함

개발 순서

① 계획 및 정의(Planing) : 개발 목적, 제약 조건 등을 설정

② 위험 분석(Risk Analysis) : 위험 요소를 분석하고, 기능 선택의 우선순위를 지정

③ 공학적 개발(Engineering) : 개선된 한 단계 높은 수준의 프로토타입을 개발

④ 고객 평가(Customer Evaluation) : 개발된 결과(프로토타입)을 평가

장·단점

· 가장 현실적인 모형으로, 대규모 프로젝트나 큰 시스템에 적합

· 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항 첨가 가능하고 정밀하며 유지보수 과정이 필요 없음

· 위험 분석 단계에서 기술과 관리의 위험 요소들을 하나씩 제거해 나감으로서 완성도 높은 소프트웨어를 만들 수 있음

· 위험성 평가에 크게 의존하기 때문에 이를 발견하지 않으면 반드시 문제가 발생함

· 비교적 최신 기법이므로 폭포수 모형이나 프로토타입 모형보다 널리 사용되지 않음

② 4GT 모형

4GT 모형은 사용자와 개발자가 쉽게 접근하고 사용할 수 있는 4세대 언어를 이용하여 개발자가 조사한 요구사항 명세서로부터 원시 코드를 자동으로 생성할 수 있게 해주는 모형

· 설계 단계를 축소하고, 요구 분석 단계에서 구현 단계로 전환할 수 있는 비절차적 모형

개발 순서

요구사항 수집 → 설계 전략 → 4세대 언어를 이용한 구현 → 제품화

장·단점

· 설계 단계 단축 가능

· 4세대 언어를 사용하므로 원시 코드를 자동으로 생성함

· 중·소형 소프트웨어 개발에 사용하면 개발 시간이 감소되지만 대규모 소프트웨어 개발에서는 자동화로 인해 단축된 시간보다 분석, 설계 단계 등에서 더 많은 시간을 필요로 함

출처 : 2017 시나공 정보처리기사 필기