TE (CIS) Software Engineering (CS-302)

Fall 2019 Semester

INTRODUCTION TO SOFTWARE ENGINEERING AND PROCESS MODELS

Software Engineering
An engineering discipline that is concerned with all aspects of software
production from the early stages of system specification to maintaining the
system after it has gone into use.
Two key phrases in the above definition:-
1. Engineering Discipline:
 The creative application of scientific principles to design and
develop useful things.
 Involves selectively applying theory, methods and tools where
these are appropriate.
 Engineers always try to discover solutions to problems even
when no applicable theories and methods.
 They must work to organizational and financial constraints.
2. All aspects of software production:
 SE is not just concerned with the technical processes of software
development
o but also with activities such as software project management
and
o with the development of tools, methods and theories to
support software production.

Software Engineering Vs Computer Science

 Computer Science is concerned with the basic principles and methods
underlying computers and software systems.
 Software Engineering is concerned with the practical problems of
producing software.
 Ideally, all of software engineering should be underpinned by
theories of computer science, but in reality this is not the case.
 Software engineers must often use ad hoc approaches to developing
the software.
 Elegant theories of computer science cannot always be applied to
real, complex problems that require a software solution.
Attributes of Good Software
 Includes Services provided by software
 Other associated attributes that reflect the quality of that software.
 They reflect its behavior while it is executing and
 the structure and organization of the source program and the
associated documentation.
  Examples of these attributes (sometimes called non-functional
attributes) are the software’s response time to a user query and the
understandability of the program code.

Product Description
Characteristic
Acceptability o Software must be acceptable to the type of users
for which it is designed.
o This means that it must be understandable,
usable, and compatible with other systems that
they use.
o Requirement: appropriate user interface and
adequate documentation.
Maintainability o Software may evolve to meet the changing
needs of customers.
o Critical attribute
 software change is an inevitable
consequence of a changing business
environment.
Dependability o Range of characteristics, including reliability,
security and safety.
 Should deliver services as per specification,
 should be protected from external attack by
malicious users and
 should not cause damage to people and
system’s environment.
Efficiency o Avoiding wasteful use of system resources such
as memory and processor cycles.
o Includes responsiveness, processing time,
memory utilization etc.
Software engineering is important for two reasons:-
1. Reliance on advanced software systems. There is a need to produce
reliable systems economically and quickly.
2. Software engineering methods and techniques are able to produce
cheaper and high quality softwares.

2
Software Process
Set of activities that lead to the production of a software product
 For some systems, such as critical systems, a very structured
development process is required.
 For business systems, with rapidly changing requirements, a flexible,
iterative process is likely to be more effective.
 Fundamental activities common to all software processes:-
o Software specification: The functionality of the software and
constraints on its operation must be defined.
o Software Development: Involves design and implementation
 Software design: Involves developing the blueprint of software
 Software implementation: Involves the development of executable
code of software.
o Software validation: The software must be validated to ensure that it
does what the customer wants.
o Software evolution: The software must evolve to meet changing
customer needs.
o Other activities: software configuration management and project
planning.
 Software engineering tools provide automated or semi-automated
support for the process and the methods.
o CASE: When tools are integrated so that information created by one
tool can be used by another, a system for support of software
development, called computer-aided software engineering (CASE), is
established.
o The effectiveness of CASE tools is limited is because of the immense
diversity of software processes.
 Besides the activities, software processes also involve following elements:-
1. Products or deliverables are the outcomes of a process activity.
o e.g. the outcome of architectural design may be a model of software
architecture.
2. Roles reflect the responsibilities of the people involved in the
process.
o e.g. roles are project manager, configuration manager, and
programmer.
3. Pre- and post-conditions that must hold before and after a process
activity has been enacted or a product produced.
o e.g., before architectural design begins, a precondition may be that the
consumer has approved all requirements;
o After this activity is finished, a post-condition might be that the UML
models describing the architecture have been reviewed.

3
 Software Process Models
An abstract representation of a software process
 Each process model represents a process from a particular perspective.
