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

정보처리기사

수제비2024 기출문제집으로 공부하면서 기록

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

1. 소프트웨어 생명주기 모델

1. 소프트웨어 생명주기 모델 프로세스

소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다

2. 소프트웨어 생명주기 모델 프로세스

소프트웨어 개발은 요구사항 수집/분석, 설계, 구현(코딩), 테스트, 유지보수까지 생명주기를 가진다

이 생명주기 동안 최상의 품질을 유지하기 위해서 단계를 나눈 것이 생명주기 모델이다

1. 요구사항 분석
2. 설계
   • 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계
3. 구현(코딩)
4. 테스트
5. 유지보수
   • 시스템이 인수되고 설치된 후 일어나는 모든 활동 단계

3. 소프트웨어 생명주기 모델 종류 [폭프나반]

폭포수 모델은 가장 오래된 모델이다

• 폭포수 모델
  • 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델
  • 요구사항의 변경이 어렵고 각 단계의 결과가 확인되어야 다음 단계로 넘어갈 수 있는 선형 순차적, 고전적 생명주기 모형
• 프로토타이핑 모델
• 나선형 모델
  • 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델

• 반복적 모델

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

2. 소프트웨어 개발 방법론 종류

• 구조적 방법론
  • 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
• 정보공학 방법론
  • 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
• 객체 지향 방법론
  • 객체, 클래스, 메시지를 사용
• 컴포넌트 기반 방법론
• 애자일 방법론
• 제품 계열 방법론

3. 애자일

절차보다는 사람이 중심이 되어 변화에 유연한 신속 적응적 경량 개발 방법론으로 개발 기간이 짧고 최근 회사에서 각광받는 워터폴에 대비되는 방법론

애자일 방법론은 대표적으로 XP, 스크럼, 린 등이 있다

XP(eXtreme Programming)

• 수시로 발생하는 고객의 요구 사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상하는 방법
• 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

XP의 12가지 기본원리

• Pair Programming (짝 프로그래밍)
  • 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성
• Collective Ownership (공동 코드 소유)
  • 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리
• CI (Continuous Integration, 지속적인 통합)
  • 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
• Planning Process (계획 세우기)
  • 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리
• Small Release (소규모 릴리즈)
  • 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리
• Metaphor
  • 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다는 원리
• Simple Design
• TDD (Test Driven Development, 테스트 기반 개발)
  • 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
• Refactoring
  • 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 통해 시스템을 재구성한다는 원리
• 40-Hour work
• On Site Customer (고객 상주)
  • 개발자들의 질문에 즉각 대답해줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
• Coding Standard (코드 표준)
  • 효과적인 공동 작업ㅇ르 위해서는 모든 코딩에 대한 코딩 표준을 정의해야 한다는 원리

스크럼

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

린

• 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론

3. 객체 지향 분석 방법론

4. 객체 지향 설계 원칙(SOLID)

• 단일 책임의 원칙 (SRP; Single Responsibility Principle)
• 개방 폐쇄 원칙 (OCP; Open Close Principle)
• 리스코프 치환의 원칙 (LSP; Liskov Substituition Principle)
• 인터페이스 분리의 원칙 (ISP; Interface Segregation Principle)
  • 객체 설계 시 특정 기능에 대한 인터페이스는 그 기능과 상관없는 부분이 변해도 영향을 받지 않아야 한다는 원칙이다
  • 예를 들어, 복합기에 대한 객체가 있고 프린터, 복사기, 스캐닝 기능을 사용하는 사용자가 각각 있다고 하면 프린터 기능 인터페이스는 복사기나 스캐닝 기능이 변하여도 프린터 기능을 사용하는 데에는 문제가 없어야 한다.
• 의존성 역전의 원칙 (DIP; Dependency Inversion Principle)

6. 객체 지향 분석 방법론 종류

럼바우(Rumbaugh)

• 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론
• 분석 절차는 객체 모델링 -> 동적 모델링 -> 기능 모델링 순서로 진행
• 객체 모델링(Object Modeling)
  • 정보 모델링(Information Modeling)이라고도 한다
  • 가장 중요하고 선행되어야 할 모델링입니다
  • 객체 다이어그램 (객체의 관계)를 표시한다
  • 시스템에서 요구하는 객체를 찾고 객체 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링으로 객체 다이어그램을 활용하여 표현
• 동적 모델링(Dynamic Modeling)
  • 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링으로 상태 다이어그램을 활용하여 표현
• 기능 모델링(Functional Modeling)
  
  • 프로세스들의 자료 흐름을 중심으로 처리 과정으로 표현하는 모델링으로 자료 흐름도(DFD)를 활용하여 표현

2. 프로젝트 관리

2. 비용산정 모형

2. 비용산정 모형 분류

비용산정 모형은 하향식 산정방법과 상향식 산정방법이 있다

하향식 산정방법

• 경험이 많은 전문가에게 비용 산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식
• 종류
  • 전문가 판단
  • 델파이 기법(전문가의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한 기법으로 전문가 합의법이라고도 한다)

3. 비용산정 모형 종류

• LoC 모형
• Man Month 모형
• COCOMO 모형
• 푸트남 모형
• 기능점수(FP; Functional Point) 모형
  • 기능점수 모형은 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식이다
  • 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여한다

3. 일정관리 모델

2. 일정관리 모델 종류

일정관리 모델 종류는 주 공정법, PERT, 중요 연쇄 프로젝트 관리가 있다

• 주 공정법 (CPM; Critical Path Method 임계 경로: 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로이다)
  • 여러 작업들의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
