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

01. 요구사항 확인

(1) 소프트웨어 생명 주기

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

• 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것
• 소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현한다.
• 대표적인 생명 주기 모형
  • 폭포수 타입
  • 프로토타입 모형
  • 나선형 모형
  • 애자일 모형

 

폭포수 모형(Waterfall Model)

• 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단게를 진행하는 개발 방법론
• 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
• 고전적 생명 주기 모형이라고 한다.
• 모형을 적용한 경험과 성공 사례가 많다.
• 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 한다.

 

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

• 사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형
• 견본품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.

 

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

• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형
• 보헴(Bohem)이 제안하였다.
• 폭포수 모형과 프로토 타입 모형의 장점에 위험 분석 기능을 추가한 모형이다.
• 누락되거나 추가된 요구사항을 첨가할 수 있다.
• 유지보수 과정이 필요 없다.
• 4가지 주요 활동
  • "계획하고 분석한 후 개발하고 평가한다."

 

애자일 모형(Agile Model)

• 애자일은 '민첩한', '기민한' 이라는 의미로, 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형이다.
• 어느 특정 개발 방법론이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭한다.
• 폭포수 모형과 대조적이다.
• 기업 활동 전반에 걸쳐 사용된다.
• 대표적인 개발 모형
  • 스크럼(Scrum)
  • XP(eXtreme Programming)
  • 칸반(Kanban)
  • Lean
  • 기능 중심 개발(FDD: Featue Driven Development)

 

애자일 개발 4가지 핵심 가치

• 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
• 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
• 계약 협상보다는 고객과 협업에 더 가치를 둔다.
• 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

 

소프트웨어 공학

• 소프트웨어 공학(SE; Software Engineering)은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문이다.
• 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 한다.
• 소프트웨어 공학의 기본 원칙
  • 현대적인 프로그래밍 기술을 계속적으로 적용해야 한다.
  • 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
  • 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.

 

 

(2) 스크럼(Scrum) 기법

스크럼(Scrum)

• 팀이 중심이 되어 개발의 효율성을 높이는 기법
• 팀원 스스로가 스크럼 팀을 구성하고, 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 한다.

 

스크럼 팀

구성원	역할
제품 책임자 (PO; Product Owner)	- 요구사항이 담긴 백로그(Backlog)를 작성하는 주체 - 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람으로 선정
스크럼 마스터 (SM; Scrum Master)	- 스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행함.
개발팀 (DT; Development Team)	- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행함.

*백로그(Backlog) : 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록

*이해관계자(Stakeholder) : 소프트웨어 개발과 관련해서 이해관계자는 소프트웨어 개발 의뢰자, 소프트웨어 개발자, 소프트웨어 사용자 등이다.

 

스크럼 개발 프로세스

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

*제품 백로그(Product Backlog) : 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록으로, 개발 과정에서 새롭게 도출되는 요구사항으로 인해 계속 업데이트 된다. 제품 백로그에 작성된 사용자 스토리는 전체 일정 계획인 릴리즈 계획(Release Plan)을 수립할 때 사용된다.

*소멸 차트(Burn-down Chart) : 해당 스프린트에서 작업의 진행 상황을 확인할 수 있도록 시간의 경과에 따라 남은 작업 시간을 그래프로 표현한 것이다. 초기에 추정했던 전체 작업 시간은 작업이 진행될 수록 점점 줄어(Burn-down)들게 된다. 

 

• 스크럼 개발을 진행할 때는 "계획하여 진행(스프린트)한 후 회의와 검토를 거쳐 회고한다."

 

 

(3) XP(eXtreme Programming) 기법

XP(eXtreme Programming)

• 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 높이는 방법
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.
• 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높인다.
• XP의 5대 핵심 가치
  • 의사소통(Communication)
  • 단순성(Simplicity)
  • 용기(Courage)
  • 존중(Respect)
  • 피드백(Feedback)

 

XP 개발 프로세스

프로세스	내용
릴리즈 계획 수립 (Release Planning)	- 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것 - 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 함.
이터레이션 (Iteration, 주기)	실제 개발 작업을 진행하는 과정으로 보통 1~3주 정도의 기간으로 진행됨.
승인 검사 (Acceptance Test, 인수 테스트)	하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트
소규모 릴리즈 (Small Release)	요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것

• "계획하고 진행(이터레이션)한 후 검사하고 출시(릴리즈)한다."

 

XP의 주요 실천 방법(Practice)

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

*영문으로도 알고 있어야 하며, 각각의 의미는 서로 구분할 수 있을 정도면 됨.

 

 

(4) 현행 시스템 파악

현행 시스템 파악 절차

프로세스	현행 시스템	내용
1단계	시스템 구성 파악	조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술함.
	시스템 기능 파악	현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시함.
	시스템 인터페이스 파악	단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시함.
2단계	아키텍처 구성 파악	최상위 수준에서 계층별로 표현한 아키텍처 구성도를 작성함.
	소프트웨어 구성 파악	소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시함.
3단계	하드웨어 구성 파악	단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 서버의 이중화 적용 여부를 명시함
	네트워크 구성 파악	서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성함.

 

 

(5) 개발 기술 환경 파악

개발 기술 환경 파악의 개요

개발하고자 하는 소프트웨어와 관련된 운영체제(OS), 데이터베이스 관리 시스템(DBMS), 미들웨어 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈 소스를 사용할 때 주의해야 할 내용을 제시한다.

 

운영체제(OS, Operating System)

• 운영체제는 컴퓨터 시스템의 자원을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어이다.
• 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종이다.
• 다른 응용 프로그램이 유용한 작업을 할 수 있도록 환경을 제공한다.
• 운영체제 관련 요구사항 식별 시 고려사항
  • 가용성
  • 성능
  • 기술 지원
  • 주변 기기
  • 구축 비용

 

데이터베이스 관리 시스템(DBMS; DataBase Management System)

• 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해주는 소프트웨어
• 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템이다.
• 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록 관리한다.
• DBMS 관련 요구사항 식별 시 고려사항
  • 가용성
  • 성능
  • 기술 지원
  • 상호 호환성
  • 구축 비용

 

웹 애플리케이션 서버(WAS; Web Application Server)

• 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
• 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리를 제공한다.
• 주로 데이터베이스 서버와 연동해서 사용한다.
• 웹 애플리케이션 서버 관련 요구사항 식별 시 고려사항
  • 가용성
  • 성능
  • 기술 지원
  • 구축 비용

 

오픈 소스(Open Source)

• 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어
• 오픈 소스 라이선스를 만족한다.
• 오픈 소스 관련 요구사항 식별 시 고려사항
  • 라이선스의 종류
  • 사용자 수
  • 기술의 지속 가능성

 

 

(6) 요구사항 정의

요구사항

• 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약 조건
• 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다.
• 개발에 참여하는 이해관계자들 간의 의사소통을 원할하게 하는 데 도움을 준다.
• 요구사항의 유형
  • 기능 요구사항(Functional Requirements)
  • 비기능 요구사항(Non-functional Requirements)
  • 사용자 요구사항(User Requirements)
  • 시스템 요구사항(System Requiremetns)

 

기능 요구사항(Functional Requirements)

• 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항
• 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지에 대한 사항
• 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
• 시스템이 반드시 수행해야 하는 기능
• 사용자가 시스템을 통해 제공받기를 원하는 기능

 

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