o e.g., a process activity model shows the activities and their sequence but
may not show the roles of people involved in these activities.
Process models to be covered
I. The waterfall model
II. Evolutionary Development
III. Incremental development
IV. Configuration and Integration (or Component-based) models
 Sub-systems within a larger system may be developed using different
approaches.
o It should be understood that, in practice, different process models are often
combined.
I. The Waterfall Model
 It takes the fundamental process activities of specification, development,
validation and evolution and represents them as separate process phases.
 Suggests a systematic sequential approach to software development.
 An example of a plan-driven process.
 Sometimes called the classic life cycle.

Fig 1: The software life cycle

The principal stages of the model:-
1. Requirements analysis and definition:
o The system’s services, constraints and goals, are established by
consultation with system users.
o They are then defined in detail and serve as a system specification.
4
2. System and software design:
o Partitions the requirements to either hardware or software systems.
o Establishes an overall system architecture.
o Software design involves identifying and describing the fundamental
software system abstractions and their relationships.
3. Implementation and unit testing:
o The software design is realized as a set of programs or program units.
o Unit testing involves verifying that each unit meets its specification.
4. Integration and system testing:
o The individual program units or programs are integrated and tested as a
complete system to ensure that the software requirements have been met.
o After testing, the software system is delivered to the customer.
5. Operation and maintenance:
o The system is installed and put into practical use.
o Involves correcting errors which were not discovered in earlier stages of
the life cycle, improving the implementation and enhancing the system’s
services as new requirements are discovered.
 Problems encountered
1. Real projects rarely follow the sequential flow that the model proposes. In
practice, these stages overlap and feed information to each other.
2. It is often difficult for the customer to state all requirements explicitly.
3. A working version of the program(s) will not be available until late in the
project time-span.
 Advantages of the waterfall model
o Documentation is produced at each phase and
o It fits with other engineering process models.
 Where and When to use
o The waterfall model should only be used when the requirements are well
understood and unlikely to change during system development.
 When well-defined adaptations or enhancements to an existing system
must be made
 (e.g. an adaptation to accounting software that has been mandated
because of changes to government regulations).
o Critical systems where there is a need for extensive safety and security
analysis of the software specification and design.
5
  In these systems, the specification and design documents must be
complete so that this analysis is possible.
 Unsuitability
o The waterfall model is not the right process model in situations where
 informal team communication is possible and
 software requirements change quickly.
o Iterative development and agile methods are better for these systems.

II. Evolutionary Process Model

 Plan-driven approaches not suitable under following situations:-
1. Business and product requirements change frequently as development
proceeds.
2. Tight market deadlines make completion of a comprehensive software
product impossible.
o a limited version must be introduced to meet competitive or business
pressure.
3. A set of core product or system requirements is well understood,
o but the details of product or system extensions have yet to be defined.
 Evolutionary development: An iterative approach in which specification,
development and validation activities are interleaved rather than separate
with rapid feedback across activities.
 Basic Process
o developing an initial implementation,
o exposing this to user comment and
o refining it through many versions until an adequate system has been
developed.

Fig 2: Evolutionary development

Two fundamental types of evolutionary development:-
1. Exploratory development where the objective of the process is to work with the
customer to explore their requirements and deliver a final system.

6
 o The development starts with the parts of the system that are understood.
o The system evolves by adding new features proposed by the customer.
2. Throwaway prototyping where objective is to understand customer’s requirements
and hence develop a better requirements definition for the system.
o The prototype concentrates on experimenting with the customer
requirements that are poorly understood.
o Although prototyping can be used as a standalone process model, it is
more commonly used within the context of any one of process models.
 Prototyping process
o Customer communicates basic objectives to software engineer.
o A prototyping pattern is planned quickly and quick design is developed.
o The quick design focuses on visible aspects of software (e.g., human
interface layout or output display formats).
o The prototype is built and then evaluated by the customer/user.
o Feedback is used to refine requirements for the software.
o Iteration occurs as the prototype is tuned to satisfy the needs of the
customer, while at the same time enabling the developer to better
understand what needs to be done.
 Advantage of evolutionary approach
o the specification can be developed incrementally.
o As users develop a better understanding of their problem, this can be
reflected in the software system.
 From an engineering and management perspective, the evolutionary
