[ 정보처리기사 - 필기 요점 ] 4. 소프트웨어 공학

소프트웨어 공학 요점 정리

  ) -->   

■ 소프트웨어 위기 발생 요인

 ① 유지 보수 어려움에 따른 엄청난 비용

 ② 개발 기간의 지연 및 개발 비용의 증가

 ③ 성능 및 신뢰성의 부족

  ) -->   

■ 소프트웨어 생명주기(Life cycle)

 1) 폭포수 모형(Waterful Model)

 -앞 단계가 끝나야만 다음 단계로 넘어갈 수 있다.

 -각 단계가 끝난 후 결과물이 명확히 정의되어야 한다.

 -새로운 요구나 경험을 설계 중간에 반영하기 힘들다.

 -적용 사례가 많다.

 -각 단계의 병렬 수행이 불가능하다.

 -제품의 일부가 될 매뉴얼을 작성해야 한다.

타당성 검토-계획-분석-설계-구현-시험-유지보수

  ) -->   

2) 프로토타이핑

 -개발자가 구축한 소프트웨어 모델인 시제품을 사전에 미리 만드 는 공정이다.

 -사용자의 요구 사항을 정확히 파악한다.

 -발주나 개발자 모두에게 공동의 참조 모델을 제공한다.

 -최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있다.

 -개발 단계에서 오류가 수정되므로 유지보수가 필요없다.

 -프로토타입은 구현 단계의 구현 골격이 될 수 있다.

  ) -->   

 3) 나선형 모델(Spiral Model)

 ① 계획화(Planning)

 ② 위험성 분석(Risk Analysis)

 ③ 공학화(Engineering) 

 ④ 사용자 평가(Customer Evaluation)

  ) -->   

■ 프로젝트 관리를 위한 3P

 ① 사람(People)  ② 문제(Problem)  ③ 프로세스(Process)

  ) -->   

■ 분산형 팀 구성

 -민주주의식 팀의 구조 

 -팀구성원 사이의 의사교통이 활성화시키므로 복잡한 장기 프로젝 트에 적합하다.

  ) -->   

■ 중앙집중식 팀 구성

 -책임 프로그래머 팀의 구조

 -한사람에 의하여 통제할 수 있는 비교적 소규모 프로젝트에 적 합한다.

 ① 책임 프로그래머: 요구분석 및 설계 등의 중요한 업무를 담당. 중요한 기술적 판단을 내린다.

 ② 보조 프로그래머 : 책임 프로그래머를 지우너, 여러 가지 기술 적 문제에 대한 자문 담당   ③ 프로그래머: 원시코드작성, 테스트, 디버깅, 문서작성

 ④ 프로그램 사서: 프로그램 리스트, 설계문서, 테스트 계획 등을 관리

  ) -->   

■ 소프트웨어 비용 산정에 영향을 주는 요소 

 - 개발자의 능력

 - 제품의 복잡도 

 - 요구되는 신뢰도

 - 제품의 크기

 - 가용시간

 - 기술수준

  ) -->   

■ 프로젝트 계획 수립시 소프트웨어 영역 

 -기능, 성능, 제약조건, 인터페이스, 신뢰성

  ) -->   

■ 소프트웨어 추정 도구

 ① SLIM : Putnam 평가 모델을 기초로 해서 만든 자동화된 비용 시스템

 ② ESTIMACS : Function Point 평가 방법을 사용한다.

 ③ COCOMO 모델 : LOC를 기반으로 한 비용추정하는 모델

  ) -->   

■ COCOMO(COnstructive COst MOdel) 산정법

 1) 프로젝트 개발 유형에 따른 분류 

① Organic Mode : 아주 작고 간단한 소프트웨어 프로젝트, 프로 그램 규모는 5만라인 이하 

 ② Semidetached Mode : 중간급의 소프트웨어 프로젝트로서, 프 로그램 규모는 30만라인 이하

 ③ Embedded Mode: 초대형 규모의 시스템이 해당된다. 2) 비용 추정 단계에 따른 분류 ① Basic

 ② Intermediate

 ③ Detailed 

  ) -->   

■ 소프트웨어 일정 계획

 ① WBS  ② CPM  ③ PERT  

