[정보처리기사실기 요약정리] 요구사항확인

 

· 소프트웨어 생명 주기(Software Life Cycle)

소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것

소프트웨어 개발 단계와 각 단계별 주요 활동, 활동에 대한 산출물로 표현

 

· 나선형 모델(Spiral Model, 점진적 모델)

보헴(Boehm)이 제안한 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형

계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가 [반복]

 

· 폭포수 모형(Waterfall Model, 고전적 생명 주기 모델)

각 단계를 확실히 매듭짓고 철저하게 검토, 승인 과정을 거친 후 다음 단계를 진행하는 방법론(이전 단계로 돌아갈 수 없음)

가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모델

 

· 프로토타입 모형(Prototype Model, 원형 모형)

실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형

사용자와 시스템 사이의 인터페이스에 중점을 두어 개발

 

· 애자일(Agile)

요구사항 변화에 유연(능동적으로)하게 대응할 수 있도록 일정 주기(사이클)를 반복하면서 개발하는 모형

고객과의 소통에 초점을 맞춘 방법론

 

프로세스와 도구보다는 개인과 상호작용

방대한 문서보다는 실행되는 SW

계약 협상보다는 고객과의 협업

계획을 따르기보다는 변화에 반응

 

1) 스크럼(Scrum)

팀이 중심이 되어 개발의 효율성을 높이는 기법

 

  - 제품 책임자(PO; Product Owner) 

       요구사항이 담긴 백로그(backlog)를 작성하는 주체

       요구사항을 책임지고 의사를 결정하는 사람

   - 스크럼 마스터(SM; Scrum Master)

        스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행함

   - 개발팀(DT; Development Team)

        제품 개발을 수행하는 팀원

스크럼 개발 프로세스 1. 스프린트 계획 회의(Sprint Planning Meeting)      이번 스프린트에서 수행할 작업을 대상을 단기 일정을 수립하는 회의 2. 스프린트(Sprint)     실제 개발 작업을 진행하는 과정 (보통 2~4주) 3. 일일 스크럼 회의(Daily Scrum Meeting)      모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 상황을 회의      남은 작업 시간은 소멸 차트(Burn-down Chart)에 표시함 4. 스프린트 검토 회의(Sprint Review)     부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의 5. 스트린트 회고(Sprint Retrospective)     정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것

 

 

2) XP(eXtreme Programming) 

요구사항에 유연하게 대응하기 위해  고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

XP의 5가지 핵심 가치 - 의사소통(Communication) - 단순성(Simplicity) - 용기(Courage) - 존중(Respect) - 피드백(Feedback)

 

XP의 주요 실천 방법(Practice) - Pair Programming(짝 프로그래밍)   다른 사람과 공동으로 개발하고 책임을 나눠 갖는 환경 - Collective Ownership(공동 코드 소유)   개발 코드에 대한 권한과 책임을 공동으로 소유한다 - Test-Driven Development(테스트 주도 개발)   테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악한다   자동화된 테스팅 도구(구조, 프레임워크)를 사용한다 - Whole Team(전체 팀)   모든 구성원(고객 포함)들은 각자 역할이 있고 그 역할에 대해 책임을 가져야 한다 - Continuous Integration(계속적인 통합)   모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리 될 때마다 지속적으로 통합된다 - Refactoring(리팩토링)   프로그램 기능의 변경 없이 시스템을 재구성한다   쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 한다 - Small Releases(소규모 릴리즈)   릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있다

 

3) 칸반(Kanban)

4) Lean

5) 기능 중심 개발(FDD; Feature Driven Development)

 

 

· 소프트웨어 공학(SE; Software Engineering)

소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문

현대적인 프로래밍 기술을 계속적으로 적용해야 한다

개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다

명확한 기록을 유지해야 한다

 

· 데이터베이스 관리 시스템(DBMS)

사용자와 데이터베이스 사이에서 정보를 생성해주고 데이터베이스를 관리해주는 소프트웨어

DBMS 관련 요구사항  식별 시 고려사항 - 가용성 - 성능 - 기술 지원 - 상호 호환성 - 구축 비용

 

· 웹 애플리케이션 서버(WAS)

사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어