approach has two problems:-
a. The process is not visible:
o Managers need regular deliverables to measure progress.
o If systems are developed quickly, it is not cost-effectiveness to produce
documents that reflect every version of the system.
b. Systems are often poorly structured:
o Continual change tends to corrupt the software structure.
o Incorporating software changes becomes increasingly difficult and
costly.
 For small and medium-sized systems, the evolutionary approach is the best
approach to development.
 The problems of evolutionary development become particularly acute for
large, complex, long-life-time systems, where different teams develop
different parts of the system.
o It is difficult to establish a stable system architecture in this approach,
which makes it hard to integrate contributions from the teams.
7
 For large systems, a mixed process is recommended:-
o Developing a throwaway prototype using an evolutionary approach to
resolve uncertainties in the system specification.
o Then reimplement the system using a more structured approach.
 Other parts of the system, such as the user-interface, which are difficult to
specify in advance, should always be developed using an exploratory
programming approach.
Spiral Development [Boehm, 1988]
 An evolutionary software process model that
o couples the iterative nature of prototyping with
o the controlled and systematic aspects of the waterfall model.
 The software team performs activities that are implied by a path round the
spiral in a clockwise direction, beginning at the center.
 Each loop in the spiral: a phase of the software process.

Fig 3: Boehm’s spiral model of the software process

 Main difference between spiral and other process models: explicit recognition
of risk in the spiral model.
 Provides the potential for rapid development of increasingly more complete
versions of the software.
 Anchor point milestones – a combination of work products and conditions
attained along the path of the spiral – are noted for each evolutionary pass.
Each loop in the spiral is split into four sectors:-
1. Objective setting: Specific objectives (functionality, performance) for that
project phase are defined.

8
 o Constraints on the process (cost, schedule) and the product (interface) are
identified and a detailed management plan is drawn up.
o Project risks are identified.
o Alternative strategies, depending on these risks, may be planned.
o This first circuit around the spiral might result in the development of a
product specification; subsequent passes around the spiral might be used
to develop a prototype and then progressively more sophisticated
versions of the software.
2. Risk assessment and reduction:
o Risks result in project problems such as schedule and cost overrun so risk
minimization is a very important project management activity.
o Each alternative is assessed against these risks by information-gathering
activities such as
 prototyping and simulation,
 benchmarking, reference checking,
 administering user questionnaires, analytic modeling, or
 combination of these and other risk-resolution techniques.
o For example, if there is a risk that the requirements are inappropriate, a
prototype system may be developed.
o This path around the spiral results in adjustments (Cost and schedule) to
the project plan.
3. Development and Validation: After risk evaluation, a development model
for the system is chosen.
o For example, if user interface risks are dominant, an appropriate model
might be evolutionary prototyping.
o If safety risks are the main consideration, formal transformations model
may be the most appropriate.
o Waterfall may be most appropriate development model if main identified
risk is sub-system integration.
4. Planning: The project is reviewed and a decision made whether to continue
with a further loop of the spiral.
o If it is decided to continue, plans are drawn up for the next phase of the
project.
Spiral model vs Other process models
 Unlike other process models, the spiral model can be adapted to apply
throughout the life of the computer software.

9
  Therefore, the first circuit around the spiral might represent a concept
development project
o which starts at the core of the spiral and
o continues for multiple iterations until concept development is complete.
 If the concept is to be developed into an actual product,
o the process proceeds outward on the spiral and
o a new product development project commences.
 The new product will evolve through a number of iterations around the
spiral.
 Later, a circuit around the spiral might be used to represent a product
enhancement project.
 In essence, the spiral, remains operative until the software is retired.
Advantages
 Due to extensive risk management, the spiral model is a realistic approach
to development of large-scale systems and software.
 Maintains the systematic stepwise approach suggested by the classic life
cycle but incorporates it into an iterative framework that more realistically
reflects the real world.
Drawbacks
Like other paradigms, the spiral model is not a panacea.

 It may be difficult to convince customers (particularly in contract situations)

that the evolutionary approach is controllable.

 It demands considerable risk assessment expertise and relies on this

expertise for success.

III. Incremental Delivery

 Suitable under following conditions:-
