2022 정보처리기사 실기 Chapter 01 요구사항 확인

01 소프트웨어 개발 방법론

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

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

* 소프트웨어 생명주기 모델 프로세스 => 요구사항 분석/설계/구현/테스트/유지보수

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

=> 폭프나반

• 폭포수 모델(Waterfall Model): 각 단계를 마무리 지은 후에 다음 단계로 넘어감/가장 오래된 모델/
• 프로토타이핑 모델(Prototyping Model): 프로토타입을 구현해, 고객의 피드백을 반영하며 만들어 간다. 
• 나선형 모델(Spiral Model): 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
  • 절차: 계위개고 계획 및 정의 => 위험 분석 => 개발 => 고객평가 
• 반복적 모델(Iteration Model): 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발한다. 

▶  소프트웨어 개발 방법론(Software Development Methodology) 종류

=> 구정객컴 애제

• 구조적 방법론: 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론/나씨-슈나이더만 차트 사용(도형식 표현방법을 통해서 논리를 기술하는 것) => 기능
• 정보공학 방법론: 정보시스템 개발에 필요한 관리 절차와 작업 기반을 체계화 => 정보
• 객체지향 방법론: '객체'라는 기본 단위로 시스템을 분석 및 설계
• 컴포넌트 기반 방법론(CBD): 컴포넌트를 조립해 하나의 새로운 응용 프로그램 작성 
• 애자일 방법론: 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템 개발 
• 제품계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발, 임베디드

* 컴포넌트: 특정한 기능을 수행하기 위해서 독립적으로 개발되어 보급되는 잘 정의된 인터페이스를 가지며 다른 부품과 조립되어 응용 시스템을 구축하기 위해 사용되는 소프트웨어

▶ 애자일 방법론의 유형

=> XP, 스크럼, 린(LEAN)

• XP: 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질 높이기 위한 방법론
• SCRUM: 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 방법론
• LEAN: 도요타의 린 시스템 품질 기법을 소프트웨어 개발 프로세스에 적용해 낭비 요소를 제거하는 방법론

▶ XP의 5가지 가치

=> 용단의 피존

• 용기: 용기를 가지고 자신감 있게 개발(코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못 하는 코드를 리팩토링할 수 있는 용기)
• 단순성: 필요한 것만 하고 그 이상의 것들은 하지 않음
• 의사소통: 개발자, 관리자, 고객 간의 원활한 소통
• 피드백: 의사소통에 대한 빠른 피드백
• 존중: 팀원 간의 상호 존중

▶ XP의 12가지 기본원리

• 개발자 둘이서 짝으로 코딩하는 원리
• 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리
• 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
• 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 아려주어야 하는 원리
• 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리
• 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다는 원리
• 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
• 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성하는 원리
• 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템을 재구성한다는 원리
• 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야한다는 원리
• 개발자들의 질문에 즉갑 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
• 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리

• 짝 프로그래밍(Pari Programming)
• 공동 코드 소유(Collective Ownership)
• 지속적인 통합(CI; Continous Integration)
• 계획 세우기(Planning Process)
• 작은 릴리즈(Small Release)
• 메타포어(Metaphor)
• 간단한 디자인(Simple Design)
• 테스트 기반 개발(TDD; Test Driven Develop)
• 리팩토링(Refactoring)
• 40시간 작업(40-Hour Work)
• 고객 상주(On Stie Customer)
• 코드 표준(Coding Standard)

▶ 스크럼 

매일 정해진 시간, 장소에서 짧은 시간 동안 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

• 제품과 프로젝트에 대한 요구사항 
• 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발 품질 향상
• 매일 15분 정도 미팅으로 To-Do List 계획 수립/데일리미팅이라고도 함
• 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
• 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
• 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트/백로그는 보통 수직축에 위치하며 시간은 수평줄에 위치

• 백로그(Backlog)
• 스프린트
• 스크럼 미팅
• 스크럼 마스터
• 스프린트 회고
• 번 다운 차트

