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

소프트웨어 개발 방법론

▶ 소프트웨어 생명주기(SDLC)

 

시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 것

 

▶ 소프트웨어 생명주기 모델 종류 4가지

 

• 폭포수 모델: 한 단계씩 순차적으로 개발하며 이전단계로 되돌아갈 수 없다. 계획 - 요구사항 분석 - 설계 - 구현 - 테스트 - 유지보수 순으로 개발을 진행한다.
• 프로토타이핑 모델: 프로토타입을 구현해, 고객의 피드백을 반영하며 개발을 진행한다.
• 나선형 모델: 반복적으로 제품을 개발하며 위험을 최소화한다. 계획 및 정의 - 위험 분석 - 프로토타입 개발 - 고객 평가 순으로 개발을 진행한다.
• 반복적 모델: 구축 대상을 나누어 증분을 병렬적, 반복적 으로 개발 후 통합한다.

 

▶ 소프트웨어 개발 방법론 종류 6가지

 

• 구조적 방법론: 정형화된 분석 절차에 따라 사용자의 요구사항을 파악하여 문서화하는 처리 중심의 방법론으로, 분할과 정복 원리를 사용한다. 나씨-슈나이더만 차트를 사용한다. 
• 정보공학 방법론: 정보 시스템 개발에 필요한 관리 절차와 작업 기반을 체계화
• 객체지향 방법론: '객체'라는 기본 단위로 시스템 분석 및 설계
• 컴포넌트 기반 방법론 (CBD): 컴포넌트를 조립해 하나의 새로운 운용 프로그램 작성
• 애자일 방법론: 절차보다 사람이 중심이 되어 변화에 유연하고 신속하게 적응하며 효율적으로 시스템 개발
• 제품 계열 방법론: 여러 제품에 적용할 수 있는 재사용 가능한 공통된 기능을 정의해 개발한다.

 

▶ 애자일 방법론의 유형 3가지

 

• Extreme Programming (XP): 의사소통 개선과 즉각적 피드백으로 소프트웨어의 품질을 높이기 위한 방법론
• SCRUM: 짧은 개발 주기로 매일 15분 정도의 회의를 통해 스프린트를 정하고, 각 스프린트마다 계획을 구현하는 프로젝트 관리 방법론
• LEAN: 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해 낭비요소를 제거하는 방법론

 

▶ XP의 5가지 가치

 

• 용기
• 단순성
• 의사소통
• 존중
• 피드백

 

▶ XP의 12가지 기본원리 중 6가지

 

• Pair Programming: 다른 사람과 개발을 진행함으로써 개발에 대한 책임을 공동으로 나눠갖는 환경
• Continuous-Integration (CI): 모듈 단위로 나눠 개발된 코드들은 하나의 작업이 마무리 될때마다 지속적으로 통합
• Small Releases: 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응
• Test-Driven Development (TDD): 실제 코드를 작성하기 전 테스트케이스를 먼저 작성하고 이를 통과할 수 있도록 코드 작성. 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구 사용
• Refactoring: 프로그램 기능의 변경 없이 단순화, 유연성 강화 등을 통해 시스템 재구성
• Metaphor: 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다.

 

▶ 상향식 비용산정기법의 정의 및 종류 5가지

 

프로젝트의 세부적인 작업단위 별로 비용을 산정한 후 합산하는 방식

 

• Line Of Code (LOC): 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하는 방법
• Man/Month (M/M): 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 비용을 산정하는 방식
• COCOMO 모형: 보헴이 제안한 방식으로, 프로그램의 규모에 따라 비용 산정 

• Organic Mode: 5만 라인 이하
• Semi-Detached Mode: 5만 라인 이상 ~ 30만 라인 이하
• Embedded Mode: 30만 라인 이상

 

• Putnam 모형: Putnam이 제안한 방식으로, 소프트웨어 생명 주기의 전 과정 동안 사용될 노력의 분포를 가정해 주는 모형이다. 생명 주기 예측 모형이라고도 하며, Rayleigh-Norden 곡선의 노력 분포도를 기초로 비용을 산정한다.
• 기능점수 (FP): 알브레히트가 제안한 방식으로, 요인별 가중치를 합산하여 총 기능점수를 구하고, 이를 통해 비용을 산정한다.

 

▶ 하향식 비용산정기법의 정의 및 종류 2가지

 

과거 유사 경험을 바탕으로 회의를 통해 비용 산정

 

