Part1 - 소프트웨어의 종류 및 개발 방법론 [정보처리기사 요약]

1과목 - 1chapter 정리

 

시스템 소프트웨어 기본요소

: 입력, 출력, 처리, 제어, 피드백

 

플랫폼(Platform)

: 많은 응용 프로그램들을 쉽고 편리하게 사용할 수 있도록 지원해주는 하드웨어나 소프트웨어 환경

 

플랫폼의 기능

: 비용절감, 그룹 형성으로 네트워크 효과, 개발 생산성 향상

 

플랫폼의 성능 특성 분석 항목

: 가용성, 응답시간, 정확성, 사용률

 

프레임워크

: 목적을 달성하기 위해 복잡하게 연결되어 있으며, 문제를 해결하기 위한 구조이자 sw 개발에 있어 하나의 뼈대 역할

 

프레임워크 특징

: 모듈화, 재사용성, 확장성, 제어의 역 흐름

 

프레임워크를 적용할 경우 기대효과

: 개발 용의성, 품질 보증, 변경 용이성, 유지보수 용이성, 재사용성 향상, 표준화율 향상, 상호 운용성 향상

 

컴포넌트

: 부품화 된 프로그램을 모듈, 모듈들의 집합을 라이브러리, 라이브러리 집합을 컴포넌트

 

컴포넌트 설계

: 협약(Contract)에 의한 설계를 따를 경우 조건들이 포함

 

CBD(Component Based Development)

: 재사용이 가능한 컴포넌트 기반의 개발 방법론, 개발 기간 단축으로 생산성과 품질을 높일 수 있음, 유지보수 비용을 최소화, 시스템을 신속하게 구축, 새로운 기능 추가 및 확장을 용이하게 함

 

소프트웨어 공학의 기본 원칙

: 현대적인 프로그래밍 기술 적용, 지속적인 검증 시행, 결과에 관한 명확한 기록, 품질 높은 SW상품 개발

 

운영체제 분석 시 고려사항

: 신뢰도, 성능, 기술 지원, 주변 기기, 구축 비용

 

CISC vs RISC

CISC

: 복잡, 많은 가변 길이 명령어, 컴파일 쉽고, 호환성이 좋지만, 느림. 마이크로 프로그래밍(sw) 제어 방식

RISC

: 간단, 적은 수의 고정길이 명령어, 효율성이 떨어지고, 호환성도 떨어짐, 전력 소모가 적음, 명령어 길이가 정해져 있어 해석이 빠름

 

DBMS 분석 시 고려사항

: 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

 

미들웨어

: 운영체제와 소프트웨어 애플리케이션 사이에 위치, OS가 제공하는 서비스를 추가 및 확장하여 제공하는 컴퓨터 소프트웨어, 클라이언트와 서버 간 통신을 담당

 

미들웨어 종류

: DBMS, RPC(원격 프로시저를 로컬 프로시저처럼 호출하는 방식), MOM(메시지 기반 비동기형 메시지 전달 방식, 데이터 동기를 위해 사용), TP-Monitor(트랜잭션이 잘 처리되고 있는지 데이터 감시 프로그램), ORB(객체 지향 미들웨어로 코바 표준 스펙을 구현), WAS

 

Jetty

: 가장 많이 사용하는 WAS

 

WAS 분석 시 고려사항

: 가용성, 성능, 기술 지원, 구축 비용

 

개발 방법론

구조적 방법론

: 타당성 검토 - 계획 - 요구사항 - 설계 - 구현 - 시험 - 운용/유지보수

 

구조적 방법론 특징

: 구조화 프로그래밍, 구조적 프로그램 작성, 모듈 중심으로 개발, 분할 정복 방법으로 하향식으로 기능을 분해, 프로세스 중심의 개발에 유용, 재사용성, 유지보수성이 낮음

 

정보공학 방법론 특징

: 정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론, 데이터 중심의 방법론, 자료 구조 중심의 방법론으로 비교적 안정적, 데이터와 프로세스가 균형, 기능별로 유지 보수하며, 재사용성이 낮음

 

