정보처리기사 실기 준비

정보처리기사 : 1장 - 요구사항 확인
정보처리기사 : 2장 - 데이터 입출력 구현
정보처리기사 : 3,4장 - 통합 구현, 서버 프로그램 구현

---

1장 : 요구사항 확인

정보처리기사 책이 도착했다. 실기 준비를 시작하였고 워낙 내용이 방대하고 많기 때문에 단원별 요약하고 중요내용을 체크하려고 한다. 총 12장으로 구성되어있고 그중 1장 요구사항 분석편이다.

• 정보처리 실기 목차

1. 요구사항 확인 - (링크텍스트)
2. 데이터 입출력 구현
3. 통합구현
4. 서버 프로그램 구현
5. 인터페이스 구현
6. 화면 설계
7. 애플리케이션 테스트 관리
8. SQL 응용
9. 소프트웨어 개발 보안 구축
10. 프로그래밍 언어 활용
11. 응용 소프트웨어 기초 기술 활용
12. 제품 소프트웨어 패키징

01. 소프트웨어 생명 주기

• 소프트웨어는 요구사항을 분석해서 설계하고 그에 맞게 개발한 후 소프트웨어의 품질이 항상 최상의 상태를 유지할 수 있도록 관리하는데, 이러한 과정을 단계로 나눈 것을 소프트웨어어 생명 주기라고 한다.
  소프트웨어 : 요구사항 분석 - 설계 - 개발 - 품질관리
  이러한 단계별로 나눈것 소프트웨어 생명주기.

  • 대표적인 생명 주기 모형
    -폭포수 모형
    -프로토타입 모형
    -나선형 모형
    -애자일 모형

폭포수 모형(Waterfall Model)

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

프로토타입 모형(Prototype Model)

• 프로토타입 모형은 사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어의 견본품(prototype)을 만들어 최종 결과물을 예측하는 모형(사용자-시스템 인터페이스를 중심으로 개발)

나선형 모형(Spiral Model)

• 여러번의 개발 과정을 거쳐 점진적으로 최종 소프트웨어를 개발하는 모형
• 보헴(Boehm)이 제안
• 폭포수 모형과 프로토타입 모형의 장점에 위험 분석기능을 추가
• 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객평가 -> 계획수립.....

  계획 - 분석- 개발 - 평가

애자일 모형(Agile Model)

• 애자일은 '민첩한', '기민한'이라는 의미로 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
• 고객과의 소통에 초점을 맞춘 방법론

  • 대표적인 개발 모형
    -스크럼(Scrum) - (Section 02)
    -XP(eXtreme programing) - (Section03)
    -칸판(Kanban)
    -Lean
    -기능 중심 개발(FDD:Feature Driven Development)

소프트웨어 공학

• 소프트웨어 공학(Software Engineering)은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
• 여러가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 둔다.

02. 스크럼(Scrum) 기법

• 스크럼은 팀이 중심이 되어 개발의 효율성을 높이는 기법
• 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고

  스프린트(Sprint) : 실제 개발 작을 진행하는 과정으로 보통 2~4주 정도의 기간 내에서 진행함.

03. XP(eXtreme Programming) 기법

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

  • XP의 핵심가치 5가지
    -의사소통
    -단순성
    -용기
    -존중
    -피드백
    = 피용의단종(종)

• XP의 주요 실천 방법
  -Pair Programming(짝 프로그래밍) : 개발에 대한 책임을 공동 분담
  -Collectrive Ownership(공동 코드 소유) : 개발 코드에 대한 책임 공동 소유
  -Test-Driven Development(테이스 주도 개발) : 코드 작성 전 테스트 케이스를 먼저 작성
  -Whole Team(전체 팀) : 개발에 참여한 모든 구성원이 책임 분담
  -Continuous Integration(계속적인 통합) : 모듈 단위로 나눠서 개발된 코드들을 하나의 작업이 마무리 될때마다 직속적으로 통합
  -Refactoring(리팩토링) : 프로그랭 기능 변경없이 시스템을 재구성 (쉽게 이해, 쉽게 수정, 빠르게 개발하기 위한 목적)
  -Small Releases(소규모 릴리즈) : 릴리즈 기간을 짧게 반복하여 고객 요구변화에 대응

