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

2021 시나공 정보처리기사 실기책 참고

주의! 중요도가 낮은 항목(C, D)은 일부 제외

1. 소프트웨어 생명 주기 – A

- Software Life Cycle

• S/W를 개발하기 위한 과정을 각 단계별로 나눈 것
• 폭포수, 프로토타입, 나선형, 애자일

- 폭포수 모형(Waterfall Model)

• 각 단계를 확실히 매듭짓고 결과를 검토하여 승인 과정을 거친 후 다음 단계 진행
• 가장 오래되고 가장 폭넓게 사용된 전통적인 S/W 생명 주기 모형
• 고전적 생명 주기 모형
• 모형을 적용한 경험과 성공 사례 많음
• 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함

- 프로토타입 모형(Prototype Model)

• 실제 개발될 S/W에 대한 견본품을 만들어 최종 결과물을 예측
• 사용자와 시스템 사이의 인터페이스에 중점

- 나선형 모형(Spiral Model)

• 여러 번의 S/W 개발 과정을 거쳐 점진적으로 개발
• 보헴이 제안
• 폭포수, 프로토타입 + 위험 분석 기능
• 누락되거나 추가된 요구사항 첨가 가능
• 유지보수 과정 필요 없음
• 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가

- 애자일 모형(Agile Model)

• 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하며 개발
• 고객과의 소통에 초점
• 기업 활동 전반에 걸쳐 사용됨
• Scrum, XP, Kanban, Lean, FDD
• 개인과 상호작용에 더 가치를 둠
• 실행되는 S/W에 더 가치를 둠
• 고객과 협업에 더 가치를 둠
• 변화에 반응하는 것에 더 가치를 둠

- 소프트웨어 공학(Software Engineering)

• S/W의 위기를 극복하기 위한 방안으로 연구된 학문
• S/W의 품질과 생산성 향상이 목적
• 현대적인 프로그래밍 기술을 계속적으로 적용
• 품질이 유지되도록 지속적으로 검증
• 명확한 기록 유지

2. 스크럼(Scrum) 기법 – B

• 팀이 중심이 되어 개발의 효율성을 높이는 기법
• 팀원 스스로가 팀을 구성, 개발에 대한 모든 것 스스로 해결
• 제품 책임자(PO; Product Owner)
  • 요구사항이 담긴 백로그 작성
  • 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람
• 스크럼 마스터(SM; Scrum Master)
  • 스크럼을 잘 수행할 수 있도록 가이드 역할
• 개발팀(DT; Development Team)
  • PO, SM을 제외한 모든 팀원
  • 개발 수행
• 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고

3. XP(eXtreme Programming) 기법 – A

• 요구사항에 유연하게 대응하기 위함
• 고객의 참여와 개발 과정의 반복을 극대화해 생산성 향상
• S/W를 빠르게 개발하는 것이 목적
• 릴리즈 기간을 짧게 반복하면서 요구사항 반영에 대한 가시성을 높임
• 의사소통, 단순성, 용기, 존중, 피드백
• 릴리즈 계획 수립 -> 이터레이션 -> 승인검사 -> 소규모 릴리즈
• Pair Programming
  • 다른 사람과 함께 프로그래밍을 수행하여 책임을 공동으로 나눠 갖음
• Collective Ownership
  • 코드에 대한 권한과 책임을 공동으로 소요
• Test-Driven Development
  • 코드를 작성하기 전에 테스트 케이스를 먼저 작성
  • 자동화된 테스팅 도구 사용
• Whole Team
  • 모든 구성원들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가짐
• Continuous Integration
  • 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리 될 때마다 지속적 통합
• Refactoring
  • 프로그램 기능의 변경 없이 시스템 재구성
  • 프로그램을 쉽게 이해하고 수정하여 빠르게 개발하기 위함
• Small Releases
  • 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응

4. 개발 기술 환경 파악 – B

• 운영체제(OS; Operating System)
  • 컴퓨터 시스템의 자원을 효율적으로 관리
  • 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공
  • 사용자와 하드웨어 간의 인터페이스
  • 프로그램이 유용한 작업을 할 수 있도록 환경 제공
  • 가용성, 성능, 기술지원, 주변 기기, 구축 비용
