정보처리기사 실기 (1) 요구사항 확인

소프트웨어 생명 주기

• 소프트웨어를 개발하기 위한 과정
• 소프트웨어 생명 주기 모형 : 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형
• 폭포수 모형
  - 폭포처럼 이전으로 돌아갈 수 없음을 의미하며, 각 단계를 확실히 끝내고 다음 단계를 진행하는 모형
  • 가장 오래되고 폭넓게 사용된 소프트웨어 생명 주기 모형
• 프로토타입 모형
  - 실제 개발될 소프트웨어의 시제품(프로토타입)을 만들어 최종 결과물을 예측하는 모형
• 나선형 모형
  - 나선을 돌듯이 여러 번의 과정을 돌며 개발을 완료해가는 모형
  • 폭포수 모형과 프로토타입 모형의 장점을 합침
• 애자일 모형
  - 요구사항에 유연하게 대처 가능한 모형으로, 일정 주기를 반복하면서 개발하는 모형
  • 애자일 모형 : 스크럼, XP, 칸반, Lean 등
• 소프트웨어 공학 : 소프트웨어의 품질과 생산성 향상을 위해 연구된 학문
  
  

스크럼

• 팀이 중심이 되어 개발의 효율성을 높이는 기법
• 팀 구성
  • 제품 책임자 : 요구사항이 담긴 백로그를 작성하고, 전체적으로 제품에 대해 이해도가 높고 책임질 수 있거나 결정할 위치에 있는 사람이 담당
  • 스크럼 마스터 : 팀이 잘 수행될 수 있게 가이드 역할을 담당
  • 개발팀 : 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
• 개발 프로세스 : 스프린트 계획 회의 → 스프린트 → 일일 스크럼 회의 → 스프린트 검토 회의 → 스프린트 회고
• 제품 백로그 : 제품 개발에 필요한 모든 요구사항을 우선 순위에 따라 나열한 목록
  
  

XP(eXtreme Programming)

• 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법론
• XP의 핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백
• 개발 프로세스
• XP의 주요 실천 방법 : 짝 프로그래밍, 공동 코드 소유, 테스트 주도 개발, 전체 팀, 계속적인 통합, 리팩토링, 소규모 릴리즈
  
  

개발 기술 환경 파악

• 개발하고자 하는 환경, 운영체제 등을 선정할 때 고려해야 할 사항
• 운영체제
  - 컴퓨터 시스템의 자원을 관리하고, 편리하며 효율적으로 사용할 수 있게 도와주는 소프트웨어
• DBMS
  - 데이터베이스 관리 시스템
  • 사용자와 데이터베이스 사이에서 사용자의 요구를 들어주고 데이터베이스를 관리하는 소프트웨어
• WAS
  - 웹 애플리케이션 서버
  • 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어로, 주로 데이터베이스 서버와 연동해서 사용
• 오픈소스
  - 누구나 제한없이 사용할 수 있도록 공개되어 있는 소스코드 및 소프트웨어
  - 오픈소스 사용 시, 라이선스를 고려해야 함
  
  

요구사항 정의

• 요구사항 : 소프트웨어가 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 운영에 필요한 조건
• 개발 과정에서 필요한 기준과 근거를 제시
• 요구사항의 유형
  - 기능 요구사항 : 기능이나 수행에 관련된 요구사항
  - 비기능 요구사항 : 품질이나 제약사항과 관련된 요구사항
  - 사용자 요구사항 : 사용자 관점에서 시스템이 제공해야 할 요구사항
  - 시스템 요구사항 : 개발자 관점에서 시스템이 제공해야 할 요구사항
  
  

요구사항 개발 프로세스

