첨부

[2006학년도 1학기 기말시험] 소프트웨어공학.hwp

[2007학년도 1학기 기말시험] 소프트웨어공학.hwp

[2008학년도 1학기 기말시험] 소프트웨어공학.hwp

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

소프트웨어구조

건축 설계사들은 집에 대한 자세한 설계를 하기 전에 집의 전반적인 모습과 구조의 틀을 잡는다.

다시 말해 앞으로의 설계와 시공에 대한 가이드가 될 큰 밑그림을 그리는 셈이다. 일관적인 모양과 조화를 위한 스타일을 정하는 작업이라고 할 수도 있다.

이러한 스타일이라는 개념을 소프트웨어 구조에도 적용할 수 있다. 소프트웨어 시스템이 더욱 복잡해지면서 시스템의 구조 문제는 더욱 중요해졌다. 일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않다. 대부분의 서브시스템에 대한 인터페이스를 변경하여야 하기 때문이다.

이런 문제의 중요성을 인식하여 소프트웨어 구조(software architecture)란 개념이 출현한 것이다. 소프트웨어 구조는 시스템 분할, 전체 제어 흐름, 오류처리 방침, 서브시스템 간의 통신 프로토콜을 포함한다.

 

저장소 구조

저장소 구조(repository architecture)는 서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경한다. 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화한다. 제어 흐름은 중앙 저장소에서 올 수도 있고 서브시스템에서 올 수도 있다.

저장소 구조는 급여 시스템이나 은행 시스템과 같은 데이터베이스 관리 시스템에서 대표적으로 볼 수 있다. 데이터가 중앙에 위치하여 서브시스템 사이의 병렬처리와 통합 문제를 더 잘 다룰 수 있다. 컴파일러나 소프트웨어 개발 환경들도 아래와 같은 저장소 구조를 따르고 있다. 컴파일러의 여러 서브시스템들이 파싱 트리와 심볼 테이블을 접근하고 변경한다. 디버거와 구문 편집기도 심볼 테이블을 사용한다.

저장소는 단지 동시에 요청된 접근이 순서대로 실행되도록 하면 된다. 역으로 말하면 저장소는 내부 상태를 기초로 서브시스템을 호출한다. 이런 시스템을 블랙보드 시스템이라 한다.

MVC 구조

MVC(Model/View/controller) 구조는 모델, 뷰, 제어구조라는 세 가지 다른 서브시스템으로 구성되어 있다.

모델 서브시스템은 도메인의 자식을 저장보관하고 있고 뷰 서브시스템은 이를 사용자에게 보여주며 제어 서브 시스템은 사용자와의 상호 작용을 관리한다.

모델 서브시스템은 뷰 서브시스템과 제어 서브시스템에 관련 없이 개발된다.]

MVC구조는 저장소 구조의 특수한 경우로 모델은 중앙 데이터 구조이며 제어 객체가 제어 흐름을 지시한다.

모델, 뷰, 제어로 분리하는 이유는 사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될 수 있기 때문이다.

 

클라이언트/서버 구조

클라이언트/서버 구조에서 서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공한다. 클라이언트는 사용자와 대화하여야 한다.

클라이언트는 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집한다.

서버 시스템은 저장소 구조의 특수한 형태이다.

저장소 구조의 중앙 데이터 구조는 한 프로세스에 의하여 관리되지만 클라이언트 서버 시스템에서는 제한이 없다. 웹에서와 같이 단일 클라이언트가 수천 개의 서버로부터 데이터를 받을 수 있다.

 

계층 구조

각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용하도록 구성된다.

상위층은 클라이언트가 되며 하위층이 서버처럼 작동한다.

시스템에 따라 바로 아래층이 제공하는 서비스만 접근할 수 있도록 폐쇄적인 구조를 취할 수도 있고 더 깊은 계층의 서비스도 자유롭게 접근하게 할 수도 있다.

계층형 구조는 추상화의 성질을 잘 이용한 구조이다.

계층형 구조의 장점은 층과 층 사이의 인터페이스 제약만 어기지 않으면 각 층을 필요에 따라 쉽게 변경할 수 있다는 점이다. 도한 연결된 층의 인터페이스만 맞추어주면 특정 계층을 쉽게 재사용할 수 있다.

단점

• 각 서브시스템 사이에 복잡하게 관계를 맺고 있어 이를 독립적인 층으로 분리 추상화하기 어렵다.
• 과다한 계층 분할은 시스템 사이의 인터페이스가 오히려 성능 저하를 가져온다.

 

파이프 필터 구조

파이프 필터 구조는 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복된다.

서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프라 한다.

각 필터는 입력 파이프에 받은 데이터의 내용과 형식만을 알고 그것을 생성한 필터에 대하여는 모른다.

파이프와 필터 구조는 변경 가능하다. 필터는 다른 필터와 교환 될 수 있고 다른 목적으로 재구성될 수 있다.

파이프 필터 구조의 대표적인 예는 Unix 쉘이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

프로세스 모형(소프트웨어 생명주기 모형)

 

COCOMO 모델

비용 예측 방법으로 B. Boehm이 제안한 원시 프로그램의 규모에 의한 방법이 COCOMO(Constructive Cost Model) 모델이다. 먼저 완성될 시스템 규모(lines of code)를 추정하고 이를 준비된 식에 대입하여 소요 인월/월을 예측한다. 1981년에 제안된 초기 모델은 소프트웨어 공학 기술이 발전되면서 1995년 COCOMO II로 확장되었다.

COCOMO

소프트웨어 개발 프로젝트에 대하여 3가지로 구분하고 프로그램 규모(kilo delivered source instruction)와 이를 개발하는 데 소요되는 프로그래머 인원/월(programmer man/month)의 관계를 추출

프로젝트 유형	공 식	유형 해설
단순형(Organic)	PM = 2.4 * (KSDI)1.05	소규모 팀이 개발하는 잘 알려진 응용 시스템
중간형(Semi-detached)	PM = 3.0 * (KSDI)1.12	단순형과 임베디드의 중간형으로 트랜잭션 처리 시스템,운영체제, DBMS
임베디드형(Embedded)	PM = 3.6 * (KSDI)1.20	하드웨어가 포함된 실시간 시스템. 미사일 유도, 신호기 제어 시스템

 

Organic

• 기관 내에서 개발된 중소 규모의 소프트웨어
• 일괄 자료 처리, 과학 기술 계산용, 비지니스 자료 처리용 등
• 5만 라인 이하의 소프트웨어를 개발하는 유형

Semi-detached

• 트랜잭션 처리 시스템, 운영체제, DBMS 등
• 30만 라인 이하의 소프트웨어를 개발하는 유형

