Home > Software Project Management

Software Project Management


Software Engineering: 
A Perspective for 2003
 

Linda Shafer

Director, Software Quality Institute (SQI)

The University of Texas at Austin

www.utexas.edu

lshafer@mail.utexas.edu 

Don Shafer

Chief Technology Officer, Athens Group, Inc.

www.athensgroup.com

donshafer@athensgroup.com


Copyright © 2002 Linda and Don Shafer  
 

2  

Seminar Dedication 

Enrico Fermi referred to these brilliant Hungarian scientists as “the Martians,” based on speculation that a spaceship from Mars dropped them all off in Budapest in the early 1900’s.


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

3  

Software Engineering Seminar  

Many professionals  feel that the Waterfall Model is old fashioned or simplistic, having long ago outlived its usefulness – the very name seems wrong, since water cannot “fall” uphill to accommodate the backward arrows.  All sorts of new models have been depicted to better show how the “real world” works, or how software can be developed faster, or how customers can become more engaged in the process to improve functionality.  The Spiral Model, the Evolutionary Rapid Prototyping Model, the “V”-Shaped Model and others have emerged to solve one issue or another. Today, most practitioners might agree that there are so many different types of projects, a one size SLC cannot possible fit all.  The modern viewpoint is that unique projects require unique models, or combinations of models to succeed.  We will discuss the choice of appropriate SLC models, or modified versions of SLC models, the real baseline for beginning software engineering. We will describe several of the more modern SLC’s (e.g. eXtreme, RUP), and how a project manager can decide which one to use.  We will also explain what the various bodies of knowledge (e.g. PMBOK, SWEBOK) map to our life cycles.


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

4  

Presentation Description 

  • The key to managing a software development project is having a high level road map to identify where you are on the project. The life cycle model you adopt for your development project is this roadmap. Using IEEE 1074, we will walk through a "standard" development life cycle and all the supporting processes required; e.g. configuration management, documentation, project management, software quality assurance. Using this as the baseline we'll construct a first pass WBS for the life cycle.
  • The next steps will be to customize the baseline life cycle for two different types of development: evolutionary rapid prototyping and commercial-of-the-shelf package selection.
  • To wrap up, some metrics on life cycles for web-based application delivery.

Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

5  

NOT the Model you want! 

Code & Test 

Do Until Done 

Inputs 

Outputs


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

6  

Methods 

Tools 

Technology 

Product Development 

Products


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

7  

A Quick Level Set 

  • Technology
    • Application of scientific knowledge in industry or business
  • Tool
    • An implement or machine used to do work or perform a task.
  • Method
    • A manner, means or process for accomplishing something.

Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

8  

What’s in each segment? 

Java

UML

XML 

VoIP

Oracle

Copernic 

Internet

Intranet

Extranet

Object-Oriented 

Software Engineering    Project Management 

Methods 

Tools 

Technology 

Products


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

9  

How do products happen? 

Methods 

Tools 

Technology 

Products 

Methods 

Tools 

Technology 

Products 

Ideas 

Products


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

10  

Project Management Mitigates the Front End Risks 

Concept

Definition 

Needs Assessment 

Plan 

Project Plans 

Specifications 

Databases 

ROI Analysis 

Risk Analysis 

Adapt 

Improve 

Observe 

Analyze 

Management Plan 

Risk Reduction 

Planning 

Training 

Configuration Management 

Quality 

Research 

Estimating 

Market and

System

Requirements 

Candidate

Architecture

Identification


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

11  

  1. Become familiar with the various models
  2. Review, analyze the type of work:  development, enhancement, maintenance, etc.
  3. Review project criteria
  4. Identify a minimum set of phases
  5. Identify phase activities
  6. Establish a minimum set of deliverables
  7. Define templates and content guides for deliverables
  8. Evaluate progress and effectiveness of the life cycle framework
  9. Implement improvements
 

Defining Your Life Cycle Model


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