• 품질이나 제약사항과 관련된 요구사항
• 시스템 장비 구성 요구사항
• 성능 요구사항
• 인터페이스 요구사항
• 데이터를 구축하기 위해 필요한 요구사항
• 테스트 요구사항
• 보안 요구사항
• 품질 요구사항
  • 가용성
  • 정합성
  • 상호 호환성
  • 대응성
  • 이식성
  • 확장성
  • 보안성
• 제약사항
• 프로젝트 관리 요구사항
• 프로젝트 자원 요구사항

 

기능 요구 사항과 비기능 요구 사항의 예

*기능 요구 사항 : "사용자는 회원ID와 비밀번호를 입력하여 로그인할 수 있다." (기능)

*비기능 요구 사항 : "시스템은 1년 365일, 하루 24시간 운용이 가능해야 한다." (품질이나 제약사항)

 

사용자 요구사항(User Requirements)

• 사용자 관점에서 본 시스템이 제공해야 할 요구사항
• 사용자를 위한 것으로, 친숙한 표현으로 이해하기 쉽게 작성된다.

 

시스템 요구사항(System Requirements)

• 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
• 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현된다.
• 소프트웨어 요구사항이라고도 한다.

 

 

(7) 요구사항 개발 프로세스

요구사항 개발 프로세스

• 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동
• 요구사항 개발 프로세스가 진행되기 전에 타당성 조사(Feasibility Study)가 선행되어야 한다.
• 요구사항 개발은 요구공학(Requirement Engineering)의 한 요소이다.

"도분명확"

 

요구사항 도출(Requirement Elicitation, 요구사항 수집)

• 시스템, 사용자, 개발자 등 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정
• 개발자와 고객 사이의 관계가 만들어지고 이해관계자(Stakeholder)가 식별된다.
• 소프트웨어 개발 생명 주기(SDLC) 동안 지속적으로 반복된다.
• 요구사항을 도출하는 주요 기법
  • 청취와 인터뷰
  • 설문
  • 브레인스토밍(Brain Storming) : 3인 이상이 자유롭게 의견을 교환하면서 독창적인 아이디어를 도출해 내는 방법
  • 워크샵
  • 프로토타이핑(Prototyping)
    • 프로토타입(견본품)을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출하는 작업
    • 가장 단순한 형태 : 설명을 위해 종이에 대략적인 순서느 형태를 그려 보여주는 것
  • 유스케이스(Use Case) : 사용자의 요구사항을 기능 단위로 표현하는 것

 

요구사항 분석(Requirement Analysis)

• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
• 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.
• 서로 상충되는 요구사항이 있으면 이를 중재하는 과정이다.
• 요구사항 분석에 사용되는 대표적인 도구
  • 자료 흐름도(DFD)
  • 자료 사전(DD)

 

요구사항 명세(Requirement Specification)

• 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것
• 기능 요구사항을 빠짐없이 기술한다.
• 비기능 요구사항은 필요한 것만 기술한다.
• 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 사용될 수 있다.

 

요구사항 확인(Requirement Validation, 요구사항 검증)

• 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동
• 이해관계자들이 검토해야 한다.
• 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리(SCM)를 수행한다.

 

요구공학(Requirement Engineering)

• 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문
• 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트 실패를 최소화하는 것을 목표로 한다.

 

요구사항 명세 기법

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

 

 

(8) 요구사항 분석

요구사항 분석(Requirement Analysis)

• 소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.
• 사용자의 요구를 정확하게 추출하여 목표를 정한다.

 

구조적 분석 기법

• 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
• 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화한다.
• 하향식 방법을 사용하여 시스템을 세분화할 수 있다.
• 분석의 중복을 배제할 수 있다.
• 주요 구조적 분석 기법 도구
  • 자료 흐름도(DFD)
  • 자료 사전(DD)
  • 소단위 명세서(Mini-Spec.)
  • 개체 관계도(ERD)
  • 상태 전이도(STD)
  • 제어 명세서

 

자료 흐름도(DFD; Data Flow Diagram)

• 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
• 자료 흐름 그래프, 버블 차트라고도 한다.
• 자료 흐름과 처리 를 중심으로 하는 구조적 분석 기법에 이용된다.

 

자료 흐름도 기본 기호

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

*자료 흐름도에서 사용하는 기본 기호 4가지가 단답형으로 출제될 수 있다. (4가지 기호와 종류와 명칭을 영문까지 암기)

*Yourdon/DeMacro 표기 방법이 주로 사용된다.

 

자료 사전(DD; Data Dictionary)

• 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
• 데이터를 설명하는 데이터로, 데이터의 데이터 또는 메타 데이터(Meta Data)라고도 한다.
• 자료 사전에서 사용되는 표기 기호

기호	의미
=	자료의 정의 : ~로 구성되어 있다. (is composed of)
+	자료의 연결 : 그리고(and)
(  )	자료의 생략 : 생략 가능한 자료(Optional)
[  ]	자료의 선택 : 또는(or)
{  }	자료의 반복 : Iteration of ① $\{\}_{n}$ : n번 이상 반복 ② $\{\}^{n}$ : 최대로 n번 반복 ③ $\{\}^{n}_{m}$ : m 이상 n 이하로 반복
*  *	자료의 설명 : 주석(Comment)

 

 

(9) 요구사항 분석 CASE와 HIPO

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

• 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구
• 대표적인 요구사항 분석용 CASE
  • SADT
    • 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구
    • SoftTech 사에서 개발
    • 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구
  • SREM = RSL/REVS
    • TRW 사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 도구
    • RSL과 REVS를 사용하는 자동화 도구
      • RSL : 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어
      • REVS : RSL로 기술된 요구사항들을 자동으로 분석하여 요구사항 명세서를 출력하는 요구사항 분석기
  • PSL/PSA
    • PSL과 PSA를 사용하는 자동화 도구
      
      • PSL : 문제(요구사항) 기술 언어
      • PSA : PSL로 기술한 요구사항을 분석하여 보고서를 출력하는 문제 분석기
    • 미시간 대학에서 개발
  • TAGS
    • 시스템 공학 방법 응용에 대한 자동 접근 방법
    • 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

 

HIPO(Hierarchy Input Process Output)

• 시스템의 분석 및 설계, 또는 문서화에 사용되는 기법으로, 시스템 실행 과정인 입력·처리·출력의 기능을 표현한 것
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
• 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉽다.
• HIPO Chart : 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것
  • 종류
    • 가시적 도표(Visual Table of Contents, 도식 목차)
    • 총체적 도표(Overview Diagram, 총괄 도표, 개요 도표)
    • 세부적 도표(Detail Diagram, 상세 도표)

 

 

(10) UML(Unified Modeling Language)의 개요

UML(Unified Modeling Language)

• 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원할하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합하였다.
• OMG(Object Management Group)에서 표준으로 지정하였다.
• UML의 구성 요소
  • 사물(Things)
  • 관계(Relationships)
  • 다이어그램(Diagram)

 

사물(Things)

• 다이어그램 안에서 관계가 형성될 수 있는 대상들
• 모델을 구성하는 가장 중요한 기본 요소
• 사물의 종류
  • 구조 사물(Structured Things)
    • 시스템의 개념적, 물리적 요소를 표현
    • 클래스(Class), 유스케이스(Use Case), 컴포넌트(Component), 노드(Node) 등
  • 행동 사물(Behavioral Things)
    • 시간과 공간에 따른 요소들의 행위를 표현
    • 상호작용(Interaction), 상태 머신(State Machine) 등
  • 그룹 사물(Grouping Things)
    • 요소들을 그룹으로 묶어서 표현
    • 패키지(Package)
  • 주해 사물(Annotaton Things)
    • 부가적인 설명이나 제약조건 등을 표현
    • 노트(Note)

 

 

