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

1. 요구사항 확인

요구사항 확인 단원은 소프트웨어 개발 방법론, 현행 시스템 분석, 요구사항 확인으로 구성되어 있습니다.

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

시스템의 전 공정을 체계화한 절차

SDLC 모델 종류

• 폭포수 모델 : 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어감, 선형 순차적 모형(고전적 생명주기 모형)
• 프로토타이핑 모델 : 프로토타입을 구현해, 고객의 피드백을 반영하며 만들어 간다
• 나선형 모델 : 위험을 최소화하기 위해 점진적으로 개발
• 반복적 모델 : 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발(SDLC 모델)

소프트웨어 개발방법론

• 구조적 방법론 : 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합 (하향식 방법론) 나씨-슈나이더만 차트 사용(도형식, 제어 논리 구조, 명확한 식별)
• 정보공학 방법론 : 정보시스템 개발에 필요한 관리 절차와 작업 기반을 체계화
• 객체지향 방법론 : 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용
  컴포넌트 기반 방법론(CBD) : 컴포넌트를 조립해 하나의 새로운 응용 프로그램 작성(생산성, 확장성, 재사용)
• 애자일 방법론 : 절차보다는 사람이 중심, 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템 개발
• 제품 계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발, 임베디드에 유용

애자일

XP : 의사소통 개선과 즉각적 피드백
5가지 가치 : 용기, 단순성, 의사소통, 존중, 피드백 (용단의피존)

• 12가지 기본 원리
  • 짝 프로그래밍(Pair Programming) : 개발자 둘이서 짝 코딩
  • 공동 코드 소유(Collective Ownership) : 시스템 코드는 누구든지 언제라도 수정 가능
  • 지속적인 통합(Continuous Integration) : 매일 여러 번씩 SW통합, 빌드 해야함
  • 계획 세우기(Planning Process) :개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려줘야함
  • 작은 릴리즈(Small Release) : 작은 시스템 먼저 만들고 짧은 단위 업데이트
  • 메타포어(Metathor) : 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게
  • 간단한 디자인(Simple Design): 요구사항에 적합한 가장 단순한 시스템 설계
  • 테스트 기반 개발(Test Driven Develop)
  • 리팩토링(Refactoring) : 프로그램의 기능은 바꾸지 않고 중복제거, 단순화 등을 위해 시스템 재구성
  • 40시간 작업 : 40시간 이상 일 X
  • 고객 상주(On Site Customer) : 개발자들의 질문에 대답할 수 있는 고객 풀타임 상주
  • 코드 표준(Coding Standard) : 효과적인 공동 작업을 위해 코딩 표준을 정의

SCRUM : 매일 정해진 시간, 장소에서 짧은 시간의 개발

주요개념

• 백로그(Backlog) : 제품과 프로젝트에 대한 요구사항
• 스프린트(Sprint) : 2~4주의 짧은 개발 기간 반복적 수행
• 스크럼 미팅(Scrum Meeting) : 매일 15분 정도 미팅
• 스크럼 마스터(Scrum Master) : 프로젝트 리더
• 스프린트 회고(Sprint Retrospective) : 스프린트 주기 되돌아보며 규칙 준수 여부, 개선점 확인
• 번 다운 차트(Burn Down Chart)
• LEAN : 도요타, 낭비 요소를 제거하여 품질 향상
  낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

객체 지향 설계 원칙(SOLID)

• 단일 책임의 원칙(SRP : Single Responsibility Principle)
  • 하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다 는 원칙이다.
• 개방 폐쇄 원칙 (OCP : Open Close Principle)
  • 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다는 원칙이다.
• 리스코프 치환의 원칙 (LSP : Liskov Substitution Principle)
  • 서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 한다는 원칙이다.
• 인터페이스 분리의 원칙 (ISP: Interface Segregation Principle)
  • 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙, 객체 설계 시 특정 기능에 대한 인터페이스는 그 기능 과 상관없는 부분이 변해도 영향을 받지 않아야 한다는 원칙이다.
• 의존성 역전의 법칙 (DIP : Dependency Inversion Principle)
  • 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙이다.

럼바우 데이터 모델링

• 객체 모델링(Object Modeling) = 정보 모델링(Information Modeling)
  • 시스템에서 요구하는 객체를 찾고 객체 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링으로 객체 다이어그램을 활용하여 표현
• 동적 모델링(Dynamic Modeling)
  • 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링으로 상태 다이어그램을 활용하여 표현
• 기능 모델링(Functional Modeling)
  • 프로세스들의 자료 흐름을 중심으로 처리 과정을 표현하는 모델링으로 자료 흐름도(DFD)를 활용하여 표현

