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

순서는 2021 시나공 기준, 자료는 2020 시나공 필/실기와 NCS 1000제를 참고했습니다.

 

 

소프트웨어 생명 주기

요구사항을 분석해서 설계하고 그에 맞게 개발한 후 소프트웨어의 품질이 항상 최상의 상태로 유지할수 있도록 관리하는 과정을 단계로 나눈 것

폭포수 모형
- 가장 오래되고 폭넓게 사용된 전통적인 모형
- 순서 : 타당성 검토 > 계획 > 요구 분석 (문서화) > 설계 > 구현 (코드화) > 검사 > 유지보수
- 고객의 요구사항이 명확할 때 사용 / 수정 X
📌 한 단계가 끝나야 다음 단계로 넘어가는 선형 순차적 모형

프로토타입 모형
- 요구사항이 명확하지 않을때 파악하기 위해 📌견본품을 만들어 최종 결과물 예측하는 모형
- 폭포수 모형의 단점 보완
- 순서 : 요구 수집 > 빠른 설계 > 프로토 타입 구축 > 고객 평가 > 프로토타입 조정 > 구현 > 요구 수집 …
- 사용자와 시스템 사이의 인터페이스에 초점
- 추가, 변경, 삭제 등 요구 즉시 반영가능 / 비용, 시간 ↑

나선형 모형
- 여러번의 개발 과정을 반복하면서 진행하여 점진적 모형
- 폭포수 모형 장점 + 프로토타입 모형 장점 + 위험 분석 기능 추가
📌 누락 및 추가된 요구사항 첨가 가능, 유지보수 과정 필요 X
- 대규모 프로젝트에 적합 / 비용 ↑ / 보헴이 제안

애자일 모형
- 고객과의 소통에 초점을 맞춘 방법론
- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기 반복
📌 고객의 요구사항에 우선순위 부여
- 소규모 프로젝트, 숙달된 개발자, 급변하는 요구사항에 적합

 

 

스크럼(Scrum) 기법

Product Backlog를 바탕으로 기술적으로 분할되고 재해석된 Sprint의 반복을 통한 제품완성을 구현하는 애자일 방법론
- 팀 스스로가 스크럼 팀을 구성, 개발 작업에 관한 모든 것을 스스로 해결
- 특징 : 투명성, 타임박싱, 커뮤니케이션, 경험주의 모델
- 구성요소 : Product Backlog, Sprint Backlog, Sprint, Daily 미팅, Burndown Chart

제품 책임자 (PO)	제품에 대한 이해도 높음, 의사 결정, 요구사항 작성 주체 > 개발 의뢰자, 사용자가 담당 비즈니스 관점에서의 중요도/우선순위 지정 및 갱신 스프린트 계획 수립까지만 역할 수행하고, 스프린트가 시작되면 팀 운영에 관여X
스크럼 마스터 (SM)	객관적인 시각에서 조언하는 조력자 일일 스크럼 회의 주관, 스크럼 원칙과 가치를 지키도록 지원함 개발 과정 속 장애 요소 를 찾아 제거함
개발팀 (DT)	PO와 SM을 제외한 모든 팀원 (개발자, 디자이너, 테스터 등) 매일 스크림 회의에 참여하여 진척 상황을 점검함

 

 

XP(eXtreme Programming) 기법

고객의 요구사항에 유연하게 대응하기 위해 고객 참여와 개발 과정의 반복을 극대화하여 개발 생산성 향상시키는 방법
- 핵심가치 : 의사소통, 단순성, 용기, 존중, 피드백

짝 프로그래밍	다른 사람과 함께 프로그래밍 책임 공동	테스트 주도 개발	테스트케이스 먼저 작성 자동화된 테스팅 도구 사용
전체 팀	각자 자신의 역할에 대한 책임	계속적인 통합	모듈 단위로 나눠서 개발된 코드들 지속적으로 통합
디자인 개선 / 리팩토링	프로그램 기능 변화 없이 시스템 재구성	소규모 릴리즈	요구변화 신속 대응

 

 

현행 시스템 파악

