Management of Software Projects

1
Management of Software Projects

• CS 209

2
Bibliography

• Bennatan E.M., On Time, Within Budget, 2d Ed.,
  John Wiley Sons, 1995
• Pressman R.S., Software Engineering A
  Practitioner Approach, 4th Ed. 1996

3
Course Goal

• Understand the software production
• Use the Software Life Cycle models
• Use development process (SEI ISO 9000) models
• Use of standards (IEEE, ISO)
• Understand need for tools, training, and
  homogeneous teams

4

• Will Discuss
• Quality issues
• Customer perspective
• Software metrics and their use in better system
  production
• Will NOT Discuss
• Use of Language
• Management styles

5
Understanding Software Development

• A production line starts with
• Requirements for the article
• Design of article
• Bread-board of article
• Prototype
• Production Line design
• Application of quality standards
• PRODUCTION
• Sample testing.
• Problem reporting from customers

6
Software Production

• Starts with
• Requirements
• Design
• Coding
• Testing
• Product Shipment etc.
• Regardless of magnitude same method

7
Software Development

• Exacerbating technical issues
• Need for software grows at an alarming rate
• Everything is written ? easy to change
• Changes cause problems when ever and where ever
  introduced
• Problems (bugs) ?Testing is taking more and more
  time and resources

8
Low Quality Issues

• Job Security
• The Feedback Factory
• Low Availability
• Low Reliability
• Customers hate it
• US Car Industry, Motorola, Elscint
• No new Products, Sales Down etc.

9
Software Development

• SW development takes special personal traits
• Mainly work alone (we want team) ?
• Interfacing between teams very difficult
• Keeping standards very difficult to implement
• Personal writing style
• Dress and talk very personal
• Ability to concentrate on details (the big
  picture not seen) ? Personal Solutions

10
Projects Success

• SW development war stories
• projects ran up to 400 times their original
  budget (OS 370, Anti-missile defense system)
• Projects abandoned after substantial investment
  (artificial intelligence)
• Project failure biased by customers perception
  (part of Motorola products, Hong Kong air-port
  etc.)
• Projects success is On time, within budget,
  accepted and used by customer ? may vary and
  difficult to measure

11
Project Management Goal

• Ensure projects success
• Hokus-Pocus ?
• Need for software engineering

12
Is There Software Engineering?

• It better be !
• Needs a lot of management and tools
• SW Engineers tend to waste time on solving what
  they like
• A tool with problems will not be used
• Tool has to demonstrate that it executes better
  and faster then SW engineer
• Tool to be used for is own goal and not others

13
SW Problem Solution

