[정처기/실기] 1단원(요구사항 확인) 요약

*  수제비 정보처리기사 실기 책을 보고 직접 정리한 내용입니다.

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

[1-1] 소프트웨어 생명주기 모델 프로세스

• 요구사항 분석
• 설계
• 구현
• 테스트
• 유지보수

[1-2] 소프트웨어 생명주기 종류

폭포수 모델

• 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델
• 가장 오래된 모델
• 장점 : 모형의 적용 경험과 성공 사례 多, 단계별 정의와 산출물이 명확, 관리가 편리
• 단점 : 요구사항 변경이 어려움
• 타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트

프로토타이핑 모델

• 고객이 요구한 주요 기능을 프로토 타입으로 구현하여, 고객의 피드백을 반영해 소프트웨어를 만드는 모델
• 장점 : 요구분석 용이, 타당성 검증 가능
• 단점 : 프로토타입 폐기에 따른 비용 증가

나선형 모델

• 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해나가는 모델
• 장점 : 위험성 감소, 변경에 유연한 대처
• 단점 : 단계 반복에 따른 관리 어려움
• 계획 및 정의 → 위험 분석 → 개발 → 고객 평가

반복적 모델

• 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 모델

[2-1] 소프트웨어 개발 방법론 종류

• 구조적 방법론
• 정보공학 방법론
• 객체 지향 방법론
• 컴포넌트 기반 방법론
• 애자일 방법론
• 제품 계열 방법론

[2-2] 애자일(Agile)

• 변화에 유연하고 신속하게 적응 → 효율적으로 시스템 개발
• 개발 기간이 짧고 신속, 폭포수 모형에 대비되는 방법론으로 개발 즉시 피드백을 받아서 유동적으로 개발  

  비교대상	애자일 방법론	전통적 방법론
  계획수립	유동적 범위 설정	확정적 범위 설정
  업무수행	팀 중심 업무 수행	관리자 주도적 명령과 통제, 개인 단위로 업무 수행
  개발/검증	반복 주기 단위로 개발/검증	분석/설계/구현/테스트를 순차적으로 수행
  팀관리	업무 몰입, 팀 평가	경쟁, 개별 평가
  문서화	코드 강조	상세한 문서화 강조
  성공요소	고객 가치 전달	계획/일정 준수
  유형	XP, 스크럼, 린	폿포수, 프로토타입, 나선형

XP

• 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
• XP의 12가지 기본원리
  • 짝 프로그래밍
  • 공동 코드 소유
  • 지속적인 통합
  • 계획 세우기
  • 작은 릴리즈
  • 메타포어
  • 간단한 디자인
  • 테스트 기반 개발
  • 리팩토링
  • 40시간 작업
  • 고객 상주
  • 코드 표준

린(Lean)

• 도요타의 린 시스템 품질기법을 적용하여 낭비 요소를 제거해 품질을 향상시킨 방법론
• JIT(Just In Time),  칸반(Kanban) 보드 사용
• 린의 7가지 원칙 : 낭비 제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

스크럼(SCRUM)

• 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
• 주요 개념
  • 백로그 : 제품과 프로젝트에 대한 요구사항
  • 스프린트 : 2 ~ 4주의 짧은 개발 기간. 반복적 수행으로 개발품질 향상
  • 스크럼 미팅 : 매일 15분 정도 미팅으로 To-Do List 계획 수립
  • 스크럼 마스터 : 프로젝트 리더. 스크럼 수행 시 문제를 인지 및 해결하는 사람
  • 스프린트 회고 : 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
  • 번 다운 차트 : 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트

[3-1] 객체 지향 구성요소

• 클래스
• 객체
• 메서드
• 메시지
• 인스턴스
• 속성

[3-2] 객체 지향 기법

• 캡슐화(Encapsulation)
• 상속성(Inheritance)
• 다형성(Polymorphism)
• 추상화(Abstraction)
• 정보 은닉(Information Hiding)
• 관계성(Relationship)

[3-3] 객체 지향 설계 원칙(SOLID)

• 단일 책임의 원칙(SRP)
• 개방 폐쇄 원칙(OCP)
• 리스코프 치환의 원칙(LSP)
• 인터페이스 분리의 원칙(ISP)
• 의존성 역전의 원칙(DIP)

[3-4] 객체 지향 분석 방법론 종류

OOSE

OMT