새로 개발하려는 시스템의 개발 범위를 명확히 설정하기 위해 구성과 제공 기능, 시스템 간 전달 정보, 사용되는 기술 요소, 소프트웨어, 하드웨어, 네트워크 구성 등을 파악

1단계	시스템 구성 파악	시스템 기능 파악	시스템 인터페이스 파악
	기간 업무 지원 업무	현재 제공하는 기능들을 주요 기능/ 하부 기능/세부 기능 구분하여 계층형 표시	주고받는 데이터의 종류 및 형식, 통신규약, 연계유형

 

2단계	아키텍처 구성 파악	소프트웨어 구성 파악
	업무 수행에 사용되는 기술요소들을 최상위 수준에서 계층별로 표현	소프트웨어 제품명, 용도, 라이센스 적용방식 등 명시

 

3단계	하드웨어 구성 파악	네트워크 구성 파악
	서버의 주요 사양, 수량, 이중화 적용여부	서버 위치, 서버 간 네트우크 연결 방식 장애 발생 원인을 찾아 복구하기 위한 용도로 활용

* 서버의 이중화 : 운용 서버의 장애 시 서비스를 계속 유지할 수 있도록 예비 서버에도 변경사항이 동일하게 복제되도록 관리

 

 

개발 기술 환경 파악

운영체제 (OS)
- 컴퓨터 시스템의 자원들을 효율적으로 관리, 사용자와 하드웨어 간 인터페이스 역할
- 요구사항 식별시 고려사항 : 가용성, 성능, 기술 지원, 주변 기기, 구축 비용
- 종류 : 컴퓨터 Windows, UNIX, Linux, MAs OS / 모바일 iOS, Android

데이터베이스 관리 시스템 (DBMS)
- 사용자와 데이터베이스 사이에서 사용자 요구에 따라 정보 생성, 데이터베이스 관리해주는 소프트웨어
- 데이터의 종속성과 중복성의 문제 해결
- 요구사항 식별시 고려사항 : 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

* JDBC : 자바에서 DB를 연결하여 데이터를 관리하게 해주는 인터페이스
* ODBC : 응용 프로그램에서 DB에 접근하여 데이터를 관리하게 해주는 표준 인터페이스

📌  웹 애플리케이션 서버 (WAS)
- 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하는 미들웨어
- 요구사항 식별시 고려사항 : 가용성, 성능, 기술 지원, 구축 비용
- 종류 : Tomcaat, JEUS, WebLogic 등

오픈 소스
- 누구나 제한 없이 사용할 수 있또록 소스 코드를 공개한 것으로 오픈 소스 라이선스를 만족하는 소프트웨어
- 요구사항 식별시 고려사항 : 라이선스 종류, 사용자 수, 기술의 지속 가능성

*가비지 컬렉션 : 실제로 사용되지 않지만 반환되지 않는 메모리 공간을 강제로 해제하여 사용할 수 있게 하는 메모리 관리 기법

 

 

요구사항

소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상 운영에 필요한 제약조건 등 나타냄

기능 요구사항	비기능 요구사항
시스템에서 제공되어야 할 특정 기능을 정의함	시스템의 전체적 품질이나 기능적 요구사항의 구현 시 고려해야하는 제약사항
사용자 요구사항	시스템 요구사항
사용자 관점	개발자 관점

 

📌 요구사항 개발 프로세스 (도분명확)

도출	분석	명세	확인/검증
주요 기법 - 인터뷰,  - 설문, 문헌 조사 - 프로토타입 - 벤치마킹 - 워크샵 -유스케이스	요구사항 중 명확하지 않은 부분을 발견하고 걸러내기 위한 과정	요구사항을 체계적으로 분석한 후 승인될 수 있도로 문서화 하는 것	주요 기법 - 요구사항 검토 - 프로토타이핑 - 모델 검증 - 인수 테스트

 

요구공학
- 무엇을 개발해야 하는지 요구사항 정의, 분석, 관리하는 프로세스를 연구하는 학문
- 목표 : 요구사항 변경의 원인과 처리 방법을 이해, 프로세스 품질 개선, 프로젝트 실패 최소화

 

요구사항 분석 기법

