Software Process

Lecture 2
Agenda
• Historical Aspects
• Software Engineering
• Software Product
• Software process phases
• Improving software process
Historical Aspects
• The term 'software engineering' was suggested at
conferences organized by NATO in 1968 and 1969 to discuss
the 'software crisis'.
• The software crisis was the name given to the difficulties
encountered in developing large, complex systems in the
1960s.
• Software is delivered
• Late
• Over budget
• With residual faults
Examples of failures due to
software
• In 2015, CareFusion’s Alaris Pump was recalled over a software
error that caused the pump, designed to automatically deliver
medicine and fluids to hospital patients, to delay an infusion
that could cause the patient to suffocate.
• Equifax, one of the United States’ largest credit reporting
agencies, announced that up to 143 million of their consumer
records were stolen by hackers in May 2017. Names, Social
Security numbers, birth dates, and credit card numbers were
all amongst the data stolen.
• Facebook's apps outage: In the summer of 2019 Facebook
users stopped being able to view or load images from the
newsfeed.
Software Engineering
• Software Engineering is an engineering branch related to
the evolution of software product using systematic well-
defined scientific principles, techniques, and procedures.
• The result of software engineering is an effective and
reliable software product.

• To achieve these goals, a software engineer has to

acquire a broad range of skills, both technical and
managerial
Software Product
• Software is a set of items or objects that form a
“configuration” that includes
• Programs that when executed provide desired function and
performance
• Data structures that enable programs to adequately manipulate
information
• Documents that describe the operation and use of the programs
What is Failure, Error and
Faults?
• Error – a human action that produces an incorrect result. This
is also sometimes referred to as Mistake.
• Fault – a manifestation of an error in software, also known
as Defect or Bug.
• Failure – a deviation of the software from its expected delivery
or service.
Relative Cost to Correct
Defects
Software Process
• Software process is the way software is produced. When
you build a product, it is important to go through a series
of predictable steps, a roadmap that helps you create a
high quality product, in a timely manner.
• On the other hand, Software engineering also
encompasses technologies that populate the process –
technical methods and tools
• Methods provide the technical HOW TO for building
software
• Tools provide automated or semi-automated support
for the process and the methods
• Software process is the glue
Software Process Phases
1
• Requirements Analysis Phase

2
• Specification Phase

3
• Design Phase

4
• Implementation Phase

5
• Integration Phase (in parallel with phase 4)

6
• Maintenance Phase

7
• Retirement
Software Process Phases
1. Requirements Analysis phase
2. Specification phase
3. Design phase
4. Implementation phase
5. Integration phase (in parallel with 4)
6. Maintenance phase
7. Retirement

Testing and documentation are activities that take place

through all phases
Requirements Phase
Students’ Activity
• Give three examples of
Requirements for
same/separate systems.
Requirements Phase
(1) Requirements Gathering (Elicitation)
• The most important phase of the Software Development Life
Cycle (SDLC) is the requirement gathering and analysis phase
• This is when the project team begins to understand what the
customer wants from the project.
• During the requirements gathering sessions, the project team
meets with the customer to outline each requirement in
detail.
Requirements Phase
(contd.)
(2) Requirements Capturing:
• Capturing Data Requirements
• Information to be stored
• Capturing Functionality Requirements
• Examples include: “add customer” and “print invoice”
• Capturing Quality Attributes (non-functional requirements)
• Performance
• Security
• Availability
• Usability
Requirements Phase
(contd.)
(3) Validate Requirements: Through Rapid Prototyping
• Software that incorporates much of the functionality of the
target product but omits aspects invisible to the client (e.g.
file updating or exception handling)
• Client and users experiment with the prototype to
determine whether it meets their needs

• (4) Deliverable: Requirements document

• Checked by the client, selected users, and the development
team
Software Process Phases
1. Requirements phase
2. Specification phase What?
3. Design phase
4. Implementation phase
5. Integration phase (in parallel with 4)
6. Maintenance phase
7. Retirement

Testing and documentation are activities that take place

