[정보처리기사]기사따기14일차_4과목_소프트웨어공학_2_190208

# 최초 등록일 : 2024년 12월 31일 17:22

# 최근 변경일 : 2024년 12월 31일 17:22

# 내용 : 정보처리기사 필기 4과목 공부 후 정리한 내용 올리기

 

이전 기사따기13일차는 아래에 링크로!!

[정보처리기사]기사따기13일차_4과목_소프트웨어공학_1_190207

 

이건 많이 언급되는 단어

이건 내가 궁금한거 쳐봐서 나온 결과

 

------------------------------------------------------------------------------------------------------------------------------

 

프로젝트 계획

 

프로젝트 계획 수립

1) 프로젝트 규모 파악 : 개발 기간을 추정, 개발 노력을 추정, 참여 인원 추정

2) 프로젝트 계획의 목표 : 위험성을 최소화, 일정에 대한 최적의 방법, 소프트웨어의 품질을 향상, 모든 자원을 준비

3) 프로젝트 계획 단계의 특징 : 정의 단계, 개발 비용을 추정, 유지보수 비용은 개발이 모두 끝난 후

4) 외주 개발을 위한 제안서 평가 항목 : 개발자의 기술력, 가격의 타당성, 사용자의 지원 능력

 

범위(영역, Range, Scope) 측정

1) 범위 측정의 이해 : 기능에는 입력 기능, 출력 기능, 통신 기능 등의 범위를 말하며 성능에는 처리 시간, 처리 용량 등을 말한다.

2) 범위 결정의 주요 요소

 - 처리 기능 : 입출력 기능, 인터페이스 기능, 통신 기능,데이터베이스 기능

 - 성능 : 처리 시간, 처리 용량, 신뢰도 등의 범위

 - 제약조건 : 메모리 제한, 기능 제한, 사용자 수 제한 등의 범위

 - 개발 인원 : 개발 조직 측정, 선임(고급) 기술진, 하급 기술진 인원 수 파악

 - 일정 계획 : 개발 기간의 한계, 소프트웨어 사용 시기 등의 범위

 

자원(Resource) 측정

1) 하드웨어 자원

 - 개발 시스템(호스트 시스템) : 컴퓨터와 관련 주변 장치로 소프트웨어를 개발하는 곳에서 사용될 시스템

 - 목표 시스템(목표 기계) : 관련된 주변 장치로 실제로 설치되어 사용되는 시스템

 - 개발 지원 시스템 : 검사 등의 확인을 위해 일시적으로 필요한 시스템

 

2) 소프트웨어 자원 : 어떤 도구를 선택할 것인가 계쐭

 - CASE : Computer Aided Software Engineering는 소프트웨어의 생명주기 전반을 지원하는 프로그램 또는 소프트웨어 개발을 지원하는

               자동화 도구 혹은 방법론의 결합이다.

 - CASE의 분류

  * 상위 CASE : 요구분석과 설계를 지원하며, 명세서와 문서를 작성. PSL/PSA, SREM, SYSREM, FOUNDATION 등이 있다.

  * 하위 CASE : 코드 작성(구현), 검사(테스트)를 지원

  * 통합 CASE : 공통의 정보 저장소와 통일된 사용자 인터페이스를 사용하여 도구들을 통합한다.

 

 - CASE의 특징 : 생산성을 증대시키고자 하는 목적, 일관된 방법론, 개발의 표준화를 지향, 개발 비용이 절감, 툴 가격은 비쌈

                        수정이 용이하고 정확, 속도를 향상, 유지보수를 용이하게 함, 생산성 문제 해결, 모듈의 재사용성, 품질 향상

                        툴 들간의 호환성은 없음. 재사용성을 향상, 자동화, 분석가의 지원이 반드시 필요

 - CASE 도구의 정보 저장소 : Repository라고 하며 통신과 소프트웨어 시스템 정보의 공유를 향상, 운영체제가 현재 담당하며

                                          정보 저장소는 재사용성의 기본임, 시스템 구성 요소들과 시스템 정보가 정보 저장소에 의해 관리

 

3) 인적 자원

 - 소프트웨어 개발 자원

  * 관리자 : 실무자를 관리하는 사람

  * 선임 기술진 : 모든 단계에서 활발히 참여

  * 하급 기술진 : 구현 단계에 주력

  * 요구분석가 : 과정에서 책임을 지고 주도적인 역할을 담당하는 컴퓨터 전문가

 