Embedded

• 최대 규모의 하드웨어가 포함된 실시간 처리 시스템
• 미사일 유도 시스템, 도시 가스 제어 시스템 등

원시코드의 크기를 바탕으로 하는 대부분의 비용 예측 방법

• PM inital = c * KLOC^k
• 결과 MM은 원시 코드의 라인수에 비례
  • 상수 K는 1보다 큰 값
  • 따라서 비선형적으로 비례
  • 따라서 비선형적으로 비례

비용 승수 요소

프로토타이핑 모형의 장단점

정의

프로토타이핑이란 시스템의 일부 혹은 시스템의 모형이 될 만한 것을 만드는 과정이다.

프로토타이핑 모형은 요구 분석 단계로부터 시작한다. 발주자나 사용자는 한 번에 완전한 요구를 낼 수 없기 때문에 프로토타입이 설계된다. 프로토타입이 구현된 후에 발주자와 개발자는 이를 평가하여 요구를 수정한다. 새로운 요구에 다라 프로토타입을 수정하거나 보완하고 확장하면 시스템이 구현되는 것이다.

장점

• 발주자가 완성된 시스템의 모습을 먼저 볼 수 있고, 이를 보고 요구를 수정할 수도 있다.
• 발주자나 개발자에게 공동의 참조모델을 제공한다.
• 발주자는 프로토타입으로 인하여 소프트웨어 개발에 더 관심을 가지고 참여할 수 있다.
• 개발자는 프로토타입을 통하여 사용자의 요구를 자세하게 도출할 수 있다.
• 프로토타이핑으로 소프트웨어 개발이 제대로 되고 있는지 확인할 수 있다.

단점

• 두 차례에 걸쳐 개발할 기회가 있으므로 잘못된 부분을 고칠 기회가 많다.
• 발주자가 프로토타입이 최종 결과라 믿고 곧 소프트웨어 개발이 완성되리라고 오해한다.
• 발주자가 개발 일정 단축을 요구하므로 소프트웨어 품질을 저하시킬 우려도 있다.
• 프로토타입이 과대 선전되어 발주자로 하여금 개발하여 인수해야 할 시스템보다 더 많은 기능을 기대하는 심리를 유발시킬 수 있다.
• 개발

기능점수방법

기능점수는 소프트웨어 시스템이 가지는 기능을 정량화한 것이다. 원시 코드가 아직 작성되지 않은 상태이므로 정확한 라인수의 예측은 불가능하다. 따라서 일반적인 소프트웨어가 갖는 기능(예를 들면, 입력, 출력, 절의, 파일, 인터페이스)의 개수로 소프트웨어의 규모와 복잡도를 나타내고 이를 시스템 개발에 필요한 기간과 소요 인력 계산의 기초로 삼는 방법이다. 이 방법은 경험 중심적이며 여러 가지 실험 결과에 의하면 비즈니스 응용 분야의 소프트웨어 개발비용 산정에 정확하다고 한다. 기능 점수를 이용하여 비용을 산정하려면 생산성 메트릭이 있어야 한다. 즉, 단위 시간당 프로그래머의 생산성을 기능 점수로 표현한 자료가 있어야 한다.

자료흐름도

구조도

설계원리

모든 소프트웨어 개발 방법에는 근간을 이루는 개념과 원리가 있다. 방법은 상황에 맞게 개념과 원리를 적용하는 것이다. 따라서 기술의 발전이나 경영 관리 상황, 개인들의 관심에 따라 방법론은 달라질 수 있다. 구조적 설계는 구조적 분석의 ‘형식은 기능을 따른다’는 원리를 일관되게 적용한다. 자료 흐름도의 프로세스 패턴이 시스템의 구조를 결정한다. 분할과 정복, 즉 큰 일을 작게 나누고 작은 일을 하나씩 해결하는 과정을 반복한다. 프로세스를 모듈로 분할하는 원리는 아래 그림과 같다. 자료 흐름도를 크게 입력, 프로세스, 출력 부분으로 나눈다면 구조도에는 입력, 프로세스, 출력 부분을 표시하고 그 위에 제어부분을 붙인다.

추상화란 자세한 사항을 접어두고 근본적인 본질에 집중하는 것을 말한다. 즉, 자세한 사항을 처음부터 다루지 않고 전체적이고 포괄적인 개념으로부터 차례로 자세하게 세분화함으로써 구체화시켜 나가는 방법이다. 구체화하는 과정의 설계단계에서는 소프트웨어의 구조를 이루는 계층을 파악할 수 있고, 각 구성 요소도 선택할 수 있다. 추상화는 ‘어떤 결과가 얻어져야 하는가?’라는 명세화 관점을 ‘어떻게 달성할 것인가?’라는 구현에 대한 관점과는 별개로 생각함으로써 설계 작업에 집중할 수 있게 한다.

정보 은닉 원리에 의하여 설계된 각 모듈은 자세한 처리 내용이 시스템의 다른 부분으로부터 감추어져 있어야 한다는 것이다. 모듈 안의 내용을 부여주지 않고 잘 정의된 인터페이스를 통하여 메시지를 전달하도록 하는 개념이다. 즉, 설계상의 결정 사항들이 각 모듈 안에 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 한다.

이와 같은 정보 은닉은 모듈화의 기준으로 사용할 수도 있다. 즉, 모듈이 외부로부터 얼마나 은폐되었는가를 분석한 후에 가능하면 모든 사항이 모듈 안에 감추어지도록 모듈의 설계를 고쳐 나간다. 정보 은닉을 따른 모듈 설계는 모듈의 구현을 독립적으로 맡길 수 있고, 설계 과정에서 하나의 모듈이 변경되더라고 다른 모듈의 설계에 영향을 주지 않는다. 또한 모듈의 이해도를 높일 수 있는 장점도 있다.

단계적 분해는 문제를 상위 개념부터 더 구체적인 단계로 하향식으로 분할하는 기법이다. N. Wirth에 의하여 제안된 개념으로 다음과 같은 과정으로 구성된다.

1. 문제를 기본 단위로 나눈다.
2. 독립된 문제로 구별한다.
3. 구분된 문제의 자세한 내용은 가능한 한 뒤로 미룬다.
4. 구체화 작업이 계속 점증적으로 일어난다는 것을 보인다.

소프트웨어구조

건축 설계사들은 집에 대한 자세한 설계를 하기 전에 집의 전반적인 모습과 구조의 틀을 잡는다.

다시 말해 앞으로의 설계와 시공에 대한 가이드가 될 큰 밑그림을 그리는 셈이다. 일관적인 모양과 조화를 위한 스타일을 정하는 작업이라고 할 수도 있다.

