Csis 3600 systems analysis and design
This presentation is the property of its rightful owner.
Sponsored Links
1 / 62

CSIS 3600 Systems Analysis and Design PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

CSIS 3600 Systems Analysis and Design. Information Systems Projects/Project Plan. What is Project Management.

Download Presentation

CSIS 3600 Systems Analysis and Design

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Csis 3600 systems analysis and design

CSIS 3600 Systems Analysis and Design

Information Systems Projects/Project Plan

What is project management

What is Project Management

  • Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality (Dennis, Wixom and Tegarden, 2002).

  • Project Management can be seen as a job responsibility or it can be a job in and of itself.

  • A Project Manager is not just a senior analyst who happens to be in charge. A project manager must apply a set of skills different from those applied by the analyst.

Roles of the project manager

Roles of the Project Manager

  • Scoping the project:

    • Project managers estimate resource requirements and formulate plans to deliver the target system.

  • Planning Tasks and Staffing the Project Team

    • Once the project has begun, the project manager becomes a supervisor. As a supervisor, the project manager directs the team's activities and evaluates progress.

Roles of the project manager continued

Roles of the Project Manager continued

  • Organizing and Scheduling the Project Effort

    • The project manager is responsible for securing resources so they are available when needed.

  • Directing and Controlling the Project

    • One of the most difficult and important functions of the project manager is controlling the project. Few projects come off without problems or delays.

Project management process

Project Management Process

  • Initiating the Project

  • Planning the Project

  • Executing the Project

  • Closing down the Project

3 steps of project management

3 Steps of Project Management

  • Create the work plan

  • Staff the project

  • Control and direct the project

Pitfalls of project management

Pitfalls of Project Management

To be successful in project management, you should be aware of some of the common pitfalls that can lead to project failure:

  • Taking shortcuts through or around the system methodology because:

    • Project gets behind schedule and team wants to catch up

    • Project is over budget and team wants to make up costs

    • Team members are not trained or made fully aware of the task requirements so simply miss or skip them

Pitfalls continued

Pitfalls continued:

  • Poor Expectations Management that results in:

    • Scope Creep - unexpected growth of user expectations and business requirements

    • Feature Creep - uncontrolled addition of technical features

      Poor People Management that results in:

    • Mythical man-month - assigning more people to the project. There is not a linear relationship between number of people assigned to a project and time to completion.

    • No one in charge and no one sure of the progress of the project

Did you notice that many of the causes of failed projects are related

Did you notice that many of the causes of failed projects are related?

  • Scope creep causes project to get behind which causes shortcuts to be taken which causes more people to be assigned to the project which causes feature creep which causes project to be way over budget and way behind schedule which causes shortcuts to be taken . . .

Managing expectations

Managing Expectations

The Greatest Trait for Success is the ability to Manage Expectations

  • The best way to manage expectations is to Scope the Project. If you cannot scope project expectations and constraints, you cannot manage expectations. If you cannot manage expectations, your chances for success are greatly reduced.

Managing expectations continued

Managing Expectations continued

  • The three most important items of project scope include:

    • Identifying a project champion and executive sponsor

    • Articulation of the statement of the problem or opportunity including project goals

    • Identification of project constraints

      Failure to achieve consensus on these dooms a project before it even starts (Whitten & Bentley, 1999)

Expectations management matrix

Expectations Management Matrix

  • An expectations matrix is a rule-driven tool for assessing the dynamics of changing project parameters.

  • The parameters include: cost, schedule, scope and quality.

Expectations management matrix continued

Expectations Management Matrix continued


You must record three X.s

No row may contain more than one X.

No column may contain more than one X.

Emm example

EMM Example

Project – Land Man on the Moon before End of Decade and before USSR

Priority One was the Scope

Priority Two was deadline (USSR was ahead in the space race)

Priority Three was cost – Cost control is a priority but we may to ‘accept’ cost overruns to achieve the scope by the required deadline.

