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

 
정보처리기사 수제비 2022 실기 문제집을 요약하며 공부했습니다! 😁 

 

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

 

1-1-1. 소프트웨어 생명 주기

 

📌  생명 주기란

소프트웨어 생명주기(SDLC; Software Development Life Cycle) : 개발 될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때 까지 어떠한 순서를 밟는지에 대한 작업 프로세스
 

📌 생명주기 모델 종류

 - 폭포수모델: 이전 단계를 마무리 지은 후에 다음 단계로 넘어갈 수 있다. 가장 오래된 모델, 선형 순차적 모델, 요구사항 변경이 어렵다.
- 프로토타이핑 모델: 고객이 요구한 주요 기능을 프로토타입으로 구현하여 피드백을 반영해가며 소프트웨어를 만들어나감
- 나선형 모델: 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
- 반복적 모델: 구축 대상을 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 모델, 제품 일부분을 반복적 개발
 

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

 

📌 개발 방법론 종류

 - 구조적 방법론(Structured Development): 전체 시스템을 기능에 따라 나누어 개발, 이를 통합하는 분할과 정복 접근 방식. 정형화된 분석 절차에 따른다. 나씨-슈나이더만 차트 사용
- 정보공학 방법론(Information Engineering Development): 정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화 함. 대규모 프로젝트 구축에 적합
- 객체 지향 방법론(Object-Oriented Development) : 객체라는 기본 단위로 시스템을 분석 및 설계. 객체/클래스/메시지를 사용
- 컴포넌트 기반 방법론(Component Based Development ; CBD): 컴포넌트를 조립해서 하나의 새로운 응용프로그램 작성. 확장성 및 재사용에 좋음. 개발 기간 단축
- 애자일 방법론(Agile Development): 절차보다는 사람이 중심. 변화에 유연하고 신속하게 적응 -> 신속 적응적 경량 개발 방법론
- 제품 계열 방법론(Product Line Development): 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론. 임베디드 소프트웨어를 작성하는데 유용
 

📌 애자일(Agile)의 개념 및 유형

- 기존 개발 방법론의 한계를 극복하기 위해 등장 -> 신속한 대응 및 빠르고 효율적인 개발 방법론의 필요성
- XP, 린(Lean), 스크럼(Scrum)

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

---

✏️ 스크럼: 매일 정해진 시간, 장소에서의 짧은 시간의 개발

• 주요 개념
  • 백로그(요구사항), 스프린트, 스크럼 미팅, 스크럼 마스터, 스프린트 회고, 번 다운 차트(남아있는 백로그 대비 시간을 그래픽으로 표현한 차트)

---

✏️ 린(Lean) : 도요타의 린 시스템 품질 기법. 낭비 요소를 제거하여 품질 향상(JIT, 칸반 보드 사용) 
 
 

1-1-3.  비용산정, 일정 관리 모형

📌 비용 산정 모형

 - 상향식 선정방법(전문가 판단, 델파이 기법), 하향식 선정방법(코드라인수 LoC, Man Month, COCOMO, 푸트남 모형, 기능점수(FP))

• ✏️ LoC(Lines of Code): 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
  
  •  예측치 = (a + 4b + b)/6, a: 낙관치, b:비관치, m: 기대치(중간치)
  • 비관치: 가장 많이 측정된 코드 라인 수, 중간치: 측정된 모든 코드 라인수의 평균, 낙관치: 가장 적게 측정된 코드 라인 수
• ✏️ Man Month: 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정
  • Man Month = LoC / 프로그래머의 월간 생산성
  • 프로젝트 기간 = Man Month / 프로젝트 인력 
• ✏️ COCOMO:  보헴이 제시한 모델로 프로그램 규모에 따라 비용을 산정
  •  조직형(Organic Mode): 중소 규모의 소프트웨어로 일괄 자료 처리나 과학 기술 계산용, 비즈니스자료 처리용으로 5만(50KDSI)라인 이하의 소프트웨어 개발
  • 반분리형(Semi-Detached Mode): 조직형과 임베디드의 중간형, 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만(300KDSI)라인 이하의 소프트웨어를 개발
  • 임베디드(Embedded Mode): 최대형 규모의 트랜잭션 처리 시스템이나 운영체제 등의 30만(300KDSI)라인 이상 소프트웨어를 개발
• ✏️푸트남(Putnam): 개발주기의 단계별로 요구할 인력의 분포를 가정해주는 모형. 생명주기 예측 모형. Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
• ✏️기능점수(FP 모형): 요구 기능을 증가시키는 인자별로 가중치 부여. 요인별 가중치를 합산하여 총 기능의 점수 계산

 

📌 일정 관리 모델

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