• PERT (Program Evaluation and Review Technique)
  • 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법
• 중요 연쇄 프로젝트 관리

2. 현행 시스템 분석

1.  현행 시스템 파악

3. 소프트웨어 아키텍처

2. 소프트웨어 아키텍처 프레임워크 개념

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

 

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

• 유스케이스 뷰
  • 유스케이스란?
  • 시스템이 액터에게 제공해야 하는 기능으로서 시스템 요구사항이자, 사용자 입장에서 바라본 시스템의 기능이다
  • 행위자(actor)가 관심을 가지고 있는 유용한 일을 달성하기 위한 시나리오의 집합을 명시한다
  • ex. 음료 자판기의 유스케이스: 콜라 사기
  • ex. 음료 자판기의 시나리오: 재고 없음, 금액이 맞지 않음 등
• 논리 뷰
• 프로세스 뷰
  • 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
• 구현 뷰
• 배포 뷰

4. 소프트웨어 아키텍처 패턴

• 계층화 패턴
  • 시스템을 계층으로 구분하여 구성하는 패턴
  • 서로 마주 보는 두 개의 계층 사이에서만 상호 작용이 이루어짐
• 클라이언트-서버 패턴
• 파이프-필터 패턴
  • 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴

• 브로커 패턴
• 모델-뷰-컨트롤러 패턴

5. 소프트웨어 아키텍처 비용 평가 모델 [SACAA(사카)]

SAAM (Software Architechture Analysis Method)

• 변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능한 비용 평가 모델

ATAM

CBAM

ADR

ARID

4. 디자인 패턴

3. 디자인 패턴 유형 [생구행]

• 생성
• 구조
• 행위
  • 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

4. 디자인 패턴 종류

생성 패턴

• Builder
  • 복잡한 인스턴스를 조립하여 만드는 구조로, 복합 객체를 생성할 때 객체를 생성하는 방법과 객체를 구현하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있는 디자인 패턴
• Factory Method
  • 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식으로, 상위 클래스에서는 인스턴스를 만드는 방법만 결정하고, 하위 클래스에서 그 데이터의 생성을 책임지고 조작하는 함수들을 오버라이딩하여 인터페이스와 실제 객체를 생성하는 클래스를 분리할 수 있는 특성을 갖는 디자인 패턴

구조패턴

• Bridge
  • 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 디자인 패턴
• Adapter
  • 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만드는 패턴으로, 상속을 이용하는 클래스 패턴과 위임을 이용하는 인스턴스 패턴의 두 가지 형태로 사용되는 디자인 패턴
  • 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록 타 클래스의 인터페이스를 기존 인터페이스에 덧씌움
• Proxy
  • '실체 객체에 대한 대리 객체'로 실체 객체에 대한 접근 이전에 필요한 행동을 취할 수 있게 만들며, 이 점을 이용해서 미리 할당하지 않아도 상관없는 것들을 실제 이용할 때 할당하게 하여 메모리 용량을 아낄 수 있으며, 실체 객체를 드러나지 않게 하여 정보은닉의 역할도 수행하는 디자인 패턴

행위 패턴 [행 미인이 템옵 스테 비커스트 메체]

길 가던 행인들과 미인이 부추겨서 템포 업이 되어 스테이크를 비커에 넣어 스트레이트로 마시다 싶이 먹어서 매체(메체) 소개되었다

• Template Method
  • 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴
  • 일반적으로 상위클래스에는 추상 메서드를 통해 기능의 골격을 제공하고, 하위 클래스의 메서드에는 세부 처리를 구체화하는 방식으로 사용하여 코드 양을 줄이고 유지보수를 용이하게 만드는 특징을 갖는 디자인 패턴
• Observer
  • 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이 가고 자동으로 내용이 갱신되는 방법으로 일대 다의 의존성을 가지며 상호 작용하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인 패턴
• Strategy
  • 알고리즘 군을 정의하고 같은 알고리즘을 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서로 교환해서 사용할 수 있게 하는 패턴으로, 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 디자인 패턴
• Visitor
  • 각 클래스 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들어 놓고 해당 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 만드는 패턴으로, 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 사용하는 디자인 패턴
  • 객체의 구조는 변경하지 않으면서 새로운 기능(연산)만 따로 추가하거나 확장할 때 사용하는 디자인 패턴

 

2.  요구사항

1. 요구사항 개요

1. 요구공학의 개요

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

 

3. 요구사항의 분류

요구사항은 기능적 요구사항과 비기능적 요구사항으로 분류된다

기능적 요구사항

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

비기능적 요구사항

• 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항

2. 요구공학 프로세스

1. 요구사항 개발 단계 구성

1. 요구사항 도출

• 요구사항 도출 단계는 소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계이다
• 요구사항 도출 단계 주요 기법
  • 인터뷰
    • 이해관계자와 직접 대화를 통해 필요한 정보를 얻는 공식적, 비공식적 정보 수집 방법
  • 브레인스토밍
    • 말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어를 비판없이 수용할 수 있도록 하는 회의
  • 델파이 기법
  • 롤 플레잉
    • 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법
  • 워크숍
  • 설문 조사

2. 요구사항 분석

3. 요구사항 명세

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

요구사항 명세 단계의 산출물로 요구사항 명세서가 있다

4. 요구사항 확인 및 검증 단계

• 동료 검토
• 워크 스루
  • 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화하는 비공식적인 검토 방법
• 인스펙션
  • 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법

 

 

https://cyndi0330.tistory.com/43

[정보처리기사 필기] 1. 소프트웨어 설계