12  

Build and Fix


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

13  

Build and Fix – Good and Bad 

Not a life cycle model 

No specifications 

Does not scale with large projects 

One step beyond code and test 

Works for projects generating less than 200 LOC 

Cons: 

Pros:


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

14  

Basic 1074 Life Cycle


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

15  

Full 1074 Life Cycle (1)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

16  

Full 1074 Life Cycle (2)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

17  

Full 1074 Life Cycle – Good and Bad 

Is not in and of itself a life cycle to implement 

Is a process for defining your life cycle 

Contains more than you may reasonably use 

Contains all the life cycle supports you would need 

Too much process 

THE starting point for defining you life cycle 

Cons: 

Pros:


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

18  

Waterfall Model 

Planning 

Analysis 

Design 

Build 

Test 

Deploy


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

19  

Waterfall Model – Good and Bad 

Document and deliverable driven 

Enforced discipline 

Too much documentation 

Easiest to instrument 

Does not model the real world 

Easiest to understand 

Cons: 

Pros:


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

20  

Waterfall with Prototyping 

REVIEW       

DETAIL DESIGN 

Process Steps 

Process Gates 

Prototypes 

REVIEW       

REQUIREMENTS DEFINITION 

REVIEW       

HIGH LEVEL DESIGN 

REVIEW       

SYSTEM CONSTRUCTION 

REVIEW       

VERIFICATION & VALIDATION 

REVIEW       

SYSTEM DELIVERY 

PROTOTYPE

1 

PROTOTYPE

2 

PROTOTYPE

3 

POST

IMPLEMENTATION

REVIEW 

Project Management Support Processes

Risk Reduction     Training     Planning     Configuration Management     Estimating     Metrics     Quality Assurance


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

21  

Prototyping Model - Pros and Cons 

Real world modeling 

Document and deliverable driven 

Recursion among process steps 

Prototyping becomes early code hacking 

Easiest to instrument 

Not stopping the prototyping 

Easiest to understand 

Cons: 

Pros:


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

22  

Spiral Model


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

23  

Spiral Good and Bad 

Risk focused testing 

Risk and prototyping tools a must 

Easy look at product with prototypes 

Requires a mature organization 

Maintenance and development mesh 

High overhead costs 

Supports reuse 

Internal development of large systems 

Emphasizes risk reduction 

Cons: 

Pros:


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

24  

Rapid Application Development


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

25  

RAD – Good/Bad 

Tight delivery control 

Poorly set expectations 

Increased overhead if too many prototypes 

Incremental building 

Needs maturity of tools and process 

Early proof of concept 

Users intimately involved 

Lots of user interaction 

Cons: 

Pros:


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

26  

Requirements 

Waterfall 

Prototype 

Spiral 

RAD 

Are the requirements easily defined and/or well known? 

Yes 

No 

No 

Yes 

Can the requirements be defined early in the cycle? 

Yes 

No 

No 

Yes 

Will the requirements change often in the cycle? 

No 

Yes 

Yes 

No 

Is there a need to demonstrate the requirements to achieve definition? 

No 

Yes 

Yes 

Yes 

Is a proof of concept required to demonstrate capability? 

No 

Yes 

Yes 

Yes 

Selecting a Life Cycle Model - Project Characteristic Category Matrix Requirements


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

27  

Project Team 

Waterfall 

Prototype 

Spiral 

RAD 

Are the majority of team members new to the problem domain for the project? 

No 

Yes 

Yes 

No 

Yes 

No 

Yes 

No 

Yes 

No 

Yes 

No 

Are the team members subject to reassignment during the life cycle?  

  

No 

Yes 

Yes 

No 

Is there training available for the project team if required?  

No 

No 

No 

Yes 

Selecting a Life Cycle Model - Project Characteristic Category Matrix Project Team 

Are the majority of team members new to the technology domain for the project? 

Are the majority of team members new to the tools used on the project?


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