4) 소프트웨어 개발 팀 구성

 - 책임 프로그래머 팀 : Chief Programmer Team은 팀장이 모든 개발 인적 자원들의 지원을 받는 형태로 규모가 작은

                                소프트웨어를 개발하기에 적합한 조직이다

 - 민주주의식 팀 : Democratic Team은 대상을 분리하여 각자 개발한 후 통합하기 전에 전체 회의를 통하여 소프트웨어를 완성하는

                         형태의 조직, 규모가 크고 장기적인 프로젝트를 개발할 때 적합한 조직, 이직률을 낮춘다.

 - 혼합형 팀 : Hierarchical Structure Team은 위 두 방법을 혼합한 방법, 경험자는 초보자에게 작업의 지시를 하며 초보자는

                   지시에 따라 작업하고 경험자에게 보고, 유기적인 관계를 갖는다.

 

소프트웨어 비용 측정

1) 소프트웨어 비용 측정에 이해 : 소프트웨어 측정은 주관적인 관점이 개입되는 요소가 많기 때문에 비용 측정 어려움

2) 개발 비용과 개발 기간의 상관관계

 

3) 비용 측정의 4가지 원칙

 - 소프트웨어 비용 측정을 최대한 지연시킨다.

 - 분해 기술1을 이용한다.

 - 실험적 비용 측정 모델을 이용한다.

 - 자동화 도구를 이용한다.

 

4) 비용 측정 요소(개발 비용 결정 시 영향을 주는 요소)

 - 직접 측정 요소 : 인월, 라인 수, 오류 수, 투입 인원, 처리 속도, 문서 수 등이 있다.

 - 간접 측정 요소 : 생산성, 품질, 기능 점수, 문서화 비율, 효율성, 신뢰도, 유지보수성 등이 있다.

 

5) 소프트웨어 생산성(Productivity) : 소프트웨어 개발 과정의 효율성을 뜻함

 - 프로그래머 능력 : 프로그래머의 개발 능력은 대부분 경험이 바탕

 - 조직(개발 팀) 간의 상호 작용 : 규모가 커질수족 조직이 비대해지고 복잡

 - 개발 제품의 복잡도 : 복잡도가 큰 소프트웨어 개발, 직접적인 영향을 주게 된다.

 - 기술 수준 : 재사용할 부품을 발취하는 개술들이 생산성을 높여준다.

 - 관리 기술 : 관리 기술은 가장 폭넓게 적용

 - 요구되는 신뢰도 : 새롭게 개발되는 소프트웨어에 신뢰성이 있는 모듈을 많이 이식할수록 검사 노력이 줄고 생산성이 증가

 

6) 인월 : 임의의 프로젝트르 한 사람 기준으로 몇 개월에 개발할 수 있는 양인가를 측정

7) 비용 측정 요소를 구하는 공식

 - 생산성 = KLOC/인월

 - 품질 = 오류의수/KLOC

 - 문서화 비율 = 문서 페이지 수/KLOC

 - 비용 = 인월 * 단위 비용

 - 개발 기간 = 인월/투입 인원

 

비용 측정 방법론

1) 방법론의 분류

 

 - 하향식 방법 : 프로젝트의 총 비용을 측정한 후 단계별로 비용을 세분화하는 방법

 - 상향식 방법 : 프로젝트의 총 비용을 맨 마지막에 측정하고 단계별로 측정한 결과들을 모아서 총 비용을 측정하는 방법

 

2) 전문가 측정 방법(Expert Judgement) : 경험이 많은 전문적인 비용 측정가에게 의뢰

3) 델파이(Delphi) 측정 방법 : 전문가의 의견을 종합하여 측정하는 방법

4) 원시 코드 라인 수 측정 : 라인 수를 측정

5) 개발 단계별 인월 수 방법 : 라인 수의 가중치나 개발자들의 능력 차이를 단계별로 비용 측정에 적용

6) Walston Felix 모형 : 비용 측정 자료를 모아 통계적으로 분석한 공식으로 개발 비용을 측정하는 방법

7) COCOMO(COnstuctive COst MOdel) 방법 : 소프트웨어의 종류에 따라 다르게 책정되는 비용 산정 방정식을 이용하는 합리적인 방식

                                                                 으로 Boehm이 제시한 원시 프로그램의 규모에 의한 비용 예측 모형

 - Base COCOMO의 비용 산정 방식

  * 유기형 : 5만 라인 이하의 소프트웨어 평가

  * 준 분리형 : 30만 라인 이하의 소프트웨어 평가

  * 내재형(Embedded) : 최대형 규모의 트랜잭션 시스템이나 운영체제 등의 소프트웨어

 

