0% found this document useful (0 votes)
99 views40 pages

Software Management Insights by Al-Sukairi

The document discusses software project management. It describes conventional waterfall models and their low success rates. It then discusses how iterative development processes, reuse, tools and quality practices can improve economics. The rest of the document details specific software development processes including artifacts, roles, activities, metrics and tailoring the process based on factors like scale and maturity.

Uploaded by

Swetha D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
99 views40 pages

Software Management Insights by Al-Sukairi

The document discusses software project management. It describes conventional waterfall models and their low success rates. It then discusses how iterative development processes, reuse, tools and quality practices can improve economics. The rest of the document details specific software development processes including artifacts, roles, activities, metrics and tailoring the process based on factors like scale and maturity.

Uploaded by

Swetha D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

[Link].

com
Dr. Abdallah Al-Sukairi
sukairi@[Link]

Information & Computer Science Department

6RIWZDUH3URMHFW0DQDJHPHQW
[Link]
Conventional Software Management
‹ The success rate for software projects is very low. Only 10%
of projects are delivered successfully within initial budget and
schedule
‹ Waterfall model
‹ Finding and fixing a software problem after delivery costs 100
time more
‹ For every $1 we spend on development, we need $2 on
maintenance
‹ Variations among people account for the biggest difference in
software productivity
‹ Only about 15% of software development is devoted to
programming
‹ Walkthrough catch 60% of the errors
‹ 80% of contribution comes from 20% of the contributors

2
[Link]
Evolution of Software Economics

‹ Effort
` Personnel
` Environment
` Quality
` Size-Process
‹ Cost estimation models
` COCOMO

3
[Link]
Improving Software Economics
‹ Size
` Higher order languages & objected-oriented
` Reuse and commercial components
‹ Process
` Iterative development
‹ Personnel
` Skill development
` Teamwork
` Win-win cultures
‹ Environment
` Integrated tools
` Open systems
` Automation
‹ Quality
` Demo-based assessment

4
[Link]
The Old Way and the New

‹ Architecture-first approach
‹ Iterative life-cycle process
‹ Component-based development
‹ Change management environment
‹ Round-trip engineering

Planning Design

Assessment Implementation

5
[Link]
Life-Cycle Phases

‹ Engineering stage
` Inspection phase
` Elaboration phase
‹ Construction phase
‹ Transition phase

6
[Link]
Artifacts of the Process
‹ Requirements set
` Vision document
` Regiments model
‹ Design set
` Design model
` Test model
` Software architecture
‹ Implementation set
` Source code
` Component executable
‹ Deployment set
` Product executable
` User manual

7
[Link]
Management Set

‹ Planning artifacts
` Work breakdown structure
` Business case
` Release specifications
` Software development plan
‹ Operational artifacts
` Release descriptions
` Status assessments
` Software change order database
` Deployment documents
` Environment

8
[Link]
Software Architecture
‹ The central design problem of a complex software system
‹ A significant project milestone
‹ It describes
` the structure of software systems
` their behavior
` their collaboration
` their composition
‹ Architecture should include
` Requirements: use cases, quality objectives, priority relationship
` Design: names, attributes, structures, behaviors, groupings, and
relationships of significant classes and components
` Implementation: source component inventory and bill of material
` Deployment: executable components sufficient to demonstrate
the critical use cases

9
[Link]
Software Process Workflows
‹ Management:
` Business case, Software development plan, Status assessment,
Vision, Work breakdown structure
‹ Environment
` Environment, Software change order database
‹ Requirements
` Requirement set, Release specifications, Vision
‹ Design
` Design set, Architecture description
‹ Implementation
` Implementation set, Deployment set
‹ Assessment
` Release specifications, Release descriptions, User manual
‹ Deployment
10
[Link]
Checkpoints of the Process

‹ Major milestones
` system wide events
` synchronize the management and engineering
perspectives
` verify that the aims of the phase have been achieved
‹ Minor milestones
` iteration-focused events
` review the content of an iteration and to authorized
continued work
‹ Status assessment
` provide management with frequent and regular insight into
the progress being made

11
[Link]
Work Breakdown Structures (WBS)

‹ A hierarchy of elements that decompose the project


plan
` Clear task decomposition for assignment of
responsibilities
` A framework fro scheduling, budgeting, and expenditure
tracking

12
[Link]
Conventional WBS

‹ Structured around
the product design

13
[Link]
Evolutionary WBS

‹ Structured around the process framework


` First level elements are the workflow
` Second level elements are defined for each phase of the
lifecycle
` Third level elements are defined for the focus of activities
that produce the artifacts of each phase

14
[Link]
Default Work Breakdown Structure

15
[Link]
Planning Guidelines

16
[Link]
Project Organizations & Responsibilities

17
[Link]
Software Management Team Activities

18
[Link]
Software Architecture Team Activities

19
[Link]
Software Development Team Activities

20
[Link]
Software Assessment Team Activities

21
[Link]
Evolution of Organization

22
[Link]
Process Automation

23
[Link]
Round-Trip Engineering

24
[Link]
Software Change Orders

25
[Link]
The Seven Core Metrics

26
[Link]
Indicators

‹ Management
` Work and Progress
` Budgeted Cost and Expenditure
` Staffing and Team Dynamics
‹ Quality
` Change Traffic and Stability
` Breakage and Modularity
` Rework and Adaptability
` MTBF and Maturity

27
[Link]
Tailoring the Process

28
[Link]
29
Project Scale
[Link]
Process Flexibility

30
[Link]
Process Maturity

31
[Link]
Process Maturity

32
[Link]
Domain Experience

33
[Link]
Example: Small vs. Large

34
[Link]
… Example: Small vs. Large

35
[Link]
Modern Project Profiles

36
[Link]
Top 10 Management Principles
‹ Base the process on an architecture-first approach
‹ Establish an iterative life-cycle process
‹ Transition design methods to emphasize component-based
development
‹ Establish a change management environment
‹ Enhance change freedom through tools that support round-trip
engineering
‹ Capture design artifacts in rigorous, model-based notation
‹ Instrument the process for objective quality control and progress
assessment
‹ Use a demonstration-based approach to assess intermediate artifacts
‹ Plan intermediate release in groups of usage scenario with evolving
levels of details
‹ Establish a configurable process that is economically scalable

37
[Link]
Balanced Principles

38
[Link]
Modern Software Economics
‹ Finding and fixing a software problem after delivery costs 100 times more
‹ You can compress software development schedules 25% of nominal, but not
more
‹ For every $1 you spend on development, you will spend $2 on maintenance
‹ Software development and maintenance costs are primarily a function of the
number of source lines of code
‹ Variations among people account for the biggest differences in software
productivity
‹ The overall ratio of software to hardware costs is still growing
‹ Only about 15% of software development effort is devoted to programming
‹ Software systems and products typically costs 3 times as much per SLOC as
individual software programs
‹ Walkthrough catch 60% of errors
‹ 80% of the contribution comes from 20% of the contributors

39
[Link]
Culture Shifts
‹ Lower level and mid-level managers are performers
‹ Requirements and designs are fluid and tangible
‹ Ambitious demonstrations are encouraged
‹ Good and bad project performance is much more obvious earlier
in the life cycle
‹ Early increments will be immature
‹ Artifacts are less important early, more important later
‹ Real issues are surfaced and resolved systematically
‹ Quality assurance is everyone’s job, not a separate discipline
‹ Performance issues arise early in the life cycle
‹ Investments is automation are necessary
‹ Good software organizations should be more profitable

40

You might also like