• Use of Tools
• Reuse of patterns and functions
• Tends to
• Shorten development time
• Removes developers individual methods
• Results in use of old stuff (not using new
  methods and techniques
• Information about existing solutions in the
  organization decreases (memory, attrition,
  turnover) ? a lot of dead wood
• New SW architecture (client/server) results in
  increased engineers freedom

14
Role of Management

• Often good engineers make poor managers
• Managerial skills are a must
• Technical know how IS NEEDED
• From projects inception management is needed
• Management is needed in order to
• Supervise and control activities of the
  development team(s)
• Constant awareness of developers REAL work
  status
• Planning
• Includes preparation of estimates (effort
  time) development schedule, training and budget
  (hw sw) needed for development, efficient
  assignment of personnel with relevant experience
  (knowledge)

15
Management Roles (cont.)

• Technical leadership
• Gain developers respect understand lingo
• Persuade higher mgmt about need for new/different
  development tools and methods
• Customer Relations
• Documenting customers requests
• Controlling changes
• Handle customers involvement
• Reports reviews

16
Customer perspective

• When does the Consumer see the system
• What bothers the consumer
• What happens with half working systems
• What if damage is done
• What if revenue is withheld
• Customer wants .
• ? Ensuring the customer satisfaction is part of
  the SW projects management

17
Dialogue with higher mgmt.

• New methods are theoretical.
• SW development record is poor (rate of
  success/failure very low!)
• All methods (including the used ones!) have
  theoretical basis
• Other companies (subject and size) use the new
  methods with success (measured!)
• Project managers are too formalistic (everything
  in writing!)
• Ensures common understanding of commitments
  (beneficial to higher mgmt.)

18
Dialogue with higher mgmt.

• Project managers are ..(cont.)
• Ensures common understanding of both
  functionality and customer commitments
  (beneficial to customer higher mgmt.)
• Documentation of changes and requests ensure
  correct development!!
• Excessive paperwork
• Paperwork should be kept to a minimum however,
  well documented instructions are given only once
  and save time by not being repeated or
  misunderstood!!

19
Dialogue with higher mgmt.

• Methods are good but this is not the right time
• There is no correct time, rather cool reasoning
  of benefit (metrics are the HELP!)
• Training all team (in new methods)?
• Bulk training is cheaper!
• SW Engineers need training as 50 of their
  knowledge become obsolete in just 2 years
• New development field need new knowledge
• Metrics collection? This is not a university!
• Quality can be measured only by metrics
  collection
• Increased quality ? satisfied customer ?more
  sales!!

20
Things to Remember

• Personal and collective (team) experience and
  knowledge in field is essential for success
• Commitment for either schedule or budget are
  binding only after full knowledge of
  functionality
• Too many problems (bugs) may indicate that a
  sensible decision would be to develop a new
  system from scratch rather then fixing the old
  one
• Customers at best have a vision of their need, it
  is the developers task to develop the correct
  set of requirements
• Adherence to schedule and budget does not make
  sense if customer requirements are not met

21
Things to Remember

• Regardless of the genius and tricks used in
  development, customer satisfaction resides only
  in functionality and performance
• Avoid use of revolutionary techniques and
  tools! (SW engineers love them, customer hates
  them)

22
Software Life Cycle

• Old Model
• Successive approximations
• Requirements
• Requirements analysis
• HLD LLD
• Code
• Integration

23
Software Life Cycle

• What is missing
• The different testing levels
• The positive feedback
• Exact development
• Monitoring!
• Plan to include in development the above
  and.(next slide)

24
Hidden Projects Goals

• Developers need
• Testability
• Maintainability
• Customer and Developer need
• The 5-Nines Model
• Six Sigma

25
What is a Process

• Informal process
• low on objectives
• varying quality
• no feedback?
• Formal process (Ob En Ex Fu)
• measurement

26
Process Schematics
Entry Criteria Requirements input has to comply
with
Exit Criteria Requirements which output has to
comply with
Objectives what must be accomplished
Functions Methods (how) is the objective to be
accomplished
Note The Functions are themselves a mini process
27
Process and Measurements

• Schedule, Budget, and Quality have to be planned
• Need for processes to ensure a viable plan for
  meeting commitments
• Two main standards exist
• Software Engineering Institute Level (USA)
• ISO 9003 (European)
• Standards allow organization to measure itself

28
SEI Capability Maturity Model

• Goal
• Through Evolution (not revolution) help
  organizations improve their software development
  process
• Hidden Assumption
• A garage with adequate tools does a better job
  then a garage with no tools!

29
SEI Levels

• There are five levels
• Ad-hoc (Level 1)
• Repeatable
• Defined
• Managed
• Optimized (Level 5)
• Levels known as SEI Level x

30
SEI Level 2 (Repeatable)

• Processes in place to track cost, schedule and
  functionality
• Infrastructure for successful repetition is in
  place ?
• At least in the present field one can assume
  successful completion of projects via the
  discipline in place

31
SEI Level 3 (Defined)

• Processes for management and engineering are in
  place and FOLLOWED
• All projects use approved processes (tailored for
  each project) ? who decides?
• One is assured that success is probable in new
  fields of development!! Through the use of a
  consistent process

32
SEI Level 4 (Managed)

• Measurements of process and product are routinely
  taken
• Organizations processes and products are
  understood and controlled ?feedback?
• Only successful process and methods are used
  ensuring a small error margin regarding projects
  success
• Organization is using a predictable process

33
SEI Level 5 (Optimized)

• Continuous Process Improvement including
  increased product quality,reduced development
  time, and budget is achieved via use of
  quantitative measurements (of level 4 and new
  measurements)
• AS PROCESS BECOMES DYMANIC CAN VERY EASILY
  DETERIORET TO AD-HOC!
• Organizations attaining Levels 4 or 5 are very
  rare

34
Measurement Why and How

• Improvement is relative ? know where you are now
  relative to previous measurement
• SEI measurement measure the process not the
  products quality
• There is a high correlation between process and
  quality, quality and lines of code production,
  process and time to market
• Obvious correlation between process and
  testability, maintenance and development budget

35
Key Process Areas

• Based on above each level contains specific
  process parts I.e. Key Process Areas
• As we go to higher SEI levels additional KPAs
  are included
• Key process areas are measured via a set of
  specific questions pertaining to that area
• The audit technique is used in all process
  measurements (e.g. ISO 9000)
• Key process areas are not orthogonal and many
  times appear with different depth at various
  levels

36
The Audit Process

• Contains questions divided into categories in
  each KPA
• Categories are
• Commitment to perform
• Activities to perform
• Ability to perform
• Measurement and analysis
• Verifying Implementation
• Pass is needed separately in each KPA

37
Level 2 KPAs

• Requirement management (establish common
  understanding between customer and development
  team regarding WHAT will be developed)
• Software project planning (establish reasonable
  plans for development and the software
  management)
• Software project tracking and oversight (provide
  adequate visibility to project management of
  actual progress so actions can be taken on time!)
• Software subcontract management (selection of
  qualified subcontractors and their management)

38
Level 2 KPAs

• Software quality assurance (provide management
  with appropriate visibility into process used and
  ensure product being built conforms with required
  process and standards)
• Software configuration management (provides
  stable development environment, controls changes,
  provide software baselines, control access to
  development areas)

39
Level 3 KPAs

• Organization process focus (development,
  improvement maintenance)
• Organization process definition (development of a
  set of processes for tailoring)
• Training program (personal process and technology
  training)
• Integrated software management (integrated
  management and process tailored from
  organizations process standards)

40
Level 3 KPAs

• Software Product Engineering (consistent
  performance of a well defined engineering process
  that integrates all software engineering
  activities and produces correct, consistent
  software products effectively and efficiently)
• Inter-group coordination (establishes means of
  interaction between different SW engineering
  groups and teams so the project is better able to
  effectively satisfy the customer needs

41
Level 3 KPAs

• Peer reviews (to remove defects from the software
  products and deliverable early and efficiently
  is a methodical examination of work products with
  authors peers to identify defects, and needed
  changes process identifies the deliverables to
  be reviewed)

42
Level 4 KPAs

• Quantitative process management
• controls process performance in the project
• establishes goals for process performance
  acceptable band
• causal analysis for exceptions (measure the
  projects performance and later analyze it so
  process can be adjusted)
• Process based on metrics already measured and
  statistical analysis (uses histograms, Pareto
  diagram analysis, correlations, graphs, control
  charts, problems causal analysis etc.)

43
Level 4 KPAs

• Software quality management (develops a
  quantitative understanding of the projects
  software products and achieves specific quality
  goals) uses same techniques specified earlier
• By definition level 4 needs a deeper involvement
  of developers in the process monitoring and
  understanding ? many organizations think it is
  not worth while as it becomes a university (BS!)

44
Level 5 KPAs

• Defect Prevention (identify defects cause and
  change process to prevent them)
• Technology change management (identify new
  technologies tools, methods, and process and
  use a controlled deployment process in order to
  incorporate the change in the organization)
• Process Change (continuous process improvement to
  achieve higher quality and shorter time to market)

45
The Metrics

• What can be measured (time, effort, quality)
• Time to market
• Time for development
• Effort (staff hours, lines of code)
• Productivity (lines of code/per engineer/year)
• Number of problems (total/category)
• Rate of problems
• Problem fixing effort and time (LOC,
  open-closure, time to fix)
• MTBF

46
The Metrics

• What can be easily measured
• Development phase efficiency
• Engineer productivity
• Overall product quality
• Cost of non quality
• Testing efficiency
• Effort per functional area (staff hours, calendar
  time)
• Time per requirement
• Development team quality ?
• Individual engineer quality and productivity ?
• Number of installed systems

47
The Metrics

• Complex Measurements
• Phase containment efficiency over time
• Quality over time
• Productivity over time
• Test efficiency and remaining hidden problems
• MTBF
• All metrics after the fact, we still need metrics
  for on time within budget with high quality

48
Planning Tracking and Measuring

• Plan project so that by tracking it we can
  measure present rates of development and predict
  project closure
• Project phases ? step by step development
• Step by step is water fall model
• Variations exist but all basically the same
• Addition of fast prototype as means of
  requirement collection and estimates
• Some parallelism in phases

49
Plan Projects Phases

• Concept Exploration
• Requirement Collection
• Requirement Analysis
• High Level Design
• Low level Design
• Coding
• Unit and Subsystem Tests
• Integration and system Test
• Installation
• Acceptance Test
• Maintenance

50
Planning Per Phase contains

• Calendar Time
• Effort (Staff Days LOC)
• Personnel
• Risk analysis (probability, contingency plan)
• How does it interact with auxiliary processes of
  Configuration management and SQA

51
The Phase Deliverables

• Concept Phase
• Need of system determined
• Problem to be solved
• Interface to existing systems
• Time by which system has to be completed
• Budget range
• Basic concept established
• Minimal required functionality
• Possible additions
• Reliability
• Mandatory standards
• Environment system has to function in

52
The Phase Deliverables

• Concept Phase (cont.)
• Initial organization setup
• Person to lead effort
• Team to carry out work and research
• Review and audit team
• Outputs
• Product Description Document
• A technical document describing the system,
  environment, interfaces and standards
• A driver for requirements collection
• To be used as a primary marketing document
• In an RFP makes the technical requirements part

53
The Phase Deliverables

• Concept Phase (cont.)
• Outputs (cont.)
• Concept document
• Concept phase is usually very informal ?
  decisions may be taken informally and reasons not
  given
• Document contains the technical reasoning behind
  the product description
• Problems and issues
• Drive and mood of team varies
• Higher management needs clear binding
  functionality and estimates
• Initial status yield broad stroke functionality
  and rough estimates

54
The Phase Deliverables

• Problems and issues(cont.)
• Difficult to staff the initial team with correct
  mix of knowledge, expertise, and seniority
• Research neither comprehensive nor deep enough
• Too many chiefs no work but many different
  approaches
• No chiefs no coordination and probable miss of
  the main point
• A possible costly solution quick prototype
• Eliminates excessive chiefs
• Demonstrate shortcoming and not needed
  functionality

55
The Phase Deliverables

• The Software Requirements Phase
• Forms the projects first formal binding
  documents
• Best developed using a formal standard (e.g. IEEE
  standard 830-1984 and others)
• Needs customers inputs
• Completeness ensured by subject experts
• The basis for ALL ensuing effort
• Schedule, design, coding, testing, training, and
  customer documentation start here!

56
The Phase Deliverables

• The Software Requirements Phase (cont.)
• Entry criteria Product description document
  completed
• The documents produced are
• Requirements
• Program development plan
• Software quality assurance plan (includes tests
  hierarchy)
• Configuration management plan
• Ensuring completeness and quality of these
  documents is of paramount importance to the
  project
• Exit Criteria Reviewed and base-lined documents

57
The Phase Deliverables

• The documents contents
• Requirements
• Contain the formal requirements of the system,
  numbered and grouped according to functionality
• Customer involvement needed to ensure system
  includes the customer need and only its need!
• Subject matter expert needed to ensure system to
  be developed has all the necessary functionality
• Best written using a standard and a template
• Many places use IEEE 830-1984

58
The Phase Deliverables

• The documents contents (cont.)
• Program development plan
• Probably the most important managerial document
• The most difficult to compile
• Needs a lot of knowledge about the project and
  the teams ability
• Describes the following
• How the project will be developed
• The resources needed (hardware, software and
  personnel)
• How are resources to be used, when needed etc.
• The projects schedule
• Risks and contingency plan

59
The Phase Deliverables

• The documents contents (cont.)
• Software quality assurance plan
• Combines both preceding documents and sets up the
  frame work for the quality assurance process in
  the project
• Needs knowledge of the organizations ability and
  history
• It sets the framework for the testing, the
  quality goals, standards etc.
• Proclaims the development tools to be used
• Included are the languages to be used!
• Configuration management plan

60
The Phase Deliverables

• The documents contents (cont.)
• Configuration management plan
• Sets the framework for the configuration
  management process
• has close links with quality and security
• can be part of the SQAP or the PDP
• Describes the documents to be managed under this
  heading
• States the tool or manual method to be used
• Points to responsible person/team that carries
  out the configuration management and his tasks
• Sets the rules for the baselines and tape building

61
The Phase Deliverables

• Problems and Issues
• Customer reluctant to finalize requirements
• Developer only eager to close as soon as possible
• Disagreement over estimates
• Disagreement over risks management
• Difficulty in closing needed interface details
  (especially for incomplete software and hardware,
  third party functionality)
• Staffing (existing, recruiting, outsourcing
  training)
• Equipment procurement (what and when)

62
The Phase Deliverables

• All the above
• Increases the difficulty of obtaining signoff
• Tends to yield several iterations and major
  changes in requirements
• Strains relations with customer
• Delay in time to market may kill project
• Partial answer is rapid prototyping
• Remember a prototype is not a product

63
The Phase Deliverables

• The Design Phase
• Uses the Requirements, PDP and SQAP to produce
  the architecture and design of the proposed
  system
• Best developed using formal tool/s which abide to
  a design standard (Structured or Object Oriented)
• Side product of these phase are the subsystem,
  integration and system test plans

64
The Phase Deliverables

• The Design Phase (cont.)
• Entry criteria Requirements PDP and SQAP
  base-lined
• The documents produced are
• High Level Design (HLD)
• Low Level Design (LLD)
• System, integration, and subsystem test plans
  (what is going to be tested!)
• A high level description of test cases
• Tests procedures require knowledge which is not
  yet available
• Exit Criteria Reviewed and base-lined documents

65
The Phase Deliverables

• The documents contents (cont.)
• High Level Design (HLD)
• Contains the systems architecture (in OOD
  constructed using UML)
• The HLD-LLD division enables a critical
  examination of proposed design (needed in large
  systems!)
• Contains a description, relationship and
  interface between subsystems
• Low Level Design (LLD)
• Contains description of all functions making each
  subsystem (plain language or PDL) install too
• A cross reference to requirements

66
The Phase Deliverables

• The documents contents (cont.)
• System/Integration/Subsystem Test Plans
• Contains in hierarchical way the description of
  tests the system has to undergo.
• Description written in plain language
• Tests grouped in suits according to functionality
• Test cases cross referenced to requirements

67
The Phase Deliverables

• Problems and Issues
• Project starts rolling
• ? Requirements found to be wanting
• ? changes tend to creep in
• Team grows fast
• ? project hierarchy not in place yet
• ? need for management, training
• ? confusion and endless discussions
• Answer Planning Management!!!

68
The Phase Deliverables

• The Coding Phase
• Entry criteria HLD, LLD Testing Plans
  base-lined
• Parallelism can be introduced (described later)
• The documents produced are
• Code
• Unit Tests
• System, integration, and subsystem test
  procedures
• User documentation/demo/training
• Testing strategy (up, down, superposition, and
  inside-out)
• Exit Criteria Reviewed and base-lined documents

69
Test types

• Unit Testing
• Subsystem Tests
• System Tests
• Integration
• Acceptance Tests

70
The Phase Deliverables

• The documents contents
• Code
• Code written in the assigned language of all
  functions described in the LLD
• Each function cross referenced to LLD
• Unit Tests
• Per function a list of tests to be carried out
  and their data and results (best done using an
  automated tool)
• Test requirement go through every code line at
  least once, every if statement at least twice!
• Other Tests Procedures
• Data and interface format fixed ? tests data and
  results have to be compiled

71
Testing Purpose

• Testing congruent to Debugging ?
• Testing proves SW works ?
• Testing shows SW does not works?
• Testing reduces risk ?
• Testing is a discipline resulting in low risk
  systems!

72
Testing Versus Debugging
Testing
Debugging

• Known conditions
• Planned, designed etc.
• Proof of error/correctness
• Predictable
• No system knowledge

• No starting point
• Cannot be planned
• Shows what is wrong usually after a known problem
• Demands intuition and experimentation
• System knowledge

73
Testing Paradox

• The Pesticide Paradox Regardless of testing
  quality some problems stay!
• Eliminating easy bugs allow complexity to grow
  and we get to the complexity barrier. Our
  ability to understand those complex states and
  conditions!

74
The Phase Deliverables

• The documents contents
• User Documentation
• Preliminary user documentation written using the
  design documents.
• Testing the documentation and completing it comes
  in the next
• User Training (completed in the next phase)
• Subjects user need learn in order to operate the
  system
• Demo (completed in the next phase)
• Data and modality to enable a pseudo live
  operation
• To be used by marketing and trainers
• Needed in large systems with many users

75
The Phase Deliverables

• Problems and Issues
• Project has to complete on time
• ? Conflicts with management and SQA
• ? Pressure to show something
• Estimate not good enough
• ? a lot of over time and conflicts (additional
  staff?)
• ? cutting corners in process and orderly
  development
• Technical solution wants
• ? changes in requirements customer relations
  suffer
• Answer Planning Management!!!

76
The Phase Deliverables

• The Integration and Tests Phase
• Entry criteria Code unit tested and base lined
• Parallelism can be introduced (described later)
• The documents produced are
• Problem Reports
• Tests Statistics
• Working installable system
• Complete user documentation/demo/training
• Acceptance Test Plan and procedures
• Exit Criteria Reviewed and base-lined documents

77
The Phase Deliverables

• The documents contents
• Deal only with the first 2 documents (management
  tools)
• Problem reports
• For each problem a special form is completed
  (using a tool!)
• Problem reports are linked to the configuration
  management
• Reason/permit for changes to based lined code or
  document
• Information entered by discoverer
• Unique Id number Date (discovered)
• Severity status Functional area
• Problem description (plain language and any
  additional info.)

78
The Phase Deliverables

• The documents contents
• Problem reports (cont.)
• Information entered by project manager
• Date (automatic) Fixing priority
• Allocated investigator Status (open, investigate,
  reject, duplicate, deferred, pending, closed)
• Information entered by investigator
• Date (automatic) Exact code location
• Fix description and location Status (investigate,
  reject, duplicate, pending) Problem cause
• Information entered by fix tester
• Date Status (closed, open)

79
The Phase Deliverables

• The documents contents
• Problem reports (cont.)
• Comments full complex process
• Many pitfalls (especially witch doctors!)
• Excellent managerial tool
• Lots of statistical valid information for
  management, capability, quality,
• Should not be used for engineers assessment
• Can be used from projects inception if enough
  severity states included (catastrophic, major,
  minor, nice to have, question, suggested change
  etc.)
• As tool has sorted reports capability, may be
  used for any tracking!

80
The Phase Deliverables

• The documents contents
• Tests Statistics
• Simple Statistics
• Number of problems in each category
• May be grouped according to phase found, phase
  inserted, severity, and status
• Different cuts used by different entities
• Complex statistics
• Rate of arrival
• Rate of closure (pending)
• Link to developer, tester, investigator (NOT TO
  BE USED!)
• Enabler for continuous improvement and measurement

81
The Phase Deliverables

• Problems and Issues
• Project has to complete on time
• ? Conflicts with management and SQA
• ? Pressure to show something
• Customer finally sees parts of system
• ? conflicts with customer if not involved in
  development
• ? wants last minute changes
• Estimate/design/coding not good enough
• ? a lot of over time and finger pointing
  (additional staff?)
• ? cutting corners in severity tagging process and
  orderly fixing and testing
• ? low quality of final system
• Elusive problems solution
• ? frustration (regardless of source not me!)

82
The Phase Deliverables

• Problems and Issues (cont.)
• Staff motivation (wants out)
• Acceptance delayed by customer
• Solutions
• Prepare for possibility (like in risk analysis)
• Add contingency factors to estimates (via risk
  analysis!!)
• Start testing early
• Assign best developers
• Explain need and show carrot
• Difficult to predict customer new features
• ? prepare estimates and show price tag (time
  money)
• Do not volunteer make sure only manager agrees
  to changes

83
The Phase Deliverables

• The Maintenance Phase
• Entry criteria System installed, working, and
  accepted by customer (prior to this system
  incomplete)
• The documents produced are only updates to
  customer documentation
• Release notes for new version
• Version release documentation
• Bugs fixed description
• Additional functionality description
• Updated training material
• Updated user guide

84
The Phase Deliverables

• The Maintenance Phase
• Any additional features requested are a new
  project
• Remember customer satisfaction ensured only if
  part of his requests are fulfilled at no extra
  cost
• Set time and formal process for fixing customer
  reported problems
• Assign team for customer assistance and
  hand-holding
• Configuration Management is the key for
  successful software maintenance
• Any fix will cause a new software version to be
  released
• Exit Criteria system retirement! (old systems
  never die!)

85
The Phase Deliverables

• Problems and Issues
• Lack of enthusiasm
• Usually maintenance is a money drain ? Under
  staffed, no budgets, no platforms, usually failed
  developers!
• ? high turnover ? not enough system knowledge ?
  frustrated customers
• After enough fixes system becomes patchy
• ? lots of dead wood and reduced system
  availability
• Solutions
• Maintenance manager to add additional interesting
  jobs and training
• Continuous updating of documentation
• Special training for maintenance team

86
Waterfall And Parallel Phases

• Classic Waterfall Model has a soft belly
• Drain on budget as everybody awaits sign offs
• Parallel phases invented
• Caution not all phases can be produced in
  parallel!!
• Requirement only orthogonal parts can be
  developed in parallel

87
Waterfall And Parallel Phases

• Parallel phases
• Acceptance Tests, System Test better not handled
  in parallel
• Unit test and coding of that unit cannot be in
  parallel
• Usually end of phase x can be in parallel with
  beginning of next phase
• Caution! due to changes in outputs of phase x may
  require redoing phase y!
• Starting the next phase requires knowledge of
  process and functional areas

88
Parallel Waterfall Model

• Partial parallelism an answer for partially
  orthogonal functional area

Requirements
HLD
LLD
Coding
Unit Testing
Subsystem test
Subsystem test
Integration test
System test
Acceptance test
89
The Risk Analysis

• Preventive maintenance better then best fix
• Risks are situations which if happen are a threat
  to the project completion (schedule budget,
  quality)
• Possible threats war, fire, personnel turnover,
  training, equipment availability, third party
  deliverables (hw sw OS and applications),
  computer speed and resources development
  language, lifecycle etc.
• There is only a probability that they happen
• Prevention is planning ahead of time what to do
  if.CONTINGENCY PLAN
• Prevention needs tracking (responsible tracker)

90
The Risk Analysis

• Should we plan for EVERYTING?
• Physical impossibility
• List above has the most obvious ? needs brain
  storming session
• Prepared threats list has high/low impact items
  varying probability
• List analysis comprises of
• Item description (I.e. what is the risk)
• Expectation (probability it happens 1-10 scale )
• Impact (damage to project 1-10 scale )

91
The Risk Analysis

• List analysis technique
• Carry out with experts
• Make a table containing all threats description,
  their expectation and impact
• Calculate their severity (multiply expectation by
  impact 1-100 scale )
• Order items in table according to descending
  severity
• Define a cutoff (10,20) below which no plan is
  necessary (threat not harmful)

92
Raw Risk Table Example
93
Ordered Risk Table
94
Risk Handling

• Contingency plan
• Plan better not be used, however, sometime
  requires implementation before risk materialize
• Possible solution
• Decide that project has to discontinued (NOT
  USE!)
• Postpone delivery (try not to use!!)
• Have two different alternatives developed
• Device a way to alleviate risk
• Plan has to tell what has to be done
• Plan to have a trigger time/level for start

95
Risk Handling

• Form the risk handling table
• Add tracker to ordered risk list (usually a team
  leader)
• Add contingency plan
• Example Possible Contingency plans
• High staff turn over contingency plan
• Allocate bonuses for successful completion
• Have regular pep talks with team
• Cultivate a culture of openness so working
  environment is friendly
• do things other than work with team
• Prepare possible replacement from day 1
• Trigger in the course of 4 weeks two engineers
  left

96
Risk Handling

• Late delivery of outsourced sw
• start integration without this piece of sw
• develop a simulator to replace missing part
• Trigger third party weekly reports indicate
  lateness of more then 5 working days
• Data base does not cope with rate
• Consult with DB experts on having distributed DB
  on different computers
• Develop DB handling as client server application
• Trigger simulator to feed data into the db at
  twice the expected average rate

97
Risk Handling

• System response time too slow
• Use faster CPU, add memory to reduce paging
• Trigger response time for single user about
  right
• New HW protocol wrong
• Get prototype from hw manufacturer and test
  against it
• Develop SW simulator so hw manufacturer tests
  against it
• Trigger documentation supplied by hw not showing
  all protocol or partially correct

98
Risk Handling

• Lab facility not ready for testing
• Use development machines for initial testing, go
  into two shift mode to accommodate load, pay
  incentive to engineers
• Trigger two weeks prior to test start lab not
  ready
• CM disk burns
• Example of important risk not treated due to low
  severity!

99
What Accomplished

• Explained
• Process
• SEI levels
• Metrics
• Deliverables
• Risk handling and analysis
• Remain
• Schedule, size, and effort estimates
• Tracking methods

100
Relations Between Estimates

• A PDP describes a relation between Time, size,
  and staff needed to deliver a set of functions to
  a customer
• Time is monitored easily by hours, days, weeks
• Time used for
• Mile stones (really check points) in which a
  definite comparison between forecast and actual
  can be made
• Needed to describe requirements (facilities
  availability, training needed, personnel on
  board)
• Payment profit function of verified mile-stones
  
• Payment fixed! ? estimates of staff, effort, and
  their translation to a time table the essence of
  a PDP!

101
Relations Between Estimates

• Project start subject to agreement (at PDP time
  not existent) ? the use of After Receipt of Order
  (ARO)
• Effort measured in staff-month, or staff-year
• Usually translated from size of project
• Size of project is a complex function of
• Quality of system delivered
• Size of functionality complexity
• Size of development team
• Experience of team

102
Relations Between Estimates

• Quality measured in terms of reliability and
  sigma
• Functions creating quality are reviews, tests,
  audits, and process
• Development time may vary by a factor of 3
  between no special reliability requirement and a
  full fault tolerance system
• Common Measurement units of time availability
  (not MTBF)
• Size of functionality complexity
• No. of requirements ? No. of languages ?
• No. of lines of code ? Timing constraints ?
• Size of executable in MB ? Storage constraints ?

103
Relations Between Estimates

• Size of development team measured in number of
  engineers and length of time assigned to project
• Not all engineers are equal in their capability
  and traits
• Engineer productivity may vary by an order of
  magnitude
• Quality of work reduces productivity ? careful
  evaluation of productivity needed
• Experience of team

104
Relations Between Estimates

• Team Experience
• Experience makes perfection ? subject matter
  experience reduces development time, increases
  quality and productivity
• Fields of development change ? knowledge and
  experience change with time!
• New development constitute a major risk
• Getting up to speed a personal trait ? team
  experience difficult to measure

105
Projects Estimates

• Project estimate consists of many subjects which
  are very difficult to measure with any accuracy
  (gutstimation)
• Estimates vary between different methods and
  people
• have to be revised (updated)
• benefit from sample development
• require use of organizational data base
• careful and probing review by experts
• Remember ONE PDP IS PRESENTED

106
Decomposition chart
SW Project
Partial experience
Full experience
Off the shelf
New Development
FE
FE
ND
FE
ND
ND
ND
107
Estimation Methods

• A stepwise approach
• Divide functionality into small enough portions
• Small enough is a part which can be easily
  understood (bias?)
• Estimate each portion
• Sum up all estimates
• Division according to team experience
• Off the shelf components
• Full experience
• Partial experience
• New development
• Each class represents a different set of risks
  and development activities

108
Estimation Methods

• Off the shelf components
• Elements previously developed by the organization
  tested with full documentation
• Represent a very low risk
• Promote reuse of software
• Shorten development
• When used as is not best fitting functionality
• Custom made suit relative to ready made off the
  rack suit
• Project to use them as is ? project adapts to
  package
• Full experience components
• Organization developed something similar in the
  past
• Only if effort documentation exists
• Only if at least part of team still working in
  organization
• Only if really the same type of development

109
Estimation Methods

• Full experience components (cont.)
• Examples
• Organization developed interactive web pages
• New project in the field of e-business
• Experience in interactive web pages relevant
• Part of money handling and security algorithms no
  experience
• Organization developed a data link protocol for
  TCP/IP
• New project to develop data link for Asynchronous
  Transmission Mode (ATM)
• Same type of expertise needed time constraints
  NEW!

110
Estimation Methods

• Partial experience
• Organization developed parts in other projects
  which are similar to some parts of the new
  project
• The caveats are the same as before
  (documentation, team presence, really same
  functionality)
• Reasonable risk as only part has to be developed
• Example
• Developed a GPS system which colored the present
  position on a map
• New development real time calculation of a
  missile position so that missile will stay on
  planned course comparison of
• Position calculation the same however, all the
  aerodynamic calculation totally different

111
Estimation Methods

• New development
• Development of sw in a totally new field.
• A company with knowledge in large DB development
  turning to develop real time spatial guiding
  systems
• High risk development
• Need for sw in new fields grows, companies have
  to adjust to new fields!
• New development lacks reliable basis
• need specific methds for estimation

112
Estimation Methods

• Once project decomposed estimation problem is
  mainly new development
• Danger! wrong type assignment a common mistake
• Mature organizations have historical information
  allowing (given model) good estimates
• For large projects use average engineers
• Prototyping is used as a method to help estimates
  especially with totally ND

113
Estimation Methods

• Prototyping needs resources
• time, team, and measurement infrastructure
• Good estimates calculated when representing
  samples used
• The Statistical Methods
• Identify ND
• Prepare initial design (critical to good
  estimate)
• Divide designed modules into categories
• Complexity, functionality(communication, DB GUI),
  type(libraries, services)
• Select a representative module from each category
• Develop and measure effort (different phases
  etc.)
• Combine estimates for all project

114
Estimation Methods

• Prototype issues
• Develop typical parts
• Do not waste time on fancy GUI
• Use average engineers
• Carefully measure and record ALL tasks
• Go through all process parts
• small tasks tend to become the bottle neck e.g.
  unit test
• Most effort a throw away effort
• Complete calculation when all measurements
  available ?long process!

115
Estimation Methods

• Use of guru
• Expert person knowing organization and team
  performs estimates
• No use of formal knowledge, rather informal
  understanding
• informally based on org. historical data

116
Estimation Methods

• Use of guru (cont.)
• Many times a good process
• Tends to lengthen project and increase cost
• Easily bent to accommodate management
• Race to market and dwindling purse usually need a
  more objective and respectable method

117
Estimation Methods

• Reasons for formal estimation tools
• Not all organizations a mature
• Team not yet in place
• Management and customer feel comfortable with
  reproducible results
• Caution even the best tools yield results based
  on input!! (garbage in garbage out)
• Two main methods
• Constructive Cost Model (COCOMO)
• Functional Point Analysis (FPA)

118
Formal Estimation Methods

• Non formal methods extrapolate from known
  experimental evidence to ND to produce estimates
  for new project
• Formal methods need a starting point
• Start point quantities for the ND usually are not
  known but estimated
• Start point quantities are inaccurate
• Relay on estimating team consensus
• Computerized tools used ? different estimates and
  assumptions can be compared

119
COCOMO Method

• Invented by Boehm (1981) later enlarged by him
  and others
• Basis for estimation are Source Lines Of Code
  (SLOC)
• Decompose project into small parts
• Estimate number of SLOC in every module
• Use COCOMO to estimate effort and schedule

120
COCOMO Method

• COCOMO is made of a formula for estimating basic
  effort (engineer months)
• Basic estimate then modified by multiplicative
  factors
• Factors introduce elements like
• Experience
• Complexity
• Development environment
• Reliability

121
COCOMO Method

• Software four basic classes (refining division
  depends on particular model used)
• System software (interrupt handlers,
  communications, resource time, memory, storage
  sharing)
• Algorithmic Software (scientific programming,
  sort utilities, fault tolerant sw, compilers,
  voice and pattern recognition)
• Service software (graphic editors, word
  processors, system calls libraries)
• Data processing software (DB applications, report
  generators, spreadsheets applications, web
  applications)

122
COCOMO Method

• Example
• In line spelling corrector
• Uses a dictionary ? Data Base part is present
• For funny words needs phonetics ? comparison
  algorithm between sound of written word with
  sound of possible words in dictionary
• For common errors instantaneous correction
• As main task is algorithmic ? spelling corrector
  belongs to algorithmic software

123
COCOMO Basic Formula

• SEM C(L)f
• Where
• SEM is software engineer months
• C a class dependent multiplicative constant
• f a class dependent exponent
• C represents the different levels of complexity
  while the exponent f shows the grows of
  complexity with size

124
SEM for different classes
125
Numerical Example

• Assume KSLOC10, calculate SEM