소프웨어 개발 방법론
소프트웨어 생명주기 모델
1. 소프트웨어 생명주기 (SDLC : Software Development Life Cycle) 모델 개념
- 소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다.
- 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지의 모델
2. 소프트웨어 생명주기 모델 프로세스
| 순서 |
프로세스 |
설명 |
활동 |
| 1 |
요구사항 분석 |
- 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경되니 제품에 부합하는 요구와 조건을 결정하는 단계 - 개발할 소프트웨어의 기능과 제약 조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계 |
- 기능 요구사항 - 비기능 요구사항 |
| 2 |
설계 |
- 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계 |
- 시스템 구조 설계 - 프로그램 설계 - 사용자 인터페이스 설계 |
| 3 |
구현 |
- 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계 - 프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하는 단계 |
- 인터페이스 개발 - 자료 구조 개발 - 오류 처리 |
| 4 |
테스트 |
- 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계 |
- 단위 테스트 - 통합 테스트 - 시스템 테스트 - 인수 테스트 |
| 5 |
유지보수 |
시스템이 인수되고 설치된 후 일어나는 모든 활동 |
- 예방, 완전, 교정, 적응 유지보수 |
- 소프트웨어 생명주기 모델 종류
소프트웨어 생명주기 모델 종류로는 폭포수 모델, 프로토타이핑 모델, 나선형 모델, 반복적 모델이 있다.
| 종류 |
설명 |
| 폭포수 모델 |
- 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어 가는 모델 - 가장 오래된 모델 - 선형 순차적 모형으로 고전적 생명주기 모형이라고도 함 - 모형의 적용 경험과 성공 사례가 많음 - 단계별 정의와 산출물이 명확 요구사항 변경이 어려움 절차 : 타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수 |
| 프로토타이핑 모델 |
- 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델 - 프로토타입은 발주자나 개발자 모두에게 공동의 참조 모델을 제공 - 프로토타입은 구현 단계의 구현 골격 |
| 나선형 모델 |
- 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델 절차 : 계획 및 정의 → 위험 분석 → 개발 → 고객 평가 |
| 반복적 모델 |
- 구축 대상을 나눠 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증적으로 완성시키는 SDLC 모델 - 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델 |
소프트웨어 생명주기 모델 간 비교:
| 구분 |
폭포수 모델 |
프로토타이핑 모델 |
나선형 모델 |
반복적 모델 |
| 절차도 |
|
|
|
|
| 특징 |
순차적 접근 |
프로토타입 개발 |
위험 분석, 반복 개발 |
증분방식으로 병행 개발 |
| 장점 |
이해가 용이하며 관리가 편리 |
요구분석 용이 타당성 검증 가능 |
위험성 감소와 변경에 유연한 대처 |
병행 개발로 인한 일정 단축 가능 |
| 단점 |
요구사항 변경이 어려움 |
프로토타입 폐기에 따른 비용 증가 |
단계 반복에 따른 관리 어려움 |
병행 개발에 따른 관리 비용 증가 |
2. 소프트웨어 개발 방법론
- 소프트웨어 개발 방법론 개념
- 소프트웨어 개발 방법론은 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법이다.
- 소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론이다
- 소프트웨어 개발 방법론 종류
- 소프트웨어 개발 방법론 종류로는 구조적 방법론, 정보공학 방법론, 객체 지향 방법론, 컴포넌트 기반 방법론(CBD), 애자일 방법론, 제품 계열 방법론이 있다.
- 소프트웨어 개발 방법론 종류
| 종류 |
설명 |
| 구조적 방법 |
- 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론 - 프로세스 중심의 하향식 방법론 - 구조적 프로그래밍 표현을 위해 나씨-슈나이더만 차트 사용 나씨-슈나이더만 차트 특징: - 논리의 기술에 중점을 둔 도형식 표현 방법 - 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현 - 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합 |
| 정보공학 방법론 |
- 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론 - 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론 |
| 객체 지향 방법론 |
- 객체라는 기본 단위로 시스템을 분석 및 설계하는 방법론 - 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론 - 객체 클래스, 메시지를 사용 |
| 컴포넌트 기반 방법론 |
- 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론 - 개발 기간 단축으로 인한 생산성 향상 - 새로운 기능 추가 쉬움(확장성) - 소프트웨어 재사용이 가능 |
| 애자일 방법론 |
- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론 - 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론 |
| 제품 계열 방법론 |
- 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론 - 임베디드 소프트웨어를 작성하는데 유용한 방법론 - 영역 공학과 응용 공학으로 구분 영역 공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역 응용 공학 : 제품 요구분석, 제품 설계, 제품을 구현하는 영역 |
- 애자일
- 애자일 방법론의 개념
- 애자일 방법론은 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론이다.
- 개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아서 유동적으로 개발할 수 있다.
- 애자일 방법론 등장 배경
- 애자일 방법론은 기존 개발 방법론의 한계를 극복하기 위해 등장했다.
- 소프트웨어 개발 환경의 변화 : 소프트웨어 개발 트렌드가 모바일 환경으로 변화, 시장 적시성과 잦은 배포의 중요성 부각
- 기존 개발 방법론의 한계 : 전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어려움, 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성 증가
- 애자일 방법론의 유형
- 애자일 방법론은 대표적으로 XP, 린(Lean), 스크럼(SCRUM) 등이 있다.
- 애자일 방법론 유형
- xp
- 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
- 1‒ 3주의 반복(Iteration) 개발주기
- 5가지 가치와 12개의 실천항목이 존재
- XP의 5가지 가치
| 가치 |
설명 |
| 용기 |
용기를 가지고 자신감 있게 개발- 코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드는 리펙토링 할 수 있는 용기 |
| 단순성 |
필요한 것만 하고 그 이상의 것들은 하지 않음 |
| 의사소통 |
개발자, 관리자, 고객 간의 원활한 소통 |
| 피드백 |
의사소통에 대한 빠른 피드백 |
| 존중 |
팀원 간의 상호 존중 |
- 12가지 기본원리
| 기본원리 |
설명 |
| 짝 프로그래밍 |
개발자 둘이서 짝으로 코딩하는 원리 |
| 공동 코드 소유 |
시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리 |
| 지속적인 통합 |
매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리 |
| 계획 세우기 |
고객이 요구하는 비즈니스 가치를 정의하고 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 언리 |
| 작은 릴리즈 |
작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리 |
| 메타포어 |
공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리 |
| 간단한 디자인 |
현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리 |
| 테스트 기반 개발 TDD |
작성해야 하는 프로그램에 대한 테스트를 통화할 수 있도록 실제 프로그램의 코드를 작성한다는 원리 |
| 리펙토링 |
프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템을 재구성한다는 원리 |
| 40시간 작업 |
개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리 |
| 고객 상주 |
개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리 |
| 코드 표준 |
효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리 |
- 스크럼
- 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
| 주요개념 |
설명 |
| 백로그 (Backlog) |
- 제품과 프로젝트에 대한 요구사항 |
| 스프린트 (Sprint) |
- 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상 |
| 스크럼 미팅 (Scrum Meeting) |
- 매일 15분 정도 미팅으로 To-Do List 계획수립 - 데일리 미팅(Daily Meeting)이라고도 함 |
| 스크럼 마스터 (Scrum Master) |
- 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람 |
| 스프린트 회고 (Sprint Retrospective) |
- 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록 - 해당 스프린트가 끝난 시점이나 일정 주기로 시행 |
| 번 다운 차트 (Burn Down Chart) |
- 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트 - 백로그는 보통 수직축에 위치하며 시간은 수평축에 위치 |
- 린
- 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
- JIT(Just In Time), 칸반(Kanban) 보드. 사용
- 7가지 원칙 : 낭비제거, 품질 내재화, 지식 창출, 늦은 확정 빠른 인도, 사람 존중 전체 최적화
- 애자일과 전통적 방법론 비교
| 비교 대상 |
애자일 방법론 |
전통적 방법론 |
| 계획수립 |
유동적 범위 설정 |
확정적 범위 설정 |
| 업무수행 |
팀 중심 업무 수행 |
관리자 주도적 명령과 통제 개인 단위로 업무수행 |
| 개발/검증 |
반복 주기 단위로 소프트웨어를 개발/검증 |
분석/ 설계/ 구현/ 테스트를 순차적으로 수행 |
| 팀관리 |
업무 몰입, 팀 평가 |
경쟁, 개별 평가 |
| 문서화 |
문서화보다는 코드를 강조 |
상세한 문서화를 강조 |
| 성공요소 |
고객 가치 전달 |
계획/일정 준수 |
| 유형 |
XP, 스크럼, 린 |
폭포수, 프로토타입, 나선형 |
3. 객체지향 분석 방법론
- 객체 지향(Object Oriented) 개념
- 객체 지향은 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법이다
- 객체 지향 구성요소
| 구성요소 |
설명 |
| 클래스(Class) |
• 특정 객체 내에 있는 변수와 메서드를 정의하는 일종의 틀 • 객체 지향 프로그래밍에서 데이터를 추상화하는 단위 • 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현 • 속성은 변수의 형태로, 행위는 메서드 형태로 선언 |
| 객체 (Object) |
• 물리적, 추상적으로 자신과 다른 것을 식별 가능한 대상 • 클래스에서 정의한 것을 토대로 메모리에 할당됨 • 객체마다 각각의 상태와 식별성을 가짐 |
| 메서드 (Method) |
• 클래스로부터 생성된 객체를 사용하는 방법 • 객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산 • 전통적 시스템의 함수(Function) 또는 프로시저(Procedure)에 해당하는 연산 기능 |
| 메시지 (Message) |
• 객체 간 상호 작용을 하기 위한 수단 • 객체에게 어떤 행위를 하도록 지시하는 방법 • 객체 간의 상호 작용은 메시지를 통해 이루어짐 • 메시지는 객체에서 객체로 전달됨 |
| 인스턴스 (Instance) |
• 객체 지향 기법에서 클래스를 통해 만든 실제의 실형 객체 • 클래스에 속한 각각의 객체 • 실제로 메모리상에 할당 |
| 속성 (Property) |
• 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의 • 성질, 분류, 식별, 수량, 현재 상태 등에 대한 표현 |
- 객체 지향 기법
| 기법 |
설명 |
| 캡슐화 (Encapsulation) |
- 서로 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로 드러내는 기법 • 결합도가 낮아지고 재사용이 용이 • 인터페이스가 단순화됨 • 정보 은닉과 관계가 깊음 • 변경 발생 시 오류의 파급 효과가 적음 |
| 상속성 (Inheritance) |
• 상위 클래스의 속성과 메서드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법 |
| 다형성 (Polymorphism) |
• 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력 • 상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질 • 오버로딩, 오버라이딩이 대표적 오버로딩 (Overloading) - 매개변수의 유형과 개수를 다르게 하여 같은 이름의 메서드를 여러 개 가지는 기법 오버라이딩(Overriding) - 상위 클래스에서 정의한 일반 메서드의 구현을 하위 클래스에서 무시하고 재정의할 수 있는 기법 |
| 추상화 (Abstraction) |
• 공통 성질을 추출하여 추상 클래스를 설정하는 기법 • 종류로는 과정 추상화, 자료 추상화, 제어 추상화가 있음 |
| 정보 은닉 (Information Hiding) |
• 코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술 • 필요하지 않은 정보는 접근할 수 없도록 하여 한 모듈 또는 하부 시스템이 다른 모듈의 구현에 영향을 받지 않게 설계됨(고려되지 않은 영향인 Side-Effect들을 최소화) • 모듈 내부의 자료 구조와 접근 동작들에만 수정을 국한하지 않기 때문에 요구사항 등 변화에 따른 수정이 가능 • 모듈 사이의 독립성을 유지하는 데 도움을 줌 • 설계에서 은닉되어야 할 기본 정보로는 IP 주소와 같은 물리적 코드, 상세 데이터 구조 등이 존재 |
| 관계성 (Relationship) |
• 두 개 이상의 엔터티 형에서 데이터를 참조하는 관계를 나타내는 기법 • 종류로는 연관화, 분류화, 집단화, 일반화, 특수화가 있음 연관화 • is-member-of 관계 • 클래스와 객체의 참조 및 이용관계 • 같은 계층에 속하는 클래스들 사이의 상호 의존성을 보여주는 비계층적 관계성을 나타냄 집단화 • is part of 관계, part-whole 관계 • 서로 관련 있는 여러 개의 객체를 묶어 한 개의 상위 객체를 만드는 특징이 있음 • 일반화와 달리 상위 클래스의 성질들이 하위 클래스로 상속되지는 않음 분류화 • is-instance-of 관계 • 공통된 속성에 의해 정의된 객체 구성원들의 인스턴스 일반화 • is-a 관계 • 클래스들 간의 개념적인 포함 관계 • 상위 클래스의 특성을 하위 클래스가 상속받음 특수화 • is-a 관계 • 상위 클래스의 특성들을 상속받으면서 하위 클래스에서 나름대로 수정을 가하고 자기 자신의 고유한 특성을 갖는 관계 |
- 객체 지향 설계 원칙
| 원칙 |
설명 |
| 단일 책임의 원칙 (SRP; Single Responsibility Principle) |
• 하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다는 원칙 • 객체 지향 프로그래밍의 5원칙 중 나머지 4원칙의 기초 원칙 |
| 개방 폐쇄 원칙 (OCP; Open Close Principle) |
• 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙 |
| 리스코프 치환의 원칙 (LSP; Liskov Substitution Principle) |
• 서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 한다는 원칙 |
| 인터페이스 분리의 원칙 (ISP; Interface Segregation Principle) |
• 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙 • 객체 설계 시 특정 기능에 대한 인터페이스는 그 기능과 상관없는 부분이 변해도 영향을 받지 않아야 한다는 원칙 |
| 의존성 역전의 원칙 (DIP; Dependency Inversion Principle) |
• 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙 |
- 객체 지향 분석의 개념
- 객체 지향 분석 (OOA； Object Oriented Analysis)은 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법이다.
- 객체 지향 분석 방법론 종류
| 종류 |
만든이 |
설명 |
| OOSE (Object Oriented Software Engineering) |
야콥슨 (Jacobson) |
• 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용하는 방법론 • 분석, 설계, 구현 단계로 구성 • 기능적 요구사항 중심의 시스템 |
| OMT (Object Modeling Technology) |
럼바우 (Rumbaugh) |
• 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론 • 분석 절차는 객체 모델링 - 동적 모델링 - 기능 모델링 순서로 진행 객체 모델링 (Object Modeling) • 정보 모델링(Information Modeling)이라고도 함 • 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링 • 객체 다이어그램을 활용하여 표현 동적 모델링 (Dynamic Modeling) • 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링 • 상태 다이어그램을 활용하여 표현 기능 모델링(Function Modeling) • 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링 • 자료 흐름도(DFD)를 활용하여 표현 |
| OOD (Object Oriented Design) |
부치 (Booch) |
• 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론 • 분석과 설계의 분리가 불가능 • 분석하는 데 이용된 객체 모델의 설계 시 적용 |
- 추가적으로 코드-요든(Coad—Yourdon) 방법론은 E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석 방법이다.
- 워프-브록(Wirfs-Brock) 방법론은 분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 분석 방법이다
- 기능 모델링 주요 기법
- 데이터 흐름도(DFD； Data Flow Diagram)
- 데이터 흐름도 개념
- 데이터 흐름도는 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림이다.
- 시스템 분석과 설계에서 매우 유용하게 사용되는 다이어그램이다.
- 자료 흐름 그래프 또는 버블(Bubble) 차트라고도 한다.
- 데이터 흐름도 특징
- 구조적 분석 기법에 이용된다.
- 데이터(Data)의 흐름에 중심을 두는 분석용 도구이다.
- 제어 (Control) 의 흐름은 중요하지 않다.
- 시간 흐름을 명확하게 표현할 수는 없다.
- 자료 사전
- 자료 사전(DD； Data Dictionary) 개념
- 자료 사전은 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들 간의 관계, 관계 값, 범위, 단위들을 구체적으로 명시하는 사전이다.
- 자료 사전은 파일 혹은 데이터베이스에 있는 자료에 대한 자료 또는 각 자료 항목에 주어진 이름과 길이 그리고 서술과 같은 데이터를 포함하는 참조를 위한 작업이다.
- 자료 사전의 작성 목적
- 자료 사전은 조직에 속해 있는 다른 사람들에게 특정한 자료 용어가 무엇을 의미하는지를 알려주기 위하여, 용어의 정의를 조정하고 취합하고 문서로 명확히 하는 목적이 있다.
- 자료 흐름도에 나타나는 어떤 자료의 흐름도 자료 사전에 정의되어 있어야 한다
프로젝트 관리
- 프로젝트 관리
- 프로젝트 관리의 개념
- 프로젝트 관리는 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동이다.
- 프로젝트 관리는 소프트웨어 개발 계획을 세우고 분석, 설계, 구현 등의 작업을 통제하는 것으로 소프트웨어 생명 주기의 전 과정에 걸쳐서 진행된다.
- 소프트웨어 프로젝트를 성공적으로 수행하기 위해서는 수행할 작업의 범위, 필요한 자원, 수행 업무, 비용, 추진 일정들을 관리해야 한다.
- 프로젝트 관리 대상
- 프로젝트 관리 대상에는 계획 관리, 품질 관리, 범위 관리 등이 있다.
| 관리 대상 |
설명 |
| 계획 관리 |
프로젝트 계획, 비용 산정, 일정 계획, 조직 계획에 대한 관리 |
| 품질 관리 |
품질 통제 및 품질 보증 |
| 범위 관리 |
이해관계자가 요청한 모든 요구사항이 프로젝트 범위에 포함되었는지 보장하고, 필요한 작업만 수행될 수 있도록 관리 |
- 프로젝트 관리 3대 요소
- 효과적인 프로젝트 관리를 위한 3대 요소(3P)는 사람, 문제, 프로세스이다.
| 요소 |
설명 |
| 사람(People) |
프로젝트 관리에서 가장 기본이 되는 인적 자원 |
| 문제 (Problem) |
사용자의 입장에서 문제를 분석하여 인식함 |
| 프로세스 (Process) |
소프트웨어 개발에 필요한 전체적인 작업 계획 및 구조(Framework |
- 비용산정 모형
- 비용산정 모형 개념 : 비용산정 모형은 소프트웨어 규모파악을 통한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식이다.
- 비용산정 모형 분류
| 분류 |
설명 |
종류 |
| 하향식 산정방법 |
• 경험이 많은 전문가에게 비용 산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식 |
• 전문가 판단 • 델파이 기법 |
| 상향식 산정방법 |
• 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식 |
• 코드 라인 수(LOC) • Man Month • COCOMO 모형 • 푸트남 모형 • 기능점수 (FP) 모형 |
- 비용산정 모형 종류
- LoC(Lines of Code) 모형
- LoC 모형은 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식이다.
- 측정이 쉽고 이해하기 쉬워 많이 사용한다.
- 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정한다.
- 예측치 =(낙관치+4*중간치 + 비관치)/6
- 비관치: 가장 많이 측정된 코드 라인 수
- 중간치: 측정된 모든 코드 라인 수의 평균
- 낙관치: 가장 적게 측정된 코드 라인
- Man Month 모형 [2020년 1회]
- Man Month 모형은 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식이다.
- (Man Month) = (LoC)/(프로그래머의 월간 생산성)
- (프로젝트 기간) = (Man Month)/(프로젝트 인력)
- COCOMO(COnstructive COst MOdel) 모형
- COCOMO 모형은 보헴(Boehm)이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식이다.
비용산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 산정한다.
비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용된다.
- 규모에 따라 유형이 조직형(= 기본형, 단순형), 반 분리형, 임베디드형으로나뉜다.
| 유형 |
설명 |
| 조직형 (Organic Mode) |
• 기관 내부에서 개발된 중소규모의 소프트웨어로 일괄 자료 처리나 과학 기술 계산용, 비즈니스 자료 처리 개발에 적용 • 5만(50KDSI) 라인 이하의 소프트웨어를 개발하는 유형 |
| 반 분리형 (Semi-Detached Mode) |
• 단순형과 임베디드형의 중간형 • 트랜잭션 처리 시스템이나, 데이터베이스 관리 시스템, 컴파일러, 인터프리터와 같은 유틸 개발에 적용 • 30만(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형 |
| 임베디드형 (Embedded Mode) |
• 초대형 규모의 트랜잭션 처리 시스템이나 운영체제, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적용 • 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형 |
- 푸트남(Putnam) 모형
- 푸트남 모형은 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식이다.
- 푸트남이 제안한 것으로 생명주기 예측 모형이라고 한다.
- 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
- 기능점수 (FP; Function Point) 모형
- 기능점수 모형은 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 종 기능의 점수를 계산하여 비용을 산정하는 방식이다
- 기능점수(FP) = 총 기능점수 x [0.65 + (0.1 x 총 영향도)]
- 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여한다.
- 일정관리 모델
- 일정관리 모델 개념
- 일정관리 모델은 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리 하는 모델이다.
- 일정관리 모델 종류
- 일정관리 모델 종류는 공정법, PERT, 중요 연쇄 프로젝트 관리가 있다.
| 모델 |
설명 |
| 주공정법 (CPM; Critical Path Method) |
• 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법 • 모든 자원 제약사항을 배제한 상태로 프로젝트의 시작과 끝을 나타내는 노드(Node)와 노드 간을 연결을 통해 공정을 계산하기 위한 액티비티(Activity) 표기법 |
| PERT (Program Evaluation and Review Technique) |
• 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법 |
| 중요 연쇄 프로젝트 관리 (CCPM; Critical Chain Project Management) |
• 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법 |
- 위험 관리
- 위험 관리(Risk Management) 개념
- 위험 관리는 프로젝트에 내재된 위험 요소를 인식하고 그 영향을 분석하여 이를 관리하는 활동이다.
- 위험 관리는 프로젝트를 성공시키기 위하여 위험 요소를 사전에 예측, 대비하는 모든 기술과 활동을 포함한다.
- 위험의 종류
- 소프트웨어 개발 시 나타나는 일반적인 위험 요소에는 인력 부족, 예산 관리, 일정 관리, 사용자 요구사항 변경 등이 있으며, 이중 가장 대표적인 위험 요소는 사용자 요구사항 변경이다.
- 위험의 종류에는 알려진 위험, 예측 가능한 위험, 예측 불가능한 위험이 있다.
| 종류 |
설명 |
| 알려진 위험 |
프로젝트 계획서, 기술적 환경, 정보 등에 의해 발견될 수 있는 위험 |
| 예측 가능한 위험 |
과거 경험으로부터 예측할 수 있는 위험 |
| 예측 불가능한 위험 |
사전 예측이 매우 어려운 위험 |
- 위험 대응 전략
| 전략 |
설명 |
| 회피 |
|
| (Avoidance) |
발생 가능성을 원천적으로 제거하는 전략 |
| 전가 |
|
| (Transference) |
위험에 대한 책임을 제3자에게 넘기는 전략 |
| 완화 |
|
| (Mitigation) |
위험 발생 가능성을 감소시키거나 영향력을 감소시키는 전략 |
| 수용 |
|
| (Acceptance) |
위험을 그대로 받아들이는 전략 |