(11) UML - 관계(Relationship)

관계(Relationships)

• 사물과 사물 사이의 연관성을 표현하는 것
• 관계의 종류
  • 연관 관계
  • 집합 관계
  • 포함 관계
  • 일반화 관계
  • 의존 관계
  • 실체화 관계

 

연관(Association) 관계

• 2개 이상의 사물이 서로 관련되어 있는 관계
• 사물 사이를 실선으로 연결하여 표현한다.
• 방향성은 화살표로 표현한다.
• 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결한다.
• 다중도를 선 위에 표기한다.
  • 다중도 : 연관에 참여하는 객체의 개수

다중도	의미
1	1개의 객체가 연관되어 있음.
n	n개의 객체가 연관되어 있음.
0..1	연관된 객체가 없거나 1개만 존재함.
0..* 또는 *	연관된 객체가 없거나 다수일 수 있음.
1..*	연관된 객체가 적어도 1개 이상임.
n..*	연관된 객체가 적어도 n개 이상임.
n..m	연관된 객체가 최소 n개에서 최대 m개임.

 

예제 1

사람이 집을 소유하는 관계이다. 사람은 자기가 소유하고 있는 집에 대해 알고 있지만 집은 누구에 의해 자신이 소유되고 있는지 모른다는 의미이다.

• 해설
  • '사람' 쪽에 표기된 다중도가 '1'이므로 집은 한 사람에 의해서만 소유될 수 있다.
  • '집' 쪽에 표기된 다중도가 '1'이므로 사람은 집을 하나만 소유할 수 있다.

 

예제 2

선생님은 학생을 가르치고 학생은 선생님으로부터 가르침을 받는 것과 같이 선생님과 학생은 서로 관계가 있다.

• 해설
  • '선생님' 쪽에 표기된 다중도가 '1..*'이므로 학생은 한 명 이상의 선생님으로부터 가르침을 받는다.
  • '학생' 쪽에 표기된 다중도가 '1..*'이므로 선생님은 한 명 이상의 학생을 가르친다.

*사물, 즉 객체는 유스케이스, 클래스, 컴포넌트 와 같이 별도의 표현 형태가 있는 경우를 제외하고는 기본적으로 사각형으로 표현한다.

 

집합(Aggregation) 관계

• 하나의 사물이 다른 사물에 포함되어 있는 관계
• 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적이다.
• 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 빈 마름모를 연결하여 표현한다.

 

예제 

프린터는 컴퓨터에 연결해서 사용할 수 있으며, 다른 컴퓨터에 연결해서 사용할 수도 있다.

 

포함(Composition) 관계

• 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
• 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립될 수 없고 생명주기를 함께한다.
• 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, While)으로 속이 채워진 마름모를 연결하여 표현한다.

 

예제 

문을 열 수 있는 키는 하나이며, 해당 키로 다른 문은 열 수 없다. 문이 없어지면 키도 더 이상 필요하지 않다.

 

일반화(Generalization) 관계

• 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
• 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다.
• 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현한다.

 

예제 

아메리카노와 에스프레스는 커피이다. 다시 말하면, 커피에는 아메리카노와 에스프레소가 있다.

 

의존(Dependency) 관계

• 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
• 하나의 사물과 다른 사물이 소유 관계는 아니지만, 사물의 변화가 다른 사물에도 영향을 미치는 관계
• 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현한다.

 

예제 

등급이 높으면 할인율을 적용하고, 등급이 낮으면 할인율을 적용하지 않는다.

 

실체화(Realization) 관계

• 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화 할 수 있는 관계
• 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현한다.

 

예제 

비행기는 날 수 있고 새도 날 수 있다. 그러므로 비행기와 새는 날 수 있다는 행위로 그룹화 할 수 있다.

 

 

(12) UML - 다이어그램

다이어그램(Diagram)

• 사물과 관계를 도형으로 표현한 것
• 여러 관점에서 시스템을 가시화한 뷰(View)를 제공함으로써 의사소통에 도움을 준다.
• 정적 모델링에서는 주로 구조적 다이어그램을 사용한다.
• 동적 모델링에서는 주로 행위 다이어그램을 사용한다.

 

구조적(Structural) 다이어그램의 종류

