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

devheyrin·2022년 7월 7일

0

정보처리기사

목록 보기

1/10

15. 클래스 다이어그램

정적 모델링

클래스 다이어그램

클래스 다이어그램의 구성 요소

클래스
- 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현한것
- 3개의 구획으로 나누어 클래스 이름, 속성, 오퍼레이션 표기
- 속성 : 클래스의 상태, 정보 표현
- 오퍼레이션 : 클래스가 수행할 수 있는 동작. 메소드, 함수라고도 함
제약조건
- 속성에 입력될 값에 대한 제약조건
- 오퍼레이션 수행 전후에 지정해야 할 조건
- 클래스 안에 제약조건 기술할 때는 {} 사용! 예) 경력: int{경력 > 0}
관계
- 클래스와 클래스 사이의 연관성
- 연관관계, 집합관계, 포함관계, 일반화 관계, 의존 관계가 있음

연관 클래스

연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스
두 클래스의 연관 관계를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시
연관 클래스명은 연관 관계의 이름을 이용해 지정한다.

문제

클래스 다이어그램
각각의 객체들이 갖는 속성과 오퍼레이션을 표현한 것
연관 클래스

16. 시퀀스 다이어그램

동적 모델링

시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호작용을 표현한 것
시스템 내부 구성 요소들 간에 이루어지는 동작이라는 관점에서 표현
시스템이 실행될 때 구성 요소들 간의 메시지 호출, 즉 오퍼레이션을 통한 상호 작용에 초점

동적 모델링의 종류

시퀀스 다이어그램
커뮤니케이션 다이어그램
상태 다이어그램

시퀀스 다이어그램

시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정을 그림으로 표현한 것
시스템이나 객체들의 상호작용 과정에서 주고받는 메시지를 표현
각 동작에 참여하는 시스템이나 객체들의 수행 기간을 확인할 수 있음
클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현

시퀀스 다이어그램의 구성 요소

액터
- 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미
객체
- 메시지를 주고받는 주체 (로그인화면, 회원정보, 상품선택화면 등..)
생명선
- 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현
- 객체 소멸이 표시된 기간까지 존재
실행 상자, 활성 상자
- 객체가 메시지를 주고받으며 구동되고 있음을 표현
- 생명선 상에 겹쳐 직사각형 형태로 표현
메시지
- 객체가 상호 작용을 위해 주고받는 메시지
객체 소멸
- 해당 객체가 더 이상 메모리에 존재하지 않음을 표현
프레임
- 다이어그램의 전체 또는 일부를 묶어 표현

문제

생명선, 실행 상자, 메시지
시퀀스 다이어그램
실행 상자

17. 커뮤니케이션 다이어그램

커뮤니케이션 다이어그램

커뮤니케이션 다이어그램은 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것이다.
동작에 참여하는 객체들 사이의 관계를 파악하는 데 사용된다.
클래스 다이어그램에서 관계가 제대로 표현됐는지 점검하는 용도로도 사용된다.
초기에는 협업 다이어그램이라고 불렸다.

커뮤니케이션 다이어그램의 구성요소

액터
- 시스템으로부터 서비스를 요청하는 외부요소로, 사람이나 외부 시스템을 의미
객체
- 메시지를 주고받는 주체
링크
- 객체들 간의 관계를 표현한 것
- 액터와 객체, 객체와 객체 간에 실선을 그어 표현
메시지
- 객체가 상호 작용을 위해 주고받는 내용
- 화살표의 방향은 메시지를 받는 쪽으로 향하게 표현
- 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서를 표시

문제

커뮤니케이션 다이어그램
링크

18. 상태 다이어그램

상태 다이어그램

객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것
객체의 상태란 객체가 갖는 속성 값의 변화를 의미한다.
특정 객체가 어떤 이벤트에 의해 상태 변환 과정이 진행되는지 확인하는 데 사용된다.
시스템에서 상태 변환 이벤트를 확인할 필요가 있는 객체만을 대상으로 그린다.

상태 다이어그램의 구성 요소

상태
- 객체의 상태를 표현한 것
시작 상태
- 상태의 시작을 표현한 것
종료 상태
- 상태의 종료를 표현한 것
상태 전환
- 상태 사이의 흐름, 변화를 화살표로 표현한 것
이벤트
- 상태에 변화를 주는 현상
- 이벤트에는 조건, 외부 신호, 시간의 흐름 등이 있음
프레임
- 상태 다이어그램의 범위를 표현한 것

문제

