1
Introduction to Software Engineering:
Project Management ( Highlights )
John T. Bell
Department of Computer Science Department of Computer Science
University of Illinois, Chicago
Based on materials from chapters 14, 15, and 16 of “Object Oriented Software Engineering” by Bruegge & DuToit 3e.
What would you do
if they put you in charge ?
Project Management Tasks
during the course of a typical project
Identify Project Goals
3
A Work Breakdown Structure, WBS,
divides work into manageable pieces.
Q: How do you eat an elephant?
3
Planning Temporal Dependencies
5
Critical Path Analysis
Source: wikipedia.org/Critical_path_method
(10?)
6 "SimpleAONwDrag3" by Nuggetkiwi - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons
Drag = min( duration, parallel floats ) for critical items only.
Scheduling Activities with Gantt Charts
Source: wikipedia.org/Gantt_chart
7
Gantt Charts in MS Project
Source: wikipedia.org/Gantt_chart
5
Allocating Personnel with a
Skill Matrix
9
Also useful for identifying skill shortages, and for planning long-term skill development.
Earned Value as a Classical Metric
Introduction to Software Engineering:
Software Life Cycle Modeling
John T. Bell
Department of Computer Science
Department of Computer Science
University of Illinois, Chicago
Based on Chapter 15 of Bruegge & DuToit 3e.
Capability Maturity Model, CMM
1. Initial / Ad Hoc – Everyone does their own
thing Sometimes it works out really well thing. Sometimes it works out really well.
2. Repeatable – Everyone does the same thing, the
same way every time, thru habit/inertia.
3. Defined – There exists documentation on how
to do things, and people follow it.
4. Managed – Someone monitors the process, to g p , ensure quality & standards conformance.
5. Improving – There exists a process improvement
7
IEEE Standard 1074 Defines Process
Groups, Processes, and Activities:
13
Life Cycle Models – 1074 Processes
Sequential Activity Models
15
Waterfall V
9
Unified Software Development Process
( a.k.a. the Unified Process )
17
One Sample Cycle of the Unified Process
Entity-Centered Models
19 In a waterfall approach all issues in one category would need to be closed before any in the next category could be opened. Other approaches can have open issues in multiple categories concurrently.
A Final Word on Models:
No Real Process is Ideal or Pure
Models are useful for studying and
y g
discussing ideal processes, but real
processes in practice are always going to
be some sort of a hybrid mix, drawing
ideas from different ideals and combining
them into something appropriate for the
current project.
11
Introduction to Software Engineering:
Methodologies
John T. Bell
Department of Computer Science Department of Computer Science
University of Illinois, Chicago
Based on materials from chapter 16 of Bruegge & DuToit 3e.
Definition of “Methodology”
“A software engineering methodology is a collection of methods and tools for developing and managing a software system to achieve a specified goal in a given environment. It
specifies when methods or tools should be used and what to do when unexpected events occur”
22
and what to do when unexpected events occur. - Bruegge & DuToit, 3rdEdition, Chapter 16.
The project environment can influence
the selection of SW methodology
• Participant’s expertise.
• End user access.
• Technological climate.
• Geographical distribution.
• Project duration vs. rate of change.
23
j g
• Client type – see next slide.
Types of Client, categorized by
decision power and domain knowledge
• Local king client – Has knowledge and authority.
• Proxy client – Has knowledge but no authority.Proxy client Has knowledge but no authority.
• Pseudo client – Has authority but no knowledge.
13
Issues to consider
when selecting a methodology
• How much planning should be done?
• How much reuse to incorporate in design?
( and in what form(s) and to what detail? )
• How much modeling to do before coding?
• How much detail for the process definition?
25
• How much control and monitoring?
• When should project goals be redefined?
Three Methodologies
• Royce’s Methodology, based on the Unified
Process.
• Extreme Programming, XP
• Rugby ( Scrum )
Key Principles of Royce’s Methodology
• Architecture-first approach.
• Confront risks early,
based on iterations of the Unified Process model.
• Minimize lines of human-generated code.
• Change management environment, w. baselines.
27
• Objective quality control, w. automated metrics.
• Visual modeling languages, e.g. UML
15
Key Principles of Extreme
Programming
• Rapid Feedback – Test and confront issues early.
• Incremental Change – One step at a time.
• Simplicity – Design focuses on current
requirement(s) only, w.o. considering the future.
• Embracing Change – Normal, not an exception.
29
• Quality Work – Do excellent work the first time,
instead of going back and fixing things later.
Summary of Extreme Programming
Principles of the Agile Manifesto
( Shared by XP, Scrum, & other Agiles )
The Agile Manifesto values:
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract
31 negotiation.
• Responding to change over following a plan. Both sides have value, but the former moreso.