• 개발 대상에 대한 요구사항을 위한 일련의 과정
• 타당성 조사 → 도출 → 분석 → 명세 → 확인
• 요구사항 도출
  - 시스템 개발에 필요한 요구사항을 어떻게 할지 등에 대해 이야기하고 관계가 이루어지는 단계
  • 요구사항을 도출하기 위해서 다음과 같은 기법을 사용
    • 인터뷰, 설문, 워크샵
    • 브레인 스토밍 : 3인 이상이 자유롭게 의견을 나누는 방법
    • 프로토타이핑 : 설명을 위해 단순하게 순서나 형태를 그려서 설명
    • 유스케이스 : 사용자의 요구사항을 기능 단위로 표현
• 요구사항 분석
  - 도출한 요구사항 중에 모호하거나 이해되지 않는 부분을 수정, 삭제하는 과정
• 요구사항 명세
  - 분석된 요구사항으로 모델을 작성하고 문서를 작성
• 요구사항 확인(검증)
  • 명세된 요구사항이 제대로 작성되었는지를 검토
  • 이해 관계자들이 실제 개발을 요구사항에 할당하기 전에 시작

요구사항 분석

• 개발하고자 하는 대상에 필요한 사용자의 요구사항을 이해하고 문서화하는 활동
• 위 과정을 위해 구조적 분석 기법을 사용
• 구조적 분석 기법 : 자료의 흐름과 처리를 중심으로 요구사항을 분석
  • 구조적 분석 기법을 위해 다음과 같은 도구를 사용
    • 자료 흐름도 : 자료의 흐름 및 과정을 도형으로 기술하는 방법.
      버블 차트라고도 함
    • 자료 사전 : 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록함.
      데이터의 데이터, 메타 데이터라고 불림
    • 소단위 명세서, 개체 관계도, 상태 전이도 등

요구사항 분석 CASE, HIPO

• 요구사항 분석 CASE : 요구사항을 자동으로 분석하고 분석 명세서를 기술하도록 개발된 도구
• 분석 CASE의 종류
  • SADT : SoftTech사에서 개발한 구조적 요구 분석을 위해 블록 다이어그램을 채택한 자동화 도구
  • SREM = RSL/REVS : TRW사에서 개발한 자동화 도구
  • PSL/PSA : 미시간 대학에서 개발
  • TAGS : 시스템 공학 방법 응용에 대한 자동접근 방법
• HIPO
  - 시스템의 입력, 처리, 출력의 기능을 표현한 것
  • 기호, 도표를 사용하여 하향식 소프트웨어 개발을 문서화하는 도구
  • HIPO Chart의 종류 : 가시적 도표, 총체적 도표, 세부적 도표

UML(Undefined Modeling Language)

• 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 객체지향 모델링 언어
• 객체지향 방법론의 장점을 통합하였으며, OMG(Object Management Group)에서 표준으로 지정
• 구성 요소 : 사물, 관계, 다이어그램

1. 사물

• 모델을 구성하는 가장 중요한 기본 요소
• 다이어그램 안에서 관계가 형성될 수 있는 대상

1. 구조 사물
   • 시스템의 개념적, 물리적 요소 표현
   • 클래스, 유스케이스, 컴포넌트, 노드 등
2. 행동 사물
   • 시간과 공간에 따른 요소들의 행위 표현
   • 상호작용, 상태 머신 등
3. 그룹 사물
   • 요소들의 그룹으로 묶어서 표현
   • 패키지
4. 주해 사물
   • 부가적인 설명이나 제약조건 등 표현
   • 노트

2. 관계

• 사물과 사물 사이의 연관성 표현

1. 연관 관계
   • 2개 이상의 사물이 서로 관련되어 있음을 표현
   • 실선과 화살표로 연결하여 표현하지만, 양방향 관계의 경우 화살표 없이 실선으로 연결하여 표현

2. 집합 관계

   • 하나의 사물이 다른 사물에 포함되어 있는 관계
   • 부분(포함되는 쪽)에서 전체(포함하는 쪽)로 속이 빈 마름모를 연결하여 표현

   

3. 포함 관계

   • 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
   • 부분(포함되는 쪽)에서 전체(포함하는 쪽)로 속이 채워진 마름모를 연결하여 표현

   