이러한 스타일이라는 개념을 소프트웨어 구조에도 적용할 수 있다. 소프트웨어 시스템이 더욱 복잡해지면서 시스템의 구조 문제는 더욱 중요해졌다. 일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않다. 대부분의 서브시스템에 대한 인터페이스를 변경하여야 하기 때문이다.

이런 문제의 중요성을 인식하여 소프트웨어 구조(software architecture)란 개념이 출현한 것이다. 소프트웨어 구조는 시스템 분할, 전체 제어 흐름, 오류처리 방침, 서브시스템 간의 통신 프로토콜을 포함한다.

 

저장소 구조

저장소 구조(repository architecture)는 서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경한다. 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화한다. 제어 흐름은 중앙 저장소에서 올 수도 있고 서브시스템에서 올 수도 있다.

저장소 구조는 급여 시스템이나 은행 시스템과 같은 데이터베이스 관리 시스템에서 대표적으로 볼 수 있다. 데이터가 중앙에 위치하여 서브시스템 사이의 병렬처리와 통합 문제를 더 잘 다룰 수 있다. 컴파일러나 소프트웨어 개발 환경들도 아래와 같은 저장소 구조를 따르고 있다. 컴파일러의 여러 서브시스템들이 파싱 트리와 심볼 테이블을 접근하고 변경한다. 디버거와 구문 편집기도 심볼 테이블을 사용한다.

저장소는 단지 동시에 요청된 접근이 순서대로 실행되도록 하면 된다. 역으로 말하면 저장소는 내부 상태를 기초로 서브시스템을 호출한다. 이런 시스템을 블랙보드 시스템이라 한다.

MVC 구조

MVC(Model/View/controller) 구조는 모델, 뷰, 제어구조라는 세 가지 다른 서브시스템으로 구성되어 있다.

모델 서브시스템은 도메인의 자식을 저장보관하고 있고 뷰 서브시스템은 이를 사용자에게 보여주며 제어 서브 시스템은 사용자와의 상호 작용을 관리한다.

모델 서스시스템은 뷰 서브시스템과 제어 서브시스템에 관련 없이 개발된다.]

MVC구조는 저장소 구조의 특수한 경우로 모델은 중앙 데이터 구조이며 제어 객체가 제어 흐름을 지시한다.

모델, 뷰, 제어로 분리하는 이유는 사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될 수 있기 때문이다.

 

클라이언트/서버 구조

클라이언트/서버 구조에서 서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공한다. 클라이언트는 사용자와 대화하여야 한다.

클라이언트는 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집한다.

서버 시스템은 저장소 구조의 특수한 형태이다.

저장소 구조의 중앙 데이터 구조는 한 프로세스에 의하여 관리되지만 클라이언트 서버 시스템에서는 제한이 없다. 웹에서와 같이 단일 클라이언트가 수천 개의 서버로부터 데이터를 받을 수 있다.

 

계층 구조

각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용하도록 구성된다.

상위층은 클라이언트가 되며 하위층이 서버처럼 적동한다.

시스템에 따라 바로 아래층이 제공하는 서비스만 접근할 수 있도록 폐쇄적인 구조를 취할 수도 있고 더 깊은 계층의 서비스도 자유롭게 접근하게 할 수도 있다.

계층형 구조는 추상화의 성질을 잘 이용한 구조이다.

계층형 구조의 장점은 층과 층 사이의 인터페이스 제약만 어기지 않으면 각 층을 필요에 따라 쉽게 변경할 수 있다는 점이다. 도한 연결된 층의 인터페이스만 맞추어주면 특정 계층을 쉽게 재사용할 수 있다.

단점

• 각 서브시스템 사이에 복잡하게 관계를 맺고 있어 이를 독립적인 층으로 분리 추상화하기 어렵다.
• 과다한 계층 분할은 시스템 사이의 인터페이스가 오히려 성능 저하를 가져온다.

 

파이프 필터 구조

파이프 필터 구조는 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복된다.

서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프라 한다.

각 필터는 입력 파이프에 받은 데이터의 내용과 형식만을 알고 그것을 생성한 필터에 대하여는 모른다.

파이프와 필터 구조는 변경 가능하다. 필터는 다른 필터와 교환 될 수 있고 다른 목적으로 재구성될 수 있다.

파이프 필터 구조의 대표적인 예는 Unix 쉘이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

 

 

 

 

 

 

 

 

 

 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

개요

1장. 소프트웨어 소프트웨어 공학 공학 개요(1)
1.1 소프트웨어와 시스템
1.2 소프트웨어 위기
1.3 소프트웨어 공학
1.4 좋은 소프트웨어의 조건
1.5 소프트웨어 생명주기 모형
1.6 소프트웨어 공학 근본 지식

l 소프트웨어 공학 개요

1. 소프트웨어의 중요성

A. 컴퓨터 시스템에 대한 의존도 증가

2. 소프트웨어 개발에 필요한 지식

A. 프로그래밍 외에 설계/시험 방법, 응용 분야,

B. 인간공학, 경영 등에 관한 지식이 필요

3. 3. 소프트웨어 개발과 관리

A. 설계와 구현 과정에서 도구와 방법론을 적용

B. 프로젝트 계획과 관리 기술이 필요

l 소프트웨어와 시스템

1. 소프트웨어

A. 소프트웨어의 포괄적 의미

i. 프로그램 + 프로그램의 개발, 운용, 보수에 필요한 정보 일체

B. 소프트웨어의 성질

i. 비가시성(Invisibility)

1. 무형, 관리가 힘듦

ii. 테스트 가능(Testability)

iii. 복잡성(Complexity)

1. 규칙적이고 정형적인 구조가 없음

2. 소프트웨어의 특성

A. 소프트웨어의 성질(계속)

i. 변경성(Changeability)

1. 하드웨어에 비해 수정이 용이

2. 순응성(Conformity)

ii. 장수(Longevity)

1. 마모되지 않음

iii. 복제 가능(Duplicability)

3. 소프트웨어의 분류

A. 기능에따른분류

i. 응용 소프트웨어

ii. 시스템 소프트웨어

B. 성격에따른분류

i. 프로토타입

ii. 연구생산물

iii. 패키지

1. 다수 사용자용, generic S/W

iv. 주문형 소프트웨어

1. 특정 사용자용, custom S/W

C. 응용 분야에 따른 분류

4. 시스템

A. 시스템의 의미

i. 유기적으로 상호 작용하는 구성요소들의 집합

