-
소프트웨어 개발 방법론의 필요성
- 소프트웨어 개발 방법론의 구성 요소
| 구성요소 |
내용 |
비고 |
| 작업절차 |
- 프로젝트 수행 시 이루어지는 작업 단계의 체계
- 단계별 활동 및 활동별 세부 작업 열거, 활동의 순서 명시
|
단계.활동.작업 |
| 작업방법 |
- 각 단계별로 수행해야 하는 일
- 절차/작업 방법(누가, 언제, 무엇을 작업하는지를 기술)
|
작업방법 |
| 산출물 |
- 각 단계별로 만들어야 하는 산출물의 목록 및 양식
|
설계서 등 |
| 관리 |
- 프로젝트의 진행 기록
- 계획 수립, 진행 관리, 품질, 외주, 예산, 인력 관리 등 기록
|
계획서, 실적, 품질보증 등 |
| 기법 |
- 각 단계별로 작업 수행 시 기술 및 기법의 설명
|
구조적, 객체지향,ERD, DFD |
| 도구 |
- 기법에서 제시된 각 기법별 지원 도구에 대한 구체적인 사용 표준 방법
|
CASE 등 |
| |
구조적 방법론 |
정보 공학 방법론 |
객체지향 방법론 |
CBD 방법론 |
| 시기 |
1970년대 |
1980년대 |
1990년대 |
2000년대 |
| 중점 |
기능중심 |
자료구조 중심 |
객체 중심 |
컴포넌트 중심 |
| 장점 |
|
|
|
- 생산성, 품질, 비용, 위험 개선
- 소프트웨어 위기 극복
|
| 단점 |
- 기능은 불안정한 요소
- 데이터가 정보 은닉이 안됨
- 유지보수, 재사용성이 낮음
|
- 애플리케이션은 여전히 기능적 설계
- 기능의 유지보수, 재사용성이 낮음
|
|
- 컴포넌트 유통환경 개선
- 테스트 환경의 부족
- 컴포넌트의 평가, 인증 환경의 미흡
|
| |
구조적 방법론 |
정보 공학 방법론 |
객체지향 방법론 |
CBD 방법론 |
| 시기 |
1970년대 |
1980년대 |
1990년대 |
2000년대 |
| 중점 |
기능중심 |
자료구조 중심 |
객체 중심 |
컴포넌트 중심 |
| 장점 |
|
|
|
- 생산성, 품질, 비용, 위험 개선
- 소프트웨어 위기 극복
|
| 단점 |
- 기능은 불안정한 요소
- 데이터가 정보 은닉이 안됨
- 유지보수, 재사용성이 낮음
|
- 애플리케이션은 여전히 기능적 설계
- 기능의 유지보수, 재사용성이 낮음
|
|
- 컴포넌트 유통환경 개선
- 테스트 환경의 부족
- 컴포넌트의 평가, 인증 환경의 미흡
|
-
소프트웨어 개발 방법론 적용 시 문제점 및 개선 대책
-
문제점
- 프로젝트 특성을 무시한 특정 방법론 강요
- 형식적인 적용으로 무용지물인 문서만 양산
- 소규모 프로젝트에 방대한 규모의 방법론 적용
-
개선 대책
- 기업 차원의 품질 관리 인식 제고 및 교육과 효과적 활용 도모
- 융통성이 있는 개발 방법론 적용
- CMM, SPICE 등과 연계
-
개발 방법론 선택 기준
- 프로젝트 환경 고려(응용 분야, 시스템 규모, 복잡도, 성격 등)
- 수작업을 최소화하고 자동화되어 있을수록 좋음(시간과 비용)
- 성공을 위한 가이드라인, 함정에 대한 경고 및 실제 활동에서 잊기 쉬운 점들을 검사(통제 수단과 산출물 인도 방식)
- 개발자들의 공감 하에 적절히 이용할 수 있어야 함(방법과 도구 및 경험)
-
CMM(Capability Maturity Model)
- CMM은 독립적인 평가를 통해 소프트웨어 개발 조직이 얼마나 정의된 프로세스를 잘 지키는지에 대한 등급을 매기는 모델이며, 이는 프로세스 자체의 품질이나 결과물인 소프트웨어 대한 평가 우선하여 이루어짐
- CMM은 서서히 CMMI(Capability Maturity Model Integration)로 대체됨
-
SPICE(Software Process Improvements Capability dEtermination, ISO15504)
- SPICE는 소프트웨어 개발 프로세스의 평가를 위한 프레임워크로서, CMM이나, CMMI 만큼 널리 사용됨
- SPICE를 이용하여 프로세스를 관리하고, 제어하고, 안내하며, 소프트웨어 개발 과정을 모니터링 할 수 있는 모델을 세울 수 있고, 세워진 모델을 이용하여 실제로 소프트웨어 개발 조직이나 개발팀이 소프트웨어 개발을 위해 수행하여야 하는 활동을 측정 할 수 있음