through all phases
Specification Phase
• Specifications document (or specifications)
• Exactly describes the functionality of the product
• Lists any constraints that the product have
• Includes the inputs to the product and the required outputs
• Specifications must not be:
• Ambiguous: open to more than one interpretation; not
having one obvious meaning.
• Incomplete: not having all the necessary or appropriate
parts
• Contradictory: mutually opposed or inconsistent.
Specification Phase (contd.)
• Example of ambiguous requirement:
• All customers have the same control field
• All customers have the same value in their control fields
• All customers control fields have the same format
• One control field is issued for all customers
• Example of Contradictory requirement:
• Landing gear must be present on an airplane in order to land and
takeoff.
• It should not be present during flight because of an increase in air
drag.
• The physical contradiction is that the landing gear must be both
present and absent.
• This contradiction is resolved by separating the requirements in
time — make the landing gear retractable.
Specification Phase (contd.)
• Once the specifications are complete, detailed planning
and estimating begins
• How long it will take
• How much it will cost
• Resources needed
• Milestones: when the client gets them
• Deliverables: what the client is going to get
• Software Quality Assurance (SQA) group must check the
specifications carefully
• Look for contradictions, ambiguities, and incompleteness
• Ensure that the specifications are feasible
• Trace every statement of the specification back to the
requirements document and rapid prototype
• Check by review – Done by SQA, specification team, and client
Software Process Phases
1. Requirements phase
2. Specification phase
3. Design phase  How?
4. Implementation phase
5. Integration phase (in parallel with 4)
6. Maintenance phase
7. Retirement

Testing and documentation are activities that take place

through all phases
Design Phase (UML)
(1) High-level design:
• A graphical representation of the structure of
your software system
• A document that defines high-level details of
each module in your system, including:
• A module’s interface (including input and output
data types)
• Notes on possible algorithms or data structures the
module can use to meet its responsibilities
• A list of any non-functional requirements that might
impact the module
Architectural design
example (Component)
Architectural design
example (Deployment)
Design Phase (contd.)
(2) Detailed Design (Low-level Design):
• After high-level design, a designer’s focus shifts to low-
level design
• Each module’s responsibilities should be specified as
precisely as possible
• Constraints on the use of its interface should be specified
• pre and post conditions can be identified
• module-wide invariants can be specified
• internal data structures and algorithms can be suggested
Design Phase (contd.)
• SQA group must check the design
• Look for logic faults, interface faults, lack of exception
handling, nonconformance to the specification
• Trace every part of the design to a statement in
specification document
• Review by –SQA and design team

• Documentation
• architecture design
• detailed design
Software Process Phases
1. Requirements phase
2. Specification phase
3. Design phase
4. Implementation phase
5. Integration phase (in parallel with 4)
6. Maintenance phase
7. Retirement

Testing and documentation are activities that take

place through all phases
Implementation Phase
• Implement the detailed design in code

• Testing
• Code review
• Running test cases
• Informal testing done by the programmer (desk checking)
• Testing by SQA group

• Documentation
• Source code with suitable comments
• Test cases against which the code was tested
Test Case Scenario Example
Software Process Phases
1. Requirements phase
2. Specification phase
3. Design phase
4. Implementation phase
5. Integration phase (in parallel with 4)
6. Maintenance phase
7. Retirement

Testing and documentation are activities that take

place through all phases
Integration Phase
• Integrate the modules –performed in parallel with
implementation
• Integration testing
• Testing module interfaces
• Product testing – SQA group
• Correctness: the quality or state of being free from error.
• Robustness: the degree to which a system or component
can function correctly in the presence of invalid inputs or
stressful environmental conditions.
• Acceptance testing – client
• After the software has been delivered, the customer
performed the acceptance testing to determine whether
to accept the delivered software or to reject it.
Integration Phase (contd.)
• Once the product testing is complete, the software is
supplied to selected possible future users for testing on
site – alpha version
• Corrected alpha version is called beta version

• Documentation
• Commented source code
• Test cases for the product as a whole
• User manual, operator manual, database manual
Software Process Phases
1. Requirements phase
2. Specification phase
3. Design phase
4. Implementation phase
5. Integration phase (in parallel with 4)
6. Maintenance phase
7. Retirement

Testing and documentation are activities that take

place through all phases
 Approximate Relative Cost of
Each Phase
• Maintenance constitutes 67% of total cost
Maintenance Phase
• Maintenance - any change once the client has
accepted the software
• Different types of maintenance:
• Adaptive – modifying the system to cope with changes
in the software environment (DBMS, OS)
• Perfective – implementing new or changed user
requirements which concern functional enhancements
to the software
• Corrective – diagnosing and fixing errors, possibly ones
found by users
• Preventive – increasing software maintainability or
reliability to prevent problems in the future
Maintenance Phase
(contd.)
• Common problem – not updated documentation or
lack of documentation

• Regression testing – the product must be tested

against previous test cases to make certain that the
functionality of the rest of the product has not been
compromised