상태 다이어그램
재고 확인 실패, 주문 상품 선택

19. 패키지 다이어그램 🌟

패키지 다이어그램

유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것
패키지는 또 다른 패키지의 요소가 될 수 있다.
대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용한다.
불필요한 의존관계를 제거하거나 간략화함으로써 시스템의 복잡도를 낮추는데 사용할 수 있다.

패키지 다이어그램의 구성 요소

패키지
- 객체들을 그룹화한 것
- 단순 표기법 : 패키지 이름만 표현
- 확장 표기법 : 요소까지 표현
객체
- 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들
의존 관계
- 패키지와 패키지, 패키지와 객체 간을 점선화살표로 연결하여 표현
- 스테레오타입을 이용해 의존 관계를 구체적으로 표현할 수 있다.
- 의존 관계의 표현 형태는 사용자가 임의로 작성할 수 있으며, 대표적으로 import와 access 가 사용된다.
- <<import>> : 패키지에 포함된 객체들을 직접 가져와서 이용하는 관계
- <<access>> : 인터페이스를 통해 패키지 내의 객체에 접근하여 이용하는 관계

문제

패키지 다이어그램
패키지 다이어그램

20. 소프트웨어 개발 방법론

소프트웨어 개발 방법론

소프르웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것
소프트웨어 개발 방법론의 목적은 소프트웨어의 생산성과 품질 향상이다.
주요 소프트웨어 개발 방법론
- 구조적 방법론
- 정보공학 방법론
- 객체지향 방법론
- 컴포넌트 기반 방법론
- 제품 계열 방법론
- 애자일 방법론

구조적 방법론

정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론
1960년대까지 가장 많이 적용되었던 소프트웨어 개발 방법론
쉬운 이해 및 검증이 가능한 프로그램 코드를 생성하는 것이 목적
복잡한 문제를 다루기 위해 분할과 정복 원리를 적용한다.
구조적 방법론의 개발 절차 ⭐
- 타당성 검토 단계 → 계획 단계 → 요구사항 단계 → 설계 단계 → 구현 단계 → 시험 단계 → 운용/유지보수 단계

정보공학 방법론

정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료 중심의 방법론
정보 시스템 개발 주기를 이용하여 대규모 정보 시스템을 구축하는 데 적합
정보공학 방법론의 개발 절차 ⭐
- 정보 전략 계획 수립 → 업무 영역 분석 → 업무 시스템 설계 → 업무 시스템 구축

객체지향 방법론

현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되었다.
객체지향 방법론의 구성 요소 : 객체, 클래스, 메시지 등
객체지향 방법론의 기본 원칙 : 캡슐화, 정보 은닉, 추상화, 상속성, 다형성 등
객체지향 방법론의 개발 절차 ⭐
- 요구 분석 → 설계 → 구현 → 테스트 및 검증 → 인도

컴포넌트 기반 방법론 ⭐

기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
컴포넌트의 재사용이 가능해 시간과 노력을 절감할 수 있다.
새로운 기능을 추가하는 것이 간단하여 확장성이 보장된다.
유지 보수 비용을 최소화하고 생산성 및 품질을 향상시킬 수 있다.
컴포넌트 기반 방법론의 개발 절차
- 개발 준비 → 분석 단계 → 설계 단계 → 구현 단계 → 테스트 단계 → 전개 단계 → 인도 단계

제품 계열 방법론

특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
임베디드 소프트웨어를 만드는 데 적합
제품 계열 방법론은 영역공학과 응용공학으로 구분된다.
- 영역공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역이다.
- 응용공학 : 제품 요구 분석, 제품 설계, 제품을 구현하는 영역이다.
영역공학과 응용공학의 연계를 위해 제품의 요구사항, 아키텍쳐, 조립 생산이 필요하다.

문제

컴포넌트 기반 방법론
요구사항, 설계, 구현
소프트웨어 개발 방법론

21. 소프트웨어 공학의 발전적 추세 ⭐

소프트웨어 재사용

이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
소프트웨어 개발의 품질과 생산성을 높이기 위한 방법
기존에 개발된 소프트웨어와 경험, 지식 등을 새로운 소프트웨어에 적용한다.
소프트웨어 재사용 방법
- 합성 중심 : 전자 칩과 같은 소프트웨어 부품, 즉 블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법으로, 블록 구성 방법이라고도 한다.
- 생성 중심 : 추상화 형태로 쓰여진 명세를 구체화하여 프로그램을 만드는 방법으로, 패턴 구성 방법이라고도 한다.