04. 개발 기술 환경 파악

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

운영체제(OS, Operating System)

• 운영체제는 컴퓨터 시스템의 자원을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어
• 컴퓨터 사용자와 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종
• 다른 응용 프로그램이 유용한 작업을 할 수 있도록 환경을 제공

  • 운영체제 관련 요구사항 식별 시 고려사항
    -가용성
    -성능
    -기술 지원
    -주변 기기
    -구축 비용

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

• DBMS는 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해 주는 소프트웨어

  • 데이터베이스 관련 요구사항 식별시 고려사항
    -가용성
    -성능
    -기술 지원
    -상호 호환성
    -구축 비용

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

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

  • 웹 애플리케이션 서버 관련 요구사항 식별 시 고려사항
    -가용성
    -성능
    -기술 지원
    -구축 비용

오픈 소스(Open Source)

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

05. 요구사항 정의

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

  • 요구사항의 유형
    -기능 요구사항
    -비기능 요구사항
    -사용자 요구사항
    -시스템 요구사항
    = 기능 비기능 사시
    = 기능과 비기능 구분하는 문제 출제

06. 요구사항 개발 프로세스

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

  도출 -> 분석 - > 명세 -> 확인
  = 도분명확

요구사항 도출

• 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정
• 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타입, 유스케이스

요구사항 분석 (Section 07, 08)

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

요구사항 명세

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

요구사항 확인

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

요구공학

• 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문

07. 요구사항 분석

• 요구사항 분석은 소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화 하는 활동
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.

구조적 분석 기법

• 구조적 분석 기법은 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
• 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화한다.
• 하향식 방법을 사용하여 시스템을 세분화

  • 주요 구조적 분석 기법 도구
    -자료 흐름도(DFD)
    -자료 사전(DD)
    -소단위 명세서(Mini-Spec.)
    -개체 관계도
    -상태 전이도
    -제어 명세서

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

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

  - 자료 흐름도 기본 기호
  -프로세스(Process) : 버블이라고도 함 -> 원
  -자료 흐름(Data Flow) : 자료의 흐름이나 연관관계 -> 화살표
  -자료 저장소(Data Store) : 자료저장소를 나타냄 -> 윗줄, 밑줄
  -단말(Terminator) : 시스템과 교신하는 외부개체 -> 사각형