객체지향 방법론 특징

: 데이터와 그 데이터의 동작을 모두 포함하는 방법론, 캡슐화, 추상화 기술이 필요함, 자연스럽고 유연하며 재사용이 용이

 

컴포넌트 기반 방법론 특징

: 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 애플리케이션을 작성, 모듈은 기능을 구현하기 위한 최소의 단위, 반복적, 점진적으로 개발, 재사용성, 생산성, 품질이 높음, 비용이 저렴, 비용이 계속적 증대

 

애자일 방법론 배경

: 사용자의 요구사항이 빈번히 변경되는 것을 반영, 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론

 

애자일 방법론 정의

: 요구사항 - 설계 - 구현 - 시험 단계를 거침, 소프트웨어 개발 방법에 있어서 계획이 없거나 계획이 지나치게 많은 방법들 사이에 타협점을 찾은 방법론, 변화에 신속하게 대응하기 위하여 요구사항을 지속적으로 분석하고 시간 지연을 최소화하는 방법론

 

애자일 방법론 특징

: 폭포수, 프로토타입, 나선형의 문제점을 보완한 모델, 소프트웨어를 점증적으로 개발, 다양한 요구 변화에 대응하며 팀원의 소통, 협력을 극대화, 가볍고 실용적인 방법론, 애자일 방법론을 소프트웨어 개발 방법론의 방법론이라고 함

 

애자일 방법론 선언문

: 개인과 상호 작용, 동작하는 소프트웨어, 고객과의 협력, 변화의 대응을 중시

 

애자일 방법론 원칙 6가지

: 소통, 협력, 적응, 지속, 가치 전달, 피드백

 

애자일 방법론 5가지 가치

: 의사소통, 용기, 피드백, 단순함, 존경

 

스크럼의 5가지 가치

: 확약, 전념, 정직, 존중, 용기

 

스크럼의 요소

: 백로그, 스프린트, 스크림 미팅, 스크림 마스터

 

린 방법론의 7가지 원칙

: 낭비적 요소 제거, 품질 내재화, 지식 창출, 가능한 늦게 결정, 가능한 빠르게 인도, 사람을 존중, 전체 공정 최적화

 

테일러링 개발 방법론의 필요성

내부 기준 - 목표 환경, 요구사항, 프로젝트 규모(납기일, 비용, 범위), 기술 환경(방법론, 보유 기술, 구성원의 능력) 외부 기준 - 법적 제약 사항, 표준 품질 기준

 

보안 개발 방법론

1. MS-SDL : 보안 수준이 높은 안전한 sw 개발 위해 MS가 자체적으로 수립한 SDLC

2. Seven Toouchpoints : 실무적으로 검증된 개발 보안 방법론 중 하나로써 소프트웨어 보안의 모범 사례를 SDLC에 통합한 소프트웨어 개발 보안 생명주기 방법론

3. CLASP : 활동 중심 기반의 프로세스로 구성된 집합체

4. CWE : 소프트웨어의 보안 취약점을 유발하는 원인을 7가지로 정리한 방법론

(입력 데이터 검증 표현, 보안 기능, 시간 및 상태, 오류 처리, 코드 품질, 캡슐화, API 약용)

 

 

프로젝트 관리의 3P

: 사람, 문제, 프로세스

 

소프트웨어 범위 측정

: 처리 기능, 성능, 제한 조건, 개발 인원, 일정 계획

 

PERT 네트워크

: 프로그램 평가 및 검토 기술, 소요 기간의 예측이 어려운 경우 유리, 낙관치, 기대치, 비관치를 나누어 종료 시기 결정

 

PERT 일정 계획 순서

: 소프트웨어의 전체 규모를 추정 - 작업을 기능별, 특징별로 분류 - 단계별로 작업 일정 예측 - 전체 소요 기간 예측

 

예측치 = 낙관치 + (기대치 * 4) + 비관치 / 6

 

CPM 네트워크