• 데이터베이스 관리 시스템(DBMS; DataBase Management System)
  • 사용자와 DB 사이에서 정보를 생성, DB 관리
  • 데이터의 종속성과 중복성의 문제를 해결
  • DB를 공용할 수 있도록 관리
  • 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용
• 웹 애플리케이션 서버(WAS; Web Application Server)
  • 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
  • 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공
  • DB 서버와 연동해서 사용
  • 가용성, 성능, 기술 지원, 구축 비용
• 오픈 소스(Open Source)
  • 제한 없이 사용할 수 있도록 소스 코드를 공개한 S/W
  • 라이선스의 종류, 사용자 수, 기술의 지속 가능성

5. 요구사항 정의 – B

• S/W가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명
• 정상적으로 운영되는데 필요한 제약 조건
• 기능 요구사항
  • 기능이나 수행과 관련된 요구사항
  • 입력이나 출력으로 무엇이 포함되어야 하는지
  • 어떤 데이터를 저장하거나 연산을 수행해야 하는지
  • 시스템이 반드시 수행해야 하는 기능
  • 사용자가 시스템을 통해 제공받기를 원하는 기능
• 비기능 요구사항
  • 품질이나 제약사항과 관련된 요구사항
  • 시스템 장비, 성능, 인터페이스, 테스트, 보안, 품질, 제약사항
• 사용자 요구사항
  • 사용자 관점에서 본 시스템이 제공해야 할 요구사항
  • 친숙한 표현으로 이해하기 쉽게 작성
• 시스템 요구사항
  • 개발자 관점에서 본 시스템 전체가 제공해야 할 요구사항
  • 전문적이고 기술적인 용어로 표현
  • 소프트웨어 요구사항

6. 요구사항 개발 프로세스 – B

• 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 활동
• 타당성 조사가 선행되어야 함
• 요구공학의 한 요소
• 도출(Elicitation) -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)
• 도(출) -> 분(석) -> (명)세 -> (확)인

- 요구사항 도출

• 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 식별하고 이해하는 과정
• SDLC 동안 지속적으로 반복
• 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스

- 요구사항 분석

• 요구사항 중 이해되지 않는 부분을 발견하고 걸러내기 위한 과정
• 타당성을 조사하고 비용과 일정에 대한 제약을 설정
• 상충되는 요구사항이 있으면 이를 중재
• 자료 흐름도, 자료 사전

- 요구사항 명세

• 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것
• 기능 요구사항을 빠짐없이 기술
• 비기능 요구사항은 필요한 것만 기술
• 소단위 명세서가 사용될 수 있음

- 요구사항 확인

• 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동
• 이해관계자들이 검토해야 함
• 요구사항 정의 문서들에 대해 형상 관리를 수행

- 요구공학

• 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문
• SW 프로젝트 실패를 최소화하는 것을 목표로 함

- 요구사항 명세 기법

• 정형 명세 기법

  • 수학적 원리 기반, 모델 기반
  • 수학적 기호, 정형화된 표기법
  • 요구사항을 정확하고 간결하게 표현할 수 있음
  • 일관성이 있어 완전성 검증이 가능
  • 표기법이 어려워 사용자가 이해하기 어려움
  • VDM, Z, Petri-net, CSP 등

• 비정형 명세 기법

  • 상태/기능/객체 중심
  • 자연어를 기반으로 서술 또는 다이어그램으로 작성
  • 일관성이 떨어지고, 해석이 달라질 수 이씅ㅁ
  • 내용의 이해가 쉬워 의사소통이 용이
  • FSM, Decision Table, ER모델링, State Chart 등

7. 요구사항 분석 – A

• 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동
• 타당성을 조사하고 비용과 일정에 대한 제약을 설정
• 사용자의 요구를 정확하게 추출하여 목표를 정함

- 구조적 분석 기법

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

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

• 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
• 자료 흐름 그래프, 버블차트라고도 함
• 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용
• 자료 흐름도 기본 기호
  • 프로세스(Process)
    • Yourdon/DeMacro에서 원으로 표기
    • 자료를 변환시키는 시스템의 한 부분을 나타냄
  • 자료 흐름(Data Flow)
    • 화살표로 표기
    • 자료의 이동이나 연관관계를 나타냄
  • 자료 저장소(Data Store)
    • Yourdon/DeMacro에서 직선(단선 / 이중선)으로 표기
    • 시스템에서의 자료 저장소를 나타냄
  • 단말(Terminal)
    • Yourdon/DeMacro에서 사각형으로 표기
    • 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음