WAS 관련 요구사항  식별 시 고려사항 - 가용성 - 성능 - 기술 지원 - 구축 비용

 

· 오픈 소스(Open Source)

누구나 별다른 제한 없이 사용할 수 있도록 소스코드를 공개한 무료 소프트웨어

오픈소스 관련 요구사항  식별 시 고려사항 - 라이센스의 종류 - 사용자의 수 - 기술의 지속 가능성

 

·  요구사항

소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건

개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다

이해관계자들 간의 의사소통을 원할하게 하는 데 도움을 준다

 

· 기능 요구사항(Functional Requirements)

시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항

시스템이 반드시 수행해야하고 사용자가 제공받기를 원하는 기능

입력이나 출력으로 무엇이 포함되어야 하는지에 대한 사항

어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항

 

· 비기능 요구사항(Non-Functional Requirements)

품질이나 제약사항과 관련된 요구사항으로 필수가 아님

시스템 장비 요구사항

성능 요구사항

테스트 요구사항

품질 요구사항(가용성, 접합성, 상호 호환성, 대응성, 이식성, 확장성, 보안성 등)

보안 요구사항

인터페이스 요구사항

데이터를 구축하기 위해 필요한 요구사항

프로젝트 관리, 자원 요구사항

제약사항

 

· 요구사항 개발 프로세스

개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동

타당성 조사(Feasibility Study)가 선행되어야 한다 

요구사항 개발은 요구 공학의 한 요소이다

도출(Elicitation) -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)

 

· 요구사항 명세(Requirement Specification)

분석된 요구사항을 바탕으로 모델을 작성하고 문서화 하는 것

기능 요구사항은 빠짐없이 기록하고 비기능 요구사항은 필요한 것만 명세한다

구체적 명세를 위해 소단위 명세서(Mini-Spec)가 사용될 수 있다

	정형 명세 기법	비정형 명세 기법
기법	수학적 원리 기반, 모델 기반	상태/기능/객체 중심
작성 방법	수학적 기호, 정형화된 표기법	자연어를 기반으로 서술 또는 다이어그램
특징	- 요구사항을 정확하고 간결하게 표현 - 일관성이 있으므로 완전성 검증 가능 - 표기법이 어려워 일반 사용자가 이해하기 어려움	- 자연어의 사용으로 요구사항에 대한 결과가 작성자에 따라 달라 일관성이 떨어지고, 해석이 달라질 수 있음 - 내용의 이해가 쉬워 의사소통이 용이함
종류	Z기법, VDM, CSP, Petri-net	ER모델링, SADT(State Chart), FSM, Decision Table

 

·  요구사항 분석(Requirement Analysis)

소프트웨어 개발의 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동

비용과 일정에 대한 제약 설정, 타당성 조사, 요구사항 정의 문서화, 목표 설정

 

· 자료 흐름도(DFD; Data Flow Diagram, 자료 흐름 그래프, 버블 차트)

요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법

자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용된다

원, 사각형, 직선(단선/이중선)으로 자료의 흐름을 표시

자료 흐름도의 구성 요소 - 프로세스(Process) 시스템의 한 부분(처리 과정)을 나타내며 처리, 기능, 변환, 버블이라고도 함 - 자료 흐름(Data Flow) 자료의 이동이나 연관관계를 나타냄 - 자료 저장소(Data Store) 시스템에서의 자료 저장소(파일, 데이터베이스) - 단말(Terminator) 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음

 

· 자료 사전(DD; Data Dictionary)

자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것(Meta Data)

=	정의 : ~로 구성되어 있다(is composed of)
+	연결 : 그리고(and)
()	생략 : 생략 가능한 자료(Optional)
[]	선택 : 또는(or)
{}	반복 : Iteration of
* *	설명 : 주석(Comment)

 

· 요구사항 분석용 CASE(자동화 도구)

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

SADT : 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구(SoftTech사에서 개발)

SREM, PSL/PSA, TAGS

 

· HIPO(Hierarchy Input Process Output)

시스템의 분석 및 설계 또는 문서화에 사용되는 기법으로 시스템 실행 과정인 입력 -> 처리 -> 출력 기능을 표현한 것

하향식 소프트웨어 개발을 위한 문서화 도구

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

가시적 도표, 총체적 도표, 세부적 도표가 있다

 