분류	개념 모델링	할당	협상	정형 분석
명확한 요구사항 분류	현실 개체를 단순화 하여 개념적으로 표현 한 것	요구사항 만족을 위한 구성 요소 식별	요구사항 충돌 해결	구문(Synatax)과 의미를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현 및 분석하는 과정

 

자료 흐름도(DFD ; Data Flow Diagram)
- 시스템의 처리 과정을 자료의 흐름에 중점을 두어 기술하는 분석용 도구
- 시각적으로 업무와 데이터의 흐름을 쉽게 볼 수 있음
- 일관성 유지
- 럼바우 방법론의 기능모델링

Process 프로세스	자료의 처리/변환 과정을 표현
Data Flow 자료 흐름	자료의 흐름 표현
Data Store 자료 저장소	파일, DB 등 저장소의 위치 표현
Terminator 단말	자료의 출처, 도착지 표현

 

자료 사전 (DD ; Data Dictionary)
- 자료 흐름도의 대상이 되는 모든 자료를 자세히 정의하기 위해 사용되는 도구
- 데이터를 설명하는 것으로 메타 데이터라고도 함

=	자료의 정의	+	자료의 연결
( )	자료의 생략	[ | ]	자료의 선택
{}	자료의 반복	**	자료의 설명

 

CASE
- 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발한 도구

HIPO (Hierarchical Input Process Output)
- Input - Process - Output으로 이루어진 모듈을 계층적으로 나타낸 도표
- 하향식 소프트웨어 개발을 위한 문서화 도구

가시적 도표	시스템의 전체적인 기능, 흐름을 보여주는 Tree 형태 구조도
총체적 도표	프로그램 구성 기능을 기술한 것, 전반적인 정보를 제공하는 도표
세부적 도표	총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

 

 

UML(Unified Modeling Language)

시스템 개발 과정에서 개발자들의 원활한 의사소통을 위해 표준화한 대표적 객체지향 모델링 언어
- 객체 지향 소프트웨어 개발과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합
- 구성요소 : 사물, 관계, 다이어그램

사물 (Things)
- 다이어그램 안에서 관계가 형성될 수 있는 대상

구조 사물	시스템의 개념적, 물리적 요소	클래스, 유스케이스, 컴포넌트, 노드 등
행동 사물	시공간에 따른 요소들의 행위	상호작용, 상태 머신 등
그룹 사물	요소들을 그룹으로 묶어서 표현	패키지
주해 사물	부가적인 설명, 제약조건	노트

 

관계 (Relationship)

- 사물과 사물 사이의 연관성을 표현

연관 관계

- 2개 이상의 사물이 서로 관련되어 있음
- 다중도(연관에 참여하는 객체의 개수) 선 위에 표시
- 서로에게 영향을 주는 양방향 관계의 경우 화살표 생략

 

집합 관계

- 하나의 사물이 다른 사물에 포함되어 있는 관계
- 클래스들 사이의 전체 또는 부분 같은 관계
- 전체 객체의 라이프 타임과 부분 객체의 라이프타임이 독립적 > 전체 객체가 사라져도 부분 객체는 남아있음

 

포함 관계

- 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
- 클래스들 사이의 전체 또는 부분 같은 관계
- 전체 객체의 라이프 타임과 부분 객체의 라이프타임이 의존적 > 전체 객체가 사라지면 부분 객체도 함께 사라짐

 

일반화 관계

- 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현
- 객체지향 개념에서 상속관계라고 함
- 한 클래스가 다른 클래스를 포함하는 상위 개념

 

의존 관계

- 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계

 

실체화 관계

- 사물이 할 수 있거나 해야하는 기능으로 서로를 그룹화할 수 있는 관계
- 책임들의 집합인 인터페이스와 이 책임들을 실제로 실현한 클래스들 사이의 관계

 

다이어그램

- 사물과 관계를 도형으로 표현한 것
- 여러 관점에서 시스템을 가시화한 뷰를 제공함으로써 의사소통에 도움

구조적 다이어그램
🔑 정적 모델링
📌 (베네딕트) 컴복배치 객클(개 클났다) 