Why emm


  • During the course of an average systems development project, priorities are not stable.

    • Various factors such as the economy, government, politics, etc. may change

    • During systems analysis, unanticipated business problems are identified or requirements modified

  • The EMM helps to deal with expectations management.

  • Simple tool – but sometimes simple tools are most effective

Having a plan

Having a Plan

Success is not pre-destined

  • A good project starts with a good plan

  • The plan is based on the manager's understanding of the requirements of the target system at that point in its development.

  • Project planning is challenging - many project plans call for unreasonably precise estimates of costs and time before a project even begins. This, and poor estimation techniques, can lead to missed deadlines and cost overruns.

Techniques for developing project plans

Techniques for Developing Project Plans

Identification of tasks

Identification of Tasks

  • A good place to start the development of a plan is the SDLC and the organization’s Systems Development Methodology 

  • All tasks required to complete the project must be identified and then planned:

    • How much time will be required?

    • How many people will be needed?

    • How much will the task cost?

    • What tasks will be completed before other tasks are started?

    • Can some of the tasks overlap?

Statement of work

Statement of Work

  • Work Breakdown Structure is a hierarchical decomposition of the project into phases, activities and tasks.

    • Summary Tasks – Related work units combined together

    • Primitive Tasks – Most basic unit of work that will not be broken down any further

    • Milestones – Events that signify major accomplishments

Work breakdown structure in outline format

Work Breakdown Structure in Outline Format

Phase (1)

Activity (1.1)

Task (1.1.1)