: 임계 경로 기법, 소요 기간이 확실한 경우 유리, 노드와 간선으로 표현하며 의존 관계 표시, 원형 노드는 작업명, 박스 노드는 이정표와 완료 시간 표시

 

CPM 일정 계획 순서

: 소프트웨어의 전체 규모를 추정 - 작업을 기능별, 특징별로 분류 - 단계별 상호 의존관계를 도식화 - 간선 차트 작성

 

위험 관리 순서

: 위험 식별 - 위험 분석 및 평가 - 위험 관리 계획 - 위험 관리 및 조치

 

비용 측정

직접 측정 요소 - 수치, 양, 크기 표현가능(노력(인월), 비용, 라인수(LOC), 오류 수, 투입 인원, 처리속도, 문서 수)

간접 측정 요소 - 비교 대상이 있어야 함 (생산성, 품질 , 기능 점수, 문서화 비율, 효율성, 신뢰도, 유지보수성)

 

비용 측정의 원칙

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

2. 분해 기술 이용한다.

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

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

 

개발 기간이 짧아질수록 개발 비용은 증가, 개발 기간이 길어질수록 개발 비용은 감소

 

간접 측정 평가 공식

: 생산성 = LOC/인월 , 개발 기간 = 인월/개발 인원, 개발 인원 = 인월 * 단위 비용

 

비용 측정 방법론의 분류

하향식 - 전문가 측정, 델파이 측정(중재자에게 맡겨서 진행)

상향식 - LOC 측정, 단계별 인월, 수학적 산정(Walston, COCOMO, Putnam, 기능 점수, 간이 기능 점수)

 

COCOMO 모형

유기형 - 기관 내부에서 개발된 중소 규모의 소프트웨어, 5만 라인 이하의 소프트웨어 평가 유형

준 분리형 - 트랜잭션 처리 시스템이나 운영체제, DBMS 등의 30만 라인 이하 소프트웨어 평가 유형

내재형 - 최대형 규모의 트랜잭션 시스템이나 운영체제 등 평가 유형

 

Putnam 모형

: 대형 프로젝트에 이용, 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도 곡선

 

SLIM

: Putnam 모형을 기초로 해서 만든 자동화 추정 도구

 

기능 점수의 비용 산정 요소

: 입력 유형의 수, 출력 유형의 수, 사용자 명령어 수, 데이터 파일의 수, 인터페이스의 수

 

형상 관리(SCM)

:  소프트웨어 개발 과정에서 발생하는 산출물의 변경 사항에 대한 버전 관리 활동

 

형상 관리 역할, 특성

: 리버전이나 버전에 대한 정보에 접근 가능하여 배포관리에 유용, 불필요한 사용자 소스의 수정을 제한, 동일한 프로젝트에 여러 명이 개발 가능

 

형상 관리 절차

: 형상 식별 - 변경 제어 - 형상 상태 보고 - 형상 감사

 

폭포수 모형

: 가장 오래된 모형, 요구사항의 변경이 어려움, 이전 단계 혹은 전전 단계로 돌아갈 수 없음, 고전적 생명주기 모형, 사용자 요구를 만족하는지는 최종 결과물이 나와야 확인 가능

 

폭포수 모형 개발 순서

: 타당성 검토 - 계획 단계 - 요구 분석 - 설계 - 구현 - 검사 - 운용 + 유지보수

 

폭포수 모형 특징

: 순차적 접근 방법, 단계적 정의와 산출물이 명확, 단계별로 문서화 작업이 필요, 현실적으로는 어려움, 새로운 요구를 반영하기 힘듦, 유사한 개발 경험이 있는 경우는 효율적이고 품질면에서 우수

 

프로토 타입 모형

: 요구 수집 - 빠른 설계 - 프로토타입 구축 - 고객 평가 - 조정 -- 구현

 

브룩스의 이론

: 프로토 타입 소프트웨어는 폐기 처분하는 첫 번째 시스템이다. 개발 일정이 지연된다고 해서 말기의 새로운 인원을 투입하는 것은 더욱 지연된다.

 

나선형 모델 개발 순서

