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

나선형 모형

• 여러번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형.
• 보헴이 제안.
• 4가지 주요 활동
  • 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가 -> 다시 계획 수립으로

폭포수 모형

• 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론.
• 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형.
• 고전적 생명 주기 모형.

애자일 모형

• 애자일(Agile)은 '민첩한', '기민한'이라는 의미.
• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형.
• 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춤.
• 대표적인 개발 모형
  • 스크럼
  • XP
  • 칸반
  • Lean
  • 기능 중심 개발

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

• 개인과 상호작용에 더 가치를 둔다.
• 실행되는 SW에 더 가치를 둔다.
• 고객과 협업에 더 가치를 둔다.
• 변화에 반응하는 것에 더 가치를 둔다.

XP

• 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법.
• XP의 5가지 핵심가치
  • 의사소통
  • 단순성
  • 용기
  • 존중
  • 피드백

XP의 주요 실천 방법

• Pair Programming(짝 프로그래밍)

  • 다른 사람과 함께 프로그래밍 수행.
  • 개발 책임을 공동으로 나눠 갖는 환경 조성.

• Collective Ownership(공동 코드 소유)

  • 개발 코드에 대한 권한과 책임을 공동으로 소유한다.

• Test-Driven Development(테스트 주도 개발)

  • 실제 코드를 작성하기 전, 테스트 케이스를 먼저 작성하므로 무엇을 해야할지 정확히 파악한다.
  • 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구(구조, 프레임워크)를 사용.

• Whole Team(전체 팀)

  • 모든 구성원(고객 포함)들은 각자 자신의 역할이 있고 그 역할에 대한 책음을 가져야 한다.

• Continuous Intergration(계속적인 통합)

  • 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합된다.

• Refactoring(리팩토링)

  • 프로그램 기능의 변경 없이 시스템을 재구성한다.
  • 목적: 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함.

• Small Releases(소규모 릴리즈)

  • 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있다.

기능 요구사항

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

비기능 요구사항

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

자료 흐름도의 구성 요소

기호	의미
프로세스(Process)	자료를 변환시기키는 시스템의 한 부분.
자료 흐름(Data Flow)	자료의 이동이나 연관관계를 나타냄.
자료 저장소(Data Store)	시스템에서의 자료 저장소를 나타냄.
단말(Terminator)	시스템과 교신하는 외부 개체. 입력 데이터가 만들어지고 출력 데이터를 받음.

HIPO(Hierarchy Input Process Output)

• 시스템의 실행 과정인 입력, 처리, 출력의 기능을 표현한 것.
• 하향식 소프트웨어 개발을 위한 문서화 도구.
• 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 한다.

연관 관계(Association)

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

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

집합 관계(Aggregation)

• 하나의 사물이 다른 사물에 포함되어 있는 관계
• 포함하는 쪽과 포함되는 쪽은 서로 독립적이다.
• 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마를모를 연결하여 표현한다.

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

일반화 관계(Generalization)

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

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

의존 관계(Dependency)

• 사물 사이에 연관은 있으나 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계.
• 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계.
• 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계.
• 영향을 받는 사물(이용자)이 영향을 주는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현한다.

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

구조적 다이어그램의 종류

• 클래스 다이어그램(Class Diagram)

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

• 객체 다이어그램(Object Diagram)

  • 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현한다.
  • 럼바우(Rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용된다.

• 컴포넌트 다이어그램(Component Diagram)

  • 실체 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현한다.
  • 구현 단계에서 사용된다.

• 배치 다이어그램(Deployment Diagram)

  • 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현한다.
  • 구현 단계에서 사용된다.

• 복합체 구조 다이어그램(Composite Structure Diagram)

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

• 패키지 다이어그램(Package Diagram)

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

행위 다이어그램의 종류

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

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

• 순차 다이어그램(Sequence Diagram)

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

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

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

• 상태 다이어그램(State Diagram)

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

• 활동 다이어그램(Activity Diagram)

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

• 상호작용 개요 다이어그램(Intraction Orverview Diagram)

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

• 타이밍 다이어그램(Timing Diagram)

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

컴포넌트 기반 방법론

• 새로운 애플리케이션을 만드는 방법론.
• 컴포넌트 기반 방법론의 절차
  • 개발 준비 단계 -> 분석 단계 -> 설계 단계 -> 구현 단계 -> 테스트 단계 -> 전개 단계 -> 인도 단계

CASE

• 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것이다.
• CASE의 주요 기능
  • 소프트웨어 생명 주기 전 단계의 연결.
  • 다양한 소프트웨어 개발 모형 지원.
  • 그래픽 지원.

LOC 기법

• 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법.
• 산정 공식
  • 노력(인월) = 개발 기간 * 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수
  • 개발 비용 = 노력(인월) * 단위 비용(1인당 월평균 인건비)
  • 개발 기간 = 노력(인월) / 투입 인원
  • 생산성 = LOC / 노력(인월)

수학적 산정 기법

• 주요 수학적 산정 기법
  • COCOMO 모형
  • Putnam 모형
  • 기능 점수(FP) 모형

COCOMO 모형

• LOC에 의한 비용 산정 기법.
• 보헴(Boehm)이 제안.

COCOMO의 소프트웨어 개발 유형

• 조직형(Organic Mode)
  • 기관 내부에서 개발된 중/소 규모의 소프트웨어.
  • 5만 라인 이히의 소프트웨어를 개발.
  • 사무 처리, 업무, 과학, 응용 소프트웨어 개발에 적합.
• 반분리형(Semi-Detached Mode)
  • 조직형과 내장형의 중간 소프트웨어.
  • 30만 라인 이하의 소프트웨어를 개발.
  • 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합.
• 내장형(Embedded Mode)
  • 초대형 규모의 소프트웨어.
  • 30만 라인 이상의 소프트웨어를 개발.
  • 신호 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합.

Putnam 모형

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

CPM

• 작업을 나열하고 작업에 필요한 기간을 예측하는데 사용하는 기법.

CMMI

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

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

SPICE

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

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

• 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템이다.

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

• 모듈화(Modularity)
  • 프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 소프트웨어의 품질을 향상시킨다.
  • 프레임워크는 개발 표준에 의한 모듈화로 인해 유지보수가 용이하다.

재사용성(Reusability)

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

확장성(Extensibility)

• 프레임워크는 다형성(Polymorphism)을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능하다.

제어의 역흐름(Inversion of Control)

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