컴포넌트 (Componetn) 다이어그램	실제(물리적) 구현 모듈인 컴포넌트 간의 관계나 인터페이스를 표현 논리적 클래스 혹은 클래스 자신의 구현에 대한 정보 포함 실질적인 프로그래밍 작업에 사용함 (구현 단계에서 사용)
복합체 (Composite Structure) 다이어그램	전체 클래스 안에 각 컴포넌트 클래스 표현함 클래스 내부 구조 파악에 용이
배치 (Deployment)다이어그램	시스템 하드웨어와 소프트웨어 간의 물리적 구조를 표현 노드와 의사소통(통신) 경로로 표현 구현단계에서 사용 컴포넌트 사이의 종속성 표현
패키지 (Package) 다이어그램	시스템 계층적인 구조를 표현 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계 표현
객체 (Object) 다이어그램	클래스의 여러 오브젝트 인스턴스를 나타내는 대신 실제 클래스를 사용 인스턴스를 특정 시점의 객체와 객체사이의 관계로 표현
클래스 (Class) 다이어그램	시스템 구조를 파악하고 구조의 문제점 도출 클래스와 클래스가 가지는 속성, 클래스 간의 관계 표현

 

행위 다이어그램
🔑동적 모델링

유스케이스(Use Case) 다이어그램	사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용 사용자와 사용 사례로 구성 - 구성요소 : 액터, 유스케이스, 관계 (포함, 확장)
시퀀스(Sequence) 다이어그램	객체와 객체간의 상호작용을 메시지 흐름으로 표현
커뮤니케이션(Communication) 다이어그램	상호작용에 참여하는 객체/컴포넌트 간의 관계를 명시적으로 표현
상태(State) 다이어그램	클래스의 객체가 가질 수 있는 모든 가능한 상태와 상태간의 전이를 표현
활동(Activity) 다이어그램	시스템 내부에 있는 객체의 활동 간의 처리 흐름을 모델링하는 범용적인 다이어그램 🔑 로직, 조건에 따른 처리 흐름을 순서에 따라 정의
상호작용 (Interaction Overview) 다이어그램	상호작용 다이어그램 간의 제어흐름을 표현
타이밍 (Timing) 다이어그램	객체 상태 변화와 시간 제약을 명시적으로 표현

 

소프트웨어 개발 방법론

소프트웨어 개발, 유지보수 등에 필요한 수행 방법과 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것
- 목적 : 소프트웨어의 생산성과 품질 향상

구조적 방법론
- 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론
- 목적 : 쉬운 이해 및 검증이 가능한 프로그램 코드 생성
- 분활과 정복 원리를 적용

타당성 검토

계획

요구사항

설계

구현

시험

운용/유지보수

 

정보공학 방법론
- 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료 중심의 방법론
- 정보 시스템 개발 주기를 이용하여 대규모 정보 시스템 구축

정보 전략 계획 수립

업무 영역 분석

업무 시스템 설계

업무 시스템 구축

 

객체지향 방법론
- 현실 세계의 개체를 하나의 객체로 만들어 조립해서 필요한 소프트웨어를 구현하는 방법론
- 구성요소 : 객체, 클래스, 메시지
📌 기본 원칙 : 캡슐화, 정보 은닉, 추상화, 상속성, 다형성

요구 분석

설계

구현

테스트 및 검증

인도

 

컴퓨넌트 기반 방법론 (CBD ; Component Based Design)
- 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
📌 컴포넌트의 재사용 > 시간 노력 절약, 유지보수비용 최소화, 생산성 및 품질 향상

개발 준비

분석

설계

구현

테스트

전개

인도

 

애자일 방법론
- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하며 과정 진행하는 방법론
- 종류 : XP(익스트림 프로그래밍), 스크럼, 린, 칸반, 크리스탈 등

* Lean 개발 방법론 : 품질 기법, 낭비요소 제거
* Kanban : Workflow 가시화, 작업 중인 항목의 제한 및 소요시간 측정 작업 지시서를 적용

제품 개열 방법론
- 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
- 임베디드 소프트웨어에 적합
- 영역공학, 응용공학으로 구분

 

 

S/W 공학의 발전적 추세