• 럼바우객체 모델링(Object Modeling) = 정보 모델링(Information Modeling) - 시스템에서 요구하는 객체를 찾고 객체 간의 관계를 정의하여 ER 다이어그램을 만드는 과정 - 가장 중요하며 선행되어 진행 - 객체 다이어그램을 활용하여 표현

  동적 모델링(Dynamic Modeling)	시간의 흐름에 따라 객체들 사이의 제어 흐름,동작 순서 등의 동적인 행위를 표현하는 모델링
  기능 모델링(Functional Modeling)	프로세스의 자료 흐름을 중심으로 처리 과정을 표현하는 모델링

OOD

[3-5] 기능 모델링 주요 기법

• 데이터 흐름도
• 자료 사전

[4-1] 프로젝트 관리 대상

• 계획 관리
• 품질 관리
• 범위 관리

[4-2] 프로젝트 관리 3대 요소

• 사람
• 문제
• 프로세스

[5-1] 비용산정 모형 종류

• 비용산정 모형 : 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식분류 설명 종류

  하향식 산정방법	경험이 많은 전문가와 조정자를 통해 비용 산정하는 방식	전문가 판단, 델파이 기법
  상향식 산정방법	세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식	코드 라인 수(LoC), Man Month, COCOMO 모형, 푸트남 모형, 기능점수(FP) 모형

LoC(Lines of Code) 모형

• 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용 산정
• 측정이 쉽고 이해하기 쉬워 많이 사용

Man Month 모형

• 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 비용 산정
• (Man Month) = (LoC)/(프로그래머의 월간 생산성)
• (프로젝트 기간) = (Man Month)/(프로젝트 인력)

COCOMO(COnstructive COst MOdel)모형

• 보헴(Boehm)이 제안한 모형으로 프로그램 규모에 따라 비용 산정 유형 설명
  • 조직형(Organic Mode)
  • 반 분리형(Semi-Detached Mode)
  • 임베디드형(Embedded Mode)

푸트남(Putnam) 모형

• 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
• 푸트남이 제안, 생명주기 예측 모형이라고 함

기능점수(FP; Function Point) 모형

• 요구 기능을 증가시키는 인자별로 가중치를 부여, 합산해 총 기능의 점수를 계산하여 비용 산정

[6-1] 일정관리 모델 종류

• 일정관리 모델 : 프로젝트가 일정 기한 내에 완료될 수 있도록 관리하는 모델모델 설명
  • 주 공정법(CPM; Critical Path Method)
  • 중요 연쇄 프로젝트 관리(CCPM; Critical Chain Project Management)
  • PERT(Program Evaluation and Review Technique)

[7] 위험 관리

• 프로젝트에 내재된 위험 요소를 인식하고 그 영향을 분석하여 이를 관리하는 활동
• 위험의 종류
  • 알려진 위험
  • 예측 가능한 위험
  • 예측 불가능한 위험
• 위험 대응 전략
  • 회피
  • 전가
  • 완화
  • 수용

2. 현행 시스템 분석

[1] 현행 시스템 파악

• 현행 시스템 파악 : 사용하고 있는 소프트웨어 및 하드웨어는 무엇인지, 네트워크의 구성은 어떻게 되어 있는지 파악하는 활동
• 현행 시스템 파악 절차
  • 1단계 : 구성/기능/인터페이스 파악
  • 2단계 : 아키텍처 및 소프트웨어 구성 파악
  • 3단계 : 하드웨어 및 네트워크 구성 파악

[2-1] 소프트웨어 아키텍처 프레임워크

• 소프트웨어 아키텍처 : 여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조
• 소프트웨어 아키텍처 프레임 워크 : 소프트웨어 시스템에서 아키텍처가 표현해야하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준
• 소프트웨어 아키텍처 프레임워크 구성요소
  • 아키텍처 명세서
  • 이해관계자
  • 관심사
  • 관점
  • 뷰
  • 근거
  • 목표
  • 환경
  • 시스템

[2-2] 소프트웨어 아키텍처 4+1뷰

• 고객의 요구사항을 정리해놓은 시나리오를 4개의 관점에서 바라보는 접근 방법
• 4개의 구조가 서로 충돌되지 않는지, 시스템의 요구사항을 충족시키는지 증명하기 위해 유스케이스 사용

유스케이스 뷰

• 유스케이스 또는 아키텍처를 도출하고 설계하며다른 뷰를 검증하는 데 사용되는 뷰
• 사용자, 설계자, 개발자, 테스트 관점

논리 뷰