ii. 컴퓨터 시스템은 하드웨어, 소프트웨어, 사용자, 운영자 및 주변 환경으로 구성됨

iii. 소프트웨어 자체도 하나의 시스템

B. 시스템의 특성

i. 시너지 효과

ii. 변화에 적응해야 함

iii. 상충되는 요구와 이해 관계의 절충안

C. 그림

l 소프트웨어의 위기(Crisis)

1. 소프트웨어 생산성의 문제

A. 소프트웨어 생산성의 문제

i. 소프트웨어 수요의 증가에 비해 공급 능력이 부족

ii. 소프트웨어 비용의 상대적 증가

iii. 하드웨어 비용 하락, 인건비 상승

iv. 그림

2. 소프트웨어의 위기(Crisis)

A. 소프트웨어 공정의 문제점

i. 생산성 문제

ii. 부정확한개발계획

1. 비용 초과, 기간 지연

iii. 생산 기술과 관리 기술의 부족

1. 개인의 역량에 의존해서는 안됨

iv. 품질의 문제

1. 신뢰성과 성능이 부족

v. 유지보수 문제

1. 엄청난 유지보수 비용

l 소프트웨어 공학

1. 공학이란?

A. 현실의 문제 해결을 위해 합리적이고 일반적인 해결 방법을 탐구하는 학문

B. 제조물의 설계와 구현을 중요시

2. 엔지니어링의 발전 원리

A.

3. 소프트웨어 공학

A. 정의

i. 질 좋은 소프트웨어를 경제적으로 생산하기 위하여 공학, 과학 및 수학적 원리와 방법을 적용하는 것

1. Watts Humphrey, SEI

ii. 소프트웨어의 개발, 운용, 유지보수 및 소멸에 대한 체계적인 접근 방법

1. IEEE Computer Society

iii. 품질, 효율, 비용, 인정에 관한 공학적인 접근 원리

1. F. Brooks

B. 목표

i. 품질(Quality)

ii. 생산성(Productivity)

1. 최소의 비용으로 주어진 기간 안에 개발

4. 소프트웨어 공학이 다루는 주제

A.

B. 고품질

i. 소프트웨어 공학의 목표 중 하나

ii. 소프트웨어를 대하는 입장에 따라 품질에 대한 관점이 달라짐

iii.

5. 소프트웨어 품질(Quality)

A. 정확성(Correctness)

i. 기능적으로 맞게 동작, 표준에 적합

ii. 요구 분석서의 기능과 일치하는지 점검

B. 신뢰성(Reliability)

i. 소프트웨어가 주어진 기간 동안 제대로 작동할 확률

ii. 오작동의 빈도와 관련 있음

iii. 정확성을 위한 필요조건

C. 강인성(Robustness)

i. 요구 명세에 표시하지 않은 상황(오류 입력)에서도

ii. 제대로 작동하는 성질

D. 성능(Performance)

i. 수행 속도

ii. 알고리즘의 시간 복잡도

iii. 시뮬레이션, 스트레스 테스트

E. 사용 용이성(Usability)

i. 사용자가 시스템을 사용하기 쉬워야 함

ii. 사용자 인터페이스

F. 유지보수성(Maintainability)

i. 변화하는 요구를 쉽게 수용하도록 설계되어야 함

ii. 소프트웨어 결함을 쉽게 수정할 수 있어야 함

iii. 진화성

6. 프로덕트 품질

A.

7. 프로세스 품질

A. 품질의 종류

i. 프로덕트 품질과 프로세스 품질

B. 프로세스 품질

i. 개발 과정이 품질에 많은 영향을 준다는 주장

ii. 프로세스 개선 모델

1. CMM, SPICE

C. 향상 방안

i. 특정 오류가 언제 어디서 발견되는가?

ii. 어떻게 하면 개발 과정에 오류를 조기에 발견할 수 있는가?

iii. 어떻게 하면 오류에 대한 내성이 있는 시스템, 즉 오류가 소프트웨어를 정지시키는 확률이 적은 시스템으로 만들 수 있는가?

iv. 프로세스가 좋은 품질을 보장하는 더 효율적이며 효과적인 다른 방법이 있는가?

l 소프트웨어 생명주기 모형

1. 소프트웨어 생명주기

A. 소프트웨어 생명주기

B. 소프트웨어 개발의 시작에서 폐기까지의 일련의 개발 단계

i. 설계 단계나 그 이전 단계를 중요시 함

ii.

2. 프로세스 모형

A. 개발 프로세스

B. 개발 모형

i. 실제 소프트웨어 프로세스를 단순화, 추상화시킨 것

ii. 개발 단계별로 수행 할 작업들과 중간 결과물 및 다음 단계 진행을 위한 기준을 정의함

iii. 소프트웨어 공학자가 어떤 업무를 어떤 순서로 할 것인가에 관한 지침 제공, 실정에 맞는 개발 팀의 고유한 모형의 정립 필요

C. 일반적 소프트웨어 개발 단계

i. 요구 분석과 정의

ii. 시스템 설계

iii. 프로그램 설계

iv. 프로그램의 작성(구현)

v. 테스트(단위 테스트, 통합 테스트, 시스템 테스트)

vi. 시스템 설치

vii. 유지보수

3. 대표적인 생명주기 모형

A. 중요한 모형

i. 폭포수 모형

ii. 프로토타이핑 모형

iii. 점증적 모형

iv. 나선형 모형

v. V 모형

vi. 일정 중심 설계 모형

vii. 진화적 출시 모형

4. 폭포수 (waterfall)모형

A.

B. 최초 프로세스 모형, 1970년대 소개

i. 다른 공학에서 사용하는 프로세스로부터 유도된 것

ii. 단계별 작업이 분리되어 각 단계가 다음 단계 시작 전에 끝나야 함

1. 순서적 : 각 단계 사이에 중복이나 상호작용이 없음

2. 각 단계의 결과는 다음 단계가 시작 되기 전에 점검

3. 바로 전 단계로 피드백

C. 결과물 정의가 중요

D. Method와 Methodology

5. 폭포수 모형의 프로세스와 결과물

A.

6. 폭포수 모형의 장단점

A. 장점

i. 프로세스가 단순하여 초보자가 쉽게 적용 가능

ii. 중간 산출물이 명확, 관리하기 좋음

iii. 코드 생성 전 충분한 연구와 분석 단계

B. 단점

i. 처음 단계를 지나치게 강조하여 코딩, 테스트가 지연

1. 불필요한 다종의 문서를 생산할 가능성 있음

ii. 프로토타입과 재사용의 기회가 줄어듦

iii. 변화하는 고객의 요구에 대응하기 어려움