· UML(Unified Modeling Language)

시스템 개발 과정에서 시스템 개발자와 고객, 또는 개발자 상호 간의

의사소통이 원할하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

구성 요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram)

대표적 방법론 : Rumbaugh(OMT), Booch, Jacobson

 

· 스테레오 타입(Stereotype)

UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것길러멧(Guilemet)이라고 부르는 겹화살괄호(<< >>) 사이에 표현할 형태를 기술한다

 

· 관계(Relationships) 

1) 연관(Association)

2개 이상의 사물이 서로 관련되어 있는 관계

사물 사이를 실선으로 연결하여 표현

방향성은 화살표로 표현

양방향의 경우 화살표를 생략하고 실선으로만 연결

다중도를 선 위에 표기

 (사람 / 집)

 

2) 집합(Aggregation)

하나의 사물이 다른 사물에 포함되어 있는 관계로 서로 독립적이다

포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 빈 마름모를 연결하여 표현한다

(컴퓨터 / 프린터)

 

3) 포함(Composition)

포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

포함되는 쪽과 포함하는 쪽은 독립될 수 없고 생명주기를 함께한다

포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 채워진 마름모를 연결하여 표현한다

(문 / 키)

 

4) 일반화(Generalization)

하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계

보다 일반적인 관계를 상위(부모), 구체적인 관계를 하위(자식)라고 부른다

구체적인 사물에서 일반적인 사물로 속이 빈 화살표를 연결하여 표현한다

(커피 / 아메리카노, 에스프레소)

 

5) 의존(Dependency)

연관관계와 같이 서로 연관은 있으나 서로에게 영향을 주는 짧은 시간동안만 연관을 유지하는 관계

서로 소유하는 관계는 아니지만 하나의 변화가 다른 사물에도 영향을 미친다

한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타난다

영향을 주는 사물이 영향을 받는 사물쪽으로 점선 화살표를 연결하여 표현한다

(등급 / 할인율)

 

6) 실체화(Realization)

사물이 할 수 있거나 해야하는 기능으로, 서로를 그룹화 할 수 있는 관계

한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계

사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현한다

(날 수 있다 / 비행기, 새)

 

 

· 다이어그램(Diagram)

사물과 관계를 도형으로 표현한 것

여러 관점에서 시스템을 가시화한 뷰(View)를 제공함으로써 의사소통에 도움을 준다

정적 모델링 -> 구조적 다이어그램

동적 모델링 -> 행위 다이어그램

 

1) 구조적 다이어그램 - 클객컴배복패

- 클래스(Class)

클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한다

구성 요소	표현 방법	내용
클래스(Class)	□ 세 개의 사각형 클래스명/속성/오퍼레이션	각각의 객체들이 갖는 속성과 오퍼레이션(동작) 표현 일반적으로 3개의 구획(Compartment)으로 나눔 - 이름 - 속성(Attribute) : 클래스의 상태나 정보 - 오퍼레이션(Operation) : 클래스가 수행할 수 있는 동작(함수)
제약 조건	□	속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야할 조건 클래스 안에 제약 조건을 기술 할 때에는 중괄호 {} 사용
관계(Relationships)		클래스와 클래스 사이의 연관성을 표현한 것 연관, 집합, 포함, 일반화, 의존 관계가 있음

- 연관 클래스 : 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스

두 클래스 사이의 연관관계를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시함

연관 클래스의 이름은 연관 관계의 이름을 이용해 지정

 

- 객체(Object)

클래스에 속한 객체들(Instance)을 특정 시점에 객체와 객체 사이의 관계로 표현한다

럼바우 객제지향 분석 기법에서 객체 모델링에 사용된다

 

- 컴포넌트(Component)

실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현 -> 구현 단계

 

- 배치(Deployment)

결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현 -> 구현 단계

 

- 복합체 구조(Composite Structure)

클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현

 

- 패키지(Package)

유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