• 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
• 설계자, 개발자 관점

프로세스 뷰

• 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
• 개발자, 시스템 통합자 관점

구현 뷰

• 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
• 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의

배포 뷰

• 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

[2-3] 소프트웨어 아키텍처 패턴

• 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식
• 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션
• 개발 시간 단축, 개발 생산성과 품질 확보 가능, 안정적인 개발 수행 가능

계층화 패턴(Layered Pattern)

• 시스템을 계층으로 구분하여 구성하는 패턴
• 각 하위 모듈들은특정한 수준의 추상화 제공, 각 계층은 다음 상위 계층에 서비스 제공
• 서로 마주 보는 두 개의 계층 사이에서만 상호작용 함

클라이언트-서버 패턴(Client-Server Pattern)

• 하나의 서버와 다수의 클라이언트로 구성
• 사용자가 클라이언트를 통해 서버에 서비스 요청 → 서버는 클라이언트에게 서비스 제공
• 서버는 계속 클라이언트로부터 요청 대기

파이프-필터 패턴(Pipe-Filter Pattern)

• 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴
• 서브 시스템이 입력 데이터를 받아 처리, 결과를 다음 서브 시스템으로 넘겨주는 과정 반복
• 필터 컴포넌트 ← 재사용성이 좋음, 추가가 쉬워 확장 용이

브로커 패턴(Broker Pattern)

• 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용

모델-뷰-컨트롤러 패턴(MVC; Model View Controller Pattern)

• 대화형 애플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화모델 핵심 기능과 데이터 보관

  뷰	사용자에게 정보 표시
  컨트롤러	사용자로부터 요청을 입력받아 처리

• 각 부분이 별도의 컴포넌트로 분리 → 서로 영향을 받지 않고 개발 가능, 코드의 효율적인 재사용 가능

[2-4] 소프트웨어 아키텍처 비용 평가 모델

• SAAM
• ATAM
• CBAM
• ADR
• ARID

[3-1] 디자인 패턴 구성요소

패턴의 이름

• 디자인 패턴을 부를 때 사용하는 이름과 디자인 패턴의 유형

문제 및 배경

• 디자인 패턴이 사용되는 분야 또는 배경, 해결하는 문제

솔루션

• 디자인 패턴을 이루는 요소들, 관계, 협동 과정

사례

• 디자인 패턴의 간단한 적용 사례

결과

• 디자인 패턴을 사용하면 얻게 되는 이점이나 영향

샘플 코드

• 디자인 패턴이 적용된 원시 코드

[3-2] 디자인 패턴 유형

목적

• 생성
• 구조
• 행위

범위

• 클래스
• 객체

[3-3] 디자인 패턴 종류

생성 패턴

• Builder
• Prototype
• Factory Method
• Abstract Factory
• Singleton

구조 패턴

• Bridge
• Decorator
• Facade
• Flyweight
• Proxy
• Composite
• Adapter

행위 패턴

• Mediator
• Interpreter
• Iterator
• Template Method
• Observer
• State
• Visitor
• Command
• Stratege
• Memento
• Chain of Responsibility

[4-1] 운영체제 현행 시스템 분석

• 운영체제
  • 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있게 해줌
  • 컴퓨터 사용자와 하드웨어 간의 인터페이스를 담당
  • 사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원하는 소프트웨어
• 운영체제 현행 시스템 분석 시 고려사항
  • 품질 측면
    • 신뢰도 : 장기간 시스템 운영 시 운영체제의 장애 발생 가능성, 운영체제의 버그로 인한 재기동 여부
    • 성능 : 대규모 및 대량 파일 작업 처리, 지원 가능한 메모리 크기
  • 지원 측면
    • 기술 지원
    • 주변 기기
    • 구축 비용
• 운영체제 종류 및 특징
  • PC
    • 윈도즈
    • 유닉스
    • 리눅스
  • 모바일
    • 안드로이드
    • iOS

[4-2] 네트워크 현행 시스템 분석

OSI 7계층

• 응용 계층(Application Layer)
• 표현 계층(Presentation Layer)
• 세션 계층(Session Layer)
• 전송 계층(Transport Layer)
• 네트워크 계층(Network Layer)
• 데이터 링크 계층(Data Link Layer)
• 물리 계층(Physical Layer)

[4-1] DBMS 현행 시스템 분석