비용산정 모형

하향식

• 델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법

상향식

• LoC(Lind of Code) : 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정해 예측치를 구해 비용을 산정하는 방식
• Man Month : 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정하는 방식
  • 프로젝트 기간 = man month(LoC/프로그래머 월간 생산성)/프로젝트 인력
• COCOMO : 보헴이 제안, 프로그램 규모에 따른 비용 산정
  • 조직형(Organic Mode) : 5만 라인 이하
  • 반 분리형(Semi-Detached Mode) : 30만 라인 이하
  • 임베디드형(Embedded Mode) : 30만 라인 이상

일정관리 모델

• 주 공정법(CPM) : 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정 계산(임계 경로는 가장 오래 걸리는 경로)
• PERT : 일의 순서를 계획적으로 정리하기 위한 수렴 기법, 비관치, 중간치, 낙관치의 3점 추정방식 이용
• 주 공정 연쇄법(CCPM) : 자원제약사항을 고려해 일정 작성

소프트웨어 아키텍처

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

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

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

  • 유스케이스 뷰 : 유스케이스 또는 아키텍처 도출, 다른 뷰를 검증하는데 사용
  • 논리 뷰 : 시스템의 기능적인 요구사항
  • 프로세스 뷰 : 시스템의 비기능적 요구사항
  • 구현 뷰 : 모듈의 구성을 보여줌
  • 배포 뷰 : 어떻게 배치되는가

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

• 계층화 패턴(Layered)
  • 서로 마주 보는 두 개의 계층 사이에서만 상호작용
• 클라이언트-서버 패턴(Client-Server)
  • 하나의 서버와 다수의 클라이언트
• 파이프-필터 패턴(Pipe-Filter)
  • 데이터 스트림을 생성하고 처리하는 시스템에서 사용가능
  • 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정 반복
• 브로커패턴(Broker)
  • 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 원격 서비스 실행을 통해 상호작용이 가능
• MVC패턴(MVC)
  • 모델(Model) : 핵심 기능, 데이터 보관
  • 뷰(View) : 사용자에게 정보 표시
  • 컨트롤러(Controller) : 사용자로부터 요청 입력 받아 처리

GoF 디자인 패턴

생성 패턴

• Builder
  • 복잡한 인스턴스를 조립해 만드는 구조로, 생성과 표기를 분리해 복잡한 객체를 생성
• Prototype
  • 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정해 사용하는 패턴
• Factory Method
  • 상위 클래스에서 인터페이스 정의, 하위클래스에서 인스턴스 생성
• Abstract Factory
  • 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공
    -> 동일한 주제의 다른 팩토리를 묶음
• Singleton
  • 한 클래스에 한 객체만 존재하도록 제한

구조 패턴

• Adapter
  • 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
• Bridge
  • 기능 계층과 구현 계층을 연결, 구현부에서 추상 계층 분리
• Composite
  • 객체들의 관계를 트리 구조로 구성, 부분-전체 계층을 표현
• Decorator
  • 기존에 구현되어 있는 클래스에 필요한 기능 추가해 나감
• Facade
  • 복잡한 시스템에 대해 단순한 인터페이스 제공, 시스템 구조에 대한 파악 쉽게
• Flyweight
  • 여러개의 '가상 인스턴스'를 제공하여 메모리 절약, '클래스의 경량화' 목적
• Proxy
  • 실체 객체에 대한 대리 객체, 정보 은닉, 메모리 용량 절약

- 행위 패턴

• Mediator
  • 중간에 통제, 중재자에게 모든 걸 요구하여 통신이 빈도수를 줄여줌
• Interpreter
  • 언어의 다양한 해석, 구문의 해석을 맡는 클래스를 각각 작성
• Iterator
  • 복잡 객체의 원소를 순차적으로 접근 가능하게 해줌 / 반복자사용
• Template Method
  • 상위 클래스-추상, 하위 클래스-구체 / 일부 서브클래스 캡슐화
• Observer
  • 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락 / 일대다 의존성, 느슨한 결합
• State
  • 상태에 따라 다르게 처리할 수 있도록 행위 내용 변경
• Visitor
  • 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업 수행
• Command
  • 명령이 들어오면 그에 맞는 서브 클래스 선택되어 실행
• Strategy
  • 알고리즘 군 정의, 행위를 클래스로 캡슐화해 동적으로 행위 자유롭게 교환
• Memento
  • Undo(작업취소, 복원) 요청
• Chain of Responsibility
  • 하드코딩을 동적으로 연결되게 처리