④ 간트 챠트(Gant chart) : 이정표, 작업기간, 주요작업, 작업일정

  ) -->   

■ 브룩스(Brooks) 법칙

  - 소프트웨어 개발 일정이 지연된다고 해 서 말기에 새로운 인원을 투입하면 일정은 더욱 지연된다.

  ) -->   

■ 소프트웨어 일정 계획에 필요한 작업

 ① 각 단계에 필요한 작업들은 분해

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

 ③ 프로젝트의 규모를 추정 

 ④ 확정된 결과를 간트 챠트로 그린다.

  ) -->   

■ 품질 보증 : 생산물이 설정된 명세와 일치하는가를 확인하는 데 필요한 모든 계획된 체계적인 활동을 말한다.

  ) -->   

■ 품질목표

 ① 무결성(integrity) : 데이터의 독단적인 액세스 및 수정을 제어 할 수 있는 시스템 능력

 ② 상호 운용성(interoperability) : 다른 소프트웨어와 정보를 교환 할 수 있는 시스템 능력

 ③ 유지 보수성(maintainability) : 에러가 발견되었을 때 쉽게 정정 될 수 있는 시스템 능력

 ④ 이식성(portability) : 다양한 하드웨어 환경에서 운용되기 위해 쉽게 수정될 수 있는 정도 

⑤ 신뢰성(Reliability) : 정확하고 일관된 결과로 요구된 기능을 수 행하는 시스템 능력

⑥ 재사용성(Reusalbility) : 전체나 일부 소프트웨어가 다른 응용 부분에서 사용될 수 있는 능력

 ⑦ 사용 용이성(usability) : 쉽게 배우고 허용할 수 있는 시스템 능력

  ) -->   

■ 정형 기술 검토(FTR)의 기본사항

 ① 논쟁과 반박을 제한한다. 

 ② 의제를 정하라.

 ③ 참가자의 수를 제한하라.

 ④ 제품의 검토에 집중하라.

  ) -->   

■ 소프트웨어 신뢰도 측정 척도 : MTBF = MTTF + MTTR

  ) -->   

■ 위험성 분석 : 프로젝트 개발과정에서 발생할 수 있는 모든 위험 요소를 인식하고 분석하여, 위험에 대처할 수 있는 관리활동

  ) -->   

■ 위험성 추정을 위한 위험표 ① 위험의 종류  ② 위험의 확률  ③ 위험의 영향

  ) -->   

■ 구조적 분석시에 사용되는 분석도구 ① 데이터 사전(DD: Data Dictionary) ② 데이터 흐름도(DFD) ③ 소단위 명세서(Mini-Spec)

  ) -->   

■ 데이터 사전(DD)의 기호 표기

+  료이 나열(AND) { } 반복요소 ¦  료의 나열(OR) [ ] 다중 택일(Selection) = ~으로 구성되다. ( ) 선택(option), 생략 가능

  ) -->   

■ 데이터 흐름도(DFD)의 도형 표기

 ① 직사각형(Terminal=단말) : 시작과 종료의 의미, 입력과 출력, 생산자와 소비자, 발생지와 종착지

 ② 원(Bubble=버블) : 자료 처리 과정

 ③ 화살표: 자료 흐름

 ④ 직선(단선, 이중선) : 자료 저장소

  ) -->   

■ 자료 흐름 중심 설계 절차

 ① 정보 흐름의 유형을 설정한다.

 ② 흐름의 경계를 표시한다.

 ③ 데이터 흐름도를 프로그램 구조로 사상한다.

 ④ 제어 계층을 분해시켜서 정의한다.

 ⑤ 경험적 방법으로 구체화시킨다.

  ) -->   

■ 구조적 프로그래밍 기법 -GOTO문이 없는 프로그래밍이다 -순차(Sequencing), 선택(Selection), 반복(Iteration) -단일 입구(Single Entry), 단일 출구(Single Exit)

  ) -->   

■ Fan-in : 임의 모듈을 직접 호출하는 관계에 있는 상위 모듈 의 수 

  ) -->   