소프트웨어 재사용
- 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
- 소프트웨어 개발의 품질과 생산성을 높이기 위한 방법
- 기존에 개발된 소프트웨어와 경험, 지식 등을 새로운 소프트웨어에 적용

소프트웨어 재사용 방법

합성 중심	블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법 (=블록 구성 방법)
생성 중심	추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법 (=패턴 구성 방법)

소프트웨어 재공학
- 기존 시스템을 이용하여 보다 나은 시스템을 구축 + 새로운 기능을 추가 = 소프트웨어 성능을 향상
- 유지보수 비용이 소프트웨어 개발 비용의 대부분을 차지 > 유지보수 생산성 향상을 통해 소프트웨어 위기를 해결하는 방법
- 기존 소프트웨어 데이터와 기능들의 개조 및 개선을 통해 유지보수성과 품질을 향상 시킴

소프트웨어 재공학의 이점
- 소프트웨어 품질 향상
- 소프트웨어의 생산성 증가
- 소프트웨어의 수명 연장
- 소프트웨어의 오류 감소

 

CASE (Computer Aided Software Engineering)
- 소프트웨어 개발 과정에서 사용되는 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용해 자동화 하는것
- 객체지향 시스템, 구조적 시스템 등 다양한 시스템에서 활용되는 자동화 도구
- 소프트웨어 생명 주기의 전체 단계를 연결하고 자동화하는 통합된 도구를 제공
- 소프트웨어 개발 도구와 방법론이 결합, 정형화된 구조 및 법을 소프트웨어 개발에 적용하여 생산성 향상 구현

CASE의 주요 기능
- 소프트웨어 생명 주기 전 단계의 연결
- 다양한 소프트웨어 개발 모형 지원
- 그래픽 지원

 

 

비용 산정 기법

- 비용산정을 너무 높게 산정할 경우 > 예산 낭비, 일의 효율성 저하
- 비용산정을 너무 낮게 산정할 경우 > 개발자 부담 가중, 품질문제 발생

소프트웨어 비용 결정 요소
- 프로젝트 요소 : 제품 복잡도, 시스템 규모, 요구되는 신뢰도
- 자원 요소 : 인적 자원, 하드웨어 자원, 소프트웨어 자원
- 생산성 요소 : 개발자 능력, 개발 기간

 

하향식 산정 기법

- 과거 유사 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회으릴 통해 산정하는 비과학적 방법
- 전체 비용을 산정 후 각 작업별 비용을 세분화

전문가 감정 기법
- 경험이 많은 두명 이상의 전문가에게 산정 의뢰
- 가장 편리하고 신속하나, 개인적이고 주관적일 수 있음

델타이 기법
- 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정
- 한명의 조정자와 여러 전문가로 구성
- 의견이 거의 일치할 때 까지 과정 반복

 

상향식 산정 기법

- 프로젝트의 세부적인 작업 단위별로 비용 산정 후 집계하여 전체 비용 산정하는 방법

📌 원시 코드 라인 수 (LOC) 기법
- 노력(인월)  = 개발 기간 X 투입 인원
　　　　　　= LOC / 1인당 월평균 새산 코드 라인 수
- 개발 비용 = 노력(인월) X 단위 비용 (1인당 월평균 인건비)
- 개발 기간 = 노력(인월) / 투입 인원
- 생산성 = LOC / 노력 (인월)

개발 단계별 인월수 기법
- 각 기능을 구현시키는 데 필요한 노력을 생명 주기의 각 단계별로 산정하는 기법으로 LOC 기법보다 더 정확함

 

수학적 산정 기법

- 상향식 비용 산정 기법
- 경험적 추정 모형, 실험적 추정 모형이라고도 함
- 목표 : 개발 비용 산정의 자동화
- 과거 유사한 프로젝트를 기반으로 경험적으로 유도

COCOMO 모형
- 보헴이 제안, LOC에 의한 비용 산정 기법
- 강도 분석 및 유연성이 높아 소프트웨어 개발비 견적에 널리 통용됨

📌 COCOMO 소프트웨어 개발 유형