4. 의존 관계

   • 사물 사이에 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
   • 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표 연결

   

5. 일반화 관계

   • 하나의 사물이 다른 사물에 비해 일반적인지 구체적인지 표현
   • 구체적인 사물에서 일반적인 사물 쪽으로 속이 빈 화살표를 연결

   

6. 실체화 관계

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

   

UML - 다이어그램

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

• 정적 모델링에서는 주로 구조적 다이어그램을 사용하고, 동적 모델링에서는 주로 행위 다이어그램을 사용

• 구조적 다이어그램

  • 클래스 다이어그램 : 클래스, 클래스가 가지는 속성, 클래스 사이의 관계 표현
  • 객체 다이어그램 : 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
  • 컴포넌트 다이어그램 : 구현 단계에서 사용되며 컴포넌트 간의 관계나 인터페이스를 표현
  • 패치 다이어그램 : 구현 단계에서 사용되며 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치 표현
  • 복합체 구조 다이어그램 : 복잡한 구조를 가지는 클래스 혹은 컴포넌트의 내부 구조 표현
  • 패키지 다이어그램 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계 표현

• 행위 다이어그램

  • 유스케이스 다이어그램 : 사용자의 요구를 분석하여 기능 모델링 작업에 사용됨
  • 시퀀스 다이어그램 : 상호 작용하는 시스템이나 객체들이 주고 받는 메시지 표현
  • 커뮤니케이션 다이어그램 : 객체들이 주고받는 메시지를 표현할 뿐만 아니라 객체들 간의 연관까지 표현
  • 상태 다이어그램 : 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 어떻게 변화하는지 표현
  • 활동 다이어그램 : 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
  • 상호작용 개요 다이어그램 : 상호작용 다이어그램 간의 제어 흐름 표현
  • 타이밍 다이어그램 : 객체 상태 변화와 시간 제약을 명시적으로 표현

모델링

• 기능 모델링
  - 개발될 시스템이 갖춰야 할 기능을 정리하여 사용자에게 공유하기 위해 그림으로 표현한 것

  • 유스케이스 다이어그램, 활동 다이어그램

• 정적 모델링
  - 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것

  • 객체들 사이에 어떤 관련이 있는지 구조적인 관점에서 표현
  • 클래스 다이어그램

• 동적 모델링
  - 시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것

  • 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 상태 다이어그램

유스케이스 다이어그램

• 사용자 측면에서 요구사항으로 사용자가 원하는 목표를 위해 수행할 기능을 정리한 그림
  

활동 다이어그램

• 사용자의 측면에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
  

클래스 다이어그램

• 클래스, 클래스가 가지는 속성, 클래스 사이의 관계 표현
  

시퀀스 다이어그램

• 시스템이나 객체들이 메시지를 주고 받으며 상호작용하는 과정을 표현
  

패키지 다이어그램

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

소프트웨어 개발 방법론

소프트웨어 개발 방법론의 개요

• 소프트웨어 개발, 유지보수에 필요한 수행 방법과 효율적으로 수행하려는 과정에서 필요한 기법 및 도구를 정리하여 표준화

구조적 방법론

• 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론
• Divide and Conquer 원리 적용
  

정보공학 방법론

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

객체지향 방법론

• 기계의 부품을 조립하듯이 객체들을 조립하여 소프트웨어를 구현하는 방법론
• 구조적 기법의 해결책으로 채택
  

컴포넌트 기반(CBD) 방법론

• 컴포넌트를 조합하여 새로운 애플리케이션을 만드는 방법론
• 컴포넌트의 재사용이 가능하여 시간, 노력, 비용을 절감하고 품질을 높임
  

제품 계열 방법론

• 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
• 임베디드 소프트웨어 개발에 적합
  
  

소프트웨어 공학의 발전적 추세

소프트웨어 재사용

