1. 테일러링의 정의와 필요성
- 테일러링이란?
- 프로젝트의 상황과 필요에 맞게 기존 개발 방법론을 조정하고 최적화하는 활동.
- 기존 개발 절차, 활동, 산출물을 가공하거나 적용, 반복해서 효율성을 높임.
2. 테일러링이 왜 필요할까?
- 모든 프로젝트에 단일 방법론을 그대로 적용하기는 어렵기 때문.
- 내부와 외부 요구사항이 서로 충돌할 때 이를 조정해야
3. 필요성 판단 기준
- 내부적 요소: 프로젝트 목표, 요구사항, 규모, 기술 수준 등.
- 외부적 요소: 법적 요구사항, 표준 품질 기준 등.
2. 테일러링 프로세스
- 프로젝트 일정과 자원현황 반영
- 프로젝트의 일정, 비용, 목표, 투입 자원, 위험 요소 등을 분석.
2. 단계별 절차 조정
- 프로젝트 특성에 맞는 세부 개발 절차를 수립.
- 관계자들에게 결과를 설명하며, 테일러링 내용을 확인받음.
3. 결과물 문서화
- 단계별 활동 계획과 작업 내용을 메뉴얼로 작성.
"우리 프로젝트에 맞는 방법론으로 고쳐 써보자!"
"프로젝트 상황을 먼저 확인하고, 그에 맞게 조정하자."
"조정한 내용을 문서로 잘 남기자."
3. 소프트웨어 개발 프로젝트 개요
1) 소프트웨어 개발 프로젝트란?
- 미리 계획된 일정과 자원 내에서 목표를 이루기 위해 진행하는 모든 활동.
- 프로젝트는 단계적으로 진행되며, 시간과 방법이 명확히 정해져 있음.
2) 프로젝트 관리 요소
프로젝트는 아래 5가지 요소를 중심으로 관리
- 일정
- 활동의 순서와 기간을 계획하고 조정.
2. 비용
- 원가를 산정하고, 예상 비용과 실제 비용을 비교 관리.
3. 투입 자원
- 팀원, 자금, 조직 등을 적절히 배분.
4. 위험
- 위험을 미리 파악하고, 평가하여 대응 계획을 세움.
5. 품질
- 품질 계획과 보증을 통해 프로젝트 결과물을 관리.
3) 프로젝트 계획과 비용 예측
- 프로젝트 계획을 세울 때는 영역, 인력, 비용, 일정을 고려.
- 예상치 못한 위험 요소가 발생할 수 있으니 미리 대비.
비용 결정 시 아래 3가지를 고려
- 프로젝트 요소: 프로젝트 크기, 복잡도, 신뢰도.
- 자원 요소: 팀원, 소프트웨어, 하드웨어 비용.
- 생산성 요소: 개발 기간, 개발팀의 기술력.
4. 프로젝트 일정 관리
1) 일정 관리 원칙
- 프로젝트를 작은 작업 단위로 나누기.
- 작업 순서와 관계를 정리해 일정 계획 세우기.
- 각 작업에 필요한 시간을 명확히 설정하기.
- 팀원들에게 적절한 작업 시간을 분배하기.
- Brooks의 법칙 : 늦어진 프로젝트에 사람을 투입하면 오히려 더 늦어진다.
프로젝트란?
정해진 시간과 자원을 활용해 목표를 이루는 활동.
2. 뭘 관리해야 해?
일정, 비용, 자원, 위험, 품질을 관리.
3. 어떻게 관리해?
작업을 나누고, 필요한 시간과 순서를 정리해서 일정과 비용을 예측.
4. 일정을 짤 때 주의할 점
너무 복잡하지 않게 나누고, 각 작업의 순서를 명확히 정하는 게 중요.
2. 프로젝트 일정 계획 방법론
1) 일정 계획 방법론이란?
- 프로젝트 일정을 잘 짜서 효율적이고 빠르게 끝낼 수 있도록 만드는 방법.
- 목표: 최소한의 자원과 비용으로 가장 짧은 시간에 끝내는 것
2) 주요 기법들
- PERT (Program Evaluation and Review Technique)
- 어려운 작업을 예측하는 방법.
- 모든 작업을 낙관적(가장 빠른 시간), 기대치(보통 시간), 비관치(가장 오래 걸릴 시간)으로 나눠서 계산.
- 공식: 예측치 = (낙관치 + 4 × 기대치 + 비관치) ÷ 6
예를 들어:
어떤 작업이 빠르면 2일, 보통은 4일, 오래 걸리면 6일 걸린다고 예상되면:
(2 + 4×4 + 6) ÷ 6 = 4일
노드와 간선을 통해 작업의 완료시점 (이벤트)와 해당 작업의 소요시간을 예측해 표현
- 노드(원): 작업 완료 시점.
- 간선(화살표): 작업의 소요시간.
1. 일정을 왜 계획해?
시간과 자원을 절약하면서, 빨리 끝내려고!
2. 어떻게 계획해?
PERT를 사용해서 낙관적, 기대치, 비관적 시간을 예측해.
그림(노드-간선)을 그려서 작업 흐름을 한눈에 보이게 만들어!
3. CPM (Critical Path Method) = 임계 경로 기법
CPM이란?
- 프로젝트에서 작업별 개발 시간이 확실할 때 쓰는 방법.
- **임계 경로(주요 경로)**를 계산해서 프로젝트를 완료하는 데 필요한 최단 시간을 알아내는 방법.
CPM의 구성 요소
- 노드
- 원형 노드: 특정 작업의 완료 시점.
- 박스 노드 (=이정표): 여러 작업이 끝나야 다음 작업을 시작할 수 있는 지점.
2. 임계 경로
- 임계 경로: 프로젝트에서 가장 시간이 오래 걸리는 작업들의 연결된 경로.
- 이 경로가 프로젝트 전체 시간을 결정.
4. 간트 차트 (Gantt Chart)
간트 차트란?
- 일정을 시각적으로 보여주는 도구.
- 막대 그래프로 작업을 표현해서 작업 순서와 기간을 한눈에 볼 수 있음.
장점
- 작업 간의 관계(선후 관계)를 쉽게 이해할 수 있음
한계
- 너무 세세한 작업 정보는 표현하기 어려움.
- 작은 프로젝트에 더 적합.
1. CPM
작업별 시간과 경로를 계산해서 가장 빠르게 프로젝트를 끝내는 방법을 찾는 것.
2. 간트 차트
프로젝트 일정을 막대 그래프로 만들어서
"어떤 작업이 언제 끝나는지" 시각적으로 보여주는 것.
1. 소프트웨어 사업비 종류
소프트웨어 개발에는 다양한 비용이 들어감.
- 정보 전략 계획 수립 비용
- 프로젝트를 잘 계획하기 위해 분석하고 전략을 세우는 데 드는 비용.
2. 소프트웨어 개발 비용
- 개발 인력, 개발 도구, 작업 시간 등에 드는 실제 개발 비용.
3. 소프트웨어 유지 보수 비용
- 제품 수정, 기술 지원, 사용자 서비스 제공 등 유지 관리에 드는 비용.
4. 소프트웨어 재개발 비용
- 기존 소프트웨어를 일부 다시 개발하거나 수정해야 할 때 드는 비용.
5. 데이터베이스 구축 비용
- 데이터를 관리하기 쉽게 만드는 시스템 구축 비용.
6. 시스템 운영 환경 구축 비용
- 테스트 및 운영 환경을 설계하고 구축하는 데 드는 비용.
2. 소프트웨어 비용 산정
1) 비용 산정이란?
- 프로젝트 개발에 필요한 비용을 미리 계산하는 활동.
- 너무 적으면 프로젝트 품질이 나빠지고, 너무 많으면 예산 낭비가 될 수 있음.
- 그래서 합리적이고 정확하게 계산하는 게 중요.
2) 비용 결정 요소
비용을 결정할 때는 프로젝트, 자원, 생산성을 고려해야
1. 프로젝트 요소
- 제품의 복잡도, 시스템 크기, 요구 신뢰도 등.
2. 자원 요소
- 개발에 필요한 사람, 하드웨어, 소프트웨어 등.
3. 생산성 요소
- 개발자들의 경험, 기술 수준, 개발 기간 등.
1. 비용 종류는?
프로젝트 계획, 개발, 유지 보수, 수정, 데이터베이스, 환경 구축 비용으로 나뉨.
2. 비용은 어떻게 산정해?
프로젝트 특성, 필요한 자원, 개발 효율성을 기준으로 합리적이고 과학적으로 계산해야.
1. 비용 산정 기법의 종류
비용을 산정하는 주요 기법들
- 하향식 기법
과거 유사 프로젝트 경험을 바탕으로 전체 비용을 대략적으로 계산.
- 전문가 측정 기법: 전문가의 직관과 경험을 활용.
- 델파이 기법: 여러 전문가의 의견을 조정해서 비용을 추정.
2. 상향식 기법
- 작업을 세세히 나눠 비용을 합산하는 방식.
- 더 정확하지만 계산에 시간과 노력이 많이 듬.
2. LOC 기반 기법
- LOC (Line of Code)
- 코드 라인 수를 기반으로 비용을 추정.
- 낙관치, 기대치, 비관치를 활용해 평균 계산
- 비용 공식: 노력(시간) = LOC ÷ 월평균 생산 코드 라인
- 비용 = 노력 × 월평균 인건비
- 개발 기간 = 노력 ÷ 투입 인원
2. Effort Per Task
- 단순히 코드 라인 수만 보는 대신, 각 작업별로 필요한 노력을 따로 계산함.
3. 수학적 산정 기법
- COCOMO 모델
프로젝트 규모와 특성에 따라 3가지 유형으로 분류:
- Organic (조직형): 5만 라인 이하. 사무용, 간단한 소프트웨어.
- Semi-Detached (반분리형): 30만 라인 이하. 운영체제, 데이터베이스.
- Embedded (내장형): 30만 라인 이상. 복잡하고 큰 시스템.
2. COCOMO 공식 (노력 산정):
- 노력 = 계수 × (KDSI)^지수 (KDSI: 1,000 라인 단위 코드)
- 개발 기간: 노력을 기반으로 계산. (예: 조직형은 2.5 × 노력을 사용)
하향식 기법: 과거 경험으로 대략 계산. 빠르지만 주관적임.
상향식 기법: 작업 단위별로 정밀 계산. 정확하지만 시간 많이 걸림.
LOC 기반: 코드 라인 수로 계산. 낙관/기대/비관치 활용.
COCOMO 모델: 소프트웨어 크기와 유형에 따라 노력을 산정.
1. Putnam 모델
- 비용 산정을 시간 흐름에 따른 함수로 계산하는 방법.
- 프로젝트 생명 주기의 노력 분포를 예측하는 데 사용됨.
- Rayleigh-Norden 곡선을 기반으로 계산함.
- 예를 들어, 프로젝트 초반엔 노력(자원)이 적게 들고, 중반에 집중적으로 투입되며, 후반에 다시 줄어드는 형태.
- 대규모 프로젝트에서 주로 활용함.
자동화 도구: SLIM (Software Life-cycle Management)으로 비용을 쉽게 측정 가능.
2. 기능 점수(Function Point) 기법
- 소프트웨어의 기능을 기준으로 비용을 산정하는 방법.
- 각 기능별로 중요도를 점수화하고, 이를 바탕으로 비용 계산.
주요 기능 요인
- 입력
- 시스템이 처리해야 할 데이터 입력.
2. 출력
- 시스템이 생성해야 할 결과 데이터.
3. 사용자 질의
- 사용자와의 상호작용을 포함.
4. 데이터 파일
- 데이터 저장소와 관련된 기능.
5. 인터페이스
- 다른 시스템과의 연동 기능.
가중치를 반영한 계산
- 각 기능에 복잡도(가중치)를 곱해 점수를 산출하고,
- 이 점수를 기반으로 비용을 계산함.
- 입력 기능 × 복잡도 가중치 = 입력 기능 점수
- 이런 식으로 모든 기능 점수를 합산.
자동화 도구
- ESTIMACS라는 도구를 사용해 비용을 자동으로 산정 가능.
1. Putnam 모델
프로젝트 진행 기간에 따른 노력 분포를 계산.
Rayleigh-Norden 곡선을 기반으로 대규모 프로젝트에 적합.
2. 기능 점수 기법
기능별 중요도를 점수화해 비용을 계산.
주요 요인: 입력, 출력, 사용자 질의, 데이터 파일, 인터페이스.
가중치(복잡도)를 반영해 점수를 계산하며, 자동화 도구로 활용 가능.
4. 투입 인력 자원 구성
1) 책임 프로그래머 팀 유형
중앙 집중형 팀
- 한 명의 책임 프로그래머가 중심이 되어 많은 보조 인력이 지원하는 구조.
- 소규모, 단기 프로젝트에 적합.
- 기능 구현이 단순한 프로젝트에서 주로 사용됨.
- 단점: 팀원 만족도가 낮고, 이직률이 높음.
2) 민주주의식 팀 유형
분산형 팀
- 각 개발자가 자신의 영역을 독립적으로 맡아 일하는 구조.
- 대규모, 복잡한 프로젝트에 적합.
- 팀원 만족도가 높고, 이직률이 낮음.
5. 소프트웨어 품질 관리
1) 소프트웨어 개발 표준
- ISO/IEC 12207
- 국제 표준 수명 주기 프로세스.
3가지 생명 주기로 나뉨
- 기본: 획득, 공급, 개발, 운영, 유지보수.
- 지원: 품질 보증, 형상 관리, 검증, 문제 해결.
- 조직: 관리, 교육, 개선.
2. ISO/IEC 12119
- 패키지 소프트웨어의 제품 품질 요구사항 및 테스트를 위한 국제표준
3. ISO/IEC 29119
- 소프트웨어 테스트를 위한 국제 표준
4. ISO/IEC 9126 (25010으로 개정)
- 품질 특성 평가와 관리에 사용.
6가지 외부 품질 특성
- 기능성: 요구사항 만족 능력.
- 신뢰성: 오류 없는 성능 유지.
- 사용성: 사용자의 편리함.
- 효율성: 자원을 적게 사용하며 성능 제공.
- 유지보수성: 수정 및 개선 용이성.
- 이식성: 다른 환경에서의 사용 가능성.
6. CMM (Capability Maturity Model)
1) CMM의 특징
- 소프트웨어 개발 업체의 능력 성숙도 평가 기준.
- 기술적 수준과 조직 성숙도를 측정.
2) 단계별 성숙도 평가 기준
- 초기 (Initial): 개발 관리 프로세스의 부재.
- 반복 (Repeatable): 성공한 프로젝트 프로세스 반복.
- 정의 (Defined): 프로세스 정의와 이해 가능.
- 관리 (Managed): 프로세스 성과 측정.
- 최적화 (Optimizing): 지속적 개선.
6. CMMI (Capability Maturity Model Integration)
CMMI란?
- 소프트웨어와 시스템 공학 프로세스의 능력 성숙도를 평가하는 국제 표준.
- 목표: 개발 프로세스를 체계적으로 개선하고, 품질과 생산성을 높이는 것.
CMMI의 단계별 성숙도 평가 기준
- 초기 (Initial)
- 관리 (Managed)
- 정의 (Defined)
- 정량적 관리 (Quantitatively Managed)
- 최적화 (Optimizing)
CMMI의 주요 영역
- 프로세스 관리
- 프로젝트 관리
- 엔지니어링
- 지원 활동
7. SPICE (Software Process Improvement and Capability dEtermination)
SPICE란?
- 소프트웨어 품질과 생산성을 향상시키기 위한 국제 표준 (ISO/IEC 15504).
- CMMI의 단점을 개선한 프로세스 평가 모델.
SPICE의 주요 목적
- 프로세스 개선: 개발 조직이 스스로 프로세스를 평가하고 개선.
- 품질 보증: 요구 조건을 충족하는 소프트웨어 품질 제공.
- 계약 만족도 평가: 고객 및 계약 기준 충족 여부 평가.
SPICE의 단계별 성숙도
- 불완전 (Incomplete) 프로세스가 실행되지 않거나 제대로 작동하지 않음.
- 수행 (Performed) 프로세스가 실행되지만 체계적이지 않음.
- 관리 (Managed) 프로세스가 계획되고, 결과물이 규정 기준을 충족.
- 확립 (Established) 표준화된 프로세스가 조직 내에서 적용됨.
- 예측 가능 (Predictable) 정량적 데이터로 성과를 예측 가능.
- 최적화 (Optimizing) 지속적으로 프로세스를 개선하고 혁신.
CMMI: 소프트웨어 성숙도를 5단계로 평가하며, 지속적 프로세스 개선에 초점.
SPICE: ISO 표준 기반 평가 모델로, 프로세스 성숙도를 6단계로 세분화.
SPICE는 CMMI의 단점을 보완한 평가 모델.
5. CASE 도구 (Computer Aided Software Engineering)
CASE 도구란?
- 소프트웨어 개발 과정에서 자동화를 지원하는 도구.
- 반복적 작업을 줄이고 생산성을 높이는 데 초점.
CASE 도구의 목표
- 품질 향상 및 재활용 가능성 증가.
- 개발 과정 자동화로 시간과 비용 절감.
- 표준 문서화 및 협업 지원.
CASE 도구 특징
- 품질과 신뢰성 향상.
- 도구 간 호환성이 부족할 수 있음.
- 비용 대비 효율이 높은 도구.
CASE 도구의 계층
- 상위 CASE: 요구 분석 및 설계 지원.
- 하위 CASE: 코딩, 테스트 지원.
- 통합 CASE: 전체 과정 지원.
6. 형상 관리
형상 관리란?
- 소프트웨어 개발 중 발생하는 모든 산출물과 변경을 체계적으로 관리하는 것.
- 버전 관리를 통해 혼란을 방지.
형상 관리의 주요 특징
- 여러 개발자가 협업할 때 문제를 최소화.
- 변경 사항을 추적하고 기록.
형상 관리 프로세스
- 형상 식별: 대상 산출물을 정의하고 관리 번호 부여.
- 형상 통제: 변경 요청 검토 및 승인.
- 형상 상태 보고: 변경 사항 기록 및 관리.
- 형상 감사: 변경된 사항이 제대로 반영되었는지 검토.
CASE 도구: 소프트웨어 개발 자동화 도구. 품질 향상과 시간 절약에 도움.
형상 관리: 프로젝트 변경 사항을 체계적으로 관리하여 버전 혼란을 방지.
총정리
1. 테일러링
- 정의: 프로젝트마다 다 다른 상황에 맞게 기존 개발 방법론(절차, 활동, 산출물 등)을 수정하는 작업임.
- 왜 하는가: 모든 프로젝트가 똑같지는 않음. 예를 들어, 한 프로젝트는 규모가 작고 간단할 수 있는데, 다른 프로젝트는 복잡하고 큰 경우가 있음. 이런 차이를 반영해서 효율적으로 일하기 위해 맞춤형 방법을 쓰는 것임.
- 어떻게 하는가:
- 현황 분석:
- 프로젝트 목표, 요구사항, 규모, 기술 수준 같은 내부 요인과
- 법적 요구사항, 품질 기준 같은 외부 요인을 꼼꼼히 따져봄.
2. 절차 조정:
- 분석 결과를 바탕으로 일정, 비용, 자원, 위험 요소를 고려한 맞춤형 개발 절차를 만듦.
- 이 과정을 관계자들에게 설명하고 확인받음.
3. 문서화:
- 조정한 내용을 문서로 남겨서 나중에 참고하거나 문제가 생겼을 때 다시 볼 수 있게 함.
2. 소프트웨어 개발 프로젝트 개요
- 프로젝트란: 정해진 시간과 자원을 사용해 목표를 달성하기 위한 일련의 활동임.
- 프로젝트 단계: 기획, 설계, 개발, 테스트, 배포, 유지보수 같은 단계로 진행됨.
중요 관리 요소:
- 일정: 어떤 작업을 언제 할지, 순서와 시간을 정하는 것임.
- 비용: 필요한 돈을 미리 계산하고 실제로 얼마나 썼는지 관리하는 것임.
- 자원: 팀원, 장비, 소프트웨어 등 투입되는 모든 자원을 관리함.
- 위험: 예상치 못한 문제가 발생할 수 있으므로 미리 대비하는 것임.
- 품질: 만들어진 소프트웨어가 원하는 기능을 제대로 수행하는지 확인하는 것임.
3. 프로젝트 일정 계획 및 관리
- 작업 분할: 큰 작업을 작은 작업 단위로 쪼개서 진행 순서와 소요 시간을 명확히 함.
주요 기법:
- PERT 기법:
- 각 작업에 대해 낙관적(최소 시간), 보통(예상 시간), 비관적(최대 시간) 세 가지 경우를 예상함.
- 이 세 값을 사용해 평균 소요 시간을 계산해서 일정 계획에 반영함.
2. CPM (임계 경로 기법):
- 전체 작업 중에서 가장 오래 걸리는 경로(임계 경로)를 찾아냄.
- 이 경로가 전체 프로젝트 기간을 결정하므로, 관리에 특히 주의함.
3. 간트 차트:
- 각 작업의 시작과 끝을 막대 그래프로 표시해서 전체 일정을 한눈에 볼 수 있게 함.
- 누구나 쉽게 이해할 수 있고, 진행 상황을 실시간으로 확인할 수 있음.
4. 소프트웨어 비용 산정
중요성
- 프로젝트 시작 전에 필요한 비용을 정확하게 예측해야 함.
- 비용이 부족하면 프로젝트 진행에 차질이 생기고, 너무 많으면 예산 낭비가 됨.
고려 요소
- 프로젝트 요소: 제품의 크기, 복잡도, 신뢰도 같은 것들이 비용에 영향을 줌.
- 자원 요소: 개발에 필요한 인력, 장비, 소프트웨어 비용 등을 고려함.
- 생산성 요소: 팀의 기술력과 개발 기간 등도 중요한 변수임.
산정 기법
- 하향식 기법:
- 과거 비슷한 프로젝트 데이터를 참고해 전체 비용을 대략적으로 계산함.
- 빠르지만 주관적인 면이 있음.
2. 상향식 기법:
- 프로젝트를 여러 작은 작업으로 나누고, 각 작업별 비용을 계산해서 합산함.
- 시간이 더 들지만 정확함.
3. LOC 기반 기법:
- 코드 라인 수(LOC)를 기준으로 개발에 필요한 시간과 비용을 예측함.
4. COCOMO, Putnam, 기능 점수 기법:
- 각각 다른 수학적 모델이나 평가 기준을 사용해 비용을 산정함.
결과: 여러 기법을 종합해 가장 합리적이고 과학적인 비용 예측을 시도함.
5. 투입 인력 자원 구성
중앙 집중형 팀 (책임 프로그래머 팀):
- 한 명의 책임자가 중심이 되어 나머지 보조 인력이 돕는 방식임.
- 소규모나 단기 프로젝트에 적합함.
- 단점: 책임자에게 부담이 많고, 팀원 만족도가 떨어질 수 있음.
분산형 팀 (민주주의식 팀):
- 각 개발자가 자신이 맡은 영역을 독립적으로 책임지고 일함.
- 대규모나 복잡한 프로젝트에 적합하고, 팀원들의 자율성과 만족도가 높음.
- 단, 팀원 간의 소통과 협업이 원활해야 함.
6. 소프트웨어 품질 관리
- 목적: 개발한 소프트웨어가 사용자의 요구를 만족하고, 안정적으로 동작하며, 유지보수가 용이하도록 관리하는 것임.
주요 표준 및 모델:
- ISO/IEC 시리즈:
- ISO/IEC 12207, 12119, 29119 등은 소프트웨어 개발과 테스트를 위한 국제 표준임.
- ISO/IEC 9126(현재는 25010) 같은 경우는 소프트웨어의 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성을 평가함.
2. CMM/CMMI 모델:
- 개발 조직의 프로세스 성숙도를 평가해, 초기부터 최적화 단계까지 단계별로 관리함.
- 프로세스가 잘 정립되면, 소프트웨어 품질과 생산성이 자연스럽게 향상됨.
3. SPICE:
- 소프트웨어 개발 프로세스를 평가하고 개선하기 위한 모델임.
- ISO 표준에 기반해서 체계적인 프로세스 개선을 목표로 함.
7. CASE 도구와 형상 관리
CASE 도구 (Computer Aided Software Engineering):
- 소프트웨어 개발 시 반복적이고 수동적인 작업들을 자동화해주는 도구임.
- 예를 들어, UML 도구, 코드 생성 도구 등이 있음.
- 덕분에 개발 시간이 단축되고, 오류도 줄일 수 있음.
형상 관리
- 개발 도중 생성되는 모든 산출물(소스 코드, 문서, 설정 파일 등)의 변경 이력을 관리하는 것임.
- 여러 개발자가 동시에 작업할 때 서로의 변경 사항을 추적하고, 혼란을 방지함.
- 대표적인 도구로 Git, SVN 등이 있음.
- CASE 도구와 형상 관리를 통해 작업의 일관성을 유지하고, 문제가 생겼을 때 빠르게 대응할 수 있음.
이렇게 정리하면,
- 프로젝트마다 맞춤형 방법(테일러링)으로 개발 절차를 최적화하고,
- 일정, 비용, 자원, 위험, 품질을 체계적으로 관리하며,
- 적절한 팀 구성과 도구를 활용해 효율적이고 안정적인 소프트웨어 개발을 이루는 게 목표임.
'정처기' 카테고리의 다른 글
UI 요구사항 (0) | 2025.02.11 |
---|---|
UML (0) | 2025.02.11 |
요구사항 확인 (0) | 2025.02.11 |
소프트웨어 개발 환경 분석 (0) | 2025.02.11 |
소프트웨어 개발 방법론 (0) | 2025.02.09 |