1. 실제 프로세스는 작업의 병렬 수행과 반복이 존재

C. 적용

i. 요구사항이 명확한 경우, 응용 분야를 잘 알고 있는 경우, 연구 중심 문제 등에 적합

ii. 변화가 적고 위험이 적은 프로젝트에 적합

7. 프로토 타이핑 모형

A. 기본 아이디어

i. 초기 구현을 사용자에게 보여주고, 피드백을 통해 시스템을 점진적으로 완성

B. Rapid Prototyping Model (RAD)

i.

C. 프로토타입(시범 시스템)의 적용

i. 사용자의 요구를 더 정확히 추출

ii. 알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작

D. 프로토타이핑 도구

i. 화면 생성기

ii. 비주얼 프로그래밍, 4세대 언어 등

E. 두 가지 프로토타입

i. 단순한 요구 추출 – 만들고 버림

ii. 진화적 프로토타입 – 최종 결과물로 발전

8. 프로토 타이핑 모형의 장단점

A. 장점

i. 일찍 시스템의 모습을 볼 수 있어 기능성과 유용성을 확인

ii. 발주자와 개발자 간 공통의 참조 모델을 제공

iii. 사용자가 더 관심을 가지고 참여할 수 있고 개발자는 요구를 더 정확히 도출할 수 있음

B. 단점

i. 오해, 기대심리 유발

ii. 관리가 어려움(중간 산출물 정의가 난해)

C. 적용

i. 개발 착수 시점에 요구가 불투명할 때

ii. 실험적으로 실현 가능성을 타진해 보고 싶을 때

iii. 혁신적인 기술을 사용해 보고 싶을 때

9. 점증적 모형

A. 장점

i. 최근의 비즈니스 환경은 빠른 개발을 원함

ii. 개발 시간을 줄이는 법 – 시스템을 나누어 릴리스

1. 개발과 운용이 혼재함

2.

B. 점증적 개발 방법

i. 시스템을 기능별로 여러 서브 시스템으로 나누고 하나씩 개발 (릴리스A, 릴리스B, 릴리스C)

C. 반복적 개발 방법

i. 시스템 전체 기능을 대상으로 하며 릴리스를 개발할 때 완성도를 높임 (릴리스1.0, 릴리스1.1, 릴리스1.2)

D. 단계적 개발 (점증적 방법과 반복적 방법의 병행)

i. 기능이 부족하더라도 초기에 사용 교육 가능

ii. 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음

iii. 자주 릴리스 하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히 고쳐나갈 수 있음

iv. 개발 팀이 릴리스마다 다른 전문 영역에 초점 둘 수 있음

10. 나선형(spiral) 모형

A. Boehm의 모델

i. 위험 관리 측면을 중요시 함

ii. 반복적 개발 방법과 유사

1. 나선형

2. 가장 안쪽 나선은 타당성 조사, 그 다음은 요구 정의, 그 다음은 설계 …

3. 매 나선마다 계획과 검토 후 위험 요소 분석이 뒤따름

iii. 관점에 따라

1. 중요 기능을 먼저 개발하고 다른 기능을 추가한다면 여러 번의 점증적인 릴리스로 볼 수 있음

B.

C. 소프트웨어의 기능을 나누어 점증적으로 개발

i. 실패의 위험을 줄임

ii. 테스트 용이

iii. 피드백

D. 진화 단계

i. 계획 수립(planning): 목표, 기능 선택, 제약 조건의 결정

ii. 위험 분석(risk analysis): 기능 선택의 우선순위, 위험요소의 분석

iii. 개발(engineering): 선택된 기능의 개발

iv. 평가(evaluation): 개발 결과의 평가

11. 나선형(spiral) 모형의 장단점

A. 장점

i. 대규모 시스템 개발에 적합

1. 위험을 관리하고 최소화 함

ii. 반복적인 개발 및 테스트를 통한 강인성 향상

1. 한 사이클에 추가 못한 기능은 다음 단계에 추가 가능

B. 단점

i. 폭포수 모델이나 프로토타이핑 모델보다 복잡하여 프로젝트 관리가 어려움

ii. 다수 고객을 상대하는 상업용 제품인 경우 적용이 어려움

iii. 새로운 모형으로 많이 사용하지 않아 충분히 검증이 안됨

C. 적용

i. 재정적 또는 기술적으로 위험 부담이 큰 경우

ii. 요구 사항이나 아키텍처 이해에 어려운 경우

12. V모형

A.

B. 폭포수 모형의 변형

i. 감추어진 반복과 재 작업을 드러냄

1. 점선은 오류 발생시 되돌아 갈 수 있음을 의미

ii. 작업 결과의 검증과 테스트 작업을 강조함

iii. 상세 설계는 단위 테스트, 시스템 설계는 통합 테스트, 요구는 시스템 테스트 과정에서 검증함

C. 장점

i. 오류를 줄일 수 있음

D. 단점

i. 반복이 없어 변경을 다루기가 쉽지 않음

E. 적용

i. 신뢰성이 높이 요구되는 분야

13. 일정 중심 설계 모형

A.

B. 특징

i. 사용자의 요구에 대하여 우선순위를 정하고 이것을 기초로

ii. 각 사이클을 계획

iii. 초기 단계에 중요한 기능들을 설계, 구현하여 시스템의 골격을 만듦

iv. 상대적으로 덜 중요한 기능을 나중에 함으로 일정 조정 가능

C. 단점

i. 우선순위가 낮아 출시에 포함되지 않을 기능을 분석 하고

ii. 설계하는 데 시간을 낭비

D. 적용

i. 소프트웨어 제품의 출시 날짜가 매우 중요한 경우

ii. 목표 일정을 달성할 수 있을지 불확실할 때

14. 진화적 출시 모형

A.

B. 진화적 출시(evolutionary delivery)

i. 고객의 요구를 여러 사이클에 걸쳐 개발하여 보여주면서 제품을 개선해 나가는 모형

C. 프로토타이핑 모형과 다른 점

i. 고객의 요구를 프로토타이핑 모형처럼 전적으로 수용하지는 않음

ii. 고객의 반응으로 바뀔 가능성이 적은 부분이 시스템의 핵심

iii. 프로토타이핑 모형은 시스템에서 눈에 띄는 부분을 먼저 강조하고 나중에 시스템 기반에 있는 구멍을 메워나가는 식

15. 모델 비교와 선택

A.

B.

16. SEWBOK

A. 소프트웨어 요구분석

i. 사용자의 요구의 추출,분석,검증,관리에 관한 지식(3장, 5.4절, 6장)

B. 소프트웨어 설계

