Processes in Software Development

Lecture 2
 Software products
Generic products
 Stand-alone systems that are marketed and sold
to any customer who wishes to buy them.
 Examples – PC software such as graphics programs,
project management tools; CAD software; software for
specific markets such as appointments systems for
doctors.
 The specification of what the software should do
is owned by the software developer and
decisions on software change are made by the
developer.

2
 Software products
Customized products
 Software that is commissioned by a specific
customer to meet their own needs.
 Examples – embedded control systems, air traffic
control software, traffic monitoring systems.
 The specification of what the software should do
is owned by the customer for the software and
they make decisions on software changes that
are required.

3
 Issues/Challenges that affect Software
• Heterogeneity
– Increasingly, systems are required to operate as
distributed systems across networks that include
different types of computer and mobile devices.
• Business and social change
– Business and society are changing incredibly quickly as
emerging economies develop and new technologies
become available.
• They need to be able to change their existing software and to
rapidly develop new software.

• Security and trust

– As software is intertwined with all aspects of our lives, it
is essential that we can trust that software.
4
 Challenges
• Complexity
 No two parts are alike Introduces technical and
“My first proposal is that each software organization must
managerial
determine and proclaim that great designers are as
• Invisibility
important to its success as great managers are, and that
– The
they cancode is invisibletoand
be expected unvisualizabl,
be similarly No and
nurtured ready
geometric
rewarded. Notrepresentation.
only salary, but the perquisites of
– Structure is terribly
recognition-office size,complex
furnishings, personal technical
equipment, travel funds, staff support-must be fully
• Conformity
equivalent.” Frederick P. Brooks
– Software must conform to arbitrary limitations
• imposed by humans (e.g. business rules) institutions and
systems
– Hard to plan for arbitrary changes that will occur late in
development
5
 Challenges
• Software is like a werewolf, it looks normal until the
moon comes out and it turns into a monster
– Missed deadlines
– Blown budgets
– Buggy software
• Unfortunately “No Silver Bullet” is there to hunt this “Monster”
– Visit http://www5.in.tum.de/~huckle/bugse.html and see the
bugs collection.
• “As we look to the horizon of a decade hence, we see no
silver bullet. There is no single development, in either
essence, technology or in management technique, that by
itself promises even one order-of-magnitude improvement in
productivity, in reliability, in simplicity” Frederick P. Brooks

6
 Software Crisis
• Till 60s’
– Many software projects failed.
– Many software projects late, over budget, providing
unreliable software that is expensive to maintain.
– Many software projects produced software which did not
satisfy the requirements of the customer.
– Complexities of software projects increased as hardware
capability increased.
– Larger software system is more difficult and expensive to
maintain.
– Demand of new software increased faster than ability to
generate new software.
• All the above attributes of what was called a
‘Software Crisis’. So the term ‘Software
Engineering’ first introduced at a conference in late
1960’s to discuss the software crisis
7
 Software Engineering
• In 1968 a NATO Conference was held in Germany.
– Purpose: to look for a solution to software crisis

– 50 top computer scientists, programmers and industry leaders

got together to look for a solution to the difficulties in building
large software systems (i.e., software crisis)

– The term “software engineering” was first used in that

conference to indicate a systematic, disciplined,
quantifiable approach to the production and maintenance
of software

• Three-decades later (1994) an article in Scientific American

(Sept. 94, pp. 85-96) by W. Wayt Gibbs was titled:
– “Software’s Chronic Crisis’’ Chronic crisis in 60’s are still chronic………….

8
 The software process
 A structured set of activities required to develop and
maintain software system.
 A software process model is an abstract representation of a
process.
 It presents a description of a process from some particular
perspective.
• Generic Software Process models
– The waterfall model
• Separate and distinct phases of specification and development.
– Evolutionary development
• Specification, development and validation are interleaved.
– Component-based software engineering
• The system is assembled from existing components.

9
 Software Process
• The Software Engineering Process KA can be
examined on two levels.
– The first level encompasses the technical and
managerial activities within the software life cycle
processes that are performed during software
acquisition, development, maintenance, and retirement.
– The second is the meta-level, which is concerned with
the definition, implementation, assessment,
measurement, management, change, and improvement
of the software life cycle processes themselves
» Chapter 9 SWEBOK ver 4
– IEEE Std 12207, "Systems and software engineering
Software life cycle processes“
• Primary Life Cycle Processes, Supporting Life Cycle Processes,
and Organizational Life Cycle Processes.
11
 A Process SWEBOK Chapter 9

• “A" software process, not “The" process:

– An important point to make at the outset is that this is "a"
software process, not "the" process.
– There is in fact no single process that is universally
applicable to all software.
• "use one that works".
– The one that everyone thoroughly understands and can be
productive using.
• Not through management dictation
– Training, organizational commitment and will workers
– The management and technical leaders who define a
software process must understand well the people who
will use it, and consult with them as necessary before,
during, and after the establishment of a process.
12
 SWE Process