▶ 객체 지향 분석 방법론 종류

객체 지향 분석(OOA; Object Oriented Analysis) => 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법이다.

• OOSE(Object Oriented Software Engineering): 야콥슨(Jacobson)/유스케이스를 모든 모델의 근간으로 활용
• OMT(Object Modeling Technology): 럼바우(Rumbaugh)/그래픽 표기법을 이용하여 소프트웨어 구성요소 모델링
  • 럼바우의 객체 지향 분석 절차 => 객동기
  • 객체 모델링(Object Modeling): 객체 다이어그램/동적 모델링(Dynamic Modeling): 상태 다이어그램/기능 모델링(Funcitonal Modeling): 자료흐름도(DFD)
• OOD(Object Oreinted Design): 부치(Booch)/설계 문서화를 강조하여 다이어그램 중심으로 개발

▶ 비용 산정 모형 분류

• 하향식 산정밥법 
  • 전문가 판단, 델파이 기법(전문가의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한 기법)
• 상향식 산정방법
  • 코드 라인 수(Loc)/Man Month/COCOMO 모형/푸트남 모형/기능점수(FP)모형

▶ 비용 산정 모형 종류

• 코드 라인 수(Loc; Line of Code): 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구해 비용을 산정하는 방식
• Man Month 모형: 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정하는 방식
  • Man Month = LOC/(프로그래머의 월간 생산성) 
  • 기간 = Man Month/인력
  • => 문제 풀 때 Man Month를 구하는지, 기간을 구하는지 정확하게 보기
• COCOMO 모형: 보헴이 제한, 프로그램 규모에 따른 비용 산정 => 오세임 
  • 조직형(Organic Mode): 5만 라인 이하
  • 반 분리형(Semi-Detached Mode): 30만 라인 이하
  • 임베디드형(Embedded Mode): 30만 라인 이상
• 푸트남 모형: 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식, 생명주기 예측 모형, Rayleigh-Norden 곡선
• 기능점수(FP; Functon Point) 모형: 요구 기능에 따른 가중치 부여

▶ 일정관리 모델

일정 기한 내에 적절하게 완료될 수 있도록 관리

• 주 공정법(CPM; Critical Path Method): 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정 계산 
• PERT(Program Evaluation and Review Technique): 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정 방식을 통해 일정을 관리하는 기법
• 중요 연쇄 프로젝트 관리(CCPM; Critical Chain Project Management): 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법

 

02 현행 시스템 분석

▶ 현행 시스템 파악

(현행 시스템 파악 절차 단답형으로 나오기 좋음)

구성/기능/인터페이스 파악  -> 아키텍처 및 소프트웨어 구성 파악 -> 하드웨어 및 네트워크 구성 파악

▶ 소프트웨어 아키텍처(Software Architecture)

여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체이다.

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

(소프트웨어 아키텍처 4+1뷰는 단골 문제 가능성이 높음!!)

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

* 4개의 분리된 구조로 구성되는 아키텍쳐 개념을 제시하고, 이들 4개의 구조가 서로 충돌되지는 않는지, 시스템의 요구사항을 충족시키는지를 증명하기 위한 체크 방법 => 유스케이스

• 유스케이스 뷰: 다른 뷰를 검증하는데 사용/사용자, 설계자, 개발자, 테스트 관점
• 논리 뷰: 시스템의 기능적인 요구사항 설명/설계자, 개발자 관점
• 프로세스 뷰: 시스템의 비기능적인 요구사항 설명/개발자, 시스템 통합자 관점
• 구현 뷰: 모듈이 구성, 컴포넌트 구조, 의존성
• 배포 뷰: 컴포넌트가 물리적인 아키텍쳐에 어떻게 배치되는가를 매핑해서 보여주는 뷰

▶ 유스케이스

시스템의 요구사항이자, 사용자의 입장에서 바라본 시스템의 기능

▶ 소프트웨어 아키텍처  패턴

소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식

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