- 자료 사전(DD; Data Dictionary)

• 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
• 데이터를 설명하는 데이터로, 메타 데이터라고도 함
• 자료 사전에서 사용되는 표기 기호
  • = : 자료의 정의(~로 구성되어 있다; is composed of)
  • + : 자료의 연결(그리고; and)
  • ( ) : 자료의 생략(생략 가능한 자료; Optional)
  • : 자료의 선택(또는; or)
  • { } : 자료의 반복(Iteration of)
  • * * : 자료의 설명(주석; Comment)

8. 요구사항 분석 CASE와 HIPO – B

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

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

- HIPO(Hierarchy Input Process Output)

• 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한 것
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기능과 자료의 의존 관계를 동시에 표현할 수 있음
• 기호, 도표 등을 사용해 보기 쉽고 이해하기 쉬움
• 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 함
• HIPO Chart 종류
  • 가시적 도표
  • 총체적 도표
  • 세부적 도표

9. UML의 개요 – A

• Unified Modeling Language
• 시스템 개발 과정에서 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체 지향 모델링 언어
• Runbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합
• OMG에서 표준으로 지정
• 사물, 관계, 다이어그램

- 사물

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

10. UML - 관계 – B

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

- 연관 관계

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

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

- 집합 관계

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

- 포함 관계

• 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
• 서로 독립될 수 없고 생명주기를 함께함
• 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현

- 일반화 관계

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

- 의존 관계

• 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
• 사물의 변화가 다른 사물에도 영향을 미치는 관계
• 영향을 주는 사물이 영향을 받는 사물쪽으로 점선 화살표를 연결하여 표현

- 실체화 관계

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

11. UML - 다이어그램 – B

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

- 구조적 다이어그램의 종류

• 클래스 다이어그램
  • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
• 객체 다이어그램
  • 객체들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
  • 럼바우 객체지향 분석 기법에서 객체 모델링에 활용
• 컴포넌트 다이어그램
  • 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
  • 구현 단계에서 사용
• 배치 다이어그램
  • 물리적인 요소들의 위치를 표현
  • 구현 단계에서 사용
• 복합체 구조 다이어그램
  • 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
• 패키지 다이어그램
  • 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계 표현

- 행위 다이어그램의 종류

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

- 스테레오 타입

• UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것
• << >> 사이에 표현할 형태를 기술
• 주로 표현되는 형태
  • << include >> : 포함 관계
  • << extend >> : 확장 관계
  • << interface >> : 인터페이스 정의
  • << exception >> : 예외 정의
  • << constructor >> : 생성자 역할 수행

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

- 기능 모델링

• 개발될 시스템이 갖춰야 할 기능을 정리한 후 사용자와 공유하기 위해 그림으로 표현
• 기능에 초점을 맞춰 표현
• 유스케이스 다이어그램, 액티비티 다이어그램

- 유스케이스 다이어그램

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

- 유스케이스 다이어그램의 구성요소

• 시스템/시스템 범위
  • 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현
• 액터
  • 시스템과 상호작용을 하는 모든 외부 요소
  • 주로 사람이나 외부 시스템을 의미
  • 주액터 : 시스템을 사용함으로써 이득을 얻는 대상. 주로 사람
  • 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템. 주로 조직이나 기관
• 유스케이스
  • 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것
• 관계
  • 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있음
  • 포함 관계, 확장 관계, 일반화 관계

13. 활동 다이어그램 – B

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

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

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

14. 클래스 다이어그램 – B

- 정적 모델링

• 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것
• 구조적인 관점에서 표현
• 객체들을 클래스로 추상화하여 표현
• 정적 모델링의 대표적인 것이 클래스 다이어그램

- 클래스 다이어그램

• 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것
• 구조적 다이어그램
• 시스템 구성 요소를 문서화하는 데 사용

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

• 클래스
  • 각각의 객체들이 갖는 속성과 오퍼레이션을 표현한 것
  • 3개의 구획으로 나눠 클래스의 이름, 속성, 오퍼레이션을 표기
  • 속성 : 클래스의 상태나 정보를 표현
  • 오퍼레이션 : 클래스가 수행할 수 있는 동작으로, 함수라고도 함