• 주 공정법: 노드와 노드간의 연결을 통해 공정을 계산하는 액티비티 표기법
• PERT(Program Evaluation and Review Technique): 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리
• 중요 연쇄 프로젝트 관리(CCPM: Critical Chain Project Management): 주 공정 연쇄법으로 자원제약사항을 고려하여 일정 작성

 
 

---

 

1-2 현행 시스템 분석

 

1-2-1. 현행 시스템 파악

📌 현행 시스템 파악 절차

1. 구성/기능/인터페이스 파악
2. 아키텍쳐 및 소프트웨어 구성 파악
3. 하드웨어 및 네트워크 구성 파악

 

📌 소프트웨어 아키텍쳐

- 여러가지 소프트웨어의 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소간의 관계를 표현하는 시스템의 구조나 구조체
- 소프트웨어 아키텍처 4+1뷰: 고객 요구사항 시나리오를 4개의 관점에서 바라보는 접근 방법
   => 논리뷰(기능 요구사항), 구현뷰(모듈의 구성), 프로세스뷰(비기능적인 속성), 배포뷰(배치) + 유스케이스 뷰(사용자 관점)
 

📌 소프트웨어 아키텍쳐 패턴

• 계층화 패턴 : 시스템을 계층(Layer)으로 구분하여 구성하는 패턴, 마주보는 두개의 계층 사이에서만 상호작용
• 클라이언트-서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성된 패턴
• 파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴. 확장과 재사용에 좋음
• 브로커 패턴 : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포넌트들은 원격 서비스 실행을 통해 상호작용이 가능한 패턴 -> 컴포넌트간의 통신을 조정하는 역할 수행
• 모델-뷰-컨트롤러 패턴 : MVC 패턴이라고도 하고 모델(핵심 기능, 데이터 보관), 뷰(정보 표시), 컨트롤러(요청 처리) 3개의 서브 시스템으로 구조화하는 패턴, 별도의 컴포넌트로 분리되어 있어서 서로 영향을 받지 않고 개발 작업 수행

 

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

 

• SAAM(Software Architecture Analysis Method) : 변경 용이성과 기능성에 집중, 평가 용이. 경험이 없는 조직에서도 활용 가능한 비용 평가 모델 -> 단순 비용 평가 모델
• ATTM(Architecture Trade-off Analysis Method): 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델
• CBAM(Cost Benefit Analysis Model): ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족시키는 비용 평가 모델
• ADR(Active Design Review): 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델
• ARID(Active Reviews for Intermediate Designs): 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델

 

📌 디자인 패턴

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

📌 디자인 패턴 유형

• 목적: 생성, 구조, 행위
• 범위: 클래스, 객체

📌 디자인 패턴 종류 ⭐️⭐️

 1. 생성패턴 -> 객체 인스턴스 생성에 관여

• Builder: 복잡한 인스턴스를 조립하여 만드는 구조로, 복합 객체를 생성할 때 객체를 생성하는 방법과 객체를 구현하는 방법을 분리함 으로써 동일한 생성절차에서 서로 다른 표현 결과를 만들 수 있다.
• Prototype:  처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용하는 패턴으로, 생성할 객체의 원형을 제공하는 인스턴스에서 생성할 객체들의 타입이 결정되도록 설정
• Factory Method:  상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식으로, 상위 클래스에서는 인스턴스를 만드는 방법만 결정하고, 하위 클래스에서 오버로딩하여 생성한다.
• Abstract Method:  구체적인 클래스에 의존하지 않고 서로 연관된 객체들의 조합을 만드는 인터페이스를 제공하는 패턴이며 사용자들에게 인터페이스를 제공하고 구체적인 구현은 Concrete Product 클래스에서 이루어지는 특징을 갖는 디자인 패턴
• Singleton: 전역 변수를 사용하지 않고 객체를 하나만 생성하고, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴. 한 클래스에 한 객체만 존재

 

 2. 구조패턴 -> 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴

• Bridge: 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상계층을 분리하여 추상화 된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 디자인 패턴
• Decorator: 기존에 구현되어있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴
• Facade: 복잡한 시스템에 대해 단순한 인터페이스를 제공, 시스템 간의 결합도 낮춤
• Flyweight: 다수의 객체로 생성될 경우 모두가 갖는 본질적인 요소를 클래스화 하고 클래스 경량화목적
• Proxy: 실제 객체에 대한 대리 객체로 실체 객체에 대한 접근 이전에 필요한 행동을 취할 수 있게 만들어 정보 은닉의 역할 수행
• Composite: 객체들의 관계를 트리구조로 구성하여 부분-전체 계층을 표현하는 패턴. 복합개체와 단일 객체를 동일하게 취급
• Adapter: 기존에 생성된 클래스를 재사용할 수 잇도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만드는 패턴

 

 2. 행위 패턴 -> 클래스나, 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