■ 결합도(Coupling) : 두 모듈간의 상호 의존도 

 ① Data Coupling : 두 모듈간에 꼭 필요한 자료만을 전달하는 결합성 

 ② Stamp Coupling : 두 모듈간에 배열이나, 레코드 등의 자료 구조로 전달하는 결합성

 ③ Control Coupling : 한 모듈이 다른 모듈에게 제어 요소(제어신 호)를 전달하는 결합성   ④ Common Coupling : 두 모듈간에 공통주소, 공동 자료 영역을 사용하여 전달하는 결합성

 ⑤ Content Coupling : 한 모듈이 다른 모듈의 일부분을 직접 참 조 또는 수정하는 경우의 결합성

  ) -->   

 내용 결합도  강          

 공통 결합도

 제어 결합도 ⇓

 스탬프 결합도 

 자료 결합도

 우연적 응집도 약

  ) -->   

 논리적 응집도 약 

 시간적 응집도

 절차적 응집도

 통신적 응집도 ⇓

 순차적 응집도

 기능적 응집도  강

  ) -->   

■ 소프트웨어 설계 지침

 - 결합도를 줄이고, 응집도는 높인다.

 - 복잡도와 중복을 줄인다.

 - 모듈의 기능을 예측할 수 있도록 정의한다.

 - 설계는 자료와 프로시저에 대한 분명하고 분리된 표현을 포함해야 한다.

 -소프트웨어 요소들 간의 효과적인 제어를 위해 설계에서 계층적 조건이 제시되어야 한다.

 -소프트웨어는 논리적으로 특별한 기능과 부기능을 수행하는 요소들로 나뉘어져야 한다. 

(※ 전체적, 종속적, 통합적이란 말이 들어가면 안된다.)

  ) -->   

■ HIPO(Hierarchy plus input process output)의 종류

 ① 도식목차(Visual Table of Contents): 시스템의 전체구성과 흐름 을 계층 구조도로 나타낸다.

 ② 총괄도표(Overview Diagram): 시스템의 입력, 처리, 출력 관계를 나타낸다.

 ③ 상세도표(Detail Diagram)

  ) -->   

■ Nassi and Schneiderman(N-S chart) -논리 기술에 중점을 둔 도형식 표현 방법

 ① 순차(Sequential)

 ② 선택(if-then-else, case)

 ③ 반복(repeat-until, while, forl) 구조를 사용

  ) -->   

■ 화이트 박스 검사 -모듈안의 작동을 직접 관찰 –논리구조상의 오류

 ① 기초 경로 검사(Basic path test)

 ② 조건검사(condition test)

 ③ 데이터 흐름 검사(data flow test)

 ④ 루프검사(loop test)

  ) -->   

■ 블랙 박스 검사

 -제품이 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동 되는 것을 입증하는 검사. 

 -블랙 박스 검사는 기능검사라고도 한다.

 ① 인터페이스 결함

 ② 성능 결함

 ③ 부정확한 기능

  ㉠ 동치 분할 검사(equivalence partitioning testing)

  ㉡ 경계값 분석 검사(boundary value analysis)

  ㉢ 원인 효과 그래픽 검사(cause effect graphic technique)

  ㉣ 비교 검사(comparison testing)

  ) -->   

■ 소프트웨어 검사 단계

 ① 코드검사 ② 설계검사 ③ 요구사항검사 ④ 시스템검사

  ) -->   

■ 상향식 통합 검사 과정의 수행

 -낮은 수준의 모듈들을 클러스터(cluster) 로 결합

 -드라이버(driver)라는 제어 프로그램의 작성

 -클러스터 검사

 -드라이버는 제거되고 클러스터를 상위로 결합

  ) -->   

■ 알파검사

 - 사용자가 개발자의 위치에서 검사를 수행하며, 개발자가 참석하여 통제된 환경에서 수행된다.

  ) -->   

■ 베타검사: 사용자가 고객의 위치에서 검사를 수행

  ) -->   

■ 구현(Implementation) : 프로그래밍 또는 코딩이라고 불리며 설 계 명세서가 컴퓨터가 알 수 있는 모습으로 변환되는 과정

  ) -->   

■ 유지보수(Maintenance): 소프트웨어 라이프 사이클 단계에서 가장 많은 비용을 차지한다.

  ) -->   

■ 유지보수의 행동

 ① 수정(Corrective Maintenance)

 ② 완전(Perfecftive Maintenance) 기능향상 유지보수-유지보수 중 가장 많은 비용을 차지 

 ③ 적응(Adaptive Maintenance)

 ④ 예방(Preventive Maintenance)

  ) -->   