• To establish software life cycle processes,
an appropriate infrastructure is needed
– Recourses(trained staff, tools and funding)
– Assigned responsibilities, committed management
• Software Process Management Cycle
– Four activities sequenced in an iterative
cycle
• Process Infrastructure commitment to process
implementation and change
• Planning activity  to understand the current
business objectives
• Process Implementation and Change  to execute
the plan
• Process Evaluation  Finding out how well the
implementation and change went.

13
 SWE Process
• The context of the project and organization
will determine the type of process definition
• Software life cycle models serve as a high-
level definition of the phases
– Not aimed at providing detailed definitions but at
highlighting the key activities and their
interdependencies
• Software Life Cycle Processes
– More detailed than software life cycle models
– Do not attempt to order their processes in time
– Can be arranged to fit any of the software life cycle
models
– IEEE 1074:1997 standard on developing life cycle
processes also provides a list of processes and
activities for software development and maint

14
 SWE Process
• Process assessment is carried out using both
an assessment model and an assessment
method
• Process Assessment Models
– ISO15504 [ISO15504-98] an exemplar assessment
model and conformance requirements on other
assessment models
– ISO 9001
• Process Assessment Methods
– CBA-IPI assessment method, for example, focuses
on process improvement

15
 Software Processes
1. Specification
– requirements elicitation and analysis.
2. Development
– systems design, detailed design (OO design),
implementation.
3. Validation
– validating system against requirements (testing).
4. Evolution
– meet changing customer needs and error correction
(maintenance).

19
 Software Specification
• Functionality of the software and constraints (non-
functional requirements) on its operation must be
defined.
• Involves:
– Requirements elicitation
• The client and developers define the purpose of the system.
• Output is a description of the system in terms of actors and uses
cases.
• Actors include roles such as end users and other computers the
system needs.
– Uses cases are general sequences of events that
describe all possible actions between actor and the
system for a given piece of functionality.

20
 Software specification
 The process of establishing what services are required
and the constraints on the system’s operation and
development.
 Requirements engineering process
 Feasibility study
• Is it technically and financially feasible to build the system?
 Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
 Requirements specification
• Defining the requirements in detail
 Requirements validation
• Checking the validity of the requirements

21
 Software Development
• Producing the software that meets the
specification.
• System Design
– Goals of the project are defined.
– System decomposed into smaller subsystems
(architectural model).
– Strategies to build system identified
• HW and SW platform, data management, control flow, and
security.
– Output: model describing subsystem decomposition and
system strategies.

22
 Software design and implementation
The process of converting the system specification
into an executable system.
Software design
 Design a software structure that realises the
specification;
Implementation
 Translate this structure into an executable program;
The activities of design and implementation are
closely related and may be inter-leaved.

23
 Design activities
 Architectural design, where you identify the overall structure
of the system, the principal components (sometimes called
sub-systems or modules), their relationships and how they
are distributed.
 Interface design, where you define the interfaces between
system components.
 Component design, where you take each system
component and design how it will operate.
 Database design, where you design the system data
structures and how these are to be represented in a
database.

24
 Software Validation
• Ensures the software does what the customer
• Techniques
want. – Software inspections (static):
• The software
• Analyze
conforms tosystem
and check its specification
representationsand
(e.g.,
requirements documents, design diagrams, and
meets the expectations of the customer.
program source code).
Validation: ‘Are we testing
– Software building the right product?’
(dynamic):
• Executing
Ensures the softwareanmeets the expectations
implementation of the
of the software with test
customer. data and examining the outputs against expected
results.
Verification: ‘Are we building the product right?’
• V&V process establishes the existence of defects.
Ensures the software
• Debugging is a conforms to the
process that specification.
locates and corrects
these defects.

25
 Testing stages
 Development or component testing
 Individual components are tested independently;
 Components may be functions or objects or coherent groupings of
these entities.
 System testing
 Testing of the system as a whole. Testing of emergent properties is
particularly important.
 Acceptance testing
 Testing with customer data to check that the system meets the
customer’s needs.

26
 Software Evolution
• Software must evolve to meet the customer needs.
• Software maintenance is the process of changing a
system after it has been delivered.
• Reasons for maintenance
– To repair faults.
– To adapt the software to a different operating
environment.
– To add to or modify system’s functionality.

27
 Plan-driven and agile processes
 Plan-driven processes
 Processes where all of the process activities are planned in advance
and progress is measured against this plan.
 The waterfall model (Plan driven)
 . Separate and distinct phases of specification and development.

 In agile processes,
 planning is incremental and it is easier to change the process to
reflect changing customer requirements.
 Incremental development (May be plan-driven or agile).
 Specification, development and validation are interleaved.
 Reuse-oriented software engineering (May be plan-driven or agile).
 The system is assembled from existing components.

 In practice, most practical processes include elements of

both plan-driven and agile approaches.
 There are no right or wrong software processes.
28
 Acknowledgement
• The topics covered in this lecture were taken from
the following books and material, I extend my
profound regards to the authors of the books for
shareing the material for academic purpose.
– Software Engineering by Sommerville
• Chapter 1 & 2
– Software Engineering A Practitioner's Approach 7th
edition by “Rogger S Pressman ”
• Chapter 1
– Mary Shaw’s model for Profession Development
– Chapter 9 SWEBOK ver IV

29