Introduction to Software Engineering
Lecture 9 - Overview of software project management
Jim Briggs, 7 December 1998
Read Sommerville (5th ed.) chaps 28-31.
Different from other types of project management because:
Software management structures
Possible measures (per man-month?) with potential down-sides:
Paradox is that design, documentation, testing, etc. all subsumed by one measure.
Quality of programmer very much affects productivity. Very often it is the dominant factor.
So does use of methodologies.
Effective management depends on thorough planning.
Intangible project => only measure of progress is documentation. Good milestone is finished document.
Tie in with lifecycle model: at sub-stage level.
Too many milestones implies team spends more time writing reports than doing work. One every 2-3 weeks?
Analyse alternative paths to goals.
Score options against goals (weighted). Arbitrary, but useful.
Cannot override critical objectives or constraints.
Economic analysis (payoff matrix). Probability of any scenario occurring.
Problems to anticipate: staff leaving or being ill; hardware breakdown; late delivery of essential components; intractable problems.
Estimate, then double it!
Task interdependencies. Critical path analysis.
PERT charts (best, worst, expected cases). Gantt charts (bar chart).
Boehm in Software Engineering Economics identifies 7 techniques for cost estimation:
COCOMO model: organic, semi-detached and embedded mode projects. Basic model PM = A * KDSI b, where A ranges from 2.4 to 3.6 and b from 1.05 to 1.20.
Intermediate model applies multipliers to the basic model. These based on attributes of the project. Complete model estimates cost as sum of sub-system costs.
Assume you know (or are told) what a man-month costs (for different types of staff).
Concerned with the development of procedures and standards for managing an evolving software system. How to control change? How to manage systems that have been subject to change? How to release those changed systems to customers? Tied in with quality assurance.
Decide what items are to be managed (normally formal documents). Project plans, specifications, designs, programs, test data, etc.
Database to record configuration information:
Comes into effect once product is released (not applicable during development?).
Submit change request; validate it; assess and cost; decide whether to accept; apply.
Have all the components that make up a system been included in the build?
Has the appropriate version of each required component been included?
Are all required data files available?
Are data file names used correctly?
Is the appropriate version of the compiler, etc. available?
Versions and releases.
Make and SCCS
Document quality. Writing style.
Configuration control applies to these too.
Related to verification and validation, though really V&V is a technical function and QA is a management function.
Often carried out by separate QA team that bypasses management chain.
Bersoff: "Quality assurance consists of those procedures, techniques and tools applied by professionals to ensure that a product meets or exceeds pre-specified standards during a product's development lifecycle; and without specific prescribed standards, quality assurance entails ensuring that a product meets or exceeds a minimal industrial and/or commercially acceptable level of excellence.''
Quality plan to set out attributes that product should exhibit, and (importantly) how those should be assessed.
Wrong to assume what ``high quality'' actually means. Cannot assume that a quality development process results in a quality product. But many people do. Easier to do!
Quality of process: define process standards (such as how reviews should be conducted); monitor process to ensure standards complied with; report process to management and customer.
Primary task of QA is to ensure product reliability.
Remember - perceived reliability is paramount.
Assess operational reliability, not latent faults.
All dependent on time, but could be elapsed time, processor time, or some discrete unit such as transactions.
Reliability growth models. If we assume that each repair reduces the number of faults (not true) then reliability is monotonically increasing. Improvement in reliability per repair decreases as faults as repaired.
Encapsulate best practice.
Provide framework for QA process. QA can become checking that software adheres to standards.
Assist in continuity. Learning effort is reduced.
Standards often set remote from development process (e.g. by another department or higher management).
State of art is that few metrics are useful as predictors or related to product attributes which we wish to discover.
Control metrics (used by management): effort expended, elapsed time, disk usage, etc.
Predictor metrics (used to predict product quality): readability index, complexity. Based on the (flawed) assumptions that (i) we can measure something; (ii) that a relationship exists between what we can measure and what we would like to know; and (iii) the relationship is understood, valid and can be expressed by a formula or model.