Step of the task (

Step of the task (

Task (1.1.2)

Step (…..

Task (1.1.3) …..

Activity (1.2)…..

Phase (2)

Work breakdown structure as a decomposition diagram

Work Breakdown Structure as a Decomposition Diagram

Time estimation

Time Estimation

  • Forward Scheduling – Establishing a project start date and then scheduling forward from that date. Most common for IS projects.

  • Reverse Scheduling – Establishing a project deadline and then scheduling backwards from that date. Used when a deadline is mandatory.

Estimating time

Estimating Time

  • Estimate system size

  • Estimate effort required

  • Estimate schedule time required

Estimating size

Estimating Size

  • Lines of Code

  • Function Points

    • Inputs

    • Outputs

    • Queries

    • Files

    • Program interfaces

Estimating effort

Estimating Effort

  • Function of production rates – how much work can be done

  • Several models have evolved from the research – most well known is the Boehm COCOMO model

  • Basic formula:

    • Effort (in person months) – 1.4 * thousands lines of code

Estimate schedule time

Estimate Schedule Time

  • Historical data can be used as a basis

  • Sample estimation equation:

    • Schedule time = 3.0 * person months1/3

Task time expected duration

Task – Time:Expected Duration

  • Calculated for each primitive task

  • There is no foolproof technique for estimating work duration.

Expected duration continued

Expected Duration continued

Suggested estimation technique:

  • Estimate minimum amount of time to perform the task or the Optimistic Time (OT)

  • Estimate the maximum amount of time to perform the task of the Pessimistic Time (PT)

  • Estimate the Realistic Time or Calculate the most likely time (MLT) as an average of the OT and PT.

  • Use weight factors (based on experience) for possible interruptions or delays to project the resulting Expected Duration (ED)

    ED = [OT + (x * MLT) + PT]/ y

    Common x factor = 4

    Common y factor = 6



  • Optimistic Time = 7 hours

  • Pessimistic Time = 19 hours

  • Most Likely Time = avg(OT and PT)

    • (7 + 19)/2 = 13 hours

  • Expected Duration:

    • ED = [OT + (x * MLT) + PT]/ y

      • [7 + (4*13) + 19]/6 = 8.67

Csis 3600 systems analysis and design

2 Primary Factors of Software Estimation

  • SLOC (Lines of Code)

  • Function Points

    • Based on the amount of functionality

    • Advantage is more information available early in project life cycle

Csis 3600 systems analysis and design

SLOC Determination

  • Difficult due to conceptual differences

  • Goal is to measure the amount of intellectual work needed

Csis 3600 systems analysis and design

User Function Types

  • External Input (Inputs)

    • Count each unique user data or user control input type that (i) enters the external boundary of the software system being measured and (ii) adds or changes data in a logical internal file.

  • External Output (Outputs)

    • Count each unique user data or control output type that leaves the external boundary of the software system.

Csis 3600 systems analysis and design

Function Points Continued

  • Internal Logical File (Files)

    • Count each major logical group of user data or control information as a logical internal file type.

  • External Interface Files (Interfaces)

    • Files passed or shared between software systems should be counted as external interface file types

  • External Inquiry (Queries)

    • Count each unique input-output combination, where an input causes and generates an immediate output, as an external inquiry type.

Csis 3600 systems analysis and design

What is COCOMO

  • COCOMO II is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity

  • The COCOMO II capability for estimation of Application Generator, System Integration, or Infrastructure development

  • Original COCOMO was developed by Dr. Barry Boehm in 1981

  • Reference: http://sunset.usc.edu/research/COCOMOII/

Csis 3600 systems analysis and design

COCOMO II Measures

  • In COCOMO II effort is expressed as Person Months (PM).

    • amount of time one person spends working on the software development project for one month (exclusive of holidays and vacations but accounts for weekends)

  • Person months is different from the time it will take the project to complete; this is called the development schedule.

  • For example, a project may be estimated to require 50 PM of effort but have a schedule of11 months.

Csis 3600 systems analysis and design


  • Supports either SLOC


  • Function Points

  • (Note this is true for download and commercial versions, the Web version supports SLOC.)



  • Mode of the project:

    • Organic (project is from a familiar, stable, and fairly unrestrained environment)

    • Semidetached (project is not Organic or Embedded)

    • Embedded (project environment is unfamiliar, tightly constrained, and unforgiving)

Csis 3600 systems analysis and design

Scale Drivers in COCOMO II

  • The selection of scale drivers is based on the rationale that they are a significant source of exponential variation on a project’s effort or productivity variation

  • Each scale driver has a range of rating levels, from Very Low to Extra High.

Csis 3600 systems analysis and design

Scale Drivers

  • Precedentedness

  • Development Flexibility

  • Architecture/Risk Resolution

  • Team Cohesion

  • Process Maturity

Csis 3600 systems analysis and design

Cost Drivers

  • Capture characteristics that affect the effort to complete the project

  • ETSU program lists all options as cost drivers

Csis 3600 systems analysis and design

Product Attributes

  • Required Reliability

  • Database Size

  • Product Complexity

  • Required Reuse

  • Documentation

Csis 3600 systems analysis and design

Platform Attributes

  • Execution Time Constraint

  • Main Storage Constraint

  • Platform Volatility

Csis 3600 systems analysis and design

Personnel Attributes

  • Analyst Capability

  • Programmer Capability

  • Personnel Continuity

  • Applications Experience

  • Platform Experience

  • Language and Toolset Experience

Csis 3600 systems analysis and design

Project Attributes

  • Use of Software Tools

  • Multisite Development

  • Required Development Schedule

Csis 3600 systems analysis and design

Try It

  • Visit http://sunset.usc.edu/research/COCOMOII/

  • Go about ¾ of the way down and you can try it out via the Web

  • COSMOS – Function Point and COCOMO http://www-cs.etsu.edu/cosmos/

    • Use this for homework 1 question 4

Csis 3600 systems analysis and design

Other Sources

  • Listing of Cost Estimation Software

  • http://www.dacs.dtic.mil/databases/url/key.hts?keycode=4:152&islowerlevel=1

Controlling and directing the project

Controlling and Directing the Project

  • Refine estimates

  • Match need to resources and monitor that it happens

  • Manage scope

  • Manage risk

  • Maintain quality

Quality assurance

Quality Assurance

A development process, methodology, and even a well-defined plan, do not ensure quality. Quality must be managed. Quality begins with establishing standards.

  • Some internal standards in systems development include:

    • Standards for project deliverables such as reports and documentation

    • Modeling techniques

    • Naming standards for models, objects, programs, databases, etc.

    • Quality check-points and sign-offs at various stages of the project

    • Technology standards such as approved graphical user interface components and placement

    • Testing procedures and tolerances

    • Acceptance criteria for implementation

Project tracking tools

Project Tracking Tools

  • Gantt Charts

  • Pert Charts

  • Understand the critical path and slack

Critical path and slack resource

Critical Path and Slack Resource

  • Critical Path is a sequence of dependent project tasks that result in shortest time to project completion. It contains no slack time. Any activity delayed will cause delay in project completion.

  • Activities not on the critical path contain slack time. Slack time available for any task is equal to the difference between the earliest and latest completion times.

    • Tasks with slack time can get behind schedule by an amount less than the available slack time without having an impact on the project’s final completion date.

Critical path and slack resource continued

Critical Path and Slack Resource continued

  • Understanding critical path and slack resources are indispensable. Emphasis can be placed on the critical path, and if necessary, resources temporarily diverted from tasks with slack time to more critical ones.

Gantt chart

Gantt Chart

  • A simple horizontal bar chart that depicts project tasks against a calendar.

    • Bars represent detailed tasks.

    • The length of the bar represents duration of the task.

    • The bar is positioned according to its planned start and end dates.

Csis 3600 systems analysis and design

Figure 3-10a -A Gantt Chart

Csis 3600 systems analysis and design

Activity Progress Representation on Gantt Chart

Sequence of activities

Sequence of Activities

  • Predecessor is a task that must be completed before the start of the task in question

  • Constraints include dependence or a task that is dependent on the start of another task (as opposed to its completion). Other constraints might include specific date for task initialization (programmer start date, etc.)

  • Based on predecessors and constraints, determine activities/tasks and identify all required preceding activities. Activities may have 0, 1, or more preceding activities.

Project evaluation and review technique pert chart

Project Evaluation and Review Technique (PERT) Chart

  • PERT charts represent another view of a project schedule that emphasizes intertask relationships.

Annotated pert chart

Annotated PERT Chart

  • Rectangle contains:

  • Task Name

  • Task ID and Estimated Duration

  • Start and End dates

  • Red indicates task is on critical path

Annotated pert chart continued

Annotated PERT Chart continued

Pert including time completion estimates

PERT including Time Completion Estimates

  • Note that when Te = Tl, slack time is 0.

  • Tasks with 0 slack time are on the critical path.

Gantt vs pert

Gantt vs PERT

  • PERT and Gantt charting are frequently presented as mutually exclusive tools. However, they can be used in a complementary manner.

  • PERT is recommended for larger projects with high intertask dependency. Gantt is recommended for simpler projects.

  • Gantt charts seem to be preferred in IS projects.

  • Most project management tools now incorporate critical path analysis.

Sample base line project plans

Sample Base line Project Plans

Links to sample project plans are found under Lecture Notes.

Quote of the week

Quote of the Week

Top 10 Signs of IS Project Failure:

10. All software purchased is Version 1.0.

9. All hardware purchased come from a discount company called Kludges "R" Us.

8. Project manager is spotted reading PCs for Dummies

7. Application developers think Java OLE is something to be ordered at a coffee shop.

6. Network administrators question the usefulness of an ATM system that doesn't accept bankcards.

5. Hardware technicians try to use RAID to cure software bugs.

4. Size of database balloons reaches IWSTBTB (It Wasn't Supposed To Be That Big) proportions.

3. Consultants revamp system architecture, which had been totally revamped only a month ago by a different group of consultants.

2. After system is finally deployed, end users mistake their computer mouses for foot pedals.

1. CIO is seen faxing resume.

(as published by Cahners Publishing Company, a division of Reed Elsevier Business Information, Inc.)

  • Login