종류	내용
클래스 다이어그램 (Class Diagram)	클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현함.
객체 다이어그램 (Object Diagram)	- 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현함. - 럼바우(Rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용됨.
컴포넌트 다이어그램 (Component Diagram)	- 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현함. - 구현 단계에서 사용됨.
배치 다이어그램 (Deployment Diagram)	- 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현함. - 구현 단계에서 사용됨.
복합체 구조 다이어그램 (Composite Structure Diagram)	클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현함.
패키지 다이어그램 (Package Diagram)	유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현함.

 

행위(Behavioral) 다이어그램의 종류

종류	내용
유스케이스 다이어그램 (Use Case Diagram)	- 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용함. - 사용자(Actor)와 사용 사례(Use Case)로 구성됨.
시퀀스 다이어그램 (Sequence Diagram)	상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현함.
커뮤니케이션 다이어그램 (Communication Diagram)	동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현함.
상태 다이어그램 (State Diagram)	- 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현함. - 럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용됨.
활동 다이어그램 (Activity Diagram)	시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현함.
상호작용 개요 다이어그램 (Interaction Overview Diagram)	상호작용 다이어그램 간의 제어 흐름을 표현함.
타이밍 다이어그램 (Timing Diagram)	객체 상태 변화와 시간 제약을 명시적으로 표현함.

 

스테레오 타입(Stereotype)

• UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것
• 길러멧(Guilemet)이라고 부르는 겹화살괄호(《》) 사이에 표현할 형태를 기술한다.
• 주로 표현되는 형태
  • 《include》 : 연결된 다른 UML 요소에 대해 포함 관계에 있는 경우
  • 《extend》 : 연결된 다른 UML 요소에 대해 확장 관계에 있는 경우
  • 《interface》 : 인터페이스를 정의하는 경우
  • 《exception》 : 예외를 정의하는 경우
  • 《constructor》 : 생성자 역할을 수행하는 경우

 

 

(13) 유스케이스(Use Case) 다이어그램

기능 모델링

• 사용자의 요구사항을 분석하여 개발될 시스템이 갖춰야 할 기능을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 그림으로 표현하는 것
• 개발될 시스템의 전반적인 형태를 기능에 초점을 맞춰 표현한다.
• 기능 모델링의 종류
  • 유스케이스(Use Case) 다이어그램
  • 액티비티(Activiry) 다이어그램

 

유스케이스(Use Case) 다이어그램

• 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것
• 외부 요소와 시스템 간의 상호 작용을 확인할 수 있다.
• 사용자의 요구사항을 분석하기 위한 도구로 사용된다.
• 시스템의 범위를 파악할 수 있다.

 

유스케이스(Use Case) 다이어그램의 구성 요소

예제 : 다음은 <상품주문> 시스템에 대한 유스케이스 다이어그램이다.

• 해설
  • 고객은 회원과 비회원으로 구분된다.
  • 회원은 상품조회, 상품주문, 배송조회, 리뷰작성 기능을 사용할 수 있다.
  • 비회원은 상품조회 기능만 사용할 수 있다.
  • 고객은 이름이나 브랜드로 상품을 조회할 수 있다.
  • 회원이 상품주문, 배송조회, 리뷰작성 기능을 사용하려면 반드시 로그인을 수행해야 한다.
  • 회원이 리뷰작성을 할 때 필요한 겨우 사진 업로드 기능을 사용할 수 있다.
  • 회원이 상품주문을 완료하려면 재고 시스템을 통해 재고 여부를 확인해야 한다.
  • 회원이 상품주문을 완료하려면 결제 시스템을 통해 승인을 받아야 한다.
  • 회원은 배송업체를 통해 배송조회를 할 수 있다.

구성 요소	표현 방법	내용
시스템(System) / 시스템 범위(System Scope)		시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현한 것
액터(Actor)		- 시스템과 상호작용을 하는 모든 외부 요소 - 주로 사람이나 외부 시스템을 의미함. - 주액터 : 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당됨. - 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로, 조직이나 기관 등이 될 수 있음.
유스케이스 (Use Case)		사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것
관계 (Relationship)		- 유스케이스 다이어그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있음. - 유스케이스에서 나타날 수 있는 관계 : 포함(Include) 관계, 확장(Extend) 관계, 일반화(Generalization) 관계

*포함(Include) 관계 : 2개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계

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

 

 

(14) 활동(Activity) 다이어그램

활동(Activity) 다이어그램

• 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
• 하나의 유스케이스 안에서 혹은 유스케이스 사이에 발생하는 복잡한 처리의 흐름을 명확하게 표현할 수 있다.
• 자료 흐름도 와 유사하다.

 

활동 다이어그램의 구성 요소

예제 : 다음은 회원의 상품 주문 과정에 결제 시스템과 재고 시스템이 관계되어 발생하는 처리의 흐름을 표현한 활동 다이어그램이다.

 

• 해설
  • <회원> 액터
    • 회원이 상품을 주문하기 위해 로그인 단추를 클릭한 후 회원 정보를 입력한다.
    • 입력된 정보가 잘못됐으면 회원 정보를 다시 입력받고, 그렇지 않으면 '주문 상품 선택'으로 이동한다.
    • 회원이 주문할 상품을 선택하면 흐름이 '결제 인증'과 '상품 재고 확인'으로 분할되어 진행된다.
    • 상품 주문을 완료하고 액티비티를 종료한다.
  • <결제> 시스템
    • 주문한 상품에 대한 결제 인증을 진행한다.
    • 인증에 성공하면 '주문 완료'로 이동하고, 인증에 실패하면 '인증 재시도'로 이동한다.
    • 다시 진행한 결제 인증이 성공하면 '주문 완료'로 이동하고, 이번에도 인증이 실패하면 결제 인증에 대한 처리 흐름을 종료한다.
  • <재고> 시스템
    • 주문한 상품에 대한 재고를 확인한다.
    • 재고가 있으면 액티비티의 흐름을 '주문 완료'로 이동하고, 재고가 없으면 회원이 다른 상품을 선택할 수 있도록 '주문 상품 선택'으로 이동한다.

구성 요소	표현 방법	내용
액션(Action) / 액티비티(Activity)		- 액션 : 더 이상 분해할 수 없는 단일 작업 - 액티비티 : 몇 개의 액션으로 분리될 수 있는 작업
시작 노드		액션이나 액티비티가 시작됨을 표현한 것
종료 노드		액티비티 안의 모든 흐름이 종료됨을 표현한 것
조건(판단) 노드		- 조건에 따라 제어의 흐름이 분리됨을 표현한 것 - 들어오는 제어 흐름은 1개이고, 나가는 제어 흐름은 여러 개임.
병합 노드		- 여러 경로의 흐름이 하나로 합쳐짐을 표현한 것 - 들어오는 제어 흐름은 여러 개이고, 나가는 제어 흐름은 1개임.
포크(Fork) 노드		- 액티비티의 흐름이 분리되어 수행됨을 표현한 것 - 들어오는 액티비티의 흐름은 1개이고, 나가는 액티비티 흐름은 여러 개임.
조인(Join) 노드		- 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한 것 - 들어오는 액티비티 흐름은 여러 개이고, 나가는 액티비티 흐름은 1개임.
스윔레인(Swim Lane)		- 액티비티 수행을 담당하는 주체를 구분하는 선 - 가로 또는 세로 실선을 그어 구분함.

 

 

(15) 클래스(Class) 다이어그램

정적 모델링

• 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것
• 시스템에 의해 처리되거나 생성될 객체들 사이에 어떤 관련이 있는지를 구조적인 관점(View)에서 표현한다.
• 정적 모델링은 객체(Object)들을 클래스(Class)로 추상화하여 표현한다.
• UML을 이용한 정적 모델링의 대표적인 것이 클래스 다이어그램 이다.

 

클래스(Class) 다이어그램

• 클래스와 클래스가 자신을 가지는 속성, 클래스 사이의 관계를 표현한 것
• 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램
• 시스템 구성 요소를 문서화하는 데 사용된다.

 

클래스 다이어그램의 구성 요소

예제 : 다음은 프로야구 리그에 필요한 정보의 일부를 표현한 클래스 다이어그램이다.

 

 

• 해설
  • 리그에는 10개의 팀이 참가한다.
  • 리그는 1개 이상의 경기장에서 경기가 진행된다.
  • 매 경기는 두 팀이 진행하며, 두 팀은 한 번 이상의 경기를 진행한다.
  • 한 팀에는 1명 이상의 선수가 있다.
  • 한 경기장에서는 한 경기 이상이 진행되며, 경기는 여러 경기장에서 진행된다.
  • 한 팀에서 최소 9명 이상의 선수가 한 경기에 출전하며, 경기에 출전하지 못하는 선수도 있고 여러 경기에 출전하는 선수도 있다.
  • 선수는 주전선수와 후보선수가 있다.
  • 선수의 경력은 0보다 큰 값이 입력되어야 한다.
  • 승점이 5점 이상인 선수들은 연봉을 조정할 수 있으며, 연봉은 승점만큼 증가한다.

 

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

 

연관 클래스

• 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스
• 두 클래스의 연관 관게를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시한다.
• 연관 클래스의 이름은 연관 관계의 이름을 이용해 지정한다.

 

예제 : 팀이 경기에 참여하는 상황에서 참여횟수와 참여결과 속성을 어디에 두어야 할지를 생각해보자.

먼저 '팀' 클래스에 참여횟수와 속성을 둔다면 팀이 어느 경기에 참여한 것인지 모호해진다. 또한 '경기' 클래스에 참여횟수와 참여결과 속성을 둔다면 어느 팀이 참여한 것인지 모호해진다.

이런 경우, '팀'이나 '경기' 클래스의 속성이 아닌 '참여하다'라는 연관 관게에 대한 연관 클래스를 만들어 '참여횟수'와 '참여결과' 속성을 연관 클래스의 속성으로 다루면 된다.

 

 

 

(16) 시퀀스(Sequence) 다이어그램

동적 모델링

• 시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것
• 시스템 내부 구성 요소들 간에 이루어지는 동작이라는 관점(View)에서 표현한다.
• 시스템이 실행될 때 구성 요소들 간의 메시지 호출, 즉 오퍼레이션을 통한 상호 작용에 초점을 둔다.
• 동적 모델링의 종류
  • 시퀀스 다이어그램
  • 커뮤니케이션 다이어그램
  • 상태 다이어그램

 

시퀀스(Sequence) 다이어그램

• 시스템이나 객체들이 메시지를 주고 받으며 상호 작용하는 과정을 그림으로 표현한 것
• 시스템이나 객체들의 상호 작용 과정에서 주고받는 메시지를 표현한다.
• 각 동작에 참여하는 시스템이나 객체들의 수행 기간을 확인할 수 있다.
• 클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현한다.

 

시퀀스 다이어그램의 구성 요소

예제 : 다음은 회원의 상품 주문 과정에 재고 시스템과 결제 시스템이 관계되어 상호 작용하는 과정을 표현한 시퀀스 다이어그램이다.

• 해석
  • <회원> 엑터 
    • 로그인 버튼을 클릭한다.
    • ID와 비밀번호를 입력한다.
    • 로그인이 완료되면 상품 선택 화면에서 주문할 상품을 선택한다.
    • 주문할 상품에 대한 재고 확인이 완료되면 결제 화면에 결제 정보를 입력한다.
    • 결제가 완료되어 "결제 및 주문 완료" 메시지를 확인한 후 소멸된다.
  • <로그인화면> 객체
    • <회원>으로부터 입력받은 ID와 비밀번호가 올바른지 <회원정보> 객체에게 확인을 요청한다.
    • "로그인 완료" 메시지를 받으면 <회원>에게 상품 선택 화면을 출력한 후 소멸된다.
  • <회원정보> 객체
    • 입력받은 ID와 비밀번호를 확인한다.
    • "로그인 완료" 메시지를 전송한 후 소멸된다.
  • <상품선택화면> 객체
    • <회원>이 주문할 상품을 선택하면 선택된 상품에 대한 <신발 : 신규주문> 객체를 생성한 후 소멸된다.
  • <신발 : 신규주문> 객체
    • "주문생성" 메시지를 받으면 새로운 객체로 생성된다.
    • <재고 시스템>에게 주문한 상품에 대한 재고 확인을 요청한다.
    • "재고 있음" 메시지를 받으면 <회원>에게 결제 화면을 출력한 후 소멸된다.
  • <카드 : 결제화면> 객체
    • <회원>이 결제 정보를 입력하면 <결제 시스템>에게 결제 정보 확인을 요청한다.
    • "결제 승인" 메시지를 받으면 <회원>에게 "결제 및 주문 완료" 메시지를 전송한 후 소멸된다.
  • <재고 시스템> 액터
    • <회원>이 주문한 상품에 대한 재고를 확인다.
    • <신발 : 신규주문> 객체에게 "재고 있음" 메시지를 전송한 후 소멸된다.
  • <결제 시스템> 액터
    • <회원>이 입력한 결제 정보를 확인한다.
    • <카드 : 결제화면>에게 "결제 승인" 메시지를 전송한 후 소멸된다.

 

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

*묵시적으로 (메시지에 번호가 없으면) 위쪽의 메시지가 아래쪽의 메시지보다 시간 순서상 먼저 전달되는 메시지이다. 

 

 

(17) 커뮤니케이션(Communication) 다이어그램

커뮤니케이션(Communication) 다이어그램

• 시스템이나 객체들이 메시지를 주고받으며 상호 작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것
• 동작에 참여하는 객체들 사이의 관계를  파악하는 데 사용된다.
• 클래스 다이어그램에서 관계가 표현됐는지 점검하는 용도로도 사용된다.
• 초기에는 협업(Collaboration) 다이어그램이라고 불렸다.

 

커뮤니케이션 다이어그램의 구성 요소

예제 : 다음은 회원의 상품 주문 과정을 표현한 커뮤니케이션 다이어그램이다.

 

• 해석
  • 상품 주문 과정에서 상호 작용하는 객체들 간의 관계
    • <회원> 액터는 <로그인화면>, <상품선택화면>, <신발 : 신규주문>, <카드 : 결제화면> 객체와 관계되어 있다.
    • <로그인화면> 객체는 <회원정보> 객체와 관계되어 있다.
    • <상품선택화면> 객체는 <신발 : 신규주문> 객체와 관계되어 있다.
    • <신발 : 신규주문> 객체는 <재고> 시스템과 관계되어 있다.
    • <카드 : 결제화면> 객체는 <결제> 시스템과 관계되어 있다.

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

 

 

(18) 상태(State) 다이어그램

상태(State) 다이어그램

• 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것이다.
• 객체의 상태란 객체가 갖는 속성 값의 변화를 의미한다.
• 특정 객체가 어떤 이벤트에 의해 상태 변환 과정이 진행되는지 확인하는 데 사용된다.
• 시스템에서 상태 변환 이벤트를 확인할 필요가 있는 객체만을 대상으로 그린다.

 

상태 다이어그램의 구성 요소

예제 : 다음은 상품결제 객체의 상태 변화를 표현한 상태 다이어그램이다.

• 해석
  • <결제 준비> 상태의 상태 변화
    • 결제 과정이 시작되면 객체는 <결제 준비> 상태로 전환된다.
    • '결제정보 입력' 이벤트에 의해 <결제 대기> 상태로 전환된다.
  • <결제 대기> 상태의 상태 변화
    • '결제정보 입력' 이벤트에 의해 <결제 대기> 상태로 전환된다.
    • '결제정보 일치' 이벤트에 의해 <결제 완료> 상태로 전환된다.
    • '결제정보 불일치' 이벤트에 의해 <결제 실패> 상태로 전환된다.
  • <결제 실패> 상태의 상태 변화
    • '결제정보 불일치' 이벤트에 의해 <결제 실패> 상태로 전환된다.
    • '결제 재시도' 이벤트에 의해 <결제 준비> 상태로 전환된다.
  • <결제 완료> 상태의 상태 변화
    • '결제정보 일치' 이벤트에 의해 <결제 완료> 상태로 전환된다.

 

구성 요소	표현 방법	의미
상태(State)		객체의 상태를 표현한 것
시작 상태		상태의 시작을 표현한 것
종료 상태		상태의 종료를 표현한 것
상태 전환		상태 사이의 흐름, 변화를 화살표로 표현한 것
이벤트(Event)		- 상태에 변화를 주는 현상 - 이벤트에는 조건, 외부 신호, 시간의 흐름 등이 있음.
프레임(Frame)		상태 다이어그램의 범위를 표현한 것

 

 

(19) 패키지(Package) 다이어그램

패키지(Package) 다이어그램

• 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것
• 패키지는 또 다른 패키지의 요소가 될 수 있다.
• 대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용한다.

 

패키지(Package) 다이어그램의 구성 요소

예제 : 다음은 회원이 상품 주문 시 패키지들 간의 의존 관계를 표현한 패키지 다이어그램이다.

 

• 해석
  • 패키지 구성 설명 
    • <회원>, <로그인>, <상품 주문>, <결제> 패키지가 존재한다.
    • <회원> 패키지는 <로그인>과 <상품 주문> 패키지를 포함하고 있다.
    • <결제> 패키지는 '결제 인증'과 '환불' 객체를 포함하고 있다.
  • 의존 관계 설명
    • <상품 주문>과 <로그인> 패키지 간의 의존 관계
      • <상품 주문> 패키지는 주문자를 확인하기 위해 <로그인> 패키지를 이용한다.
      • 《import》 관계이므로 패키지에 포함된 객체들을 직접 가져와서 이용할 수 있는 관계이다.
  • <상품 주문> 패키지와 <결제> 패키지의 '결제 인증' 객체와 의존 관계
    • <상품 주문> 패키지는 주문된 상품의 결제를 위해 <결제> 패키지의 '결제 인증' 객체를 이용한다.
    • 《access》 관계이므로 인터페이스를 통해 접근하여 이용할 수 있는 관계이다.

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

 

단순 표기법 예	확장 표기법 예

 

 

(20) 소프트웨어 개발 방법론

소프트웨어 개발 방법론

• 소프트웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것
• 소프트웨어 개발 방법론의 목적
  • 소프트웨어의 생산성과 품질 향상
• 주요 소프트웨어 개발 방법론
  • 구조적 방법론
  • 정보공학 방법론
  • 객체지향 방법론
  • 컴포넌트 기반(CBD) 방법론
  • 제품 계열 방법론
  • 애자일 방법론

 

구조적 방법론

• 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론
• 1960년대까지 가장 많이 적용되었던 소프트웨어 개발 방법론
• 쉬운 이해 및 검증이 가능한 프로그램 코드를 생성하는 것이 목적이다.
• 복잡한 문제를 다루기 위해 분할과 정복(Divide and Conquer) 원리를 적용한다.
• 개발 절차

 

정보공학 방법론

• 정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료(Data) 중심의 방법론
• 정보 시스템 개발 주기를 이용하여 대규모 정보 시스템을 구축하는데 적합하다.
• 개발 절차

 

객체지향 방법론

• 현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되었다.
• 구성 요소
  • 객체(Object) : 데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 소프트웨어 모듈
  • 클래스(Class) : 공통된 속성과 연산을 갖는 객체의 집합으로 객체의 일반적인 타입(Type)
  • 메시지(Message) : 객체들 간에 상호작용을 하는 데 사용되는 수단으로, 객체에게 어떤 행위를 하도록 지시하는 명령 또는 요구 사항
• 기본 원칙
  • 캡슐화(Encapsulation) : 데이터와 데이터를 처리하는 함수를 하나로 묶는 것
  • 정보 은닉(Information Hiding) : 캡슐화에서 가장 중요한 개념으로, 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것
  • 추상화(Abstraction) : 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에 중점을 두어 개략화하는 것
  • 상속성(Inheritance) : 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
  • 다형성(Polymorphism) : 메시지에 의해 객체가 연산을 수행하게 될 때 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
• 개발 절차

 

컴포넌트 기반(CBD; Component Based Design) 방법론

• 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
• 컴포넌트의 재사용(Reusability)이 가능하여 시간과 노력을 절감할 수 있다.
• 새로운 기능을 추가하는 것이 간단하여 확장성이 보장된다.
• 유지 보수 비용을 최소화하고 생산성 및 품질을 향상시킬 수 있다.
• 개발 절차

 

제품 계열 방법론

• 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
• 임베디드 소프트웨어를 만드는데 적합하다.
• 구분
  • 영역공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역
  • 응용공학 : 제품 요구 분석, 제품 설계, 제품을 구현하는 영역
• 영역공학과 응용공학의 연계를 위해 제품의 요구사항, 아키텍처, 조립 생산이 필요하다.

 

 

(21) S/W 공학의 발전적 추세

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

• 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
• 소프트웨어 개발의 품질과 생산성을 높이기 위한 방법
• 기존에 개발된 소프트웨어와 경험, 지식 등을 새로운 소프트웨어에 적용한다.
• 방법
  • 합성 중심(Composition-Based)
    • 전자 칩과 같은 소프트웨어 부품, 즉 블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법
    • 블록 구성 방법이라고도 함.
  • 생성 중심(Generation-Based)
    • 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법
    • 패턴 구성 방법이라고도 함.

 

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

• 새로운 요구에 맞도록 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것
• 유지보수 비용이 소프트웨어 개발 비용의 대부분을 차지하기 때문에 유지보수의 생산성 향상을 통해 소프트웨어 위기를 해결하는 방법
• 기존 소프트웨어의 데이터와 기능들의 개조 및 개선을 통해 유지보수성과 품질을 향상시킨다.
• 이점
  • 소프트웨어의 품질 향상
  • 소프트웨어의 생산성 증가
  • 소프트웨어의 수명 연장
  • 소프트웨어의 오류 감소

 

CASE(Computer Aided Software Engineering)

• 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
• 객체지향 시스템, 구조적 시스템 등 다양한 시스템에서 활용되는 자동화 도구(CASE Tool)
• 소프트웨어 생명 주기의 전체 단게를 연결하고 자동화하는 통합된 도구를 제공한다.
• 소프트웨어 개발 도구와 방법론이 결합되었으며, 정형화된 구조 및 방법을 소프트웨어 개발에 적용하여 생산성 향상을 구현한다.
• 주요 기능
  • 소프트웨어 생명 주기 전 단계의 연결
  • 다양한 소프트웨어 개발 모형 지원
  • 그래픽 지원

 

 

(22) 비용 산정 기법

소프트웨어 비용 산정

• 개발에 소요되는 인원, 자원, 기간 등으로 소프트웨어의 규모를 확인하여 개발 계획 수립에 필요한 비용을 산정하는 것
• 소프트웨어 비용을 너무 높게 산정할 경우 예산 낭비와 일의 효율성 저하가 초래할 수 있고, 너무 낮게 산정할 경우 개발자의 부담이 가중되고 품질 문제가 발생할 수 있다.
• 기법
  • 하향식 비용 산정 기법
  • 상향식 비용 산정 기법

 

소프트웨어 비용 결정 요소

요소	내용
프로젝트 요소	- 제품 복잡도 : 소프트웨어의 종류에 따라 발생할 수 있는 문제점들의 난이도 - 시스템 크기 : 소프트웨어의 규모에 따라 개발해야 할 시스템의 크기 - 요구되는 신뢰도 : 일정 기간 내 주어진 조건하에 프로그램이 필요한 기능을 수행하는 정도
자원 요소	- 인적 자원 : 소프트웨어 개발 관련자들이 갖춘 능력 혹은 자질 - 하드웨어 자원 : 소프트웨어 개발 시 필요한 장비와 워드프로세서, 프린터 등의 보조 장비 - 소프트웨어 자원 : 소프트웨어 개발 시 필요한 언어 분석기, 문서화 도구 등의 개발 지원 도구
생산성 요소	- 개발자 능력 : 개발자들이 갖춘 전문지식, 경험, 이해도, 책임감, 창의력 등 - 개발 기간 : 소프트웨어를 개발하는 기간

*소프트웨어 개발 비용은 시스템의 크기가 크고, 신뢰도가 높을수록 많이 들고, 개발 후기로 갈수록 적게 든다.

 

 

(23) 비용 산정 기법 - 하향식

하향식 비용 산정 기법

• 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법
• 프로젝트의 전체 비용을 산정한 후 각 작업별로 비용을 세분화한다.
• 기법
  • 전문가 감정 기법
  • 델파이 기법

 

전문가 감정 기법

• 조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법
• 가장 편리하고 신속하게 비용을 산정할 수 있다.
• 의뢰자로부터 믿음을 얻을 수 있다.
• 개인적이고 주관적일 수 있다.

 

델파이 기법

• 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법
• 전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성된다.

 

 

(24) 비용 산정 기법 - 상향식

상향식 비용 산정 기법

• 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
• 주요 기법
  • LOC(원시 코드 라인 수) 기법
  • 개발 단계별 인월수 기법
  • 수학적 산정 기법

 

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

• 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
  • 비관치 : 가장 많이 측정된 코드 라인 수
  • 낙관치 : 가장 적게 측정된 코드 라인 수
  • 기대치 : 측정된 모든 코드 라인 수의 평균
• 측정이 용이하고 이해하기 쉬워 가장 많이 사용된다.
• 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정한다.

$$ \frac{a + 4m + b}{6} \quad (a : 낙관치, b : 비관치, m : 기대치(중간치)) $$

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

 

예제 : LOC 기법에 의하여 예측된 총 라인 수가 30,000라인, 개발에 참여할 프로그래머가 5명, 프로그래머들의 평균 생산성이 월간 300라인일 때 개발에 소요되는 기간은?

• 노력(인월) = LOC / 1인당 월평균 생산 코드 라인 수 = 30000 / 300 = 100명
• 개발 기간 = 노력(인월) / 투입 인원 = 100 / 5 = 20개월

 

개발 단계별 인원수(Effort Per Task) 기법

• LOC 기법을 보완하기 위한 기법으로, 각 기능을 구현시키는 데 필요한 노력을 생명 주기의 각 단계별로 산정한다.
• LOC 기법보다 더 정확하다.

 

 

(25) 수학적 산정 기법

수학적 산정 기법

• 상향식 비용 산정 기법
• 경험적 추정 모형, 실험적 추정 모형이라고 한다.
• 개발 비용 산정의 자동화를 목표로 한다.
• 비용의 자동산정을 위해 사용되는 공식은 과거의 유사한 프로젝트를 기반으로 유도된 것이다.
• 주요 기법
  • COCOMO 모형
  • Putnam 모형
  • 기능 점수(FP) 모형

 

COCOMO(COnstructive COst MOdel) 모형

• 원시 프로그램의 규모인 LOC(원시 코드 라인 수)에 의한 비용 산정 기법
• 개발할 소프트웨어의 규모(LOC)를 예측한 후, 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 산정한다.
• 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 나타낸다.
• 보헴(Boehm)에 제안하였다.

 

COCOMO의 소프트웨어 개발 모형

유형	특징
조직형 (Organic Mode)	- 기관 내부에서 개발된 중소 규모의 소프트웨어 - 일괄 자료 처리나 과학기술 계산용, 비지니스 자료 처리용 등의 5만(50KDSI) 라인 이하의 소프트웨어를 개발하는 유형 - 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합함.
반분리형 (Semi-Detached Mode)	- 조직형과 내장형의 중간형 소프트웨어 - 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형 - 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합함.
내장형 (Embedded Mode)	- 초대형 규모의 소프트웨어 - 트랜잭션 처리 시스템이나 운영체제 등의 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형 - 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합함.

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

 

COCOMO 모형의 종류

유형	특징
기본형(Basic) COCOMO	소프트웨어의 크기와 개발 유형만을 이용하여 비용 산정
중간형(Intermediate) COCOMO	기본형 COCOMO의 공식을 토대로 사용하나, 다음 4가지 특성에 의해 비용을 산정함. - 제품의 특성 - 컴퓨터의 특성 - 개발 요원의 특성 - 프로젝트 특성
발전형(Detailed) COCOMO	- 중간형 COCOMO를 보완하여 만들어진 모형 - 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용 산정 - 소프트웨어 환경과 구성 요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 적용함.

 

Putnam 모형

• 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
• 푸트남(Putnam)이 제안한 것으로, 생명 주기 예측 모형이라고도 한다.
• 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
• 대형 프로젝트의 노력 분포 산정에 이용된다.
• 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소한다.

 

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

• 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며, 총 기능 점수와 영향도를 이용하여 기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정하는 기법
  • 총 기능 점수 : 소프트웨어 개발의 규모, 복잡도, 난이도 등을 하나의 수치로 집약시킨 것
• 알브레히트(Albrecht)가 제안하였다.
• 소프트웨어 기능 증대 요인
  • 자료 입력 (입력 양식)
  • 정보 출력 (출력 보고서)
  • 명령어 (사용자 질의수)
  • 데이터 파일
  • 필요한 외부 루틴과의 인터페이스

 

비용 산정 자동화 추정 도구

• SLIM
  • Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구
• ESTIMACS
  • 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구

 

 

(26) 프로젝트 일정 계획

프로젝트 일정(Scheduling) 계획

• 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여 소작업의 순서와 일정을 정하는 것
• 프로젝트 일정 계획에 사용되는 기능
  • WBS(Work Breakdown Structure, 업무 분류 구조) : 개발 프로젝트를 여러 개의 작은 관리 단위로 분할하여 계층적으로 기술한 업무 구조
  • PERT/CPM : 프로젝트의 지연을 방지하고 계획대로 진행되도록 일정을 계획하는 것으로, 대단위 계획의 조직적인 추진을 위해, 비용을 적게 사용하면서 최단시간 내 계획 완성을 위한 프로젝트 일정 방법
  • 간트 차트

 

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

• 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크
• 각 직업별로 다음과 같이 단계를 나누어 종료시기를 결정한다.
  • 낙관적인 경우
  • 가능성이 있는 경우
  • 비관적인 경우
• 개발 경험이 없어 소요 기간 예측이 어려운 프로젝트 일정 계획에 사용한다.
• 노드와 간선으로 구성되며, 원 노드에는 작업을, 간선에는 낙관치, 기대치, 비관치를 표시한다.
  • 낙관치 : 모든 상황이 좋아서 최대로 빨리 진행될 때 걸리는 시간
  • 기대치 : 모든 상황이 정상적으로 진행될 때 걸리는 시간
  • 비관치 : 모든 상황에 많은 장애가 생겨서 가장 늦게 진행될 때 걸리는 시간
• 결정 경로, 작업에 대한 경계 시간, 작업 간의 상호 관련성 등을 알 수 있다.
• 작업 예측치 계산 공식

$$ 작업\, 예측치 = \frac{비관치 + 4 × 기대치 + 낙관치}{6} $$ $$ 평방\, 편차 = [\frac{(비관치 - 낙관치)}{6}]^{2}$$

 

CPM(Critical Path Method 임계 경로 기법)

• 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
• 노드와 간선으로 구성된 네트워크
  • 노드 : 작업
  • 간선 : 작업 사이의 전후 의존 관계
• 원형 노드는 각각의 작업을 의미하며, 작업 이름과 소요 시간을 표시한다.
• 박스 노드는 이정표를 의미하며, 이정표 이름과 예상 완료 시간을 표시한다.
• 간선을 나타내는 화살표의 흐름에 따라 각 작업이 진행되며, 전 작업이 완료되어야 다음 작업을 진행할 수 있다.

 

간트 차트

• 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표
• 시간선(Time-Line) 차트라고도 한다.
• 중간 목표 미달성 시 그 이유와 기간을 예측할 수 있게 한다.
• 사용자와의 문제점이나 예산의 초과 지출 등도 관리할 수 있게 한다.
• 자원 배치와 인원 계획에 유용하게 사용된다.
• 이정표, 작업 일정, 작업 기간, 산출물로 구성되어 있다.
• 수평 막대의 길이는 각 작업(Task)의 기간을 나타낸다.

 

소프트웨어 개발 방법론 결정

소프트웨어 개발 방법론 결정

• 프로젝트 관리와 재사용 현황을 소프트웨어 개발 방법론에 반영하고, 확정된 소프트웨어 생명 주기와 개발 방법론에 맞춰 소프트웨어 개발 단계, 활동, 작업, 절차 등을 정의하는 것
• 결정 절차
  • ① 프로젝트 관리와 재사용 현황을 소프트웨어 개발 방법론에 반영한다.
  • ② 개발 단계별 작업 및 절차를 소프트웨어 생명 주기에 맞춰 수립한다.
  • ③ 결정된 소프트웨어 개발 방법론의 개발 단계별 활동 목적, 작업 내용, 산출물에 대한 메뉴얼을 작성한다.

 

프로젝트 관리(Project Management)

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

관리 유형	주요 내용
일정 관리	작업 순서, 작업 기간 산정, 일정 개발, 일정 통제
비용 관리	비용 산정, 비용 예산 편성, 비용 통제
인력 관리	프로젝트 팀 편성, 자원 산정, 프로젝트 조직 정의, 프로젝트 팀 개발, 자원 통제, 프로젝트 팀 관리
위험 관리	위험 식별, 위험 평가, 위험 대처, 위험 통제
품질 관리	품질 계획, 품질 보증 수행, 품질 통제 수행

 

 

(28) 소프트웨어 개발 표준

소프트웨어 개발 표준

• 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준
• 주요 소프트웨어 개발 표준
  • ISO/IEC 12207
  • CMMI(능력 성숙도 통합 모델)
  • SPICE(소프트웨어 처리 개선 및 능력 평가 기준)

 

ISO/IEC 12207

• ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스
• 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공한다.
• 구분
  • 기본 생명 주기 프로세스
    • 획득, 공급, 개발, 운영, 유지보수 프로세스
  • 지원 생명 주기 프로세스
    • 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상 관리, 문제 해결 프로세스
  • 조직 생명 주기 프로세스
    • 관리, 기반 구조, 훈련, 개선 프로세스

 

CMMI(Capability Maturity Model Integration)

• 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델
• 미국 카네기멜론 대학교의 소프트웨어 공학연구소(SEI)에서 개발하였다.
• CMMI의 소프트웨어 프로세스 성숙도

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

 

SPICE(Software Process Improvement and Capability dEtermination)

• 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
• 공식 명칭은 ISO/IEC 15504이다.

 

SPICE의 구성

범주	특징
고객-공급자(Customer-Supplier) 프로세스	- 소프트웨어를 개발하여 고객에게 전달하는 것을 지원하고, 소프트웨어의 정확한 운용 및 사용을 위한 프로세스로 구성됨. - 구성 요소 : 인수, 공급, 요구 도출, 운영 - 프로세스 수 : 10개
공학(Engineering) 프로세스	- 시스템과 소프트웨어 제품의 명세화, 구현, 유지보수를 하는데 사용되는 프로세스로 구성됨. - 구성 요소 : 개발, 소프트웨어 유지보수 - 프로세스 수 : 9개
지원(Support) 프로세스	- 소프트웨어 생명 주기에서 다른 프로세스에 의해 이용되는 프로세스로 구성됨. - 구성 요소 : 문서화, 형상, 품질 보증, 검증, 확인, 리뷰, 감사, 품질 문제 해결 - 프로세스 수 : 8개
관리(Management) 프로세스	- 소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성됨. - 구성 요소 : 관리, 프로젝트 관리, 품질 및 위험 관리 - 프로세스 수 : 4개
조직(Organization) 프로세스	- 조직의 업무 목적 수립과 조직의 업무 목표 달성을 위한 프로세스로 구성됨. - 구성 요소 : 조직 배치, 개선 활동 프로세스, 인력 관리, 기반 관리, 측정 도구, 재사용 - 프로세스 수 : 9개

 

SPICE의 프로세스 수행 능력 단계

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

 

 

(29) 소프트웨어 개발 방법론 테일러링

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

• 프로젝트 상황 및 특성에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업
• 수행 절차

 

소프트웨어 개발 방법론 테일러링 고려사항

기준	내용
내부적 기준	- 목표 환경 : 시스템의 개발 환경과 유형이 서로 다른 경우 테일러링이 필요함. - 요구사항 : 프로젝트의 생명 주기 활동에서 개발, 운영, 유지보수 등 프로젝트에서 우선적으로 고려할 요구사항이 서로 다른 경우 테일러링이 필요함. - 프로젝트 규모 : 비용, 인력, 기간 등 프로젝트의 규모가 서로 다른 경우 테일러링이 필요함. - 보유 기술 : 프로세스, 개발 방법론, 산출물, 구성원의 능력 등이 서로 다른 경우 테일러링이 필요함.
외부적 기준	- 법적 제약사항 : 프로젝트별로 적용될 IT Compliance가 서로 다른 경우 테일러링이 필요함. - 표준 품질 기준 : 금융, 제도 등 분야별 표준 품질 기준이 서로 다른 경우 테일러링이 필요함.

 

 

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

소프트웨어 개발 프레임워크

• 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템
• 선행 사업자의 기술에 의존하지 않는 표준화된 개발 기반으로 인해 사업자 종속성이 해소된다.
• 소프트웨어 개발 프레임워크의 주요 기능
  • 예외 처리
  • 트랜잭션 처리
  • 메모리 공유
  • 데이터 소스 관리
  • 서비스 관리
  • 쿼리 서비스
  • 로깅 서비스
  • 사용자 인증 서비스
• 소프트웨어 개발 프레임워크의 종류
  • 스프링 프레임워크
  • 전자정부 프레임워크
  • 닷넷 프레임워크

 

스프링 프레임워크(Springg Framework)

• 스프링 프레임워크는 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크이다.
• 동적인 웹 사이트의 개발을 위해 다양한 서비스를 제공한다.
• 전자정부 표준 프레임워크의 기반 기술로 사용되고 있다.

 

전자정부 프레임워크

• 대한민국의 공공부문 정보화 사업 시 효율적인 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍처를 제공하는 프레임워크이다.
• 개발 프레임워크의 표준 정립으로 응용 소프트웨어의 표준화, 품질 및 재사용성의 향상을 목적으로 한다.
• 오픈 소스 기반의 범용화를 이룰 수 있다.
• 공개된 기술을 활용함으로써 특정 업체의 종속성을 배제하고 사업별 공통 컴포넌트의 중복 개발을 방지한다.

 

닷넷 프레임워크(.NET Framework)

• Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크
• Microsoft 사에서 통합 인터넷 전략을 위해 개발하였다.
• 코드 실행을 관리하는 CLR(Common Language Runtime, 공용 언어 런타임)이라는 이름의 가상머신 상에서 작동한다.

 

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

특성	내용
모듈화 (Modularity)	- 프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소함으로써 소프트웨어의 품질을 향상시킴. - 프레임워크는 개발 표준에 의한 모듈화로 인해 유지 보수가 용이함.
재사용성 (Reusability)	프레임워크는 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능함.
확장성 (Extensibility)	프레임워크는 다형성(Polymorphism)을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능함.
제어의 역흐름 (Inversion of Control)	개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상시킴.