i. 사용자가 원하는 요구를 만족시킬 수 있는 솔루션에 해당하는 설계를 작성하는 데 필요한 지식(4장, 6장)

C. 소프트웨어 구축

D. 소프트웨어 테스트

i. 테스트에 관한 기본 개념,수준,측정,과정,도구에 관한 지식(8장)

E. 소프트웨어 유지보수

i. 유지보수 개념과 작업 및 관리,비용,측정에 관한 지식(9장)

F. 소프트웨어 형상 관리

i. 시스템을 이루고 있는 구성요소들을 잘 파악하고 이들의 변경, 릴리스를 잘 관리하는데 필요한 지식(9.2절)

G. 소프트웨어 엔지니어링 관리

i. 소프트웨어 프로젝트의 계획,실행,평가,조정 등의 관리에 대한 지식과 객관적인 측정에 관한 지식(2장)

H. 소프트웨어 엔지니어링 프로세스

i. 소프트웨어 프로세스의 정의,구현, 측정,관리,변경,개선에 관한 지식 (1장,2장)

I. 소프트웨어 엔지니어링 도구와 방법

i. 소프트웨어 개발 방법 및 도구와 컴포넌트 통합에 관한 지식(5장, 11장)

J. 소프트웨어 품질

i. 프로덕트 품질의 개념과 품질 특성, 품질 보증을 위한 계획, 활동에 관한 지식(10장)

K. 기타 관련 지식

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

4강.4장설계

학습에 앞서

이번 보충학습은 교재 4장 "설계" 의 내용 가운데 우리가 꼭 알고 있어야 하는 개념과 용어 일부를 정리한 것이다. 소프트웨어공학 과목을 학습할 때 관련 개념이나 용어들에 대해 그 의미를 정확히 이해하고, 적소에 사용할 수 있어야 하는 점은 매우 중요하다.

• 변환 분석에 의한 구조적 설계

자료흐름도에서 정보는 외부 자료를 내부 자료로 변환시켜 주는 경로를 따라 시스템에 입력되며(입력 흐름), 이 자료들은 변환 중심을 거쳐서 출력을 유도하는 경로를 따라 이동한다(출력 흐름). 자료흐름도의 일부가 이러한 특성을 나타내는 것을 변환 흐름이라 한다.

변환 흐름은 자료를 입력 받고 가공 처리한 후 그 결과를 외부로 출력하는 관점에서 시스템을 설계하는 기법으로 시스템을 구성 요소들로 분할시켜주며 기본적인 기능을 수행하는 모듈들과 모듈들 사이의 계층 구조를 생성시켜 줄 수 있다.

변환 분석은 설계 절차의 한 과정으로서 변환 흐름을 가진 자료흐름도를 정해진 절차에 의거하여 소프트웨어 구조로 대응시키는 방법이다. 변환분석은 다음 단계로 구성이 된다.

1. 문제에 대한 자료흐름도를 작성한다.
2. 자료흐름도에서 입력흐름 경계와 출력흐름 경계를 표시하여 변환 중심을 분리시킨다.
3. 구조도 초안을 생성한다.
4. 구조도를 수정한다.
5. 설계 작업을 확인한다.

• 처리 분석에 의한 구조적 설계

기본 시스템 모델은 변환 흐름을 의미하고 있으므로, 모든 자료흐름을 이 범주에서 특성화시키는 것이 가능하다. 그러나 처리 흐름은 많은 경로들 중 한 경로를 따라 다른 자료흐름을 야기 시키는 처리(transaction)라고 부르는 단일 자료 항목으로 특성화시킬 수 있다. 처리란 자료나 제어 시그널 등이 어떠한 행위를 유발시키는 것을 말하고, 처리 흐름에 의한 설계는 들어온 입력을 여러 갈래의 출력흐름으로 쪼갤 수 있는 경우에 가능하다. 이 경우 자료 흐름의 중심을 처리 중심(Transaction center) 라고 한다.

다음 그림은 처리 흐름의 예이고, 프로세스 T는 처리 중심이다.

처리 분석은 시스템이 처리하는 처리 유형들을 식별하고 식별된 처리 형태에 따라 프로그램을 설계할 때 사용하는 설계 전략이다. 처리 분석은 자료흐름도의 한 프로세스에서 여러 개의 자료 흐름이 유출되는 경우에 사용된다. 구조적 분석에서 처리의 의미는 여러 개의 작업 중에 하나를 선택하게 하는 프로세스를 말한다.

처리 중심 모듈은 트랜잭션의 종류를 결정하여 거기에 알맞은 모듈을 호출하게 된다. 그리고 각 모듈은 그 하위의 모듈과 함께 한 종류의 트랜잭션에 관한 모든 일을 처리해야 한다.

처리 분석은 다음 순서로 수행된다.

1. 명세서와 자료흐름도를 조사하여 트랜잭션의 소스를 식별한다.
2. 자료흐름도를 조사하여 처리 중심을 찾고 구조도에 위치시킨다.
3. 모듈을 찾고 구조도에 위치시킨다.
4. 완전하게 처리될 수 있도록 모듈을 다듬는다.

• 아키텍쳐와 비기능적 속성

소프트웨어 아키텍쳐를 어떻게 구성하는가는 시스템의 비기능적 속성과 밀접한 관련이 있다. 아래의 예를 통해 확인할 수 있듯이 아키텍쳐를 고려할 때 서로 모순되는 점이 있을 수 있다. 예를 들어 큰 규모의 컴포넌트를 사용는 것이 성능 개선에 도움이 되지만 유지 보수를 위해선 좋지 못하다. 따라서 성능과 유지보수성이 모두 중요 요구사항일 때는 타협점이 필요하다.

1. 성능(performance):가능한 서브시스템 통신을 최소화하기 위해서는 중요 오퍼레이션을 지역화(operation localization) 시키도록 아키텍쳐를 설계하여야 한다.
2. 보안(security):계층형 아키텍쳐(layered architecture)를 사용하고 주요한(critical) 요소는 내부 레이어(layer)에 놓는 것이 좋으며 이 레이어에 높은 수준의 검증을 수행하도록 한다.
3. 안전성(safety):안전성이 필요한 컴포넌트는 하나나 적은 수의 서브시스템들에 두어 고립화(isolation) 시키는 것이 좋다. 이렇게 함으로써 안전성 검증에 관한 문제와 비용을 줄일 수 있다.
4. 가용성(availability):아키텍쳐에 컴포넌트를 중복시켜 둠으로써 시스템을 멈추지 않고 컴포넌트를 대체 또는 갱신시킬 수 있다.
5. 유지보수성(maintainability):컴포넌트를 잘게 분해하고(fine-grained), 독립적인 컴포넌트(self-contained)를 사용하면 변경이 쉬어진다. 데이터의 공급자와 소비자를 분리시켜야 하며 자료의 공유를 피해야 한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