• 전문가 감정 기법: 조직 내의 경험이 많은 2명 이상의 전문가에게 비용산정 의뢰
• 델파이 기법: 많은 전문가의 의견을 종합하여 산정하는 기법으로, 전문가 기법의 주관적인 편견을 보완한다.

 

▶ 일정관리 모델의 종류 3가지

 

• 주 공정법 (CPM): 여러 작업의 수행 순서가 얽혀있는 프로젝트의 일정을 계산할 때 사용한다.
• PERT: 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로, 비관치, 중간치, 낙관치를 이용한다.
• 중요 연쇄 프로젝트 관리 (CCPM): 자원제약사항을 고려하여 일정을 작성한다.

 

현행 시스템 분석

▶ 현행 시스템 파악

 

현행 시스템의 하위 시스템, 기능, 연계 정보, 사용 소프트웨어 / 하드웨어, 네트워크 구성을 파악하는 활동

 

▶ 현행 시스템 파악의 목적

 

향후 개발하고자 하는 시스템의 개발 범위 및 이해방향성 설정에 도움을 주기 위해

 

▶ 현행 시스템 파악 절차

 

• 1단계: 시스템 구성, 기능, 인터페이스 현황 파악
• 2단계: 시스템 아키텍처, 소프트웨어 구성 현황 파악
• 3단계: 시스템 하드웨어, 네트워크 구성 현황 파악

 

▶ 소프트웨어 아키텍처

 

여러가지 소프트웨어 구성요소와 외부 특성, 구성요소 간의 관계를 표현하는 시스템 구조 또는 구조체

 

▶ 소프트웨어 아키텍처 프레임워크 정의 및 특징 4가지

 

소프트웨어 집약적 시스템에서 아키텍처가 표현해야 하는 내용 및 이들간의 관계를 제공하는 아키텍처 기술 표준

 

• 모듈화: 인터페이스에 의한 캡슐화를 통해 설계 및 구현의 변경에 따른 영향을 최소화 하는것으로, 소프트웨어의 품질을 향상시킨다.
• 재사용성: 재사용 가능한 모듈들을 제공하는 것으로, 예산 절감, 생산성 향상, 품질 보증이 가능하다.
• 확장성: 다형성을 통해 어플리케이션이 프레임워크의 인터페이스를 넓게 사용할 수 있게 한다.
• 제어의 역흐름: 개발자가 관리하고 통제해야 하는 객체들을 프레임워크가 제어하는 것으로, 제어의 흐름이 기존과는 반대인 프레임워크 > 어플리케이션으로 흐른다.

 

▶ 소프트웨어 아키텍처 4+1 뷰

 

고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적 접근 방법

 

• 논리 뷰: 시스템의 기능적 요구사항 설명
• 프로세스 뷰: 시스템의 비기능적 요구사항 설명
• 구현 뷰: 정적인 소프트웨어 모듈, 컴포넌트 구조, 의존성, 부가적인 정보 설명
• 배포 뷰: 물리적 환경의 배치 연결 작업 설명
• 유스케이스 뷰: 위의 4가지 뷰 검증

 

▶ 소프트웨어 아키텍처 패턴 정의 및 유형 5가지

 

소프트웨어 구조에서 발생하는 문제점을 해결하기 위한 일반화된 재사용 가능한 솔루션

 

• 계층화 패턴: 시스템을 계층으로 구분하여 구성하는 패턴
• 클라이언트-서버 패턴: 다수의 클라이언트와 하나의 서버로 구성된 패턴
• 파이프 필터 패턴: 데이터 스트림을 생성하고 처리하는 시스템에서 사용하는 패턴. 필터가 처리과정을 실행하고, 처리된 데이터는 파이프를 통해 전송
• 브로커 패턴: 분리된 컴포넌트들로 구성된 분산 시스템에서 사용하는 패턴으로, 브로커 컴포넌트가 컴포넌트 간의 통신 조절
• MVC 패턴: 모델, 뷰, 컨트롤러 3개의 컴포넌트가 각자의 역할을 갖고 사용자에게 서비스를 제공하는 패턴

 

▶ 운영체제

 

사용자와 하드웨어 사이의 인터페이스 역할을 하며 컴퓨터 시스템의 자원을 관리하는 소프트웨어

 

▶ 운영체제 성능 평가 기준 4가지

 