• 이미 개발되어 안정되어 있는 소프트웨어를 재사용하는 것
• 합성 중심(블록 구성 방법)
• 생성 중심(패턴 구성 방법)

소프트웨어 재공학

• 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어의 성능을 향상
• 소프트웨어 재공학의 장점 : 품질 향상, 생산성 증가, 수명 연장, 오류 감소

CASE(Computer Aided Software Engineering)

• 소프트웨어 개발 과정을 컴퓨터나 소프트웨어로 자동화하는 것
• CASE의 주요 기능
  • 소프트웨어 생명 주기 전 단계의 연결
  • 다양한 소프트웨어 개발 모형 지원
  • 그래픽 지원

비용 산정 기법

소프트웨어 비용 산정의 개요

• 소프트웨어의 개발 규모를 소요되는 인원, 자원, 기간 등으로 확인하여 실행 가능한 계획을 수립하기 위해 필요한 비용을 산정하는 것

소프트웨어 비용 결정 요소

• 프로젝트 요소 : 제품 복잡도, 시스템 크기, 요구되는 신뢰도
• 자원 요소 : 인적 자원, 하드웨어 자원, 소프트웨어 자원
• 생산성 요소 : 개발자 능력, 개발 기간

하향식 산정 기법

• 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정
• 전문가 감정 기법
  - 조직 내 경험이 많은 2명 이상의 전문가에게 비용 산정을 의뢰
  • 진행했던 유사한 프로젝트와 진행할 새로운 프로젝트 간에 새로운 요소가 있을 수 있고 경험이 없을 수 있음

상향식 산정 기법

• 프로젝트의 세부적인 작업 단위별로 비용을 산정 후 집계하여 전체 비용을 산정
• LOC(source Line Of Code) 기법
  - 소프트웨어의 각 기능의 원시 코드 라인 수로 예측치를 구하고 비용을 산정하는 기법
  • 노력(인월) = 개발 기간 x 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수
  • 개발 비용 = 노력(인월) x 단위 비용(1인당 월평균 인건비)
  • 개발 기간 = 노력(인월) / 투입 인원
  • 생산성 = LOC / 노력(인월)
• 개발 단계별 인월수 기법
  - 각 기능을 구현시키는데 필요한 노력을 생명 주기의 각 단계별로 산정
  

수학적 산정 기법

수학적 산정 기법의 개요

• 상향식 선정 기법
• 개발 비용 산정의 자동화를 목표로 함
• 경험적 / 실험적 추정 모형이라고도 함
• 과거 유사한 프로젝트를 기반으로 공식을 유도

COCOMO 모형

• 보헴이 제안하였으며 LOC에 의한 비용 산정 기법

• 개발 유형 : 소프트웨어의 복잡도 또는 원시 프로그램의 규모에 따라 분류

  • 조직형(Organic Mode) : 기관 내부에서 개발된 중∙소규모의 소프트웨어로 5만 라인 이하의 소프트웨어를 개발하는 유형
  • 반분리형(Semi-Detached Mode) : 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등 30만 라인 이하의 소프트웨어를 개발하는 유형
  • 내장형(Embedded Mode) : 최대형 규모의 트랜잭션 처리 시스템이나 운영체제 등 30만 라인 이상의 소프트웨어를 개발하는 유형

• 모형의 종류 : 비용 산정 단계 및 적용 변수의 구체화 정도로 구분

  • 기본형(Basic) : 소프트웨어의 크기와 개발 유형만을 이용하여 비용을 산정
  • 중간형(Intermediate) : 기본형을 공식을 사용하거나 4가지 특성의 15가지 요인에 의해 비용을 산정
    • 제품의 특성 : 요구되는 신뢰도, 데이터베이스 크기, 제품의 복잡도
    • 컴퓨터의 특성 : 수행 시간의 제한, 기억 장소의 제한, 가상 기계의 안정성, 반환 시간
    • 개발 요원의 특성 : 분석가의 능력, 개발 분야의 경험, 가상 기계의 경험, 프로그래머의 능력, 프로그래밍 언어의 경험
    • 프로젝트 특성 : 소프트웨어 도구의 이용, 프로젝트 개발 일정, 최신 프로그래밍 기법의 이용
  • 발전형(Detailed) : 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정