o Initial software requirements are reasonably well-defined, but the details
of product or system extensions have yet to be defined.
o There may be a compelling need to provide a limited set of functionality
to users quickly and then refine and expand on that functionality in later
software releases.
 Incremental process model is designed to produce software in increments.
 An in-between approach that combines the advantages of evolutionary and
waterfall model.
 Description
o Customers identify, in outline, the services to be provided by the system.

10
 o A number of delivery increments are then defined.
o Increments are delivered in the order of priority of services.

Fig 4: Incremental delivery

o Next requirements for the services to be delivered in the first increment
are defined in detail and that increment is developed.
o The first increment is often a core product addressing basic requirements.
o They can then experiment with the system to clarify their requirements
for later increments and for later versions of the current increment.
o As new increments are completed, they are integrated with existing
increments so that system functionality improves with each delivered
increment.
o This process is repeated following the delivery of each increment, until
the complete product is produced.
 For example, word processing software developed using the incremental
paradigm might deliver
o basic file management, editing and document production functions in the
first increment;
o more sophisticated editing and document production capabilities in the
second increment;
o spelling and grammar checking in the third increment; and
o advanced page layout capability in the fourth increment.
 Incremental Vs Evolutionary Approach
o The incremental process model, like evolutionary approaches, is iterative
in nature.
o But unlike prototyping, the incremental model focuses on the delivery of
an operational product with each increment.
 Advantages
i. Customers can use the early increments as prototypes and gain
experience that clarifies their requirements for later system increments.
ii. As the highest priority services are delivered first, and later increments
are integrated with them, it is inevitable that the most important system
services receive the most testing.

11
 iii. When staffing is unavailable for a complete implementation by the
business deadline, early increments can be implemented with fewer
people.
iv. Increments can be planned to manage technical risks. For example, a
major system might require the availability of new hardware that is
underdevelopment and whose delivery date is uncertain.
 Problems with incremental delivery
i. It can be difficult to map the customer’s requirements onto increments
of the right size.
ii. Furthermore, most systems require a set of basic facilities that are used
by different parts of the system.
o As requirements are not defined in detail until an increment is to be
implemented, it can be hard to identify common facilities that are
needed by all increments.
IV. Component-based Software Engineering
 An approach to software development that relies on component reuse.
 Commercial off-the-shelf (COTS) software components, developed by
vendors who offer them as products, can be used for building software.
o These components provide targeted functionality with well-defined
interfaces that enable the component to be integrated into the software.
 This reuse oriented approach relies on
o a large base of reusable software of components and
o some integrating framework for these components.
 These components can be designed as either conventional software modules
or object-oriented classes or packages of classes.
 The generic process model for CBSE is shown in fig below.

Fig 5: Component-based software engineering

The intermediate stages in a reuse-oriented process are different.
1. Requirements specification
o Brief descriptions of essential requirements and desirable system
features.

12
 2. Component discovery and evaluation
o Given an outline of the software requirements, a search is made for
components that provide the functionality required.
o Candidate components are evaluated to see if they meet the essential
requirements.
3. Requirements refinement
o The requirements are modified to reflect the available components,
and the system specification is re-defined.
o Where modifications are impossible, the component analysis activity
may be reentered to search for alternative solutions.
4. System design with reuse
o During this phase, the architecture of the system is designed or an
existing architecture is reused.
o The designers take into account the components that are reused and
organize the architecture to cater to this.
5. Development and Integration
o Software that cannot be externally procured is developed, and the
components and COTS are integrated to create the new system.
o System integration, in this model, may be part of the development
process rather than a separate activity.
 Advantages
o Reducing the amount of software to be developed and so reducing cost
and risks.
o Leads to faster delivery of the software.
 Drawbacks
o Requirements compromises are inevitable leading to a system that
does not meet the real needs of users.
o Some control over the system evolution is lost as new versions of the
reusable components are not under the control of the organization
using them.
New form of Contract with Iteration
 Iteration conflicts with the procurement model of many organizations
where complete system specification is part of development contract.
 In the incremental approach, there is no complete system specification
until the final increment is specified.
o This requires a new form of contract, which large customers such as
government agencies may find difficult to accommodate.

13