소프트웨어 재공학 ⭐

기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것
소스를 문서화하는 것! (역공학) 문서화 과정에서 발견한 비효율적 코드를 수정 ⇒ 재공학
유지보수 생산성 향상을 통해 소프트웨어 개발 비용의 대부분을 차지하는 유지보수 비용을 줄일 수 있다.
기존 소프트웨어의 데이터와 기능들의 개조 및 개선을 통해 유지보수성과 품질을 향상시킨다.
소프트웨어 재공학의 이점
- 소프트웨어 품질 향상
- 소프트웨어 생산성 증가
- 소프트웨어의 수명 연장
- 소프트웨어의 오류 감소

CASE(Computer Aided Software Engineering) ⭐

소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
객체지향 시스템, 구조적 시스템 등 다양한 시스템에서 활용되는 자동화 도구(CASE Tool)이다.
소프트웨어 생명 주기의 전체 단계를 연결하고 자동화하는 통합된 도구를 제공한다.
소프트웨어 개발 도구와 방법론이 결합되었으며, 정형화된 구조 및 방법을 소프트웨어 개발에 적용하여 생산성 향상을 구현한다.
CASE의 주요 기능
- 소프트웨어 생명 주기 전 단계의 연결
- 다양한 소프트웨어 개발 모형 지원
- 그래픽 지원

문제

합성 중심, 생성 중심
CASE
기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것
소프트웨어 재사용

22. 비용 산정 기법

소프트웨어 비용 산정

개발에 소요되는 인원, 자원, 기간 등으로 소프트웨어의 규모를 확인하여 개발 계획 수립에 필요한 비용을 산정하는 것
비용을 너무 높게 산정할 경우 예산 낭비와 일의 효율성 저하를 초래할 수 있고, 너무 낮게 산정할 경우 개발자의 부담이 가중되고 품질 문제가 발생할 수 있다.
하향식 비용 산정 기법과 상향식 비용 산정 기법이 있다.

소프트웨어 비용 결정 요소

프로젝트 요소
- 제품 복잡도 : 소프트웨어 종류에 따라 발생할 수 있는 문제점들의 난이도
- 시스템 크기 : 소프트웨어의 규모에 따라 개발해야 할 시스템의 크기
- 요구되는 신뢰도 : 일정 기간 내 주어진 조건하에서 픅로그램이 필요한 기능을 수행하는 정도
자원 요소
- 인적 자원 : 소프트웨어 개발 관련자들이 갖춘 능력 혹은 자질
- 하드웨어 자원 : 소프트웨어 개발 시 필요한 장비와 워드프로세서, 프린터 등의 보조 장비
- 소프트웨어 자원 : 소프트웨어 개발 시 필요한 언어 분석기, 문서화 도구 드으이 개발 지원 도구
생산성 요소
- 개발자 능력 : 개발자들이 갖춘 전문지식, 경험, 이해도, 책임감, 창의력 등
- 개발 기간 : 소프트웨어를 개발하는 기간

문제

프로젝트 요소, 자원 요소, 생산성 요소
생산성 요소, 자원 요소

23. 비용 산정 기법 - 하향식

하향식 비용 산정 기법

과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적 방법
프로젝트의 전체 비용을 산정한 후 각 작업별로 비용을 세분화
하향식 비용 산정 기법 ⭐
- 전문가 감정 기법
- 델파이 기법

전문가 감정 기법

경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법
가장 편리하고 신속하게 비용을 산정할 수 있는 방법
의뢰자로부터 믿음을 얻을 수 있다.
개인적이고 주관적일 수 있다.

델파이 기법

전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법
전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성된다.

문제

전문가 감정 기법
델파이 기법

24. 비용 산정 기법 - 상향식

상향식 비용 산정 기법

세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
상향식 비용 산정 기법
- LOC(원시 코드 라인 수) 기법
- 개발 단계별 인원수 기법
- 수학적 산정 기법

LOC(원시 코드 라인 수, source Line Of Code) 기법

각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용해 비용을 산정하는 기법
측정이 용이하고 이해하기 쉬워 가장 많이 사용된다.
예측치를 이용해 생산성, 노력, 개발 기간 등의 비용을 산정한다.
산정 공식 ⭐
- 노력(인월) = 개발 기간 * 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수 = 총 라인 / 평균 라인
- 개발 비용 = 노력 * 단위 비용(1인당 월평균 인건비)
- 개발 기간 = 노력 / 투입 인원
- 생산성 = LOC / 노력