■ 외계인 코드(Alien code): 15년 또는 그 이전에 개발된 소프트웨어를 의미한다.

  ) -->   

■ 형상 관리(SCM: Software Configuration Management)

 -소프트웨어에 가해지는 변경을 제어하고 관리

 -형상 관리는 유지보수 단계에서 수행된다.

 -대표적으로 버전 관리가 있다.

  ) -->   

■ 객체(Object): 데이터들과 이에 대한 연산으로 구성

  ) -->   

■ 속성(Attribute): 객체(Object)의 상태, 성질

  ) -->   

■ 메소드(Method)

 -객체에 정의된 연산을 의미하며, 이것은 객체의 상태를 참조 및 변경하는 수단이다.

 -메소드는 객체(Object)로부터 메시지를 받을 때 시작된다.

  ) -->   

■ 메시지는 객체(Object)에서 객체(Object)로 전달된다.

  ) -->   

■ 클래스(Class): 공통된 특성을 갖는 객체를 모은 것으로, 클래스의 각 인스턴스(Instance)라는 객체가 된다.

  ) -->   

■ 캡슐화(Encapsulation): 객체 안의 데이터와 연산들을 한 테두 리로 묶는 것

  ) -->   

■ 정보은폐(Information hiding) -객체는 다른 객체로부터 자신의 자료를 숨기고 자신의 연산만을 통하여 정보를 허용하는 것 -고려하지 않는 영향을 최소화한다.

  ) -->   

■ 캡슐화의 장점

 ① 변경 작업시 부작용의 전파를 최소화한다.

 ② 인터페이스가 단순하다.

 ③ 재사용을 용이하게 한다.

  ) -->   

■ 상속성(Inheritance)

 -상위 클래스의 메소드에 존재하는 모든 속성을 화위 클래스가 계승하는 것으로 -클래스와 객체(Object)를 재사용할 수 있는 능력

  ) -->   

■ Rumbaugh의 객체 지향 분석

 -OMT(Object Modeling Technic)을 개발

 ① 객체 모델링(Object modeling)

 ② 동적 모델링(Dynamic modeling) 

 ③ 기능 모델링(Fuction modeling)

  ) -->   

■ 소프트웨어 재사용의 이점

 ① 개발 시간과 비용 감소

 ② 소프트웨어 품질 향상

 ③ 소프트웨어 개발의 생산성 증대

 ④ 구축방법에 대한 지식공유

 ⑤ 프로젝트 실패의 위험이 줄어든다.

 

■ 소프트웨어 재사용을 방해하는 요소

 -새로운 개발 방법 도입의 어려움

  ) -->   

■ 소프트웨어 재공학(Re-Engineering): 데이터와 기능들의 개조 및 개선을 가해 유지보수 용이성을 향상시키는 것이다.

  ) -->   

■ 소프트웨어 재공학(Re-Engineering)의 목적

 ① 복잡한 시스템을 다루는 방법  ② 다른 뷰의 생성 ③ 잃어버린 정보의 복구 및 제거

  ) -->   

■ 재공학 과정

 ① 분석  ② 재구성  ③ 역공학: 설계 정보를 추출  ④ 이식

  ) -->   

■ CASE(Computer Aided) S/W 공학

 -CASE는 소프트웨어 개발의 자동화를 의미

 -CASE 소프트웨어 도구와 방법론의 결합

 -전체적인 소프트웨어 생산성 문제에 초점을 두는 방법이다.

  ) -->   

■ CASE는 다음과 같은 이점을 제공한다.

 ① 소프트웨어 품질을 향상

 ② 프로그램의 유지 보수를 용이

 ③ 개발 과정의 속도는 빨라진다. 

 ④ 소프트웨어 재사용을 가능

■ CASE의 정보 저장소 

 -도구들뿐만 아니라 사용자들, 응용 프로그램들 사이에 시스템에 관한 정보를 공동 사용할 수 있도록 한다.

 -형상 관리 요소들이 이미 정보 저장소에 보관되어 있으므로 유지보수를 용이하게 한다. 

 -재사용을 용이하게 한다.

  ) -->   

  ) -->