The Analyst as a Project Manager

Systems Analysis and Design in a Changing World, 4th Edition SatzingerJacksonBurd 2007 Chapter 2

Get Started. It's Free
or sign up with your email address
The Analyst as a Project Manager by Mind Map: The Analyst as a Project Manager

1. Project Management

1.1. 프로젝트 관리

1.1.1. 사전에 정의된 스케쥴과 예산내에서 계획된 결과를 성취하기 위해 다른 사람들을 조직화하고 관리

1.1.2. 전체 프로젝트의 32% 취소

1.1.3. 전체 프로젝트의 반이상 예산2배 소요

1.1.4. 프로젝트 성공요인

1.1.4.1. 명확한 시스템 요구정의

1.1.4.2. 실질적인 사용자 포함

1.1.4.3. 상위 경영자로부터의 지원

1.1.4.4. 철저하고 상세한 프로젝트 계획

1.1.4.5. 실제적인 작업스케쥴

1.2. SDLC 관리

1.2.1. 클라이언트

1.2.1.1. 자금 지원

1.2.1.2. 비지니스 전략 제공

1.2.2. 감독위원회

1.2.2.1. 프로젝트 검토, 감독 하는 클라이언트와 핵심관리자

1.2.3. 사용자

1.2.3.1. 새로운 시스템 사용하는 사람

1.2.3.2. 새로운 시스템에 필요한 셍사한 기능과 동작에 대한 정보제공

1.2.4. 프로젝트 관리영역

1.2.4.1. Project Scope Management

1.2.4.1.1. 프로젝트 팀에 의해 행해지는 작업의 영역 뿐만 아니라 시스템에 포함되는 기능을 정의하고 통제

1.2.4.2. Project Time Management

1.2.4.2.1. 모든 프로젝트 태스크들의 상세한 스케줄을 수립

1.2.4.2.2. 프로젝트 진도 모니터링

1.2.4.3. Project Cost Management

1.2.4.3.1. 초기 비용/이익 분석

1.2.4.3.2. 지출 모니터링

1.2.4.4. Project Quality Management

1.2.4.4.1. 품질 보증을 위한 계획 수립

1.2.4.5. Project Human Resource Management

1.2.4.5.1. 프로젝트 팀 멤버 채용, 교육, 팀 구축

1.2.4.6. Project Communication Management

1.2.4.6.1. 모든 통신 메커니즘과 스케쥴 수립

1.2.4.7. Project Risk Management

1.2.4.7.1. 모든 잠재적인 위험 검토, 감소시키기 위한 계획수립

1.2.4.8. Project Procurement Management

1.2.4.8.1. 입찰, 계약, 업체의 성능 모니터링

2. Project initiation and the Project Planning Phase

2.1. 프로젝트착수

2.1.1. 착수원인

2.1.1.1. 기회에 대응하기 위해

2.1.1.2. 비즈니스문제를 해결하기 위해

2.1.1.3. 외부지침에 따르기 위해

2.2. 문제정의

2.2.1. 목적

2.2.1.1. 해결되어야 할 비즈니스 문제 정의와 새로운 시스템 영역 정의

2.2.2. system scope document

2.2.2.1. 개발 팀이 문제 기술, 비즈니스 이익, 시스템 성능을 결합하여 생성

2.3. 프로젝트 스케쥴 생산

2.3.1. Work Breakdown Structure(WBS) 개발

2.3.1.1. 작업분할구조

2.3.1.2. phases, activities, tasks의 계층

2.3.1.3. task들을 예측, 스케줄 하기 위한 방법

2.3.1.4. 5 – 6 레벨이 적합

2.3.1.5. 정기적으로 수정되어야함

2.3.2. PERT/CPM 차트

2.3.2.1. WBS에서 확인된 모든 task, 의존 순서를 보여주는 다이어그램

2.3.2.2. critical path

2.3.2.2.1. 임계 경로

2.3.2.2.2. 프로젝트가 완료될 수 있는 가장 빠른 경로

2.3.2.3. 스케쥴 개발에 유용

2.3.2.3.1. 간트차트는 프로젝트 시작 후 유용

2.4. 프로젝트 타당성 확인

2.4.1. Economic feasibility

2.4.1.1. 경제적 타당성

2.4.1.1.1. cost/benefit 분석

2.4.1.1.2. cash flow 분석

2.4.1.1.3. 운영비, 이익발생

2.4.1.1.4. 재정적 계산

2.4.1.1.5. 무형의 이익과 비용

2.4.2. Organizational and Cultural feasibility

2.4.2.1. 조직적 문화적 타당성

2.4.2.1.1. 각 회사는 고유의 문화를 가지며 새로운 시스템은 문화에 적합해야 함

2.4.2.1.2. 잠재적인 위협

2.4.3. Technological feasibility

2.4.3.1. 기술적 타당성

2.4.3.1.1. 새로운 시스템은 현재의 기술 수준을 확대

2.4.3.1.2. 기술적 위험의 해결 방안

2.4.3.1.3. 회사 내의 전문 지식의 부족

2.4.4. Schedule feasibility

2.4.4.1. 스케줄 타당성

2.4.4.1.1. 스케줄은 프로젝트에 대한 적합한 정보와 함께 이루어지는 많은 가정과 예측들을 요구

2.4.4.1.2. 경영자가 새로운 시스템이 특정 시간내에 배치되어야 함을 지시할 때 발생

2.4.5. Resource feasibility

2.4.5.1. 자원 타당성

2.4.5.1.1. 팀 멤버 가용성

2.4.5.1.2. 팀의 기술 레벨

2.4.5.1.3. 장비

2.4.5.1.4. 지원 직원

2.4.5.1.5. 물리적 설비