자료 사전(DD; Data Dictionary)

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

  • 자료 사전에서 사용되는 표기 기호
    '=' : 자료의 정의
    '+' : 자료의 연결
    '()' : 자료의 생략
    '[]' : 자료의 선택
    '{}' : 자료의 반복
    '''' : 자료의 설명

08. 요구사항 분석 CASE와 HIPO

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

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

  • 대표적인 요구사항 분석용 CASE
    -SADT : 소프트웨어 요구사항 분석, 설계를 위한 도구 (SoftTech사에서 개발한 시스템 정의)
    -SREM, PSL/PSA, TAGS이 있다.

HIPO(Hrerarchy Input Process Output)

• HIPO는 시스템의 분석 및 설계, 또는 문서화에 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한것
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기호, 도표 등을 사용하여 보기 쉽고 이해하기 쉽게 표현

09.UML(Unified Modeling Language)의 개요

• UML은 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• 럼바우 Booch, Jacobson등의 객체지향 방법론의 장점을 통합
• OMG(Object Management Group)에서 표준으로 지정

  • UML의 구성요소
    -사물(Things)
    -관계(Relationships) (Section 10)
    -다이어그램(Diagram) (Section 11)
    =현실세계의 물질적, 개념적인 것은 개체(Entity)이다. 개체를 컴퓨터 내부에 추상적으로 표현한 것을 사물(Things) or 객체(Object)라고 한다. 이들의 관계를 다이어그램으로 표현한다.

사물(Things)

• 사물은 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말한다

  • 사물의 종류
    -구조 사물 : 시스템의 개념적, 물리적 요소를 표현(클래스, 유스케이스, 컴포넌트, 인터페이스, 노드 등)
    -행동 사물
    -그룹 사물
    -주해 사물
    = 구행그주

10. UML - 관계(Relationships)

• 관계는 사물과 사물 사이의 연관성을 표현하는 것이다.

  • 관계의 종류
    -연관 관계
    -집합 관계
    -포함 관계
    -일반화 관계
    -의존 관계
    -실체화 관계

연관(Association) 관계

• 연관 관계는 2개 이상의 사물이 서로 관련되어 있는 관계
• 방향성은 화살표로 표현
• 다중도를 선위에 표현 (ER다이어그램과 비슷한듯?)
• 예 : 선생님 - 학생

집합(Aggregation) 관계

• 집합 관계는 하나의 사물이 다른 사물에 포함되어 있는 관계
• 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)는 서로 독립적
• 방향은 속이 빈 마름모를 연결하여 표현
• 예 : 프린터 -> 컴퓨터

포함(Composition) 관계

• 포함 관계는 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
  Whole과 Part는 독립적이지 않고 생명주기를 함께한다.
  방향은 속이 채워진 마름모를 연결하여 표현
• 예 : 키 -> 문

일반화(Generalization) 관계

• 일반화 관계는 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
• 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)이라고 부름
• 구체적(하위)인 사물에서 일반적(상위)인 사물쪽으로 속이 빈 화살표를 연결한다.
• 예 : 아메리카노, 에스프레소 -> 커피

의존(Dependency) 관계

• 의존 관계는 연관 관계와 같이 사물 사이에 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
• 방향은 영향을 주는 사물(이용자)이 영향을 받느 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현
• 예: 등급 - > 할인율

실체화(Realization) 관계

• 실체화 관계는 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화 할 수 있는 관계
• 사물에서 기능쪽으로 속이 빈 점선 화살표를 연결하여 표현
• 예 : 비행기, 새 -> 날 수 있다.

11. UML - 다이어그램

• 다이어그램은 사물과 관계를 도형으로 표현한 것이다.
• 정적 모델링에서는 주로 구조적 다이어그램을 사용한다.
• 동적 모델링에서는 주로 행위 다이어그램을 사용한다.

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

구조적 다이어그램 : 클객컴배복패

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

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

행위 다이어그램 : 유순커상활상타

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

스테레오 타입(Stereotype)

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

12. 유스케이스 다이어그램

기능 모델링

• 기능모델링은 사용자의 요구사항을 분석하여 개발될 시스템이 갖춰야 할 기능을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 그림으로 표현하는 것이다.
  :사용자가 요구한 기능들이 어떻게 작동하는지를 설명하기 위해 구현될 모습을 그림으로 표현한 것
• 종류 : 유스케이스 다이어그램, 활동 다이어그램
  = 기능 모델링 : 유활

14. 클래스 다이어그램

정적 모델링

• 정적 모델링은 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것이다.
• 정적 모델링은 객체(object)들을 클래스(class)로 추상화하여 표현한다.
• UML을 이용한 정적 모델링의 대표적인 것이 클래스 다이어그램이다.
  = 정적 모델링 : 클

• 클래스 다이어그램의 구성요소
  :클래스(class), 제약조건, 관계(Relationships)

• 기능 모델링 vs 정적 모델링
  -기능 모델링 : 사용자 관점, 요구한 기능들이 어떻게 작동하는지 표현
  -정적 모델링 : 개발자 관점, 필요한 자료들의 논리적인 구조들을 표현

15. 순차 다이어그램

동적 모델링

• 동적 모델링은 시스템의 내부 구성 요소 들의 상태변화 과정과 과정에서 발생하는 상효 작용을 표현한 것이다.
• 오퍼레이션을 통한 상호 작용에 초첨을 둔다.
• 종류 : 순차 다이어그램, 커뮤니케이션 다이어그램, 상태 다이어그램
  = 동적 모델링 : 순커상

• 기능 모델링 : 유활
  :시스템이 제공할 수 있는 기능을 표현하는 방법
• 정적 모델링 : 클
  :시스템 내부 구성 요소들을 표현하는 방법
• 동적 모델링 : 순커상
  :시스템 내부 구성 요소들의 상태 변화를 표현하는 방법

• 순차 다이어그램의 구성요소
  :액터(Actor), 객체(Object), 생명선(Life line), 실행 상자(Active box), 메시지(message), 객체 소멸, 프레임(Frame)

18. 패키지 다이어그램

• 패키지 다이어그램은 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존관계를 표현한 것이다.
• 주요 요소 간의 종속성을 파악하는 데 사용한다.
• 패키지 다이어그램의 구성요소
  :패키지(Package), 객체(Object), 의존 관계(Dependency)

19. 소프트웨어 개발 방법론

• 소프트웨어 개발 방법론은 소프트웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것이다.
• 소프트웨어 개발 방법론의 목적은 소프트웨어의 생산성과 품질 향상이다.

  • 주요 소프트웨어 개발 방법론
    -구조적 방법론
    -정보공학 방법론
    -객체지향 방법론
    -컴포넌트 기반(CBD) 방법론
    -제품 계열 방법론
    -애자일 방법론

20. S/W 공학의 발전적 추세

소프트웨어 재사용

• 소프트웨어 재사용(Software Reuse)은 이미 개발되어 있는 소프트웨어를 다른 소프트웨어 개발이나 유지보수에 사용하는 것
• 소프트웨어 개발의 품질과 생산성을 높인다.
• 합성 중심과 생성 중심 방법이 있다.

소프트웨어 재공학

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

  • 소프트웨어 재공학의 이점
    -품질 향상
    -생산성 증가
    -수명 연장
    -오류 감소

CASE

• CASE(Computer Aided Software Engineering)는 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 수현, 검사 및, 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
• 객체지향 시스템, 구조적 시스템 등 다양한 시스템에서 활용되는 자동화 도구(CASE Tool)이다.
• 소프트웨어 생명 주기의 전체 단계를 연결하고 자동화하는 통합된 도구를 제공한다.

21. 비용 산정 기법 - 하향식

• 소프트웨어 비용 산정 기법은 계산 방식에 따라 하향식과 상향식이 있다.
• 종류 : 전문가 감정 기법, 델파이 기법

22. 비용 산정 기법 - 상향식

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

  • 주요 상향식 비용 산정 기법
    -LOC(원시 코드 라인 수) 기법
    -개발 단계별 인월수 기법
    -수학적 산정 기법

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

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

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

개발 단계별 인월수 기법

• 개발 단계별 인월수 기법(Effort Per Task)dms LOC 기법은 보완하기 위한 방법이다.
• LOC보다 더 정확하다.

23. 수학적 산정 기법

• 수학적 산정 기법은 상향식 비용 산정 기법으로, 경험적 추정 모형, 실험적 추정 모형이라고도 한다.
• 수학정 산정 기법은 개발 비용 산정의 자동화를 목표로 한다.

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

COCOMO 모형

• COCOMO 모형(COnstructive COst MOdel) 모형은 LOC에 의한 비용 산정 기법이다.
• 개발할 소프트웨어의 규모(LOC)를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방적익에 대입하여 비용을 산정한다.
• 비용 산정 결과는 프로젝트를 완성하는데 필요한 노력(Man - Month)으로 나타난다.
• 보헴이 제안하였다.
• 조직형(Organic Mode) : 기관 내부에서 개발된 중소 규모의 소프트웨어
  5만 라인 이하의 소프트웨어를 개발하는 유형
• 반분리형(Semi-Detached Mode) : 조직형과 내장형의 중간형 소프트웨어
  30만 라인 이하의 소프트웨어를 개발
• 내장형(Embedded Mode) : 초대형 규모의 소프트웨어
  30만 라인 이상의 소프트웨어 개발

Putnam 모형

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

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

기능 점수(FP)모형

• 기능점수 모형은 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요일별 가중치를 합산하여 총 기능 점수를 산출하며, 총 기능점수와 영향도를 이용하여 기능점수(FP)를 구한후 이를 이용하여 비용을 산정하는 기법
• 총 기능 점수 : 소프트웨어 개발의 규모, 복잡도, 난이도 등을 하나의 수치로 집약 시킨 것을 의미한다.
• 알브레히트(Alrecht)가 제안하였다.
• COCOMO나 Putnam 모형은 LOC를 중심으로 비용산정하지만 기능 점수 모형은 FP를 이용하여 비용을 산정한다.

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

24. 프로젝트 일정 계획

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

PERT(프로그램 평가 및 검토 기술)

• PERT(Program Evaluation and Review Technique, 프로그램 평가 및 검토 기술)은 프로젝트에 필요한 전체 작업의 상호관계를 표시하는 네트워크이다.

  • 낙관치, 기대치, 비관치로 작업 예측치 계산하기
    작업 예측치 = (비관치+4 x 기대치 + 낙관치) / 6

CPM(임계 경로 기법)

• CPM(Critical Path Method, 임계 경로 기법)은 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요기간을 예측하는데 사용하는 기법이다.

  임계 경로를 구할 수 있어야 한다. 문제에 제시된 그림을 보고 임계경로, 즉 최장 경로를 파악하고 고를 수 있어야한다.

간트 차트(프로젝트 일정표)

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

26. 소프트웨어 개발 표준

• 소프트웨어 개발 표준은 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준을 의미한다.

  • 주요 소프트웨어 개발 표준
    -ISO/IEC 12207
    -CMMI(능력 성숙도 통합 모델)
    -SPICE(소프트웨어 처리 개선 및 능력 평가 기준)

ISO/IEC 12207

• ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스이다.
• 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공한다.

CMMI

CMMI(Capability Maturity Model Integration, 능력 성숙도 통합 모델)는 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델이다.

• CMMI의 소프트웨어 프로세스 성숙도
  -초기, 관리, 정의, 정량적 관리, 최적화

SPICE

• SPICE(Software Process Improvement and Capability dEtermination, 소프트웨어 처리 개선 및 능력 평가 기준)는 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준이다.
• 공식 명칭은 ISO/IEC 15504이다.
• SPICE의 프로세스 수행 능력 단계
  불완전 - 수행 - 관리 - 확립 - 예측 - 최적회

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

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

  • 내부적 기준 vs 외부적 기준
    -내부적 기준 : 목표 환경, 요구사항, 프로젝트 규모, 보유 기술
    -외부적 기준 : 법적 제약사향, 표준 품질 기준

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

• 소프트웨어 개발 프레임워크(Framework)는 소프트웨어 개발에 공통적으로 사용되는 구성요소와 아키텍쳐를 일반화하여 손쉽게 구현 할 수 있도록 여러가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템이다
• 선행 사업자의 기술에 의존하지 않는 표준화된 개발 기반으로 인해 사업자 종속성이 해소된다.

  = 특정 기능을 수행하기 위해 필요한 클래스나 인터페이스 등을 모아둔 집합체

소프트웨어 개발 프레임워크의 종류

• 스프링 프레임워크(Spring Framework)
  :자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크
• 전자정부 스페임워크
  :대한민국의 공공부문 정보화 사업시 효율적인 정보시스템 구출을 지원하는 프레임워크
• 닷넷 프레임워크(.NET Framework)
  :Window 프로그램의 개발 및 실행 환경을 제공하는 프레임워크

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

• 모듈화
• 재사용성
• 확장성
• 제어의 역흐름

= 제모의 재확산