Specification Phase

Specification document explicitly describes the functionality of the product - precisely what the product is supposed to do, and lists any constraints that the product must satisfy.

	Includes inputs to the product and the required outputs.
	Constitutes a contract.
	should not include imprecise terms.
	should always be written as if it will be used as evidence at a trial.
	Difficulties that can arise:

	Specs may be ambiguous
	Specs may be incomplete

example: does not include what to do if input has errors

Specs may be contradictory SPMP (Software Project Management Plan) must be drawn up

	reflects the separate phases of the development process and shows which members of the organization are involved in each task, as well as the deadlines for completing each task.
	Major components of the plan:

	deliverables (what the client is going to get)
	milestones (when the client gets them)
	budget (how much it is going to cost)

Plan describes the process in fullest detail:

	life cycle model to be used
	organizational structure of the development organization
	project responsibilities
	managerial objectives and priorities
	techniques and CASE tools to be used
	detailed schedules, budgets, and resource allocations
	Duration and cost estimates

Specification Phase Testing

SQA group must carefully test the specifications, looking for contradictions, ambiguities, and any signs of incompleteness.

must ensure that the specifications are feasible

examples:

	specified hardware component is fast enough
	current online disk storage capacity is adequate

Specification document must have traceability.

Must be possible to trace every statement in the specification document back to a statement made in the requirements phase.

Reviews:

	walkthroughs and inspections
	representatives of the specification team and of the client are present
	meeting is usually chaired by a member of the SQA group

 

Design Phase

Determines how the product is to do what it is supposed to do.

	Algorithms are selected and data structures chosen.
	Internal data flows are determined. (Inputs and outputs have already been laid down in the specifications)
	Product is decomposed into modules.

	what module has to do and how
	module interfaces (arguments passed to and returned by the module)

Careful record is kept of the design decisions being made.

Document the designs that don't work as well as the ones that do.

Major output from the design phase:

Architectural design

a description of the product in terms of its modules

Detailed design

a description of each module

Design Phase Testing

	Traceability -  critical that every part of the design should be linked to a statement in the specification document.
	Design reviews are similar to specification reviews, except that the client is not usually present.
	members of the design team and the SQA group review the design.
	faults to look for include:

	logic faults
	interface faults
	lack of exception handling (processing of error conditions)
	nonconformance to the specifications

should also look for possible overlooked specification faults
 
 

Implementation Phase

	Component modules of the design are coded.
	Documentation includes:

	the source code itself, including comments
	all the test cases, the expected results, and the actual output

Implementation Phase Testing

Testing done by the programmer

	modules are tested while they are being implemented - Desk checking
	then modules are run against test cases

Code Review

programmer guides the review team through the listing of the modules

review team must include an SQA representative

review is similar to reviews of specifications and designs
 
 
 
 
 
 
 

Integration Phase

	Combine the modules and determine whether the product as a whole functions correctly.
	Implementation and Integration should be performed in parallel.
	Integration Phase Testing

Module interfaces should be tested

number, order, and types of formal arguments should match the number, order, and types of actual arguments

checking best done by a compiler and linker, but if it is not a strongly typed language, the SQA group does this.

SQA group then performs product testing.

The functionality of the product as a whole is checked against the specifications.

	constraints must be tested.
	product checked for robustness
	check that source code and all other types of documentation are consistent.

Acceptance testing

	Testing is done by the client with actual data as opposed to test data.
	Alpha and Beta Testing

	done by manufacturers of shrink-wrapped software, or COTS (commercial off-the-shelf software)
	should not replace testing by the Software Quality Assurance Group
	Alpha testing - company gets to test product on site
	Beta Testing - corrections to the Alpha version - "close to product"

Maintenance Phase

Any changes to the product after the product has been accepted by the client.

	Design should take future enhancements into account.
	Coding must be performed with future maintenance kept in mind.

3 types of maintenance:

	perfective
	corrective
	adaptive

Common problem is the lack of documentation. Maintenance Phase Testing

Check that the required changes have been correctly implemented.

check that no other inadvertent changes were made

Regression Testing - checking that new changes don't affect other parts of the product

Rerun original test cases.

 
 
 
 
 

Retirement

True retirement occurs when a product has outgrown its usefulness.

	The product is actually no longer in existence, as opposed to products with different versions.
	A stage is reached when further maintenance is no longer cost effective.

Possible reasons for retirement:

	Less expensive to retire than to redesign.
	Interdependencies  between components are too strong.
	Documentation is insufficient.
	Hardware and operating system must be changed.

 
 
 
 
 
 
 
 
 
 

Problems with Software Production: Essence and Accidents

Over the past 40 years hardware has become cheaper and faster, and hardware has shrunk in size.

	performance-price factor has decreased by an order of magnitude 8 times in 40 years.
	There are however physical limits on hardware size and speed.

	speed of light (186,300 miles per second)
	nonzero width of an atom