개발 단계별 인월수 기법

LOC 기법을 보완하기 위한 기법으로, 각 기능을 구현시키는 데 필요한 노력을 생명 주기의 각 단계별로 산정
LOC 기법보다 더 정확

문제

노력 = 30000 / 300 = 100, 기간 = 100 / 5 = 20 개월
개발 단계별 인원수 기법
인원 = 노력 / 기간 = 40 / 8 = 5, 5*100 = 500만원

25. 수학적 산정 기법 ⭐

수학적 산정 기법

상향식 비용 산정 기법으로, 경험적 추정 모형, 실험적 추정 모형이라고도 한다.
개발 비용 산정의 자동화를 목표로 한다.
비용의 자동산정을 위해 사용되는 공식은 과거의 유사한 프로젝트를 기반으로 유도된 것이다.

주요 수학적 산정 기법

COCOMO 모형
Putnam 모형
기능 점수(FP) 모형

COCOMO 모형

원시 프로그램의 규모인 LOC 에 의한 비용 산정 기법
LOC를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 산정
비용 산정 결과는 프로젝트를 완성하는데 필요한 노력으로 나타난다.
보헴이 제안하였다.

COCOMO의 소프트웨어 개발 유형

조직형
- 기관 내부에서 개발된 중 소 규모의 소프트웨어
- 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리용 등의 5만(50KDSI) 라인 이하의 소프트웨어를 개발하는 유형
- 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합
반분리형
- 조직형과 내장형의 중간형 소프트웨어
- 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만 라인 이하의 소프트웨어를 개발하는 유형
- 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합
내장형
- 초대형 규모의 소프트웨어
- 트랜잭션 처리 시스템이나 운영체제 등의 30만 라인 이상의 소프트웨어를 개발하는 유형
- 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합

COCOMO 모형의 종류

기본형
- 소프트웨어 크기와 개발 유형만을 이용하여 비용 산정
중간형
- 기본형 COCOMO의 공식을 그대로 사용하나, 다음 4가지 특성에 의해 비용을 산정한다.
  - 제품의 특성
  - 컴퓨터의 특성
  - 개발 요원의 특성
  - 프로젝트 특성
발전형
- 중간형을 보완하여 만들어진 모형
- 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용 산정
- 소프트웨어 환경과 구성 요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 적용한다.

Putnam 모형

소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
푸트남이 제안한 것으로, 생명 주기 예측 모형이라고도 한다.
시간에 따른 함수로 표현되는 Rayleigh-Nordan 곡선의 노력 분포도를 기초로 한다.
대형 프로젝트의 노력 분포 산정에 이용된다.
개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소한다.

기능 점수 모형

소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며, 총 기능 점수와 영향도를 이용하여 기능 점수를 구한 후 이를 이용해서 비용을 산정하는 기법
알브레히트가 제안했다.
소프트웨어 기능 증대 요인
- 자료 입력(입력 양식)
- 정보 출력(출력 보고서)
- 명령어(사용자 질의 수)
- 데이터 파일
- 필요한 외부 루틴과의 인터페이스

비용 산정 자동화 추정 도구

SLIM
- Rayleigh-Nordan 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구
ESTIMACS
- 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구

문제

기능 점수
내장형, 조직형
소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
COCOMO 모형
SLIM

26. 프로젝트 일정 계획

프로젝트 일정 계획

프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여 소작업의 순서와 일정을 정하는 것
프로젝트 일정 계획에 사용되는 기능 : WBS, PERT/CPM, 간트 차트 등

PERT - 프로그램 평가 및 검토 기술

PERT는 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크이다.
각 작업별로 다음과 같이 단계를 나누어 종료시기를 결정한다.
- 낙관적인 경우
- 가능성이 있는 경우
- 비관적인 경우
개발 경험이 없어 소요 기간 예측이 어려운 프로젝트 일정 계획에 사용한다.
노드와 간선으로 구성되며 원 노드에는 작업을, 간선에는 낙관치, 기대치, 비관치를 표시한다.
결정 경로, 작업에 대한 경계 시간, 작업 간의 상호 관련성 등을 알 수 있다.
작업 예측치 계산 공식
- ( 비관치 + 4 * 기대치 + 낙관치 ) / 6
평방 편차
- [ ( 비관치 - 낙관치 ) / 6 ] ** 2

CPM - 임계 경로 기법 - 가장 오랜 기간이 소요되는 경로