▶ 소프트웨어 아키텍처  패턴 유형

• 계층화(Layered) 패턴: 시스템을 계층으로 구분해 구성하는 패턴
• 클라이언트-서버 패턴: 하나의 서버와 다수의 클라이언트로 구성된 패턴
• 파이프-필터 패턴: 데이터 스트림을 생성하고 처리하는 시스템에서 사용
• 브로커(Broker) 패턴: 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌트들 원격 서비스 실행을 통해 상호작용 가능
• 모델-뷰-컨트롤러 패턴(MVC패턴): 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시작적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 패턴/대화형 어플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화 
  • 모델: 핵심 기능과 데이터 보관
  • 뷰: 사용자에게 정보표시
  • 컨트롤러: 사용자로부터 요청 입력 받아 처리

▶ 소프트웨어 아키텍처  비용 평가 모델 종류

=> SACCA(사카)

• SAAM(Software Architecture Analysis Method): 변경 용이성과 기능성 집중, 경험이 없는 조직에서도 활용가능
• ATAM(Architecture Trade-off Analysis Method): 아키텍처 품질 속성을 만족시키는 판단
• CBAM(Cost Benefit Analysis Method): ATAM 바탕의 시스템, 경제적 의사결정에 대한 요구 충족
• ADR(Active Design Review): 소프트웨어 아키텍처 구성요소 간 응집도 평가
• ARID(Active Reviews for Intermediate Designs): 전제 아키텍처가 아닌 특정 부분에 대한 품질 요소에 집중

▶ 디자인 패턴

소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

▶ 디자인 패턴의 유형

• 목적
  • 생성: 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식 구조화, 캡슐화 수행
  • 구조: 클래스나 객체의 조합을 다루는 패턴
  • 행위: 클래스나 객체들이 상호작용하느 방법과 역할 분담을 다루는 패턴
• 범위: 클래스, 객체

▶ 디자인 패턴  종류

디자인 패턴 유형 => 생성, 구조, 행위

• 생성 => 생빌 프로 팩앱싱
  • Builder: 복잡한 인스턴스를 조립해 만드는 구조, 복합 객체 생성 시 방법 분리, 서로 다른 표현 결과 만들 수 있음
  • Prototype: 처음부터 일반적인 원형을 만들어 놓고, 그것으 복사한 후 필요한 부분만 수정해 사용하는 패턴
  • Factory Method: 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식
  • Abstract Factory: 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공하는 패턴
  • Singleton: 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴
• 구조 => 구 브데 퍼플 프록 컴 어
  • Bridge: 기능의 클래스 계층과 구현의 클래스 계층을 연결, 구현부에서 추상 계층 분리
  • Decorator: 기존에 구현되어 있는 클래스에 필요한 기능 추가해 나감
  • Facade: 복잡한 시스템에 대해 단순한 인터페이스 제공, 시스템 구조에 대한 파악 쉽게
  • Flyweight: 메모리 절약, '클래스 경량화' 목적
  • Proxy: 실체 객체에 대한 대리 객체, 실체 객체를 드러나지 않게 해 정보은닉
  • Composite: 객체들의 관계를 트리구조로 구성, 부분-전체 계층 표현
  • Adapter: 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
• 행위 => 행미인이 템옵 스테 비커 스트 매체
  
  • Mediater: 중간에 통제, 중재자
  • Interpreter: 언어의 다양한 해석, 구문의 해석을 맡는 클래스 각각 작성
  • Iterator: 컬렉션 구현 방법 노출시키지지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공
  • Template Method: 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화, 상위 클래스-추상, 하위 클래스-구체
  • Observer: 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락
  • State: 상태에 따라 다르게 처리할 수 있도록 행위 내용 변경
  • Visitor: 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업 수행
  • Command: 명령이 들어오면 그에 맞는 서브 클래스 선택되어 수행
  • Strategy: 알고리즘 군 정의, 행위를 클래스로 캡슐화해 동적으로 행위 자유롭게 변환
  • Memento: Undo 기능 개발
  • Chain of Responsibility: 정적으로 어떤 기능에 대한 처리의 연결이 하드 코딩되어 있을 때, 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 디자인

