Project Management Project - temporary endeavor undertaken to ...
Upcoming SlideShare
Loading in...5
×
 

Project Management Project - temporary endeavor undertaken to ...

on

  • 1,767 views

 

Statistics

Views

Total Views
1,767
Views on SlideShare
1,766
Embed Views
1

Actions

Likes
0
Downloads
15
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Project Management Project - temporary endeavor undertaken to ... Project Management Project - temporary endeavor undertaken to ... Presentation Transcript

    • Project Management
      • Project - temporary endeavor undertaken to create a unique product or service
        • may be divided into subprojects
      • Project management - application of knowledge, skills, tools and techniques to project activities to meet or exceed stakeholder needs and expectations from a project
        • T.A.N.S.T.A.A.F.L.
    • Project Triangle
      •  
      Time Cost Scope QUALITY
    • Project Management Activities
      • Ensuring progress of project using metrics
      • Identifying risks and assessing the probability of them occurring
      • Ensuring progress toward deliverables within constraints of time and resources
    • Project Management Activities
      • Running coordination meetings of the project team
      • Negotiating for resources on behalf of the project
    • Development Models
      • Systems Development Life Cycle
      • Rapid Applications Development (RAD)
      • Prototyping
      • Joint Applications Development (JAD) (like RAD with users)
      • Object-Oriented
    • Systems Development Life Cycle (SDLC)
      • Overview
      • Software Acquisition Choices
      • SDLC Overview
      • SDLC:Phases
      • Alternative Approaches
    • SDLC - Prior Problems
      • Failure to meet:
        • Budgets
        • Schedules
        • Expectations
      • TOO LITTLE…. TOO LATE
    • SDLC - Characteristics
      • “ Problem” or “Opportunity”
      • Many names; Widely applicable
      • “ Analysis” vs. “Synthesis”
      • Variance across stages
    • SDLC - Characteristics
      • Disciplined approach
      • Systems approach
      • Iterative (not sequential)
      • Cyclical
    • SDLC - Advantages
      • Focus on tradeoffs
      • Focus on goals
      • Controls: milestones, checklist, accountability
    • SDLC - Advantages
      • Tools, models, CASE
      • Hierarchical decomposition
      • Designed for user & manager involvement
    • SDLC - Reasons for Failure
      • Scope too broad or too narrow
      • Lack of needed skills
      • Incomplete specifications
      • No control/no framework
    • SDLC - Reasons for Failure
      • Lack of management/user involvement
      • Too time-consuming
    • SDLC Phases
      • Initiation and Feasibility
      • Requirements Definition
      • Functional Design
      • Technical Design and Construction
      • Verification
      • Implementation
      • Maintenance & Review
    • I. Initiation & Feasibility
      • Project objectives & Scope
      • Preliminary survey & feasibility
        • Technical
        • Economic
        • Operational
      • Project proposal and schedule
      • Identify assumptions & constraints
    • II. Requirements Definition
      • Problem/Opportunity definition
      • Analyze current system
      • Focus on decisions and related information needs
      • Define business functionality
      • Plan for training, user acceptance
    • Problem/Opportunity Definition
      • Symptoms vs. real problems
      • Question decision maker’s statement of problem
      • Bound problem realistically
      • Try to ascertain actual cause
      • Sometimes figuring out the problem is half the solution
    • Analyze Current System
      • + Understand activities involved
      • + Identify decision points
      • + Identify problems & efficiencies
      • + Be aware of history
      • - Bias thinking
    • III. Functional Design
      • Focus on business needs
        • usability, reliability
      • Logical design
        • Outputs
        • Inputs
        • Presentation
        • Processes
        • Databases
        • Personnel
    • IV. Technical Design and Construction
      • Finalize architecture and acquire hardware
      • Complete technical definition of data access and other system components
      • Make (program) vs. buy
      • Develop test plans
      • Revise schedule, plan and costs
    • V. Verification
      • Program Testing
        • Structured walkthrough
        • Code inspection
        • Unit test
        • Pairs testing
      • Verification, stress, user and security testing
    • VI. Implementation
      • Cut-over
        • Parallel conversion
        • Direct cut-over
        • Pilot conversion
        • Phased conversion
      • User training
    • VII. Maintenance and Review
      • Post-implementation audit
        • Ends - information requirements (information, performance)
        • Means - process
      • Maintenance (correcting bugs & scheduled maintenance)
      • Enhancement (adding functionality)
    • Rapid Applications Development (RAD)
      • Like prototyping, uses iterative development
      • Uses tools to speed up development
        • GUI
        • reusable code
        • code generation
        • programming, language testing and debugging
      • Requirements may be frozen too early
      • Basic standards often overlooked
    • Iterative Development System Concept Version “1” Version “2” Version “N” Software Development Process
    • Uses of Prototyping
      • Verifying user needs
      • Verifying that design = specifications
      • Selecting the “best” design
      • Developing a conceptual understanding of novel situations
    • Uses of Prototyping
      • Testing a design under varying environments
      • Demonstrating a new product to upper management
      • Implementing a new system in the user environment quickly
    • Prototyping
      • Proposed Advantages
        • Improved user communication
        • Users like it
        • Low risk
        • Avoids over-design
        • Experimentation and innovation
        • Spreads labor to user department
      • Disadvantages in practice
        • Prototypes are used “as is”
          • Integration often difficult
          • Design flaws
          • Poor performance
        • Difficult to manage process
        • Creates unrealistic expectations
        • Documentation is difficult
    • Observed Effects of Prototyping
      • ease of use (+)
      • user needs (+)
      • unrealistic user expectations (-)
      • added features (?)
      • poorer performance(-)
      • mixed design quality
      • mixed maintainability
        • less need
        • more difficult to do
      • effort decreased (+)
      • difficult cost-estimation (-)
      • end-user participation increased (+)
      • more expertise needed (-)
      • difficult planning & control (-)
      Software Product Software Process
    • Examples of Software Risk Items
      • personnel shortfalls
      • unrealistic schedules/budgets
      • developing wrong functionality
      • developing wrong user interface
      • continuing stream of requirements changes
    • Examples of Software Risk Items
      • shortfalls in externally furnished components
      • shortfalls in externally performed tasks
      • real-time performance shortfalls
      • strained technical capabilities
    • Project Dimensions Affecting Risk
      • Project Size (relative to others)
        • The pregnant lady
      • Experience with Technology
        • Relative
      • Project structure
        • High vs. Low
    • Low Company-Relative Technology
    • High Company-Relative Technology
    • Tools for Project Management
      • External integration tools (beyond project team)
      • Internal integration tools ( within project team)
      • Formal planning tools
      • Formal results-control mechanisms
    • Integration Tools
      • EXTERNAL
      • User project manager
      • User specification approval process
      • User-managed control process
      • Users as team members
      • User responsibility for education&installation
      • INTERNAL
      • IT professional team leader
      • Frequent team meetings
      • Regular technical status reviews
      • Outside technical assistance
      • Goal setting by team
    • Tools of Project Management
      • Formal Planning Tools
      • PERT, CPM
      • Milestones
      • Systems specification standards
      • Feasibility study specifications
      • Project approval processes
      • Postaudit procedures
      • Formal Control Tools
      • Periodic formal status reports vs. plan
      • Change control disciplines
      • Regular milestone presentation meetings
      • Deviations from plan reports
    • Relative Contribution of Tools: High Structure Low Low High Low High Tech, Small IV Med Med Hi Low High Tech, Large III Hi Med Low Low Low Tech, Small II Hi Hi Med Low Low Tech, Large I FC FP II EI DESCRIPTION TYPE
    • Relative Contribution of Tools: Low Structure Low Low Hi Hi High Tech, Small VII Low+ Low+ Hi Hi High Tech, Large VII Hi Med Low Hi Low Tech, Small VI Hi Hi Med Hi Low Tech, Large V FC FP II EI DESCRIPTION TYPE
    • Open Sourcing
      • The process of building and improving “free” software by an Internet community
        • Release early and often
        • Delegate as much as possible
        • Archive and manage the versions
        • Be as open as possible
    • Free Software
      • The freedom to run the program for any purpose.
      • The freedom to study how the program works, and adapt it to your needs. Access to the source code is a precondition for this.
      • The freedom to distribute copies so that you can help your neighbor.
      • The freedom to improve and release your improvements to the public, so that the whole community benefits. Access to source code is a precondition for this GNU Project- Free Software Foundation, “The Free Software Definition,” http://www.gnu.org/philosophy/free- sw .html , Downloaded 4/3/02.
    • Open Sourcing Issues
      • Protection of Intellectual Property
      • Updating and maintaining open source code
      • Competitive advantage
      • Tech support
      • Standards