구성 요소	표현 방법	내용
패키지(Package)	□□ 사각형 여러 개	객체들을 그룹화 한것 - 단순 표기법 : 패키지안에 패키지 이름만 표현 - 확장 표기법 : 패키지 안에 요소까지 표현
객체(Object)	□ 사각형 안에 글씨	유스케이스, 클래스, 인터페이스, 테이블 등  패키지에 포함될 수 있는 다양한 요소들
의존 관계(Dependency)	------------->	패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결함 스테레오 타입을 이용해 의존 관계를 구체적으로 명시 <<>> <<import>> : 패키지에 포함된 객체들을 직접 가져와서 이용하는 관계 <<access>> : 인터페이스를 통해 패키지 내 객체에 접근하여 이용하는 관계

 

 

2) 행위 다이어그램 - 유시커상활상타

- 유스케이스(Use Case)

사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용하며 사용자(Actor)와 사용 사례(Use Case)로 구성된다

구성 요소	표현 방법	내용
시스템(System) 시스템 범위(System Scope)	□ 사각형	시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위 표현
액터(Actor)	- 주액터 : 사람모형 - 부액터 : 사각형	시스템과 상호작용을 하는 모든 외부 요소(사람이나 외부 시스템) - 주액터 : 시스템을 사용함으로써 이득을 얻는 대상(주로 사람) - 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템(조직 또는 기능)
유스케이스(Use Case)	○ 원형	사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능
관계(Relationship)	- 포함 -------> - 확장 <------- - 일반화 ◁--------	액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타남 포함(Include), 확장(Extends), 일반화(Generalization)

- 포함(Include) 관계 : 두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우

원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계를 포함 관계라고 한다

원래의 유스케이스 -------------> 새로운 유스케이스 <<include>>

 

- 확장(Extende) 관계 : 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스의 관계

원래의 유스케이스 <------------ 확장될 유스케이스 <<extends>>

 

 

- 시퀀스(Sequence)

상호작용하는 시스템이나 객체들이 주고받는 메시지를 표현

구성 요소	표현 방법	내용
액터(Actor)	사람 모양	시스템으로 부터 서비스를 요청하는 외부 요소(사람이나 외부 시스템)
객체(Object)	□ 사각형 안에 글씨	메시지를 주고받는 주체
생명선(Lifeline)	--------------------	객체가 메모리에 존재하는 기간으로 객체 아래쪽에 점선으로 표시함 객체 소멸이 표시된 기간까지 존재함
실행 상자 (Active Box, 활성 상자)	----□----	객체가 메시지를 주고받으며 구동되고 있음을 표현함
메시지(Message)	→ 화살표 위에 글씨	객체가 상호 작용을 위해 주고받는 메시지 화살표 방향은 메시지를 받는쪽으로 표시함 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서를 표현함
객체 소멸	X	해당 객체가 더 이상 메모리에 존재하지 않음을 표현
프레임(Frame)	□	다이어그램 전체 또는 일부를 묶어 표현한 것

 

- 커뮤니케이션(Communication)

동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현한다

구성 요소	표현 방법	내용
액터(Actor)	사람 모양	시스템으로 부터 서비스를 요청하는 외부 요소(사람이나 외부 시스템)
객체(Object)	□ 사각형 안에 글씨	메시지를 주고받는 주체
링크(Link)	|	객체들 간의 관계를 표현한 것 액터와 객체, 객체와 객체 간의 실선을 그어 표시함
메시지(Message)	→ 화살표 위에 글씨	객체가 상호 작용을 위해 주고받는 메시지 화살표 방향은 메시지를 받는쪽으로 표시함 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서를 표현함

 

- 상태(State)

하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지 표현럼바우 객체지향 분석 기법에서 동적 모델링에 활용된다

구성 요소	표현 방법	내용
상태(State)	□ 모서리가 둥근 사각형	객체의 상태를 표현
시작 상태	●	상태의 시작
종료 상태	◎ (안에 검정색으로 채워짐)	상태의 종료
상태 전환	→	상태 사이의 흐름, 변화를 화살표로 표현
이벤트(Event)	이벤트명표시(ex.결제입력)	상태에 변화를 주는 현상 이벤트에는 조건, 외부 신호, 시간의 스름 등이 있음
프레임(Frame)	□	상태 다이어그램의 범위를 표현한 것

 

- 활동(Activity)

시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현한다