3강 3장 요구 분석

학습에 앞서

이번 보충학습은 교재 3장 “ 요구 분석”의 내용 가운데 우리가 꼭 알고 있어야 하는 개념과 용어 일부를 정리한 것이다 소프트웨어공학 과목을 학습할 때 관련 개념이나, 용어들에 대해 그 의미를 정확히 이해하고 적소에 사용할 수 있어야 하는 점은 매우 중요하다

• 소프트웨어 요구 분석

소프트웨어 개발에 있어서 가장 먼저 수행할 일은 개발할 목표 도메인에 대한 이해를 하는 것이다. 목표 도메인에 대한 정확한 이해가 없으면 이후에 의도한 바와 다르게 시스템이 개발 될 수 있다. 소프트웨어를 개발할 경우 우선적으로 개발자는 고객이 원하는 요구사항과 해결안을 정확히 찾아내어야 한다. 이러한 업무가 요구사항 분석이다. 요구사항 분석은 개발할 소프트웨어가 어떻게(How) 수행되어야 하는지를 명시하는 것이 아니라, 개발할 소프트웨어가 무엇(What)을 수행하는지에 초점을 두고 있다. 요구사항을 찾아내고 분석하여 명세화하는 과정을 "요구 공학"(Requirements Engineering)이라고도 한다. 즉 요구 공학이란 고객이 시스템으로부터 요구하는 서비스가 무엇인지와 시스템이 동작하거나 개발되는 과정에 발생하는 제약사항 을 구하고 명세화하는 과정이다.

• 기능적 요구사항

시스템이 제공하는 기능과 서비스에 대한 기술이다. 기능적 사용자 요구사항(Functionaluser requirements)은 시스템의 동작사항에 대한 추상적 기술이지만 기능적 시스템 요구사항(Functional system requirements)은 시스템 서비스에 대한 상세한 기술이어야 하며, 다음과 같은 내용을 기술한다.

• 특정입력(input)에 대해 시스템이 어떻게 반응 해야 하는지에 대한 기술
• 특정 상황에 대해 시스템에 어떻게 동작해야 하는지에 대한 기술
• 시스템이 하지 말아야 할 것에 대해 기술하는 경우도 있다.

• 비기능적 요구사항

시스템에 의해 제공되는 서비스나 기능에 대한 제약사항, 시간 개발 프로세스, 표준 등에 대한 제약 사항을 기술한다. 실제 상황에선 기능과 비기능적 요구사항의 차이가 불분명할 수 있는데 사용자 요구사항에서 보안은 비기능적 요구사항이나 자세히 기술하면 사용자 인증과 같은 기능적 요구사항이 될 수도 있다. 비기능적 요구사항이 기능적 요구사항보다 훨씬 중요하다. 비기능적 요구사항이 만족되지 않는 경우 시스템 자체가 쓸모없게 될 수도 있기 때문이다. 다음과 같은 내용을 기술한다.

• 시스템 속성이나 제약사항에 대해 정의한다. 예를 들면 신뢰도, 반응 시간, 저장소용량, I/O 장치 요구사항 등이 있다.
• 프로세스 요구사항이 있을 수도 있다. 예를 들면 특정 CASE 시스템, 프로그래밍 언어나 개발 방법론을 사용해야 하는 경우이다.

• 검토회

자료 흐름도, 자료사전, 프로세스 명세서, 시스템 구조도, 각종 테스트 계획서, 사용자 지침서 및 유지보수 매뉴얼 등 시스템 개발 과정 중에 생긴 산출물의 오류를 조기에 발견하기 위하여 관련 구성원들이 모여서 산출물을 검토해 나가는 회의를 검토회(walkthrough) 라고 한다. 특히 어떤 틀에 맞추어 행해지는 검토회를 구조적 검토회(structured walkthrough) 라고 한다.

검토회를 통해 산출물의 완전성과 신뢰성을 추구할 수 있으며 개발 기간과 비용을 단축시킬 수 있다 개최 시기는 구조적 분석, 구조적 설계, 구현 및 테스트에 이르는 개발의 전과정을 통해서 중요 산출물이 만들어지면 작성자가 관리자와 상의해서 언제든지 개최할 수 있다. 검토회의 목적은 산출물을 여러 사람과 함께 검토함으로써 조기에 오류를 발견 하고자하는 것이지 작성자의 능력을 평가하는 것이 아니기 때문에 스스로 참여할 요원들과 상의해서 검토회를 개최해도 된다.

• 시스템 모델과 자료 흐름도

소프트웨어공학 분야에서 모델은 개선이 필요한 기존의 시스템을 명확히 이해하기 위해 요구 분석단계에서 사용하거나 새롭게 요구되는 시스템을 명세하는데 사용된다 사용자. 요구사항의 경우는 기술 전문가가 아닌 일반인이 이해할 수 있어야 하기 때문에 자연어(Natural Language)로 작성될 수 있다 초기 시스템 연구자들은 이렇게 모델을 자연어 를 이용하여표현하였는데 시스템을 명세하는데 다음과 같은 문제점 들이있다.

• 모호성:하나의 표현이 여러 가지 뜻을담고있는경우가있다.
• 요구사항 혼합:한 문장의 요구사항이 실제로는 여러개의 요구사항을 복합적으로 가지고 있는 경우가 있다.
• 과도한 유연성:동일한 의미를 표현하는 다양한 방법이 존재한다.
• 모듈화의 어려움:정형적으로 모듈화가 어렵다.

따라서 보다 기술적인 방법을 통해 더욱 상세한 시스템 요구사항을 만들어야 한다. 이 경우 가장 널리 쓰이는 방법이 시스템 모델을 사용하는 것이다. 시스템 모델을 통해 다양한 관점에서의 모습(view)를 제공하고 정확한 기술 기법을 이용해 시스템의 요구사항을 검증할 수 있어야한다. 소프트웨어 시스템은 크게 3가지 기능 관점, 동적 관점, 정보 관점으로 표현될 수 있다.