28  

User Community 

Waterfall 

Prototype 

Spiral 

RAD 

Will the availability of the user representatives be restricted, or limited during the life cycle? 

Yes 

No 

Yes 

No 

Are the user representatives new to system definition?  

No 

Yes 

Yes 

No 

Are the user representatives experts in the problem domain? 

No 

Yes 

No 

Yes 

Do the users want to be involved in all phases of the life cycle? 

No 

Yes 

No 

Yes 

Selecting a Life Cycle Model - Project Characteristic Category Matrix User Community


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

29  

Project Type & Risk 

Waterfall 

Prototype 

Spiral 

RAD 

Does the project identify a new product direction for the organization? 

No 

Yes 

Yes 

No 

Is the project a system integration project?  

No 

Yes 

Yes 

Yes 

Is the project an enhancement to an existing system? 

No 

No 

No 

Yes 

Is the funding for the project expected to be stable throughout the life cycle? 

Yes 

Yes 

No 

Yes 

Is the product expected to have a long life in the organization? 

Yes 

No 

Yes 

No 

Selecting a Life Cycle Model - Project Characteristic Category Matrix Project Type and Risk


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

30  

Two Derived Development Methods 

  • COTs
  • eXtreme Programming

Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

31  

Before Customizing Remember the Framework Activities … 

  • An effective process model should define a small set of framework activities that are always applicable, regardless of project type. The APM defines the following set of framework activities:

    I. project definition - tasks required to establish effective communication between developer and customer(s) and to define requirements for the work to be performed

    II. planning - tasks required to define resources, timelines and other project related information and assess both technical and management risks

    III. engineering and construction - tasks required to create one or more representations of the software (can include the development of executable models, i.e., prototypes or simulations) and to generate code and conduct thorough testing

    IV. release - tasks required to install the software in its target environment, and provide customer support (e.g., documentation and training)

    V. customer use - tasks required to obtain customer feedback based on use and evaluation of the deliverables produced during the release activity

  • Each of the above framework activities will occur for every project. However, the set of tasks (we call this a task set) that is defined for each framework activity will vary depending upon the project type (e.g., Concept Development Projects will have a different task set than Application Enhancement Projects) and the degree of rigor selected for the project.

Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

32  

… and the Umbrella Activities 

  • In addition to the framework activities, a set of umbrella activities persist across the entire software process. These umbrella activities include:
  • software project management
  • formal technical reviews
  • software quality assurance
  • software configuration management
  • reusability management
  • measurement
  • document preparation and production
  • risk management
  • Each of these umbrella activities is defined by a set of tasks that are adapted to the project type and degree of rigor with which software engineering is to be applied.

Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

33  

COTS Application Selection (1)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

34  

COTS Life Cycle (2)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

35  

COTS Life Cycle (3)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

36  

eXtreme Programming 

                                                                                                


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

37  

eXtreme Programming - the propaganda 

  • Light methods are adaptive rather than predictive. Heavy methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The light methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves.
  • Light methods are people-oriented rather than process-oriented. They explicitly make a point of trying to work with peoples' nature rather than against them and to emphasize that software development should be an enjoyable activity.

Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

38  

eXtreme Programming - the truth :-)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

39  

Classical “Best” Effort per Phase 

100% of Product Full Life Cost 

Front end: 40 – 50% 

Back end: 50 – 60% 

5% 

5% 

30% 

30% 

20% 

10%


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

40  

Real Web Project Metrics(1) 

What is the message here?


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

41  

Real Web Project Metrics(2)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

42  

Real Web Project Metrics(3)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

43  

Real Web Project Metrics(4)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

44  

Real Web Project Metrics(5)


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

45  

Web Effort per Phase (Preliminary Research) 

100% of Product Full Life Cost 

Front end: 40 – 50% 

Back end: 50 – 60% 

7%

-3% 

10%

-20% 

16%

-14% 

65%