: 계획 수립 - 위험 분석 - 개발 및 검증 - 고객 평가

 

나선형 모형 특징

: 계획 수립부터 모든 단계를 반복하면서 개발, 위험 관리가 중심인 소프트웨어 생명주기 모형, 위험 분석을 해나가면서 시스템을 개발, 폭포수, 프로토타입 모형의 장점을 살린 모형, 대규모 시스템의 소프트웨어 개발에 적합

 

V모형

:  요구 분석 - 시스템 설계 - 상세 설계 - 코딩 - 단위 검사 - 통합 검사 - 시스템 검사 - 인수/설치

상세 - 단위 (모듈 검증), 시스템 - 통합 (인터페이스 검증), 요구 - 시스템 (요구분석 검증)

 

ISO 12207 표준

: 소프트웨어 개발 프로세스를 정의하고 향상하기 위한 프로세스

 

ISO 12207 표준 구성

1. 기본 공정(공급, 획득, 개발, 운영, 유지보수)

2. 지원 공정(문서화, 형상 관리, 문제 해결, 품질 보증, 검증, 확인, 합동 검토, 감리)

3. 조직 공정(관리, 기반 구조, 개선, 교육 훈련)

 

ISO/IEC

9126 - 소프트웨어 품질 특성과 척도에 관한 표준 지침서

12119 - 패키지 소프트웨어의 일반적인 제품 품질 요구사항 및 테스트를 위한 국제 표준

12509 - OSI 7 계층의 관리 기능에 대한 공통된 정보를 명세화하는 규격

29119 - 소프트웨어 테스트 관련 국제 표준

 

ISO/IEC 품질 특성

기능성 - 적합성, 정확성, 상호 운용성, 보안성, 준수성

신뢰성 - 성숙성, 결함 허용성, 복구성

사용성 - 이해성, 학습성, 운용성, 선호도, 준수성

효율성 - 시간 반응성, 자원 활용성, 준수성

유지보수성 - 분석성, 변경성, 안정성, 시험성, 준수성

이식성 - 적응성, 설치성, 공존성, 대체성, 준수성

 

CMM

:  소프트웨어 개발과 유지보수에 대한 프로세스 개선과 능력 향상을 위한 프레임워크이며 모델, 신뢰성 있고 일관성 있는 능력 평가 기반 구조, 개발과 유지보수 능력의 증대 요인들을 준수하도록 함, 정부와 산업계에서 사용

 

CMM 5가지 성숙 단계 - 핵심 프로세스

1. 초기 - 없음

2. 반복 - 요구 관리, 계획, 추적, 감시, 형상 관리, 품질 보증

3. 정의 - 조직 프로세스 관리, 교육 훈련 프로그램, 통합 소프트웨어 관리, 생산 공학, 동료 검토, 그룹 간 조정, 중간 심사

4. 관리 - 정량적 프로세스 관리, 소프트웨어 품질관리

5. 최적 - 결함 예방, 기술 변화 관리, 프로세스 변경 관리

 

CMM 모델 평가 기준

Level 1 - 혼돈적 관리 : 순서의 일관성이 없음

Level 2 - 경험적 관리 : 일정, 비용의 경험적 법칙 적용

Level 3 - 정성적 관리 : 경험 공유, 공식적 프로세스 관리

Level 4 - 정량적 관리 : 통계적 방법과 조직적 분석

Level 5 - 최적화 관리 : 위험 예측, 최적화 도구 이용

 

SPICE 모델

: 소프트웨어 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준

 

SPICE 모델 프로세스 수행 능력 수준 6단계

: 불안정 - 수행 - 관리 - 확립 - 예측 - 최적화

 

SPICE 목적

: 개발 기관에서 프로세스 개선을 위해 스스로 평가, 개관에서 정한 요구조건을 만족하는지 개발 조직 스스로 평가, 계약을 맺기 위해 수탁 기관의 프로세스를 평가

 

CMMI 프로세스 영역

: 프로세스 관리 영역, 프로젝트 관리 영역, 엔지니어링 영역, 지원 영역