• 처리능력 (Throughput): 일정한 시간 내에 시스템이 처리하는 일의 양
• 반환시간 (Turn Around Time): 작업 의뢰 시간부터 처리 완료까지 걸리는 시간
• 사용가능도 (Availability): 시스템을 사용할 필요가 있을 때 즉시 사용 가능한 정도
• 신뢰도 (Reliability): 시스템이 주어진 문제를 정확하게 해결하는 정도

 

▶ 운영체제 고려사항 5가지

 

• 신뢰성
• 주변기기
• 성능
• 기술지원
• 구축비용

 

▶ 운영체제 종류

 

• Windows
• Unix
• Linux
• Android
• iOS

 

▶ 미들웨어

 

• 운영체제와 어플리케이션 사이에서 추가적인 서비스를 제공하는 소프트웨어
• 클라이언트 - 서버 간의 통신을 담당하는 소프트웨어
• 표준화된 인터페이스를 제공하여 데이터 교환의 일관성 보장

 

▶ 미들웨어 종류 6가지

 

• DB (Database): 원격 데이터베이스와 연결하기 위한 미들웨어
• WAS (Web Application Server): 사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리하기 위한 미들웨어
• RPC (Remote Procedure Call): 원격 프로시저를 로컬 프로시저 처럼 호출하는 미들웨어
• MOM (Message Oriented Middleware): 비동기형 메시지를 전달하는 미들웨어
• TP-Monitor (Transaction Processing Monitor): 온라인 트랜잭션을 처리 및 감시하는 미들웨어
• ORB (Object Request Broker): CORBA 표준 스펙을 구현한 객체 지향 미들웨어

 

요구사항 확인

▶ 요구사항

 

소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 제약조건

 

▶ 요구사항 분류 4가지

 

• 기능적 요구사항: 시스템이 제공하는 기능, 서비스에 관한 요구사항
  • 사용자 요구사항: 사용자의 관점에서의 기능적 요구사항
  • 시스템 요구사항: 시스템 기능, 입출력, 예외사항 등 개발자 관점에서의 기능적 요구사항
• 비기능적 요구사항: 시스템 기능들에 대한 조건과 제약사항에 관한 요구사항

 

▶ 요구사항 개발 프로세스 4단계

 

• 도출: 요구사항 식별, 인터뷰, 브레인스토밍, 설문조사, 워크숍, 롤플레잉
• 분석: 요구사항 분류, 요구사항 협상, 요구사항 할당, 개념 모델링, 정형 분석
• 명세: 시스템 요구사항 명세서, 시스템 정의서
• 확인: 요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트

 

▶ 요구사항 검증 방법 3가지

 

• 동료검토: 2~3명이 진행하며 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고, 이해관계자들이 설명을 들으며 코드에 대한 결함을 발견
• 워크스루: 회의 전 검토 자료를 배포하여 사전 검토한 후 짧은 시간동안 회의 진행
• 인스펙션: 원시 코드 등을 저작자 외의 전문가 또는 팀이 검사하여 오류를 찾아내는 기법

 

UML

▶ UML

 

개발자들이 원활한 의사소통을 하기 위해 고안된 표준화 통합 모델링 언어

 

▶ UML의 구성요소 3가지

 

• 사물
• 관계
• 다이어그램

 

▶ UML 사물 4가지

 

• 구조: 시스템의 개념적, 물리적 요소 표현
• 그룹: 요소들을 그룹으로 묶어서 표현
• 행동: 시간과 공간에 따른 요소들의 행위를 표현
• 주해: 부가적인 설명이나 제약조건 표현

 

▶ UML 관계 6가지

 

• 연관 (Association): 2개 이상의 사물이 서로 관련이 있을 경우 ( ㅡ )
• 집약 (Aggregation): 하나의 사물이 다른 사물에 포함되며, 생명주기를 공유하지 않을 경우 ( ㅡ◇ )
• 합성 (Composition): 포함하는 사물의 변화가 포함되는 사물에 영향을 미치며, 생명주기를 공유할 경우 ( ㅡ◆ )
• 일반화 (Generalization): 사물이 상속 관계에 있을 경우 ( ㅡ▷ )
• 의존 (Dependency): 사물 사이에 연관은 있으나 영향을 줄 때만 연관을 유지할 경우 ( ---- )
• 실체화 (Realization): 사물이 인터페이스를 구현하는 관계에 있을 경우 ( ----▷ )

 

▶ 구조 다이어그램 종류 6가지

 

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

 

▶ 행위 다이어그램 종류 7가지

 

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

 

▶ 유스케이스 다이어그램 구성요소 4가지

 

• 시스템
• 액터
• 유스케이스
• 관계