• Documentation
• Record of all the changes made, together with reasons
• Regression test cases
Software Process Phases
1. Requirements phase
2. Specification phase
3. Design phase
4. Implementation phase
5. Integration phase (in parallel with 4)
6. Maintenance phase
7. Retirement

Testing and documentation are activities that take

place through all phases
 Retirement
• Software becomes un-maintainable because
• A drastic change in design is proposed
• The product must be implemented on a totally new
hardware/operating system
• Documentation is missing or inaccurate

• It may be cheaper to rewrite the software from scratch than to

modify it
Overview
• Software process phases
• Improving software process (Self-study)
Improving Software
Process
• Software Engineering Institute (www.sei.cmu.edu)
• Carnegie Mellon University in Pittsburgh
• Capability maturity model (CMM)
http://www.sei.cmu.edu/cmmi/

• International Standards Organization

• ISO 9000
• ISO/IEC 15504 - standard on software process assessment
http://www.sei.cmu.edu/cmmi/faq/15504-faq.html

• Comparison of ISO 9001 and CMM

http://www.sei.cmu.edu/publications/documents/94.reports/94.tr.012.html
CMMI® ACCREDITED
ORGANIZATIONS
 Capability Maturity Model
• Improvement of software process, irrespective of the life-
cycle model
• SW–CMM for software
• P–CMM for human resources (“people”)
• SE–CMM for systems engineering
• IPD–CMM for integrated product development
• SA–for software acquisition

• These strategies are being unified into CMMI (capability

maturity model integration)
SW–CMM
• Improving software process, 1986

• Fundamental ideas:
• Improving the software process leads to
• Improved software quality
• Delivery on time, within budget
• Improved management leads to
• Improved techniques

• Incremental improvements
• Five levels of maturity are defined
• Organization advances stepwise from level to level
Maturity level 1 -Initial
Level
• Ad hoc (occasionally even chaotic) approach
• Depends totally on the current stuff
• Entire process is unpredictable
• Management consists of responses to crises

• Unfortunately, most organizations world-wide are at level 1

Maturity level 2 -
Repeatable Level
• Basic project management is established to track cost,
schedule, and functionality

• Planning and management based on previous experience

with similar products
• Measurements are made
• Tracking of costs and schedules

• These can be used for

• Detecting problems and taking immediate corrective action
• Making cost and duration predictions in future project
Maturity level 3 -Defined
Level
• Software process for both management and engineering
activities is fully documented and standardized
• Managerial and technical aspects are clearly defined
• Continual efforts are made to improve quality & productivity
• Reviews are used to improve software quality
• CASE environments are applicable (not at levels 1 or 2)

• A number of organizations have achieved maturity levels 2 and 3,

but few have reached levels 4 and 5
Maturity level 4 -Managed
Level
• Detailed measures of both software product and
process quality are collected
• Quality and productivity are continually monitored
• Statistical quality controls are in place
Maturity level 5 -
Optimizing Level
• Continuous process improvement
• Statistical quality and process controls
• Knowledge gained from each project is utilized in future projects
Summary of SW-CMM

• For each maturity level there are key process areas (KPA)
• Within each KPA are between two and four related goals
Experience with SW-CMM
• It takes
• 3 to 5 years to get from level 1 to level 2
• 1.5 to 3 years from level 2 to level 3

• SEI questionnaires highlight shortcomings, suggest

ways to improve the process
• Original idea -Defense contracts would be awarded
only to capable firms (level 3)
Other Initiatives
• ISO 9000 – series of standards applicable to wide variety of
industrial activities, including design, development,
production, installation, and servicing

• ISO/IEC 15504 – international standard on software process

assessment
ISO 9000 series
• Adopted by over 60 countries
• Set of five standards for industrial activities
• ISO 9001 for quality systems
• ISO 9000-3, guidelines to apply ISO 9001 to software

• There is an overlap with CMM, but they are not identical

• ISO 9000 philosophy –adherence to the standard does not
guarantee a high-quality product; it reduces the risk of a poor-
quality product
• ISO 9000 is required to do business with the E.U.
• More and more U.S. businesses are ISO 9000 certified
ISO/IEC 15504
• Software Process Improvement Capability determination
(SPICE)
• Started by British Ministry of Defense (MOD)
• Taken over by ISO and IEC it became an international process
improvement initiative

• Extends and improves both CMM and ISO 9000

• Framework for assessment methods, not a stand alone method or
model
• CMM and ISO 9000 conform to this framework
• Now referred to as ISO/IEC 15504 or just 15504
Questions??