Putnam 모형

• 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 가정해주는 모형
• 생명 주기 예측 모형이라고도 함
• 시간에 따라 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
• 대형 프로젝트 노력 분포 산정에 이용
• SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 측정 도구

기능 점수(FP) 모형

• 소프트웨어 기능을 증대시키는 요인별로 가중치를 부여하고 합산하여 총 기능 점수를 산출하며, 총 기능 점수와 영향도를 이용하여 기능 점수를 구한 후 이를 이용해서 비용을 산정
• 알브레히트가 제안
  
  

프로젝트 일정 계획

프로젝트 일정 계획

• 프로젝트의 소작업을 파악하여 순서와 일정을 정하는 것
• PERT : 프로젝트에 필요한 전체 작업의 상호 작용을 표시하는 네트워크
• CPM : 완성에 필요한 작업을 나열하고, 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
  • 임계 경로 : 최장 경로 (가장 오래 걸리는 경로)
• 간트차트 : 작업 일정을 막대 도표를 사용하여 표시하는 기법

소프트웨어 개발 표준

소프트웨어 개발 표준의 개요

• 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준

ISO/IEC 12207

• ISO에서 만든 표준 소프트웨어 생명 주기 프로세스
• 소프트웨어의 개발, 운영, 유지보수를 관리하기 위한 생명 주기 표준을 제공
• 기본 / 생명 / 조직의 생명 주기 프로세스로 구분

CMMI(Capability Maturity Model Integration, 능력 성숙도 통합 모델)

• 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가
• 성숙도는 초기, 관리, 정의, 정량적 관리, 최적화로 구분

SPICE(Software Process Improvement and Capability dEtermination, 소프트웨어 처리 개선 및 능력 평가 기준)

• 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
• ISO/IEC 15504
  
  
• 목적
  - 프로세스 개선을 위해 개발 기관이 스스로 평가
  - 기관에서 지정한 요구조건의 만족 여부를 개발 조직이 스스로 평가
  - 계약 체결을 위해 수탁 기관의 프로세스를 평가
  
  
• 프로세스
  - 고객 - 공급자 프로세스 : 소프트웨어를 개발하여 고객에게 전달하는 것을 지원하며, 소프트웨어의 정확한 운용 및 사용을 위한 프로세스로 구성
  - 공학 프로세스 : 시스템과 소프트웨어 제품의 명세화, 구현, 유지보수를 하는데 필요한 프로세스로 구성
  - 지원 프로세스 : 소프트웨어 생명 주기에서 다른 프로세스에 의해 이용되는 프로세스로 구성
  - 관리 프로세스 : 소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성
  - 조직 프로세스 : 조직의 업무 목적 수립과 조직의 업무 목표 달성을 위한 프로세스로 구성
  
  
• 프로세스 수행 능력 단계
  • 불완전 : 구현되지 않거나 목적을 달성하지 못함
  • 수행 : 수행되고 목적이 달성됨
  • 관리 : 정의된 자원 한도 내에서 작업 산출물을 인도
  • 확립 : 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행
  • 예측 : 목적 달성을 위해 통제되고 양적인 측정을 통해 일관되게 수행
  • 최적화 : 수행을 최적화하고 지속적인 개선을 통해 업무 목적을 만족시킴

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

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

• 소프트웨어 개발에 공통적으로 사용하는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러 가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템
• 스프링 프레임워크 : 자바 플랫폼과 동적인 웹 사이트의 개발을 위한 프레임워크
• 전자정부 프레임워크 : 우리나라의 공공부문 정보화 사업 시 효율적인 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍처를 제공
• 닷넷 프레임워크 : Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크로, Microsoft에서 통합 인터넷 전략을 위해 개발됨