CPM은 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
CPM은 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타낸다.
원형 노드는 각각의 작업을 의미하며, 작업 이름과 소요 기간을 표시한다.
박스 노드는 이정표를 의미하며, 이정표 이름과 예상 완료 시간을 표시한다.
간선을 나타내는 화살표의 흐름에 따라 각 작업이 진행되며, 전 작업이 완료되어야 다음 작업을 진행할 수 있다.

간트 차트

간트 차트는 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표이다.
시간선 차트라고도 한다.
중간 목표 미달성 시 그 이유와 기간을 예측할 수 있게 한다.
사용자와의 문제점이나 예산의 초과 지출 등도 관리할 수 있게 한다.
자원 배치나 인원 계획에 유용하게 사용된다.
이정표, 작업 일정, 작업 기간, 산출물로 구성되어 있다.
수평 막대의 길이는 각 작업의 기간을 나타낸다.

문제

14일
PERT
간트 차트

27. 소프트웨어 개발 방법론 결정

소프트웨어 개발 방법론 결정

프로젝트 관리와 재사용 현황을 소프트웨어 개발 방법론에 반영하고, 확적된 소프트웨어 생명 주기와 개발 방법론에 맞춰 소프트웨어 개발 단계, 활동, 작업, 절차 등을 정의하는 것
소프트웨어 개발 방법론 결정 절차
- 프로젝트 관리와 재사용 현황을 소프트웨어 개발 방법론에 반영
- 개발 단계별 작업 및 절차를 소프트웨어 생명 주기에 맞춰 수립
- 결정된 방법론의 개발 단계별 활동 목적, 작업내용, 산출물에 대한 매뉴얼 작성

프로젝트 관리

주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동
일정 관리
- 작업 순서, 작업기간산정, 일정 개발, 일정 통제
비용 관리
- 비용 산정, 비용 예산 편성, 비용 통제
인력 관리
- 프로젝트 팀 편성, 자원 산정, 프로젝트 조직 정의, 프로젝트 팀 개발, 자원 통제, 프로젝트 팀 관리
위험 관리
- 위험 식별, 위험 평가, 위험 대처, 위험 통제
품질 관리
- 품질 계획, 품질 보증 수행, 품질 통제 수행

문제

인력 관리
인력 관리, 위험 관리, 품질 관리, 일정 관리, 비용 관리

28. 소프트웨어 개발 표준 ⭐

소프트웨어 개발 표준

소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준을 의미
주요 소프트웨어 개발 표준
- ISO / IEC 12207
- CMMI
- SPICE - 소프트웨어 처리 개선 및 능력 평가 기준

ISO / IEC 12207

국제표준화 기구에서 만든 표준 소프트웨어 생명 주기 프로세스이다.
소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공한다.
ISO / IEC 12207 구분
- 기본 생명 주기 프로세스 : 획득, 공급, 개발, 운영, 유지보수 프로세스
- 지원 생명 주기 프로세스 : 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상관리, 문제 해결 프로세스
- 조직 생명 주기 프로세스 : 관리, 기반 구조, 훈련, 개선 프로세스

CMMI

소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델
미국 카네기멜론 대학교의 소프트웨어 공학연구소에서 개발

CMMI의 소프트웨어 프로세스 성숙도 ⭐

단계	프로세스	특징
초기	정의된 프로세스 없음	작업자 능력에 따라 성공 여부 결정
관리	규칙화된 프로세스	특정한 프로젝트 내의 프로세스 정의 및 수행
정의	표준화된 프로세스	조직의 표준 프로세스를 활용하여 업무 수행
정량적 관리	예측 가능한 프로세스	프로젝트를 정량적으로 관리 및 통제
최적화	지속적 개선 프로세스	프로세스 역량 향상을 위해 지속적인 프로세스 개선

SPICE

정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
공식 명칭은 ISO / IEC 15504

SPICE의 구성

고객-공급자 프로세스
- 소프트웨어를 개발하여 고객에게 전달하는 것을 지원하고, 소프트웨어의 정확한 운용 및 사용을 위한 프로세스로 구성된다.
- 구성 요소 : 인수, 공급, 요구 도출, 운영
- 프로세스 수 : 10개
공학 프로세스
- 시스템과 소프트웨어 제품의 명세화, 구현, 유지보수를 하는 데 사용되는 프로세스로 구성된다.
- 구성 요소 : 개발, 소프트웨어 유지보수
- 프로세스 수 : 8개
관리 프로세스
- 소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세서로 구성된다.
- 구성 요소 : 관리, 프로젝트 관리, 품질 및 위험 관리
- 프로세스 수 : 4개
조직 프로세스
- 조직의 업무 목적 수립과 조직의 업무 목표 달성을 위한 프로세스로 구성된다.
- 구성 요소 : 조직 배치, 개선 활동 프로세스, 인력 관리, 기반 관리, 측정 도구, 재사용
- 프로세스 수 : 9개