8) Putnam 모형 : 시간의 따른 함수로 표현, 대형 프로젝트의 노력분포 산정에 용이, 자동화 추정 도구는 SLIM

                        개발 기간 등의 비용 측정값을 입력하면 소프트웨어 비용 산출을 자동으로 출력

9) Albrecht 모형 : 프로젝트를 기능별로 분석, 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치 부여

                          가중치를 모두 합한 총 기능 점수 구함, 프로젝트의 특성에 따른 영향도 평가, 실질 기능 점수 계산

                          실질 기능 점수와 1 : 1로 이미 책정된 실질 기능 점수에 따른 비용을 검색하여 최동 비용을 산출

 

프로젝트 관리

 

프로젝트 관리 대상(3P)

1) 사람(People)

2) 문제(Problem) : 프로젝트를 계획하기 전에 프로세스의 목적과 영역이 설정

3) 프로세스(Process) : 전체 흐름

 

일정 계획 방법론

1) PERT : Program Evaluation and Review Technique는 시작부터 종료까지의 모든 단계를 원, 직선, 화살표를 이용하여 전체 공정의

              흐름을 일목요연하게 표시하여 파악하는 방법

2) CPM : Critical Path Method는 주 공정에 비중을 둔다. 흐름이 지연되면 다른 공정은 모두 지연시켜 주 공정이 완전히 해소되면 진행

 - CPM을 이용한 일정계획 순서

  1. 프로젝트의 규모를 추정함

  2. 각 단계에 필요한 작업들을 분해한다.

  3. 각 작업의 상호 의존 관계를 CPM 네트워크로 나타낸다.

  4. 일정 계획을 간트 차트로 나타낸다.

 

 - CPM의 세부 네트워크 : 최장 경로를 파악, 작업 사이의 전후 의존 관계 나타냄, 노드에 예상 완료 시간 표시, 완료되지 않으면 다음

                                    작업으로 진행 불가, 자원 할당 가능, 다른 일정 계획안을 시뮬레이션 가능, 비용 측정 안함! 일정 예측 불가

 

 - 간트 차트 : Gantt Chart는 일정 계획 방법론인 도구를 이용하여 그려진 일정 흐름을 보고 단계별로 일정들을 표시하는 이정표

 

 

 - PERT와 CPM에서 제공되는 항목

  * 임계 경로, 단계별 시작 시기, 소요 기간, 경계 기간, 상호관련성

 

3) WBS : Work Breakdown Structure는 모든 개발 단계를 서로 연관된 소 작업으로 분류하고 이들의 시작부터 끝나는 시점까지의 관계를

             분석하여 개발 기간 및 개발 비용을 측정하는 방법

 

소프트웨어 형상 관리(SCM : Software Configuration Management)

1) 형상 관리의 이해 : 전체 소프트웨어 프로세스에 적용되는 프로세스의 보호 활동, 대부분 유지보수 단계에서 실행

2) 형상 관리 정의 : Configuration Management의 정의는 컴퓨터 소프트웨어 생명주기 전체의 변경을 관리하는 활동들의 집합

3) 형상 관리의 목적 : 전체 비용이 최소화 소프트웨어의 현 사용자에게 방해가 최소한으로 야기되도록 보증

4) 형상 관리의 활동 : 변경을 알아내기 위해서, 사항을 관리하기 위해서, 적절하게 구현되었는지 확인, 사항을 보고하기 위해서 활동

5) 형상 관리 프로세스 : 식별(Identification), 버전 관리(Version Control), 변경 관리(Change Control)

                                 형상 감사(Configuration Auditing), 보고(Reporting)

6) 형상 관리 목표물(관리 항목) : 개발 비용은 변경사항을 관리하는 형상 관리 항목으로 정할 수 없다.

 - 정의 단계의 문서 : 시스템 분석서, 프로젝트 계획 문서, 요구분석서 등

 - 개발 단계의 문서 : 설계 분석서, 외부 설계서, 내부 설계서, 소스 코드, 검사 계획서 등

 - 유지보수 단계의 변경 사항 : 유지보수 계획서, 소스 프로그램 보고서, 유지보수 활동서, 기술 별경 사항 등

 