• Mediator:  느스한 결합을 유지하기 위해 중간에 이를 통제하고 지시할 수 있는 역할을 하는 중재자를 두어 객체 지향의 목표를 달성하게 해주는 디자인 패턴
• Interpreter: 언어의 다양한 해석, 구체적으로 구문을 나누고 그 분리된 구문의 해석을 맡는 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할 수 있게 만드는 디자인 패턴
• Iterator: 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공하는 디자인 패턴
• Template Method: 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴. 상위 클래스(추상 클래스)에는 추상 메서드를 통해 기능의 골격 제공, 하위 클래스(구체 클래스)의 메서드에는 세부 처리를 구체화하는 방법
• Observer: 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이 가고 자동으로 내용이 갱신
• State: 객체 상태를 캡슐화하여 클래스 함으로써 그것을 참조하게 하는 방식으로 상태에 따라 다르게 처리할 수 있도록 함. 객체의 상태에 따라 행위 내용을 변경
• Visitor: 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들어놓고, 해당 클래스의 메소드가 각 클래스를 돌아다니며 특정 작업을 수행
• Command: 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행
• Strategy: 알고리즘을 정의하고 캡슐화하여, 필요할 때 서로 교환해서 사용할 수 있게 하는 패턴
• Memento: 객체의 정보를 저장할 수 있을때 적용하는 패턴, Undo 기능(작업 취소)을 개발할때 사용하는 디자인 패턴
• Chain of Responsibility: 정적으로 연결되어 있을 때 하드코딩 되어 연결변경이 불가능 한데, 이것을 동적으로 연결되어 있는 경우에 따라 다르게 처리되게 함

 

---

 

1-3 요구사항 확인

1-3-1. 요구사항

 

📌 요구사항 개념 및 분류

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

• 기능적 요구사항: 시스템이 제공하는 기능, 서비스에 대한 요구사항
  • 기능성, 완전성, 일관성
• 비기능적 요구사항: 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 대한 요구사항(품질, 성능 등)
  • 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항

📌 요구사항 개발 프로세스

1. 도출(Elicitation): 소프트웨어가 해결해야 할 문제를 이해하고, 고객이 제시한 추상적 요구에 대한 관련 정보를 식별, 수집, 구체적으로 표현하는 단계
   ✏️ 도출 단계 기법 
   1. 인터뷰: 이해 관계자와 직접 대화를 통해 도출
   2. 브레인스토밍: 말하기 편한 분위기를 만들어서 참석자들의 아이디어를 비판없이 수용하는 회의
   3. 델파이 기법: 전문가의 경험적 지식을 통한 문제 해결 및 미래예측
   4. 롤 플레잉: 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항 분석 및 수집
   5. 워크숍: 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보 획득
   6. 설문조사: 설문지 또는 여론조사를 이용해 간접적으로 정보 수집
2. 분석(Analysis): 추출된 요구사항에 대해 충돌, 중복, 누락등의 분석을 통해 완전성과 일관성을 확보하는 단계
   ✏️ 분석 단계 기법
   1. 자료흐름지향분석:  데이터 흐름도 및 자료 사전으로부터 소프트웨어 구조를 유도하는 방법
   2. 객체 지향 분석: 시스템의 기능과 데이터를 함께 분석, UML로 표준화
3. 명세(Specification): 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계 -> 요구사항 명세서가 산출된다.
   ✏️ 명세 단계 기법
   1. 비정형 명세기법: 사용자의 요구를 자연어로 표기하는 기법
   2. 정형 명세기법: 사용자의 요구를 수학적인 원리와 표기법으로 서술하는 기법

       ✏️ 명세 원리 및 검증 항목

1. 명확성: 요구사항 명세 내용은 하나의 의미만 부여해야 한다.
2. 완전성: 기능, 성능, 속성, 인터페이스, 설계 제약 등에 관한 모든 시스템 요구사항이 포함되어야 한다.
3. 검증 가능성: 요구사항 충족 여부와 달성 정도 확인 가능해야한다.
4. 일관성: 요구사항 내용 간 상호 모순이 없어야 한다.
5. 수정 용이성: 요구사항 변경 시 쉽게 수정 가능 해야 한다.
6. 추적 가능성: 요구사항 근거에 대한 추적과 상호참조가 가능해야한다.
7. 개발 후 이용성: 시스템 개발 후 운영 및 유지보수에 효과적이어야 한다.

4. 확인(Validation): 요구사항 명세서에 사용자의 요구가 올바르게 기술 되었는지 검토, 베이스라인을 설정한다.
  ✏️주요 기법
 정형 기술 검토

• 동료검토:  2-3명이 진행. 요구사항 명세서 작성자가 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함 발견
• 워크스루: 검토 자료를 회의 전에 배포해서 사전 검토한 후, 짧은 시간 동안 회의를 진행하는 형태
• 인스펙션: 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적인 검토 방법