기능 모델은 시스템이 어떠한 기능을 수행하는가의 관점에서 시스템을 기술한다 기능 모델은 주어진 입력 데이터에 대하여 어떠한 계산을 통해 결과가 나오는가를 보여주는 관점이다. 기능 모델은 계산에 관한 논리와 현상을 보여주는 반면, 계산이 일어나는 순서는 물론 데이터가 생성되거나 도착하는 순서 등에 대해서는 기술하지 않는다. 기능 모델링에 사용되는 대표적인 분석기법을 구조적 분석이라 하며 자료흐름도(DFD:Data flow diagrams)와 자료사전에 의해 그 결과를 나타낸다. 구조적 분석기법은 정보의 흐름과 정보의 변환을 나타내는 방법으로 요구사항 분석 도구로 사용된다.

시스템의 데이터 처리를 모델링하는데 주로 사용 자료흐름도를 요약하면 다음과 같다.

• 데이터가 시스템을 따라 흐르면서 발생하는 단계적 처리를 보여준다.
• 시스템간의 데이터의 교환뿐 아니라 외부 시스템과의 교환 정보도 보여준다.
• 데이터 처리 중심의 비즈니스 시스템을 모델링할 때 많이 사용된다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

2강. 2장 계획

• 학습에 앞서

이번 보충학습은 교재 2장 “계획”의 내용 가운데 우리가 꼭 알고 있어야 하는 개념과 용어 일부를 정리한 것이다. 소프트웨어공학 과목을 학습할 때, 관련 개념이나 용어들에 대해 그 의미를 정확히 이해하고 적소에 사용할 수 있어야 하는 점은 매우 중요하다

• 간트 차트

간트 차트는 프로젝트 일정관리를 위한 바(bar)형태의 도구로서, 각 업무별로 일정의 시작과 끝을 그래픽으로 표시하여 전체 일정을 한눈에 볼 수 있다. 또한 각 업무(activities) 사이의 관계를 보여줄 수도 있다.

이것은 1차 대전 당시 미국의 핸리 간트에 의해 선박건조 프로젝트를 계획하고 조정하기 위하여 시각적인 표현 방식으로 만들어졌다. 차트의 상단에 날짜를 표시한고 좌측에 작업 목록을 표시한다. 각 작업의 스케쥴은 시작일과 종료일을 가진 가로 막대로 표시한다. 작업의 길이는 예산되는 소요기간을 나타낸다. 또한 계획된 가로 막대 위에 완료된 부분과 남아 있는 부분을 구분하여 표시할 수도 있다. 그리고 차트에 현재 시점을 나타내는 세로 막대를 그림으로써 계획과 실적 및 현재 시점과의 차이 등을 표현할 수 있다.

• PERT

PERT는 프로젝트 평가 및 재검토 기술(Program Evaluation and Review Technique)의 약자이다. 프로젝트가 종료될 것 같은 시점을 계산하기 위해 1958년에 미국 해군에 의해 개발된 사업관리 기술로서, 비관적인 경우, 낙천적인 경우, 그리고 가장 가망성 있는 경우 등으로 나누어 프로젝트의 각 단계별 종료 시기를 추정한다.

PERT는 복잡한 작업이나 프로젝트를 끝내는데 필요한 프로세스들의 기간을 네트워크 분석의 형태로 나타내며, 가능한 종료 시간의 범위를 계산하고, 근거 있는 자료에 바탕을 두고 프로세스들의 일정조정에 대한 결정을 내리는데 도움을 주기 위해 사용된다. PERT의 주 목적은 공기 단축에 있으며, 신규 사업이나 반복되지 않는 사업, 그리고 사업 수행 경험이 없는 사업 등에 적당하다.

• 이정표와 전달물

프로젝트 관리자는 진척 관리를 위해 정보가 필요하나 소프트웨어의 경우 눈에 보이는 것이 아니어서 개발 상태를 묘사하는 레포트나 문서의 형태로 제공되어야 한다. 프로젝트를 계획할 때 일련의 이정표(milestone)를 같이 계획하여야 한다. 이정표는 프로세스의 각 활동들의 마감을 인지하기 위한 것으로 관리부서에 제출하는 레포트와 같은 형식적 결과물이다. (활동이 모여 하나의 단계를 형성하고 단계가 모여 전체 프로세스를 구성한다.)

전달물(deliverable)은 고객에게 전달되는 프로젝트 결과물이다. 이것은 분석이나 설계와 같은 프로젝트의 주요 단계가 끝났을 때 전달되는 것으로 전달물은 대개 이정표이나 반대로 이정표가 전달물이 되지는 않는다. 이정표는 프로젝트 관리자가 사용하는 내부 문서이고 고객에게 전달되는 것은 아니다.

• 기능 점수(function point)

기능 점수는 정보 시스템이 사용자에게 제공하는 기능들을 양적으로 표시할 때 필요한 측정 단위이다. 이것은 정보 시스템을 구현하기 위한 기술과는 무관하다. 즉, 정보 시스템의 사용자가 느끼는 기능에 기초하여 시스템의 크기를 재기위한 소프트웨어 척도라고도 할 수 있다.

• 기능 점수 방법

소프트웨어 개발에 드는 노력 또는 비용을 예측하기 위한 방법으로의 기능 점수 방법은 소프트웨어가 가지는 기능(예를 들어 입력, 출력, 질의, 파일, 인터페이스)을 정량화하여 소프트웨어의 규모와 복잡도를 나타내고 이것을 시스템 개발에 필요한 기간과 노력 계산의 기초로 삼는 방법이다.

• COCOMO

COCOMO는 COnstructive COst MOdel의 약자로 1981년에 Barry Boehm이 고안한 소프트웨어 비용 산정 모델로 소프트웨어 프로젝트의 노력, 비용 및 시간을 추정하기 위한 것이다. 이 모델은 과거의 프로젝트 데이터와 현재 프로젝트의 특성으로부터 유도된 인자를 이용하는 공식을 사용한다. 분석의 상세함 수준에 따라 기본, 중간, 고급 COCOMO 모델이 존재한다.

• 위험(risk)

잠재적 위험 요인(hazard)이 존재하는 경우 이것은 실제 사고(accident)로 연결될 수도 있고 아닐 수도 있다. 위험(risk)은 사고가 일어날 가능성의 수준을 의미한다. 이것은 잠재적 위험 요인이 발생할 가능성과 그것의 심각성, 그리고 그것이 사고로 연결될 가능성을 고려하여 평가된다.

• 결함, 오류, 고장

결함(fault)은 오류를 야기할 수 있는 소프트웨어의 모습이다. 예를 들면 초기화되지 않은 변수와 같은 것이다. 이것이 사용되면 잘못된 값을 가지는 변수를 만들 수 있다. 오류(error)는 예상하지 못한 시스템 행위를 야기할 수 있는 정확하지 못한 시스템 상태이다.

고장(failure)은 사용자가 요구하는 서비스를 수행하지 못하는 사건의 발생을 의미한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.