소프트웨어의 위험 관리(Risk Management)

1) 위험 관리의 이해 : 프로젝트 추진 과정에서 예상되는 각종 돌발 상황을 미리 예상하고 이에 대한 적절한 대책을 수립하는 일련의 활동

2) 위험의 특성 

 - 불확실성 : Uncertainty는 발생하지 않을 수도 있다.

 - 손실 : Loss는 원하지 않는 결과나 손실이 발생하는 것이다.

 

3) 위험 관리 절차

 - 위험 식별 : 위험 요소가 될 사항들을 파악

 - 위험 분석 및 평가 : 위험의 비중과 영향력을 파악

 - 위험 관리 계획 : 예방하고 발생 시 대안들을 준비하고 문서화

 - 위험 감시 및 조치 : 항상 관찰하고, 발생 시 조치

 

4) 위험의 범주

 - 프로젝트 위험(Project Risk), 기술 위험(Technical Risk), 비즈니스 위험(Business Risk), 알려진 위험(Known Risk)

    예측 가능한 위험(Predictable Risk), 예측 불가능한 위험(Unpredictable Risk)

 

5) 예측 가능한 위험 항목의 체크 리스트 : 프로덕트 사이즈, 비즈니스 영향, 고객 특성, 프로세스 정의, 개발 환경, 구축 기술, 기술진들

6) 위험 투영 : Risk Projection은 파악하고 위험이 발생되었을 때 결과를 추정하는 활동

 - 위험 모니터링 : 위험 요소 징후들에 대하여 계속적으로 인지하는 것

 - 4가지 위험 투영 활동 : 인지될 확률을 반영하는 평가의 기준, 발생되었을 때의 결과와 영향을 예측 및 추정, 비교 분석

 - 위험표 개발 항목 : 위험의 내용, 위험의 종류, 발생 확률, 따르는 영향력, 위험 완화, 감시, 관리

 

요구분석 

 

요구분석

1) 요구분석의 이해 : 개발 요청자의 하드웨어나 소프트웨어에 대한 외부적 요구를 받아들여 개발하고자 하는 소프트웨어의 특성을 기술

2) 요구분석의 목적 : 개발자 간의 의사 교환, 설계 및 개발에 필요한 기본적 자료 제공, 외적인 기능을 기술하는 단계, 운영상의 계약

3) 요구분석 단계의 특징 : 프로젝트를 이해할 수 있는 개발의 실질적인 첫 단계, 목표를 명확히 도출, 사용자가 처음으로 참여,

                                   전문 인력을 가장 필요로함, 자연 언어2로 작성, 판단 및 제어 구조가 포함되어서는 안됨

4) 요구분석가의 능력 : 여러 가지 면에 해박한 지식을 갖고 개발 요청자가 원하는 사항이 무엇인지를 정확히 파악할 수 있는 능력

 

요구분석의 순서 및 문제점

1) 요구분석의 일반적 순서

 Needs 분석(체계적으로 정리) -> 개발자 준비 분석(사용자에게 질문하여 요구를 받아들임) -> 자료 흐름도 DFD 작성(자료의 흐름을

 그림) -> 자료 사전 DD 작성(구분된 자료를 체계적으로 정리) -> 소단위 명세서 Mini-Spec 작성(흐름도 처리를 간략하게 서술) ->

 요구 명세화(요구분석에 대한 모든 내용을 문서화)

 

2) 요구분석의 문제점

 - 대화의 장벽 : 개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호 이해가 쉽지 않다.

 - 소프트웨어의 복잡성 : 여러 명의 요구 분석자 조직을 구성

 - 요구의 변화 : 개발 요청자의 요구가 일관성없이 요구되거나 계속적으로 번복될 때에는 시간이나 비용의 엄청난 손실을 보게 된다.

 - 요구 명세화의 어려움 : 개발하고자 하는 시스템 자체가 복잡

 - 요구 명세화의 기본 조건 : 설계와 개발 과정에 도움, 품질 평가 기준, 자연 언어 작성, 최소의 정보만 포함, 일관성, 확장 가능

 - 요구분석에 대한 인식 부족 : 개발 요청자가 요구분석 자체의 중요성을 이해하지 못할 경우 적극성이 결어됨

 - 방법론 부족 : 사용자의 요구사항은 일률적이지 않고 다양

 