Software is conceptual, and therefore nonphysical. Fred Brooks, 1986, article "No Silver Bullet", argued that there are inherent problems with current techniques of software production that can never be solved.

	"building software will always be hard. There is inherently no silver bullet."
	Brooks divides the difficulties of software into 2 Aristotelian categories:

	essence - the difficulties inherent in the intrinsic nature of software
	accidents - the difficulties encountered today that are not inherent in software production

accidents are amenable to breakthroughs whereas essence is not.

Four aspects of software production that are inherently difficult:(according to Brooks)

Complexity - can be reduced, by using the object-oriented paradigm for example, but it can never be totally eliminated.

	with large products, no one person can know how every part works;
	maintenance is compounded

can be controlled also with documentation

the number of possible states of a system is product of the numbers of possible states of each component, which is compounded by the interdependence of the statements. Conformity

There is a misconception that software is the easiest component of a system to change

In science fiction, the software for the USS enterprise was designed before the hardware

Changeability

	the product changes because the real world changes, and software models reality
	with a successful product, there are requests for more functionality
	successful software survives longer than the hardware for which it was written

Invisibility

Product cannot be seen and handled

To aid in this, rapid prototyping can be used

Visual diagrams and visual representations cannot embody every aspect of software as a blueprint for a building can do. No Silver Bullet

What Brooks considers to be three major breakthroughs in software technology, (but stresses that they solved only accidental not essential difficulties)

	high-level languages
	time sharing
	software development environments

example: UNIX Programmer's Workbench

Brooks suggests we change the way software is produced.

	when possible, software should be bought off the shelf
	greater use of incremental development
	use of rapid prototyping
	training and encouraging great designers

Improving the Software Process

SEI - Software Engineering Institute - 1987 -  founded by the US Department of Defense - set up at Carnegie Mellon University in Pittsburgh

	DoD - said "fundamental problem is the inability to manage the software process"
	one of its major successes: the CMM (Capability Maturity Model)

Related software process improvement methods:

	ISO 9000-series standards of the International Standards Organization
	SPICE - Software Process Improvement Capability Determination - an international initiative

 
 
 
 
 
 
 
 
 
 
 
 

Capability Maturity Models:

	Several different versions of the CMM exist, to allow organizations to have a standard for improving their process.
	The term maturity  is a measure of  the goodness of the process itself.
	SW-CMM first put forward by Watts-Humphrey in 1986

	The strategy of the SW-CMM is to improve the management of the software process in the belief that improvements in techniques will be a natural consequence.
	SW-CMM induces change incrementally

SW-CMM defines 5 different levels of maturity:

Maturity Level 1: Initial Level (Ad Hoc Process)

	Everything is done on an ad hoc basis ("code and test" mentality)
	usual pattern: time and cost overruns
	most activities are response to crises
	process is unpredictable - depends on current staff
	most software organizations are at this level

Maturity Level 2: Repeatable Level (Basic Project Management)

	planning and management techniques are based on past experiences (hence the name repeatable).
	Measurements are taken

	careful tracking of costs and schedules
	use for future planning

KPAs include:

	configuration control
	software quality assurance
	project planning
	project tracking
	requirements management

Maturity Level 3: Defined Level (Process Definition)

	Process for software production is fully documented and clearly defined
	Reviews
	Use of CASE tools

Maturity Level 4: Managed Level (Process Measurement)

	Quality and productivity goals are set for each project
	continuous measurement, corrective action, and statistical quality control

Maturity Level 5: Optimizing Level (Process Control)

	Knowledge from past projects is used in future products
	positive "feed back loop"
	continuous process improvement
	Key process areas (KPAs) include:

	defect prevention
	technology innovation
	process change management

SEI has developed a series of questionnaires that form the basis of an assessment by an SEI team.

ISO 9000

ISO (International Standards Organization) 9000-series standards:

a series of five related standards that are applicable to a wide variety of industrial activities, including:

	design
	development
	production
	installation
	servicing

Stresses documenting the process in both words and pictures. emphasizes measurement underlines the need for continuous training of software professionals ISO 9001 for quality systems is the standard most applicable to software development

Because of the broadness of the 9001, ISO has published specific guidelines to assist in applying 9001 to software, namely, ISO 9000-3.

ISO standards have been adopted by over 60 countries.
 
 
 
 
 
 

SPICE

	An international process improvement initiative
	SPICE = Software Process Improvement Capability dEtermination.
	Initiated by the British Ministry of Defense - 1995
	Nominally a process assessment initiative, but goes beyond that to include process improvement and software procurement.
	Sets out a framework for assessment methods, but does not lay down a specific method.
	Generates a separate assessment of each component of the overall process, such as requirements analysis and configuration management.
	since 1997, under a joint committee of the ISO and the International Electrotechnical  Commission -

now sometimes referred to as ISO/IEC 15504, or 15504 for short.

 
 
 
 
 
 
 
 
 

Costs and Benefits of Software Process Improvement

	From an SEI report on a study on CMM, productivity and early defect detection increased, and time to market and post-release defect reports decreased.
	Hughes Aircraft spent $500,000 over a 3 yr. period, moved from CMM level 2 to level 3, and estimates its annual savings to be about $2 million.
	Conclusion: process improvement is cost effective.