구성 요소	표현 방법	내용
액션(Action) 액티비티(Activity)	- 액션 (로그인클릭) - 액티비티 (회원정보 입력)	- 액션 : 더 이상 분해할 수 없는 단일 작업 - 액티비티 : 몇 개의 액션으로 분리될 수 있는 작업
시작 노드	●	액션이나 액티비티가 시작 됨을 표현
종료 노드	◎ (안에 검정색으로 채워짐)	액티비티 안의 모든 흐름이 종료됨을 표현
조건(판단) 노드	◇->	조건에 따라 제어의 흐름이 분리됨을 표현 들어오는 제어 흐름은 하나, 나가는 제어 흐름은 여러 개
병합 노드	◇->	여러 경로의 흐름이 하나로 합쳐짐을 표현 들어오는 제어 흐름은 여러 개, 나가는 제어 흐름은 하나
포크(Fork) 노드	↓ 〓	액티비티의 흐름이 분리되어 수행됨을 표현한 것 들어오는 액티비티의 흐름은 한개, 나가는 액티비티 흐름은 여러 개
조인(Join) 노드	〓 ↓	분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한 것 들어오는 액티비티 흐름은 여러 개, 나가는 액티비티 흐름은 한 개
스윔레인(Swin Lane)	|    ㅡ	액티비티 수행을 담당하는 주체를 구분하는 선 가로 또는 세로 실선으로 표현

 

- 상호작용(Interaction Overview)

상호작용 다이어그램 간의 제어 흐름을 표현한다

 

- 타이밍(Timing)

객체 상태 변화와 시간 제약을 명시적으로 표현한다

 

 

· 구조적 방법론

정형화된 분석 절차에 따라 사용자의 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론

이해가 쉽고 검증이 간으한 프로그램 코드를 생성하는 것이 목적

타당성 검토 -> 계획 -> 요구사항 -> 설계 -> 구현 -> 시험 -> 운용/유지보수

 

· 객치제향 방법론

현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어 기계의 부품을 조립하듯 객체들을 조립하여 소프트웨어를 구현하는 기법

구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택됨

요구 분석 -> 설계 -> 구현 -> 테스트 및 검증 -> 인도

 

· 컴포넌트 기반 방법론

기존 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 새로운 애플리케이션을 만드는 방법론

컴포넌트의 재사용(Reusability)이 가능하여 시간과 노력을 절감할 수 있다

개발 준비 -> 분석 -> 설계 -> 구현 -> 테스트 -> 전개 -> 인도

 

 

· 소프트웨어 재사용(Software Reuse)

이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것

 

1) 합성 중심(Composition-Base) - 블록 구성 방법

소프트웨어 부품, 블록을 만들어 끼워 맞춰 소프트웨어를 완성 시키는 방법 

 

2) 생성 중심(Generation-Based) - 패턴 구성 방법

추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법

 

 

· 소프트웨어 재공학(Software Reengineering)

기존 시스템을 이용하여 보다 나은 시스템을 구성하고, 새로운 기능을 추가하여 성능을 향상시키는 것

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

기존 소프트웨어의 데이터와 기능들의 개조 및 개선을 통해 유지보수성과 품질을 향상

 

· CASE(Computer Aided Software Engineering)

표준화된 개발 환경 구축 및 문서 자동화 기능 제공

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

- 소프트웨어 생명 주기 전 단계의 연결

- 다양한 소프트웨어 개발 모형 지원

- 그래픽 지원

 

 

· 비용 산정 기법

1) 하향식 비용 산정 기법

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

 

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

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

 

2) 상향식 비용 산정 기법

세부적인 작업 단위별로 비용을 산정한 후 집계하여 총 비용을 산정하는 방법

 

- 개발 단계별 인월수 기법

- LOC(source Line Of Code, 원시 코드 라인 수) 기법

각 기능의 원시 코드 라인수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법

노력(인월) =	개발 기간 x 투입 입원 = LOC / 1인당 월평균 생산 코드 라인 수
개발 비용 =	노력(인월) x 단위 비용(1인당 월평균 인건비)
개발 기간 =	노력(인월) / 투입 인원
생산성 =	LOC / 노력(인원)

 

- 수학적 산정 기법(경험적 추정 모형, 실험적 추적 모형)

개발 비용 산정의 자동화를 목표로 한다

 

① COCOMO(COnstructive COst MOdel) 모형