• 제약조건
  • 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적음
  • 클래스 안에 제약조건을 기술할 때는 중괄호를 이용
• 관계
  • 클래스와 클래스 사이의 연관성을 표현
  • 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계

- 연관 클래스

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

15. 시퀀스 다이어그램 – B

- 동적 모델링

• 시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것
• 내부 구성 요소들 간에 이루어지는 동작이라는 관점에서 표현
• 구성 요소들 간의 메시지 호출, 즉 오퍼레이션을 통한 상호 작용에 초점
• 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 상태 다이어그램

- 시퀀스 다이어그램

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

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

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

16. 패키지 다이어그램 – A

• 요소들을 그룹화한 패키지간의 의존 관계를 표현한 것
• 패키지는 또 다른 패키지의 요소가 될 수 있음
• 주요 요소 간의 종속성을 파악하는데 사용

- 패키지 다이어그램의 구성 요소

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

17. 소프트웨어 개발 방법론 – B

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

- 구조적 방법론

• 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론
• 1960년대까지 가장 많이 적용되었던 소프트웨어 개발 방법론
• 쉬운 이해 및 검증이 가능한 프로그램 코드를 생성하는 것이 목적
• 분할과 정복 원리를 적용
• 타당성 검토 -> 계획 -> 요구사항 -> 설계 -> 구현 -> 시험 -> 운용/유지보수

- 정보공학 방법론

• 계획, 분석, 설계, 구축에 정형화된 기법들을 통합 및 적용하는 자료 중심의 방법론
• 대규모 정보 시스템을 구축하는데 적합
• 정보 전략 계획 수립 -> 업무 영역 분석 -> 업무 시스템 설계 -> 업무 시스템 구축

- 객체지향 방법론

• 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택
• 구성 요소 : 객체, 클래스, 메시지 등
• 기본 원칙 : 캡슐화, 정보 은닉, 추상화, 다형성, 상속성 등
• 요구 분석 -> 설계 -> 구현 -> 테스트 및 검증 -> 인도

- 컴포넌트 기반 방법론

• 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
• 컴포넌트의 재사용이 가능하여 시간과 노력을 절감
• 새로운 기능을 추가하는 것이 간단하여 확장성이 보장
• 유지 보수 비용을 최소화하고 생산성 및 품질을 향상시킬 수 있음
• 개발 준비 -> 분석 -> 설계 -> 구현 -> 테스트 -> 전개 -> 인도

- 제품 계열 방법론

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

18. S/W 공학의 발전적 추세 – A

- 소프트웨어 재사용

• 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용
• 개발의 품질과 생산성을 높이기 위한 방법
• 합성 중심 : 블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법. 블록 구성 방법
• 생성 중심 : 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법. 패턴 구성 방법

- 소프트웨어 재공학

• 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것
• 유지보수의 생산성 향상을 통해 소프트웨어의 위기를 해결하는 방법
• 기존 소프트웨어의 데이터와 기능들의 개조 및 개선을 통해 유지보수성과 품질을 향상
• 소프트웨어 재공학의 이점
  • 품질 향상
  • 생산성 증가
  • 수명 연장
  • 오류 감소

- CASE

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

19. 비용 산정 기법(하향식) – B

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

- 전문가 감정 기법

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

- 델파이 기법

• 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법
• 한 명의 조정자와 여러 전문가로 구성

20. 비용 산정 기법(상향식) – B

• 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
• LOC 기법, 개발 단계별 인월수 기법, 수학적 산정 기법

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

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

- 개발 단계별 인월수 기법

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

21. 수학적 산정 기법 – A

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

- COCOMO 모형

• LOC에 의한 비용 산정 기법
• 규모(LOC)를 예측한 후 이를 SW 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 산정
• 비용 산정 결과는 노력(Man-Month)으로 나타남
• 보헴이 제안

- COCOMO의 SW 개발 유형

• 조직형(Organic Mode)
  • 중소 규모의 SW
  • 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리용 등 5만라인 이하의 SW 개발
  • 사무 처리용, 업무용, 과학용 응용 SW 개발에 적합
• 반분리형(Semi-Detached Mode)
  • 조직형과 내장형의 중간형 SW
  • 트랜잭션 처리 시스템이나 운영체제, DB 관리 시스템 등 30만 라인 이하의 SW 개발
  • 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합