조직형 (Organic Mod)	반분리형 (Semi-Detached Mode)	내장형 (Embedded Mode)
중/소 규모의 소프트웨어 일괄 자료 처리 5만 라인 이하	중간형 규모 30만 라인 이하	최대형 규모 30만 라인 이상

COCOMO 모형 종류

기본형 (Basic)	중간형 (Intermediate)	발전형 (Detailed)
소프트웨어 크기와 개발 유형만을 이용하여 산정	4가지 특성 (제품, 컴퓨터, 개발 요원, 프로젝트)의 15가지 요인에 의해 비용 산청	개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용 산정

 

Putnam 모형
- 소프트웨어 생명주기의 전 과정 동안에 사용될 노력의 분포를 가정하는 모형
- 생명 주기 예측 모형이라고도 하며, Rayleigh-Norden 곡선의 노력분포도를 기초로 함
- 대형 프로젝트에 적합, 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소

FP(기능점수) 모형
- 알브레히트가 제안한 모형
- 소프트웨어의 기능을 증대시키는 요인별로 가중치 부여하고 합산하여 산출된 총 기능 점수와 영향도를 이용하여 비용 산정

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

 

 

프로젝트 일정 계획

프로젝트 프로세스를 이루는 소작업을 파악하고 예측된 노력을 분배하여 소작업의 순서와 일정을 정하는 것

PERT (프로그램 평가 및 검토 기술)
- 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크
- 개발 경험이 없어 소요 기간 예측이 어려운 프로젝트에 사용
- 노드와 간선으로 구성되며 원 노드에는 작업 / 간선에는 낙관치 기대치 비관치 표시

시나공 유투브

CPM (임계 경로 기법)
- 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간 예측
- 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타냄

시나공 유투브

간트 차트
- 작업이 언제 시작/종료되는지에 대한 작업 일정을 막대 도표로 표시하는 일정표
- 시간선 (Time-Line) 차트
- 중간 목표 미달 성 시 이유과 기간 예측 가능하고
- 자원 배치와 인원 계획에 유용하게 사용 됨

 

 

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

프로젝트 관리 조건을 확인하여 어떤 방법론으로 소프트웨어를 개발할지를 결정하는 것

프로젝트 관리
- 주어진 기간 내 최소 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 활동
- 일정 관리, 비용 관리, 인력 관리, 위험 관리, 품질 관리

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

 

 

소프트웨어 개발 표준

소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준

SPICE (소프트웨어 처리 개선 및 능력 평가 기준)
- 공식 명칭 ISO/IEC 15504
- 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
- 프로세스 구성 (프로세스 범주 5, 새부 프로세스 40) :  고객-공급자, 공학, 지원, 관리, 조직
- 수행능력 6단계 : 불완전 - 수행 - 관리 - 확립 - 예측 - 최적화

ISO/IEC 12207
- ISO(국제표준화기구) 에서 만든 표준 소프트웨어 생명 주기 프로세스
- 소프트웨어 개발, 운영, 유지보수 등 체계적으로 관리하기 위한 생명주기 표준 제공
- 기본 생명 주기 프로세스, 지원 생명 주기 프로세스, 조직 생명 주기 프로세스

CMMI(능력 성숙도 통합 모델)
- 미국 카네기 멜론 대학교의 SEI (소프트웨어 공학연구소)
- 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도 평가 모델

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

 

 

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

프로젝트의 특성과 필요에 따라 소프트웨어 개발 방법론의 프로세스를 수정 및 보완하는 작업

테일러링 고려사항

내부적 요건	목표 환경, 요구사항, 프로젝트 규모, 보유 기술
외부적 요건	법적 제약사항, 표준 품질 기준

테일러링 기법 4가지 : 프로젝트 규모와 복잡도, 프로젝트 구성원, 팀내 방법론 지원, 자동화

 

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

소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉬운 구현을 위한 여러 기능을 제공해주는 시스템
- 주요 기능 : 예외 처리, 트랜잭션 처리, 메모리 공유, 데이터 소스 관리, 서비스 관리 등
- 종류 : 스프링 프레임워크, 전자정부 프레임워크, 닷넷 프레임워크 등 

📌 프레임워크 특성

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