▶ 분석 산출물의 종류

=> 현기인 아소하네(각 구성도의 사례를 보여주고 어떤 구성도인지 맞추는 문제가 출제됨)

• 정보시스템 구성 현황
• 정보 시스템 기능 구성도
• 인터페이스 현황
• 현행 시스템 아키텍처 구성도
• 소프트웨어 구성도
• 하드웨어 구성도
• 네트워크 구성도

▶ 운영체제 

컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스 담당

▶ 개발 기술 환경 현행 시스템 분석 시 고려사항

=> 신성 기주구(개발 기술 환경 현행 시스템 분석 시 고려사항 확인하고 넘어가기)

• 신뢰도: 장기간 시스템 운영 시 운영체제의 장애 발생 가능성/운영체제의 버그로 인한 재가동 여부
• 성능: 대규모 및 대량 파익 작업(배치작업) 처리
• 기능: 공급사들의 안정적인 기술 지원/오픈소스여부
• 주변기기: 설치 가능한 하드웨어
• 구축환경: 지원 가능한 하드웨어 비용 등...

▶ 운영체제 종류

윈도우(마이크로소프트), 유닉스, 리눅스(리누스 토발즈), 안드로이드(구글), iOS(애플)

▶ 미들웨어

분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어/대표적인 미들웨어로 WAS(Web Application Server)

* 가비지 컬렉션: 메모리 관리 기법의 하나로, 프로그램이 동적으로 할당했던 메모리 영역 중에서 필요 없게 된 영역을 해제하는 기능이다.

▶DBMS 현행 시스템 분석 시 고려사항

=> 가성호기구

• 가용성
• 성능
• 상호 호환성: JDBC, ODBC
• 기술지원
• 구축비용

 

03 요구사항 확인

▶ 요구공학(Requirements Engineering)

사용자의 요구가 반영된 시스템을 개발하기 위해서 사용자의 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

▶ 기능적 요구사항

시스템이 제공하는 기능, 서비스에 대한 요구사항

- 특성: 기능성, 완전성, 일관성

▶ 비기능적 요구사항 

시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항, 품질, 시스템 환경, 프로젝트 계획에 대하 요구사항

- 특성: 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성, 보안성 및 품질 관련 요구사항, 제약사항

▶요구사항 개발 프로세스

=> 도분명확(요구사항 도출->분석->명세->확인 및 검증)

▶ 요구사항 도출 단계 주요 기법

• 인터뷰, 브레인스토밍, 워크숍, 설문조사
• 델파이 기법: 전문가의 경험지식을 통한 문제 해결 및 미래예측을 위한 방법
• 롤 플레잉: 현실에서 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함.

▶ 요구사항 분석 단계 주요 기법

• 자료 흐름 지향 분석
• 객체 지향 분석

▶ 요구사항 명세 단계 주요 기법

• 비정형 명세 기법: 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 방법
• 정형 명세 기법: 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법

▶ 요구사항 확인 및 검증 단계 주요 기법

• 요구사항 검토
• 정형 기술 검토 활용
  • 동료 검토(Peer Review): 2~3명이 진행, 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견
  • 워크 스루: 회의 전에 검토 자료를 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태
  • 인스펙션: 소프트웨어 요구, 설계, 원시코드 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
• 프로토타이핑 활용
• 모델 검증
• 테스트 케이스 및 테스트를 통한 확인
• CASE 도구 활용 검증
• 베이스라인(baseline)을 통한 검증
• 요구사항 추적표(RTM)을 통한 검증

* 형상통제위원회(CCB;Configuration Control Board): 형상 관리에 대한 주요 방침을 정하고 산출물을 검토하며, 단계별 의사결정을 수행하는 조직

*소프트웨어 개발 프로세스의 시작인 소프트웨어의 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물 => 요구사항 명세서