• DBMS : 데이터베이스라는 데이터의 집합을 만들고 저장 및 관리 할 수 있는 기능들을 제공하는 응용 프로그램
• DBMS의 기능
  • 중복 제어
  • 접근 통제
  • 인터페이스 제공
  • 관계 표현
  • 샤딩/파티셔닝
  • 무결성 제약 조건
  • 백업 및 회복
• DBMS 현행 시스템 분석 시 고려 사항(가성호기구)
  • 가용성
  • 성능
  • 상호 호환성
  • 기술 지원
  • 구축 비용

[4-1] 미들웨어 현행 시스템 분석

• 미들웨어 : 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이뤄질 수 있도록 제어해주는 소프트웨어, 운영체제와 애플리케이션 사이에 위치함
• 미들웨어 현행 시스템 분석 시 고려 사항
  • 가용성
  • 성능
  • 기술 지원
  • 구축 비용

3. 요구사항 확인

[1-1] 요구공학의 목적

• 요구공학(Requirements Engineering) : 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 활동
• 목적
  • 효과적인 의사소통 수단 제공, 요구사항에 대한 공통된 이해 설정
  • 요구사항 누락 방지 및 불필요한 비용과 시간 절감
  • 요구사항 변경 추적 가능

[1-2] 요구사항의 분류

기능적 요구사항

• 시스템이 요구하는 기능, 서비스에 대한 요구사항
• 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대한 기술
• 특성 : 기능성, 완전성, 일관성

비기능적 요구사항

• 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항
• 품질 속성에 관련해 시스템이 갖춰야 할 사항에 관한 기술, 시스템이 준수해야 할 제한 조건
• 특성 : 신뢰성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약 사항

[2-1] 요구공학 프로세스

요구공학 프로세스는 요구사항 개발 단계와 요구사항 관리 단계로 구성

[2-2] 요구사항 개발 단계

• 요구사항 도출
• 요구사항 분석
• 요구사항 명세
• 요구사항 확인 및 검증

[2-3] 요구사항 개발 단계 상세

요구사항 도출

• 소프트웨어가 해결해야 할 문제 이해, 고객으로부터 제시되는 요구에 대해 관련 정보 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계
• 주요기법
  • 인터뷰
  • 브레인스토밍
  • 델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한 방법
  • 롤 플레잉
  • 워크숍
  • 설문조사

요구사항 분석

• 추출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계
• 요구사항 분석 단계 절차
  • 요구사항 분류
  • 개념 모델링 생성 및 분석
  • 요구사항 할당
  • 요구사항 협상
  • 정형 분석
• 요구사항 분석 단계 기법
  • 자료 흐름 지향 분석
  • 객체 지향 분석
• 요구사항 분석 기술
  • 청취, 인터뷰와 질문, 분석, 중재, 관찰, 작성, 조직, 모델 작성 기술

요구사항 명세

• 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계
• 산출물 : 요구사항 명세서
• 요구사항 명세 단계 주요 기법
  • 비정형 명세 기법
    • 사용자의 요구를 표현할 때 자연어 기밥으로 서술하는 기법
    • 사용자와 개발자의 이해가 용이
    • 명확성 및 검증에 문제
  • 정형 명세 기법
    • 수학적인 원리와 표기법으로 서술하는 기법
    • 정형 명세 언어인 Z-스키마, Petri Nets, 상태차트 활용
    • 표현이 간결, 명확성 및 검증이 용이
    • 기법의 이해가 어려움
• 요구사항 명세 원리 및 검증 항목
  • 명확성, 완전성, 검증 가능성, 일관성, 수정 용이성, 추적 가능성, 개발 후 이용성

요구사항 확인 및 검증

• 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대한 검토, 베이스라인을 설정하는 활동
• 요구사항 확인 및 검증 절차
  • 요구사항 목록 확인
  • 요구사항 정의서 작성 여부 확인
  • 비기능적 요구사항의 확인
  • 타 시스템 인터페이스 요구사항 확인
• 요구사항 확인 및 검증 단계 주요 기법
  • 요구사항 검토
  • 정형 기술 검토
    • 동료 검토(Peer Review)
    • 워크 스루
    • 인스펙션(Inspection)
  • 프로토타이핑 활용
  • 모델 검증
  • 테스트 케이스 및 테스트를 통한 확인
  • CASE 도구 활용 검증
  • 베이스라인을 통한

[2-4] 요구사항 관리 단계

• 요구사항 협상
• 요구사항 기준선 설정
• 요구사항 변경관리
• 요구사항 확인 및 검증