• 내장형(Embedded)
  • 초대형 규모의 SW
  • 트랜잭션 처리 시스템이나 운영체제 등의 30만 라인 이상의 SW 개발
  • 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 개발에 적합

- COCOMO 모형의 종류

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

- Putnam 모형

• SW 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
• Putnam이 제안한 것으로 생명 주기 예측 모형이라고도 함
• Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
• 대형 프로젝트의 노력 분포 산정에 이용
• 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소

- 기능 점수(FP) 모형

• SW의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며, 기능 점수를 구한 후 이를 이용해 비용을 산정하는 기법
• 알브레히트가 제안
• SW 기능 증대 요인
  • 자료 입력(입력 양식)
  • 정보 출력(출력 보고서)
  • 명령어(사용자 질의수)
  • 데이터 파일
  • 필요한 외부 루틴과의 인터페이스

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

• SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발
• ESTIMACS : FP 모형을 기초로 하여 개발

22. 프로젝트 일정 계획 – B

• 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여 소작업의 순서와 일정을 정하는 것
• 사용되는 기능 : WBS, PERT/CPM, 간트 차트 등

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

• 전체 작업의 상호 관계를 표시하는 네트워크
• 개발 경험이 없어 소요 기간 예측이 어려운 프로젝트 일정 계획에 사용
• 노드와 간선으로 구성되며 원 노드에는 작업, 간선에는 낙관치, 기대치, 비관치 표시
• 결정 경로, 작업에 대한 경계 시간, 작업 간의 상호 관련성 등을 알 수 있음
• 작업 예측치 계산 공식
  • (비관치 + 4 * 기대치 + 낙관치) / 6
• 평반 편차 공식
  • ((비관치 - 낙관치) / 6) ^ 2

- CPM(임계 경로) 기법

• 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
• 노드는 작업, 간선은 작업 사이의 전후 의존 관계를 나타냄
• 원형 노드는 각각의 작업을 의미하며, 작업 이름과 소요 기간을 표시
• 박스 노드는 이정표를 의미하며, 이정표 이름과 예상 완료 시간을 표시
• 화살표의 흐름에 따라 각 작업이 진행되며, 전 작업이 완료돼야 다음 작업 진행할 수 있음

- 간트 차트

• 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표
• 시간선 차트라고도 함
• 중간 목표 미달성 시 그 이유와 기간을 예측할 수 있게 함
• 사용자와의 문제점이나 예산의 초과 지출 등도 관리할 수 있음
• 자원 배치와 인원 계획에 유용하게 사용
• 이정표, 작업 일정, 작업 기간, 산출물로 구성
• 수평 막대의 길이는 각 작업의 기간을 나타냄

23. SW 개발 표준 – A

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

- ISO/IEC 12207

• ISO에서 만든 표준 SW 생명 주기 프로세스
• SW 생명 주기 표준을 제공
• 기본 생명 주기 프로세스 : 획득, 공급, 개발, 운영, 유지보수 프로세스
• 지원 생명 주기 프로세스 : 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상관리, 문제 해결 프로세스
• 조직 생명 주기 프로세스 : 관리, 기반 구조, 훈련, 개선 프로세스

- CMMI

• SW 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델

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

- SPICE

• 정보 시스템 분야에서 SW의 품질 및 생산성 향상을 위해 SW 프로세스를 평가 및 개선하는 국제 표준
• ISO/IEC 15504

- SPICE의 구성

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

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

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

24. SW 개발 프레임워크 – B

• SW 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 제공해주는 반제품 형태의 SW 시스템
• 주요 기능
  • 예외 처리
  • 트랜잭션 처리
  • 메모리 공유
  • 데이터 소스 관리
  • 서비스 관리
  • 쿼리 서비스
  • 로깅 서비스
  • 사용자 인증 서비스
• 종류
  • 스프링 프레임워크
  • 전자정부 프레임워크
  • 닷넷 프레임워크

- 스프링 프레임워크

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

- 전자정부 프레임워크

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

- 닷넷 프레임워크

• Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크
• MS사에서 통합 인터넷 전략을 위해 개발
• 코드 실행을 관리하는 CLR이라는 이름의 가상머신 상에서 작동

- SW 개발 프레임워크의 특성

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