+45% 

2%

-8%


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

46  

Best Practices that Work 

  1. Define your life cycle
  2. Set up a metrics system
  3. Formalize project management
  4. Develop a prototyping process
  5. Institute reviews and inspections
  6. Implement non-invasive configuration management
  7. JAD with your customers

Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

47  

  1. Become familiar with the various models
  2. Review, analyze the type of work:  development, enhancement, maintenance, etc.
  3. Review project criteria
  4. Identify a minimum set of phases
  5. Identify phase activities
  6. Establish a minimum set of deliverables
  7. Define templates and content guides for deliverables
  8. Evaluate progress and effectiveness of the life cycle framework
  9. Implement improvements
 

Defining Your Life Cycle Model


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

48  

Why a metrics system?


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

49  

Best Practices that Work 

  1. Evolve to an object-oriented model
  2. Embrace modeling with UML
  3. Build early and often
  4. Build anywhere
  5. Communicate, communicate, communicate

Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

50  

Key Life Cycle Message 

Whatever life cycle you start with will not be the one that will really work for you. You have to take charge of your life cycle, monitor it and adapt it to your circumstances. In the end it must become yours!


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

51  

Are you secure with your process??? 

Questions ???


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

52  

Linda Shafer Bio: 

Linda Shafer has been working with the software industry since 1965, beginning with NASA in the early days of the space program. Her experience includes roles of programmer, designer, analyst, project leader, manager, and SQA/SQE. She has worked for large and small companies, including IBM, Control Data Corporation, Los Alamos National Laboratory, Computer Task Group, Sterling Information Group, and Motorola. She has also taught for and/or been in IT shops at The University of Houston, The University of Texas at Austin, The College of William and Mary, The Office of the Attorney General (Texas) and Motorola University. Ms. Shafer's publications include 25 refereed articles, and three books. She currently works for the Software Quality Institute and co-authored a SQI Software Engineering Series book published by PrenHall in 2002: Quality Software Project Management. She is on the International Press Committee of the IEEE and an author in the Software Engineering Series books for IEEE. Her MBA is from the University of New Mexico.


Software Engineering: A 2003 Perspective

Copyright © 2002 Linda and Don Shafer  
 

53  

Don Shafer Bio: 

Don Shafer is a co-founder, corporate director and Chief Technology Officer of Athens Group, Inc. Incorporated in June 1998, Athens Group is an employee-owned consulting firm, integrating technology strategy and software solutions. Prior to Athens Group, Shafer led groups developing and marketing hardware and software products for Motorola, AMD and Crystal Semiconductor. He was responsible for managing a $129 million-a-year PC product group that produced the award-winning audio components. From the development of low-level software drivers in yet-to-be-released Microsoft operating systems to the selection and monitoring of Taiwan semiconductor fabrication facilities, Shafer has led key product and process efforts. In the past three years he has led Athens engineers in developing industry standard semiconductor fab equipment software interfaces, definition of 300mm equipment integration tools, advanced process control state machine data collectors and embedded system control software agents. His latest patents are on joint work done with Agilent Technologies in state-based machine control. He earned a BS degree from the USAF Academy and an MBA from the University of Denver. Shafer’s work experience includes positions held at Boeing and Los Alamos National Laboratories. He is currently an adjunct professor in graduate software engineering at Southwest Texas His faculty web site is http://www.cs.swt.edu/~donshafer/. With two other colleagues in 2002, he wrote Quality Software Project Management for Prentice-Hall now used in both industry and academia. Currently he is working on an SCM book for the IEEE Software Engineering Series.


Software Engineering: A 2003 Perspective

Search more related documents:Software Project Management
Download Document:Software Project Management

Set Home | Add to Favorites

All Rights Reserved Powered by Free Document Search and Download

Copyright © 2011
This site does not host pdf,doc,ppt,xls,rtf,txt files all document are the property of their respective owners. complaint#nuokui.com
TOP