3) 요구분석 기법 : 사용자의 면접, 현재 사용 중인 각종 문서 검토, 설문 조사, 직접 사용자의 업무를 체험

4) 요구분석 실패의 결과 : 개발 요청자의 요구사항이 현실적으로 어렵거나 낙후되어 있는 내용들이어도 개발자는 개발에 어려운 부분을

                                    개발 요청자에게 이해가 되도록 충분히 설명하고 문서화 해야 한다.

 

구조적 분석

1) 기본 모형 3가지 : 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec)

2) 구조적 분석의 세부 작업 순서

 1. 배경도 작성 : 대략적인 그림으로 추상적인 개관만을 그림

 2. 상위 자료 흐름도 작성 : 기본 모형

 3. 하위 자료 흐름도 작성 : 하향식으로 자료 흐름도를 상세화

 4. 자료 사전 작성 : 자료를 구체적으로 정리

 5. 소단위 명세서 작성 : 자료 흐름도의 부족한 부분을 간략하게 서술

 

자료 흐름도(DFD : Data Flow Diagram)

1) 자료 흐름도의 이해 : 자료가 소프트웨어 내의 각 절차를 따라 흐르면서 변하는 과정을 도형화시키는 방법

2) 자료 흐름도의 표기법

구성 요소	Yourdon의 표기법(모양)	의미
외부 입출력  (Externalentty)	직사각형	입력, 출력, Enitty, 터미널, 생산자, 소비자, 단말, 도착지, 생성지,  키보드, 모니터 등
처리 과정  (Process)	원	버블(Bubble), 모듈, 함수, 처리, 단위 프로그램, 프로시저, 프로세스,  서브 루틴, 기능, 변환, 검색, 소트 등
자료 흐름  (Data Flow)	화살표	전달, 매개 변수, 메시지, 인터페이스, 흐름
자료 저장소  (Data Stone)	두 줄	저장소, Save, 디스크, 파일 데이터베이스, 테이블

 

 

3) 자료 흐름도의 작성 방법 : 4가지 기본 기호로 표시, 입력 자료가 존재해야 함, 자료 흐름은 서로 일치, 종착지는 원으로 표시,

                                       최하위 처리는 소단위 명세서를 갖는다, 개별적으로 상세화, 자료 보존 법칙을 준수, 한 페이지 단위로 그림

                                       페이지당 2~3단계가 적당, 맨 마지가 처리는 프로그램이 가능한 수준으로 상세화

4) DFD의 세분화 : DFD는 요구분석이 진행되는 동안 점차 2~3단계로 증가하면서 자세히 기술, 각 단계에서 한 개의 버블이 상세 분석되면

                         또다시 세분화된 DFD가 생성

 

자료사전(DD : Data Dictionary)

1) 자료 사전의 이해 : 자료 흐름도의 대상이 되는 자료의 내용을 구체적으로 명시한 것, 파일의 레코드를 설계하기 쉽게 표현한 문서,

2) 자료 사전 표기법

표기법	Yourdon의 표기법(모양)	의미
=	자료의 정의 (Data Define)	다음과 같이 구성
+	자료의 연결 (Data Sequence)	~과 AND
[ | ]	자료의 선택 (Data Selection)	~중 혹은 OR
{ }	자료의 반복 (Data Repeat)	반복
( )	자료의 생략	생략될 수 있는 자료
**	자료의 설명(Data Comment)	설명부

 

 

소단위 명세서(Mini-Spec)

 - 자료 흐름도에서 각 버블이 수행할 기능을 자연 언어로 간단하게 작성하는 작업, 논리적 절차를 포함하기도 한다.

 

요구분석용 자동화 도구(CASE)

1) SADT : Structure Analysis & Design Technique는 요구분석과 설계 분석, 설계 명세서를 동시에 표현할 수 있는 수동적 도구

 

2) BS(Brain Storming)의 4가지 규칙 : 비판 금지, 자유분방, 다수 환영, 연쇄 개선

3) PSL/PSA : Program Statement Language/ Program Statement Analysis는 요구분석에 필요한 내용을 PSL이란 기술 언어를 사용하여

                  작성한 뒤 PSA에 입력하면 PSA는 분석 데이터베이스에 저장하고 있는 자료를 분석하여 최적의 요구 명세서를 자동으로 출력

4) SREM, RSL/REVS : Software Requirement Engineering Methodology는 실시간 시스템용 요구분석 방법론 및 자동화 도구