The way we produce software, including the software lifecycle model, the tools we use, and the indiv

1
Software Process

• The way we produce software, including the
  software life-cycle model, the tools we use, and
  the individuals building the software.
• Software development covers all aspects of
  software production before the product enters the
  maintenance phase.

2
People

• Client The individual or organization who wants
  a product to be developed.
• Developers The members of the organizations
  responsible for building the product.
• User the person or persons on whose behalf the
  client has commissioned the product and who will
  utilize the software.

3
Requirement Phase

• The initial description from the client is often
  vague, unreasonable, contradictory, or simply
  impossible to achieve.
• When the product is delivered, the client says
  I know that this is what I asked for, but it
  isnt really what I wanted.

4
Rapid Prototype

• A piece of software hurriedly put together that
  incorporates much of the functionality
  (interfaces) of the target product but omits
  those aspects generally invisible to the client.
• Any imperfections in the rapid prototype may be
  ignored, provided that they do not give a
  misleading impression of how the product will
  behave.

5
Specification Phase

• Explicitly describes the functionality of the
  product.
• List the constraints that the product must
  satisfy.
• Identify the inputs to the product and the
  required outputs.
• Develop a software project management plan (SPMP)
  including aspects such as the life-cycle model,
  the organizational structure, project,
  responsibilities, managerial objectives and
  priorities, the techniques and CASE tools, and
  detailed schedules / budgets / resource
  allocations.

6
Problems with Specification

• Use of imprecise terms such as suitable,
  convenient, ample, enough, maximal, optimal, 98
  complete, etc.
• Ambiguous Certain sentences or sections may
  have more than one possible valid interpretation.
• Incomplete Some relevant fact or requirement
  may have been omitted.
• Contradictory One place of the specification
  requires the system to do something that
  contradict with another requirement of the system.

7
Specification Phase Testing

• Look for contradictions, ambiguities, and any
  signs of incompleteness.
• Determine whether the specifications are
  feasible.
• Trace relevant statements in the specification
  document to client meetings / rapid prototype.
• Obtain second opinion about detailed planning and
  estimating. At least perform a formal review.

8
Design Phase

• Determine the internal structure of the product.
• Select algorithms and data structures.
• Decompose the product into modules with
  well-defined interfaces to the rest of the
  product.
• Document how modules are organized and interact
  with each other architecture design.
• Document interface for each module detailed
  design.
• Record important design decisions.

9
Design Phase Testing

• Trace each part of the design back to a statement
  in the specification document.
• Look for the following types of faults logic
  faults, interface faults, lack of exception
  handling, and nonconformance to the
  specifications.
• Reveal any fault of the specifications that was
  not previously detected.

10
Implementation Phase

• Implement various component modules of the design
  into code.
• Properly comment the source code.
• Document all test cases against which the code
  was tested, the expected results, and the actual
  output.
• Perform code review for complex and / or
  important modules.
• Identify any specification or design fault that
  was not detected earlier.

11
Integration Phase

• Combine the modules and determine whether the
  product as a whole functions correctly.
• Integration testing Check whether the modules
  are properly combined.
• Product testing Check the functionality of the
  product as a whole against the specification,
  including correctness and robustness of the
  system.
• Acceptance testing The client tests the
  software on the actual hardware, using actual
  data as opposed to test data.

12
Maintenance Phase

• Corrective maintenance Remove residual faults
  w/o changing the specification.
• Perfective maintenance Change the system to
  improve the effectiveness of the product.
• Adaptive maintenance Change the system in
  response to changes in the environment in which
  the product operates.
• Regression testing Once the desired changes
  have been implemented, the product must be tested
  to ensure that no other inadvertent changes were
  made.

13
Retirement

• Document who made what decision and why.
• The proposed changes are too drastic.
• Prior changes of the system have caused too high
  degree of interdependencies to sustain even a
  minor change in a small module.
• Poorly maintained documentation has increased the
  risk of a regression fault.
• The replacement of the environment on which the
  product operates makes it cheaper to rewrite than
  to modify.

14
Capability Maturity Models

• The U.S. Department of Defense (DoD) founded the
  Software Engineering Institute (SEI) and set it
  up at Carnegie Mellon University in Pittsburgh,
  PA, in hope to improve organizations ability to
  manage the software process.
• Therere CMMs for software, for management of
  human resources, for system engineering, for
  integrated product development, and for software
  acquisition).

15
SW-CMM 1 Initial Level

• No sound software engineering management practice
  is in place in the organization.
• Everything is done on an ad hoc basis.
• Most activities are responses to crises, rather
  than planned tasks.
• Its impossible to predict with any accuracy such
  important items as the time and cost of the
  product.

16
SW-CMM 2 Repeatable Level

• Basic software project management practices are
  in place.
• Planning and management techniques are based on
  experience with similar products.
• Measurements are taken to track costs and
  schedules.
• Managers identify problems as they arise and take
  immediate corrective action to prevent them from
  becoming crises.

17
SW-CMM 3 Defined Level

• The process for software production is fully
  documented.
• Both the managerial and technical aspects of the
  process are clearly defined.
• Continual efforts are made to improve the process
  wherever possible.

18
ISO 9000

• The International Standards Organization
  9000-series of five related standards that are
  applicable to a wide variety of industrial
  activities, including design, development,
  production, installation, and servicing..
• ISO 9001 for quality system is the standard that
  is most applicable to software development.
• ISO 9001-3has specific guidelines to assist in
  applying ISO 9001 to software.