SPICE의 프로세스 수행 능력 단계 ⭐

불완전 : 프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계
수행 : 프로세스가 수행되고 목적이 달성된 단계
관리 : 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
확립 : 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계
예측 : 프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
최적화 : 프로세스 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계

문제

관리, 정의, 정량적 관리
SPICE
ISO/IEC 12207
소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델

29. 소프트웨어 개발 방법론 테일러링

소프트웨어 개발 방법론 테일러링

프로젝트 상황 및 특성에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업
수행 절차
- 프로젝트 특징 정의 → 표준 프로세스 선정 및 검증 → 상위 수준의 커스터마이징 → 세부 커스터마이징 → 테일러링 문서화

소프트웨어 개발 방법론 테일러링 고려사항

내부적 기준
- 목표 환경: 시스템의 개발 환경과 유형이 서로 다른 경우 테일러링 필요
- 요구사항 : 프로젝트의 생명 주기 활동에서 개발, 운영, 유지보수 등 프로젝트에서 우선적으로 고려할 요구사항이 서로 다른 경우 테일러링 필요
- 프로젝트 규모 : 비용, 인력, 기간 등 프로젝트의 규모가 서로 다른 경우 테일러링 필요
- 보유 기술 : 프로세스, 개발 방법론, 산출물, 구성원의 능력 등이 서로 다른 경우 테일러링 필요
외부적 기준
- 법적 제약사항 : 프로젝트별로 적용될 IT Complience가 서로 다른 경우 테일러링 필요
- 표준 품질 기준 : 금융, 제도 등 분야별 표준 품질 기준이 서로 다른 경우 테일러링 필요

문제

1 - 요구사항, 보유 기술, 목표 환경, 프로젝트 규모, 2 - 법적 제약사항, 표준 품질 기준
프로젝트 상황 및 특성에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업

30. 소프트웨어 개발 프레임워크

소프트웨어 개발 프레임워크

소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍쳐를 일반화하여 손쉽게 구현할 수 있도록 여러 가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템
선행 사업자의 기술에 의존하지 않는 표준화된 개발 기반으로 인해 사업자 종속성이 해소된다.

소프트웨어 개발 프레임워크의 주요 기능

예외처리
트랜잭션 처리
메모리 공유
데이터 소스 관리
서비스 관리
쿼리 서비스
로깅 서비스
사용자 인증 서비스

소프트웨어 개발 프레임워크의 종류

스프링 프레임워크
전자정부 프레임워크
닷넷 프레임워크

스프링 프레임워크

자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크이다.
동적인 웹 사이트의 개발을 위해 다양한 서비스를 제공한다.
전자정부 표준 프레임워크의 기반 기술로 사용되고 있다.

전자정부 프레임워크

대한민국의 공공부문 정보화 사업 시 효율적인 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍쳐를 제공하는 프레임워크
개발 프레임워크의 표준 정립으로 응용 소프트웨어의 표준화, 품질 및 재사용성의 향상을 목적으로 한다.
오픈 소스 기반의 범용화를 이룰 수 있다.
공개된 기술을 활용함으로써 특정 업체의 종속성을 배제하고 사업별 공통 컴포넌트의 중복 개발을 방지한다.

닷넷 프레임워크

Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크이다.
MicroSoft사에서 통합 인터넷 전략을 위해 개발하였다.
코드 실행을 관리하는 CLR(공용 언어 런타임)이라는 이름의 가상머신 상에서 작동한다.

소프트웨어 개발 프레임워크의 특성

모듈화
- 프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 소프트웨어의 품질을 향상시킨다.
- 프레임워크는 개발 표준에 의한 모듈화로 인해 유지 보수가 용이하다.
재사용성
- 프레임워크는 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능하다.
확장성
- 다형성을 통한 인터페이스 확장이 가능해 다양한 형태와 기능을 가진 애플리케이션 개발이 가능하다.
제어의 역흐름
- 개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상시킨다.

문제

재사용성, 모듈화
프레임워크
스프링 프레임워크

개발자 헤이린 🔜 프로덕트 매니저로 나아가는 중!

다음 포스트

[정보처리기사] 2장 - 데이터 입출력 구현

0개의 댓글