보헴(Boehm)이 제안한 LOC(원시 코드 라인 수)에 의한 비용 산정 기법

조직형(Organic Model)	5만 라인 이하의 중소 규모
반분리형(Semi-Detached Mode)	30만 라인 이하의 조직형과 내장형의 중간
내장형(Embedded Mode)	30만 라인 이상의 초대형 규모

 

② Putnam 모형

소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형

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

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

 

③ 기능 점수(FP; Function Point) 모형

소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며,

총 기능점수와 영향도를 이용하여 기능점수(FP)를 구한 후 이를 이용해 비용을 산정하는 방법

소프트웨어 기능 증대 요인

자료 입력(입력 양식) 정보 출력(출력 보고서) 명령어(사용자 질의수) 데이터 파일 필요한 외부 루틴과의 인터페이스

 

 

· 비용 산정 자동화 추정 도구

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

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

 

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

프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크로 각 작업별로 단계를 나누어 종료 시기를 결정한다

- 낙관적인 경우

- 가능성이 있는 경우

- 비관적인 경우

 

· CPM(Critical Path Method, 임계 경로 기법-최장 경로)

프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법

- 노드 : 작업

- 간선 : 작업 사이의 전후 의존 관계

 

· 간트 차트(시간선 차트)

작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표

 

· ISO/IEC 12207

ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스

기본 생명 주기	획득, 공급, 개발, 운영, 유지보수
지원 생명 주기	품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상 관리, 문제 해결
조직 생명 주기	관리, 기반 구조, 훈련, 개선

 

· SPICE(Software Process Improvement and Capability dEtermination) = ISO/IEC 15504

소프트웨어 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준

프로세스 수행 능력 단계

수준	단계	특징
0	불완전(Incomplete)	프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계
1	수행(Performed)	프로세스가 수행되고 목적이 달성된 단계
2	관리(Managed)	정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도
3	확립(Established)	소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행
4	예측(Predictable)	프로세스가 목적 달성을 위해 통제되고 양적인 측정을 통해서 일관되게 수행
5	최적화(Optimizing)	프로세스 수행을 최적화하고 지속적인 개선을 통해 업무 목적을 만족시키는 단계

 

· CMMI(Capability Maturity Model Integration)

소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델

프로세스 성숙도

단계	특징
초기(Initial)	작업자 능력에 따라 성공 여부 결정
관리(Management)	특정한 프로젝트 내의 프로세스 정의 및 수행
정의(Defined)	조직의 표준 프로세스를 활용하여 업무 수행
정량적 관리(Quantitatively Managed)	프로젝트를 정량적으로 관리 및 통제
최적화(Optimizing)	프로세스 역량 향상을 위해 지속적인 프로세스 개선

 

· 소프트웨어 개발 방법론 테일러링

소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업

테일러링의 고려 사항

기준	내용
내부적 기준	- 목표 환경 : 시스템 개발 환경과 유형이 서로 다른 경우 - 요구 사항 : 프로젝트에서 우선적으로 고려할 요구 사항이 서로 다른 경우 - 프로젝트 규모 : 프로젝트의 규모가 서로 다른 경우 - 보유 기술 : 프로세스, 개발 방법론, 산출물, 구성원의 능력이 서로 다른 경우
외부적 기준	- 법적 제약 사항 : IT Compliance가 서로 다른 경우 - 표준 품질 기준 : 금융, 제도 등 분야별 표준 품질 기준이 서로 다른 경우

 

· 소프트웨어 개발 프레임워크(Framework)

소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록

여러 가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템

표준화된 개발 기반으로 인해 사업자 종속성이 해소된다

 

· 스프링 프레임워크

자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크 

전자정부 표준 프레임워크의 기반 기술로 사용되고 있다

 

· 소프트웨어 개발 프레임워크의 특성

1) 모듈화(Modularity)

캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 품질 향상

개발 표준에 의한 모듈화로 인해 유지 보수가 용이하다

 

2) 재사용성(Reusability)

재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능하다

 

3) 확장성(Extensibility)

다형성을 통한 인터페이스 확장이 가능하여 다양한 형태와 가능을 가질 수 있다

 

4) 제어의 역흐름(Inversion on Control)

개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 넘김으로써 생산성 향상