Software Engineering 1 Fundamental Introduction PDF

IT3205: Fundamentals of
Software Engineering
IT3205 - Software Development Process Models
Learning Outcome
After successfully completing this course
students should be able to;
– explain the software engineering principles and
techniques that are used in developing quality
Software products
– apply software engineering principles and
techniques appropriately to develop a
moderately complex software system
UCSC - 2014 2
Outline of Syllabus
1. Introduction
2. Software Development Process Models
3. Requirements Analysis & Specification
4. Design
5. Coding
6. Software Testing and Quality Assurance
7. Software Maintenance
UCSC - 2014 3
8. Software Project Management

Main References
Software Engineering by
1.Ian Sommerville, 7th edition, Addison-
Wesley, 2006.
Software Engineering: A
practitioner's
2.approach by Roger S. Pressman,
UCSC - 2014 4
6th edition, McGraw-Hill International edition,

2005.
3. http://www.softwareengineering-9.com
IT3205: Fundamentals of Software
Engineering Introduction
Duration: 4 hours
UCSC - 2014 5
Learning Objectives
• Describe what software is, different types of
software and software quality attributes
• Describe with the problems associated with
software and software development
• Define what software engineering is and
explain why it is important
UCSC - 2014 6
• State some professional issues related to

software development
Detailed Syllabus
1.1 Software
1.1.1 What is software?
1.1.2 Types of software
1.1.3 Characteristics of Software
1.1.4 Attributes of good software
1.2 Software Engineering

1.2.1 What is software engineering?
UCSC - 2014 7
1.2.2 Software engineering costs

1.2.3 What are the key challenges facing software engineering?
1.2.4 Systems engineering & software Engineering
1.2.5 Professional Practice
1.1.1 WHAT IS SOFTWARE?
UCSC - 2014 8
What is software?
• Instructions given to a computer (computer
programs)
• Software is a general term for the various
kinds of programs used to operate
computers and related devices
• It can be;
– System Software
UCSC - 2014 9
– Application Software
What is software?
• Software is the set of instructions that makes
the computer work.
Example - When you type in words via the

keyboard, the software is responsible for
displaying the correct letters, in the correct place
on the screen.
UCSC - 2014 10
What is software?
• Software is held either on your computer’s
hard disk, CDROM, DVD or on a diskette
(floppy disk) and is loaded (i.e. copied) into
the computer’s RAM (Random Access
Memory), as and when required.
1.1.2 TYPES OF SOFTWARE
UCSC - 2014 11
Main Types of Software

• There are two main types of software;
1. System Software
– computer software designed to operate and
control the computer hardware and to provide a
platform for running application software
2. Application Software
UCSC - 2014 12
– set of one or more programs designed to carry out

operations for a specific application
UCSC - 2014 13
System Software
System System System

Management Support Development
Programs Programs Programs
•Operating Systems •System Utilities •Programming Language
•Operating Environments •Performance Monitors Translators
•Database Management •Security Monitors •Programming
Systems Environments
•Computer Aided
(CASE) Packages
System Software
UCSC - 2014 14
Application Software
General Purpose Application

Application Specific
Programs Programs
•Word Processing •Accounting, General Legers etc.
•Electronic Spread Sheets •Marketing-Sales Analysis etc.
•Database Managers •Manufacturing-Production Control etc.
•Graphics Software •Finance-Capital Budgeting etc.
•Integrated Packages
Application Software
UCSC - 2014 15
Common Software Types

• System Software:
– System software is a collection of
programs is written to service
the other programs.
Eg: Operating system component,
drivers, telecommunication
process.
UCSC - 2014 16

• Business software:
management information
system software that access one
or more large database
containing business
information
UCSC - 2014 17
• Embedded software:
Embedded software resides in read-
only memory and is used to control
product and system for the customer
and industrial markets
Common Software
Types
• Web-based software:
The network becomes a massive
computer providing an almost
UCSC - 2014 18
unlimited software resources that can be accessed by

anyone with a modem.
• Artificial intelligence software:

AI software makes use of non-numerical
algorithms to solve the complex problems that
are not amenable to computing or
straightforward analysis.

• Engineering and scientific software:
UCSC - 2014 19
They have been characterized by number crunching

algorithms
• Personal computer software:

Personal computer software market has
burgeoned over the past two decades.
Word processing, spreadsheets, computer
graphic, multimedia and db management
UCSC - 2014 20
1.1.3
CHARACTERISTICS OF
SOFTWARE
Characteristics of Software
• Intangibility
– Cannot touch software
• Increase use will not introduce any defects
• Software is configurable
– able to build software by combining a basic set of software
components in different ways
UCSC - 2014 21
– One can change the product easily by re-implementing it

without changing the design
• Custom built
– Most software are made upon order
UCSC - 2014 22
Cost of Hardware vs. Software
UCSC - 2014 23
UCSC - 2014 24
Failure curve for hardware (Pressman)
UCSC - 2014 25
UCSC - 2014 26
Failure curve for software (Pressman)
UCSC - 2014 27
UCSC - 2014 28
1.1.4
ATTRIBUTES OF GOOD
SOFTWARE
Software Quality
• The degree in which software possesses a
desired combination of quality attributes
• The software should deliver the required

functionality and performance to the user and
UCSC - 2014 29
should be maintainable, dependable and

acceptable
Software Quality
• Maintainability
– Software must evolve to meet changing needs
• Dependability
– Software must be trustworthy
• Efficiency
UCSC - 2014 30
– Software should not make wasteful use of system

resources
• Acceptability
– Software must accepted by the users for which it was
designed. This means it must be understandable, usable
and compatible with other systems
Bohem’s Classification
• Current Usefulness
– The qualities expected from a software system in
user’s point of view
UCSC - 2014 31
• Potential Usefulness
– The qualities expected from a software system
Current usefulness
• Efficiency
– Software should not make wasteful use of system
resources
• Reliability
• Usability
• Correctness
UCSC - 2014 32
– The degree with which software adheres to its specified

requirements
• User friendliness
• Robustness
Potential usefulness
• Maintainability
– Software must evolve to meet changing needs. The ease
with which changes can be made to satisfy new
requirements or to correct deficiencies
• Modularity
UCSC - 2014 33
• Reusability
– The ease with which software can be reused in developing
other software
• Portability
– The ease with which software can be used on computer
configurations other than its current one
McCall’s Classification
• Product operation
UCSC - 2014 34
• Product revision
• Product transition
Product Operation
• Efficiency
– The degree with which software fulfills its purpose without
waste of resources
• Correctness
• User friendliness
• Usability
UCSC - 2014 35
• Reliability
– The frequency and criticality of software failure, where
failure is an unacceptable effect or behavior occurring
under permissible operating conditions
• Robustness
Product Revision
• Maintainability
• Flexibility
• Testability
UCSC - 2014 36
Product Transition
• Interoperability
• Reusability
• Portability
UCSC - 2014 37
1.2.1 INTRODUCTION TO
SOFTWARE ENGINEERING Need
for Software Engineering
• The economies of ALL developed nations are
dependent on software.
• More and more systems are software
controlled
UCSC - 2014 38
• Expenditure on software represents a

significant fraction of GNP in all developed
countries
Need for Software Engineering
• Software is found in products and situations
where very high reliability is expected
– E.g. Monitoring and controlling Nuclear power
plants
UCSC - 2014 39
• Contain millions of lines of code

• Comparably more complex
Thus, need a systematic process to produce high

quality software product
UCSC - 2014 40
The Solution – Software Engineering

• Software engineering is concerned with
theories, methods and tools for professional
• Greater emphasis on systematic , scientific
development
• Computer assistance in software development
(CASE)
UCSC - 2014 41
The Solution – Software Engineering

• A concentration on finding out the user’s
requirements
• Formal/Semi Formal specification of the
requirements of a system
• Demonstration of early version of a system
(prototyping)
UCSC - 2014 42
• Greater emphasis on development of error

free easy to understand code
What is software engineering?
• An engineering discipline that is concerned
with all aspects of software production
• Software engineers should adopt a systematic

and organized approach to their work and use
UCSC - 2014 43
appropriate tools and techniques depending

on the problem to be solved, the
development constraints and the resources
available
Software Engineering - Definitions
Simple Definition: Designing, building and
maintaining large software systems
UCSC - 2014 44
Use of systematic, engineering approach in all

stages of software development and project
management to develop high quality and
economical software using appropriate
software tools
‘Software engineering is concerned with the theories,
methods and tools for developing, managing and
evolving software products’
UCSC - 2014 45
– I Sommerville
‘The practical application of scientific knowledge in the

design and construction of computer programs and
the associated documentation required to develop,
operate and maintain them’
– B.W.Boehm

'The establishment and use of sound engineering
principles in order to obtain economically software
UCSC - 2014 46
that is reliable and works efficiently on real

machines’
– F.L. Bauer
‘The application of systematic, disciplined, quantifiable

approach to the development, operation, and
maintenance of software’
– IEEE Standard 610.12
What makes software special?
UCSC - 2014 47
• The main difference in software engineering compared to

other engineering disciplines can be listed as below;
1. It is difficult for a customer to specify requirements
completely
2. It is difficult for the developer to understand fully the
customer needs
3. Software requirements change regularly
4. Software is primarily intangible; much of the process of
creating software is also intangible, involving experience,
thought and imagination
5. It is difficult to test software exhaustively
UCSC - 2014 48
Members of a software engineering team

1. Project manager
2. Systems analyst
3. Designer
4. Programmer
5. Tester
6. Technical clerk
UCSC - 2014 49
1.2.2 SOFTWARE
ENGINEERING COSTS
Software Engineering Costs
Distribution of costs across the different
activities in the software process depends on
the process used and the type of software
that is being developed.
UCSC - 2014 50
– Eg: Real-time software usually requires more

extensive validation and testing than web-based
systems.
Software Engineering Costs
• In the waterfall approach, the cost of
specification, design, implementation and
integration are measured separately.
• System integration and testing is the most
expensive development activity.
UCSC - 2014 51
• Normally this is about 40% of the total

development costs
Development Failures
IBM Survey, 2002
– 55% of systems cost more than expected
– 68% overran the schedules
– 88% had to be substantially redesigned
Bureau of Labour Statistics (2004)
UCSC - 2014 52
– for every 6 new systems put into operation, 2 cancelled

– probability of cancellation is about 50% for large systems
– average project overshoots schedule by 50%
Development Failures - Real Examples;

• Over Budget
Home Office IT project millions over budget
Home Office (UK) IT project runby Bull Information
Systems is expected to blow its budget by millions of
pounds and is hampered by a restrictive contract,
according to a leaked report. The National Audit Office
UCSC - 2014 53
Reportis expected to reveal damning evidence that the

project to implement two systems – the National
Probation Service Information System, and the Case
Record and Management System will cost 118m pounds
by the end of the year, 70% over its original budget.
―www.computing.co.uk/News/111627

• Over Schedule
New air traffic system is already obsolete
National Air Traffic Services (Nats) is already looking at
replacing the systems at its newcontrol center at
UCSC - 2014 54
Swanwick in Hampshire, even though the system doesn’t

become operational until next week. This project is six
years late and 180m pounds over budget.
Swanwick was originally meant to be operational by 1997,
but problems with the development of software by
Lockheed Martin caused delays, according to Nats.
―www.vnunet.com/News/1128597

• Safety
London Ambulance Dispatching System
The full introduction of the computer system effectively did away with
the radio and telephone calls to stations, with the computer
UCSC - 2014 55
dispatching crews to answer calls. But within hours, during the

morning rush, it became obvious to crews and control room staff that
calls were going missing in the system; ambulances were arriving late
or doubling up on calls. Distraught emergency callers were also held in
a queuing system which failed to put them through for up to 30
minutes. Chris Humphreys, Nupe’s divisional officer, said that it was
hard to verify how many people might have died because of the
delays but it could be as many as 20.
Causes: The managers who produced the software were naïve. They
made a terrible mistake of trying to go on-line abruptly, without
running the new and old systems together for a while

• Programming/testing Error
UCSC - 2014 56
Ariane 5 (June 1996)

It took the European Space Agency 10 years and $7 billion
to produce Ariane 5, a giant rocket capable of hurling a
pair of three ton satellites into orbit.
At 39 seconds after launch, as the rocket reached an
altitude of two and a half miles, a self-destructmechanism
finished off Ariane 5, along with its payload of two
expensive and uninsured scientific satellites. The rocket
was makingan abrupt course correction that was not
needed, compensating for a wrong turn that had not
taken place.
UCSC - 2014 57

• Programming/testing Error
Ariane 5 (June 1996)
The cause: Steering was controlled by the on-board
computer, which mistakenly thought the rocket needed a
course change because of the numbers, which in fact was
an error, coming from the inertial guidance system. The
guidance system had in fact shut down 36.7 seconds after
launch,when the guidance system’s own computer tried to
convert one piece of data – the sideways velocity of the
UCSC - 2014 58
rocket – from a 64 bit format to a 16 bit format = overflow

error.
UCSC - 2014 59
Statistics
UCSC - 2014 60
UCSC - 2014 61
1.2.3 KEY CHALLENGES FACING

SOFTWARE ENGINEERING
Key challenges facing Software Engineering
• Heterogeneity
– Developing techniques for building software that can cope
with heterogeneous platforms and execution
environments
• Delivery
UCSC - 2014 62
– Developing techniques that lead to faster delivery of

software
• Trust
– Developing techniques that demonstrate that software
can be trusted by its users
Software Problems
1. Time Schedules and cost estimates of many
software projects are grossly inaccurate
2. Software is costly
UCSC - 2014 63
3. The quality of software is not satisfactory

4. Software is difficult to maintain
5. The productivity of software people is not
satisfactory to meet the demand
Problems of software development
• Large software is usually designed to solve
'wicked' problems
UCSC - 2014 64
• Software engineering requires a great deal of

coordination across disciplines
– Almost infinite possibilities for design trade-offs
across components
– Mutual distrust and lack of understanding across
engineering disciplines
• Systems must be designed to last many years
in a changing environment.
UCSC - 2014 65
• The process of efficiently and effectively

developing requirements.
• Tooling required to create the solutions, may
change as quick as the clients mind.
• User expectations:
– User expectations increase as the technology
becomes more and more sophisticated
UCSC - 2014 66
• The mythical man-month factor:

– Adding personnel to a project may not increase
productivity
– Adding personnel to a late project will just make it
later
• Communications:
– Communications among the various
constituencies is a difficult problem. Sometimes
UCSC - 2014 67
different constituencies speak completely

different languages. For example, developers may
not have the domain knowledge of clients and / or
users. The larger the project, the more difficult
the communications problems become.

• Project characteristics:
UCSC - 2014 68
– size / complexity
– novelty of the application
– response-time
characteristics
– security requirements
– user interface requirements
– reliability / criticality requirements
UCSC - 2014 69
1.2.4 SYSTEMS ENGINEERING &

SOFTWARE ENGINEERING
software engineering vs. system engineering
• System engineering
is concerned with all aspects of computer-based systems
development including hardware, software and process
engineering.
• Software engineering
UCSC - 2014 70
is part of this process concerned with developing the

software infrastructure, control, applications and
databases in the system.
• System engineers are involved in system
specification, architectural design, integration and
deployment.
1.2.5 PROFESSIONAL PRACTICE
UCSC - 2014 71
Professional and ethical responsibility

• Software engineering involves wider
responsibilities than simply the application of
technical skills.
• Software engineers must behave in an honest
and ethically responsible way if they are to be
respected as professionals.
UCSC - 2014 72
• Ethical behavior is more than simply

upholding the law.
Issues of professional responsibility
• Confidentiality
– Engineers should normally respect the
confidentiality of their employers or clients
irrespective of whether or not a formal
confidentiality agreement has been signed.
• Competence
UCSC - 2014 73
– Engineers should not misrepresent their level of

competence. They should not knowingly accept
work which is out with their competence.
Issues of professional responsibility
• Intellectual property rights
– Engineers should be aware of local laws governing the use
of intellectual property such as patents, copyright, etc.
They should be careful to ensure that the intellectual
property of employers and clients is protected.
• Computer misuse
UCSC - 2014 74
– Software engineers should not use their technical skills to

misuse other people’s computers. Computer misuse
ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious
(dissemination of viruses).
UCSC - 2014 75
IT3205: Fundamentals of
(Compulsory)
UCSC - 2014 76
IT3205: Fundamentals of Software

Engineering
Software Development Process

Models
Duration: 8 hours
UCSC - 2014 77
Learning Objectives
• Describe different process models used for
• Identify the most appropriate software
process model for a given problem
• Identify how CASE tools can be used to
support software process activities
UCSC - 2014 78
Detailed Syllabus
2.1 What is a software process?
2.2 What is a software process model?

2.2.1 The waterfall model
2.2.2 Evolutionary development
2.2.3 Component-Based Software Engineering (CBSE)
2.3 Process Iteration

2.3.1 Incremental delivery
2.3.2 Spiral development
UCSC - 2014 79
Detailed Syllabus
2.4 Rapid software development
2.4.1 Agile methods
2.4.2 Extreme programming
2.4.3 Rapid application development (RAD)
2.4.4 Software prototyping
2.5 Rational Unified Process (RUP)
2.6 Computer Aided Software Engineering (CASE)

2.6.1 Overview of CASE approach
UCSC - 2014 80
2.6.2 Classification of CASE tools
2.1 WHAT IS A SOFTWARE

PROCESS?
Software Process
• It is important to go through a series of steps
to produce high quality software. These steps
or the road map followed is called the
software process.
UCSC - 2014 81
• Software process is a set of ordered tasks

involving activities, constraints and resources
that produce a software system
• A process is important because it imposes
consistency and structure on a set of activities
UCSC - 2014 82
Software Process
• It guides our actions by allowing us to
examine, understand, control and improve the
activities that comprise the process
• The process of building a product is
sometime called a lifecycle because it
describes the life of that product from
conception through to its implementation,
delivery, use and maintenance
UCSC - 2014 83
Generic activities in all software processes

• Specification
– what the system should do and its development
constraints
• Development
– production of the software system
• Validation
– checking that the software is what the customer wants
• Evolution
UCSC - 2014 84
– changing the software in response to changing demands

2.2 WHAT IS A SOFTWARE PROCESS
MODEL?
Software Process Models
you need to model the process because:
– when a team writes down a description of its
development process it forms a common
understanding of the activities, resources and
constraints involved in software development
UCSC - 2014 85
– creating a process model helps the team find

inconsistencies, redundancies and commissions in
the process, as these problems are noted and
corrected the process becomes more effective
Software Process Models
you need to model the process because:
– the model reflects the goals of development
and shows explicitly how the product
characteristics are to be achieved
UCSC - 2014 86
– each development is different and a process

has to be tailored for different situations, the
model helps people to understand these
differences
UCSC - 2014 87
2.2.1 THE WATERFALL MODEL
UCSC - 2014 88
Waterfall Model
• Separate and distinct phases of specification
and development
• A linear sequential model
UCSC - 2014 89
Waterfall Model Phases
UCSC - 2014 90
Requirement
Analysis &
UCSC - 2014 91
Requirement Analysis & Specification

• The system’s services, constraints and goals are
established with the consultation with the users.
• This would include the understanding of the
information domain for the software, functionality,
behavior, performance, interface, security and
exceptional requirements.
• This requirements are then specified in a manner
which is understandable by both users and the
development staff.
UCSC - 2014 92
Software design
• The design process translates requirements
into a representation of the software that can
be implemented using software tools.
• The major objectives of the design process
are the identification of the software
components, the software architecture,
interfaces, data structures and algorithms.
UCSC - 2014 93
Coding (implementation)
• The design must be translated to a machine
readable form.
• During this stage the software design is
realized as a set of programs or program units.
• Programming languages or CASE tools can
be used to develop software.
UCSC - 2014 94
Testing
• The testing process must ensure that the
system works correctly and satisfies the
requirements specified.
• After testing, the software system is
delivered to the customer.
UCSC - 2014 95
Maintenance
• Software will undoubtedly undergo changes
after it is delivered to the customer.
• Errors in the system should corrected and
the system should be modified and updated
to suit new user requirements.
UCSC - 2014 96
Problems with the Waterfall Model

1. Real projects rarely follow the sequential flow that the
model proposes. Although the Waterfall model can
accommodate iteration, it does so indirectly.
2. It is often very difficult for the customer to state all
requirements explicitly. The Waterfall model has the
difficulty of accommodating the natural uncertainty that
exists at the beginning of many projects.
3. The customers must have patience. A working version
of the program(s) will not be available until late in the
UCSC - 2014 97
project timespan. A major blunder, if undetected until the

working program is reviewed, can be disastrous.
Problems with the Waterfall Model
4. The difficulty of accommodating change after
the process is underway.
5. One phase has to be complete before moving
on to the next phase.
6. Few business systems have stable
requirements.
UCSC - 2014 98
Comment : The Waterfall model is suitable for projects

which have clear and stable requirements.
2.2.2 EVOLUTIONARY
DEVELOPMENT
UCSC - 2014 99
Evolutionary Development
• Evolutionary development approach is
typically used to develop and implement
software in a evolutionary manner.
• This approach has been described by Steve
McConnell as the "best practice for software
development and implementation".
UCSC - 2014 100

Evolutionary Development
• Early versions of the system are presented
to the customer and the system is refined and
enhanced based on customer feedback.
• The cycle continues until development time
runs out (schedule constraint) or funding for
development runs out (resource constraint).
UCSC - 2014 101

Prototyping
• It is very difficult for end-users to anticipate how
they will use new software systems to support their
work. If the system is large and complex, it is
probably impossible to make this assessment before
the system is built and put into use.
• A prototype (a small version of the system) can be

used to clear the vague requirements. A prototype
should be evaluated with the user participation.
UCSC - 2014 102

Prototyping
• A prototype is a working model that is
functionally equivalent to a component of the
product.
• There are two types of Prototyping
techniques
– Throw-away Prototyping
– Evolutionary Prototyping
UCSC - 2014 103

Throw-away Prototyping
UCSC - 2014 104

Throw-away Prototyping
• The objective is to understand the system
requirements clearly.
• Starts with poorly understood requirements.
Once the requirements are cleared, the
system will be developed from the beginning.
• This model is suitable if the requirements
are vague but stable.
UCSC - 2014 105

Some problems with Throw-away Prototyping

1. Important features may have been left out of the
prototype to simplify rapid implementation. In fact, it may
not be possible to prototype some of the most important
parts of the system such as safety-critical functions.
2. An implementation has no legal standing as a contract

between customer and contractor.
UCSC - 2014 106

3. Non-functional requirements such as those concerning

reliability, robustness and safety cannot be adequately
tested in a prototype implementation.
UCSC - 2014 107

Evolutionary Prototyping
UCSC - 2014 108

• Advantages
– Effort of prototype is not wasted
– Faster than the Waterfall model
– High level of user involvement from the start
– Technical or other problems discovered early – risk
reduced
– A working system is available early in the process
– Misunderstandings between software users and
developers are exposed
UCSC - 2014 109

– Mainly suitable for projects with vague and unstable

requirements
• Disadvantages
– Prototype usually evolve so quickly that it is not
costeffective to produce great deal of documentation
– Continual change tends to corrupt the structure of the
prototype system. Maintenance is therefore likely to be
difficult and costly
UCSC - 2014 110

– It is not clear how the range of skills which is normal in

software engineering teams can be used effectively for
this mode of development
– Languages which are good for prototyping not always
best for final product
UCSC - 2014 111

2.2.3 COMPONENT-BASED SOFTWARE

ENGINEERING (CBSE)
Component-Based Software Engineering
• Emphasizes the design and construction of
computer based systems using software
“components”.
• The process relies on reusable software
components.
UCSC - 2014 112

• Similar to the characteristics of the spiral

model.
Process
UCSC - 2014 113

UCSC - 2014 114


• Requirement specification and validation steps are
similar to the other processes.
• Component Analysis
– During this stage try to find the software components need
for the implementation once the requirements are
specified.
UCSC - 2014 115

• Requirements Modification
– Analyze the discovered software components to find out
whether it is able to achieve the specified requirements.

• System Design with Reuse
– The frame work of the system is designed to get the
maximum use of discovered components. New software
may have to design if the reusable components are not
available.
UCSC - 2014 116

• Development and integration

– Software that cannot be discovered is developed, and the
reusable components are integrated to create the new
system. The integration process, may be part of the
development process rather than a separate activity.
2.3 PROCESS ITERATION
UCSC - 2014 117

Process Iteration
• A process for arriving at a decision or a
desired result by repeating rounds of analysis
or a cycle of operations.
• The objective is to bring the desired decision
or result closer to discovery with each
repetition (iteration).
UCSC - 2014 118

• The iterative process can be used where the

decision is not easily revocable or where the
consequences of revocation could be costly.
2.3.1 INCREMENTAL DELIVERY
UCSC - 2014 119

Incremental Model
UCSC - 2014 120

UCSC - 2014 121

Incremental Development
• The Incremental development model involves
developing the system in an incremental fashion.
• The most important part of the system is fist
delivered and the other parts of the system are then
delivered according to their importance.
• Incremental development avoids the problems of
constant change which characterize evolutionary
prototyping.
UCSC - 2014 122

Incremental Development
• An overall system architecture is established
early in the process to act as a framework.
• Incremental development is more
manageable than evolutionary prototyping as
the normal software process standards are
followed.
• Plans and documentation must be produced.
UCSC - 2014 123

2.3.2 SPIRAL DEVELOPMENT
The Spiral Model

• This model is an evolutionary software
process model that couples the iterative
nature of prototyping with the controlled and
UCSC - 2014 124

systematic aspects of the linear sequential

model.
• Using the spiral model software is developed
in a series of incremental releases. During
early iterations, the incremental release might
be a paper model or prototype.
UCSC - 2014 125

The Spiral Model

• The spiral model is divided into four main task
regions
1. Determine goals, alternatives, constraints
2. Evaluate alternatives and risks
3. Develop and test
4. Plan
UCSC - 2014 126

Spiral Model
UCSC - 2014 127

UCSC - 2014 128

2.4 RAPID SOFTWARE

DEVELOPMENT
Rapid Software Development
• Because of rapidly changing business
environments, businesses have to respond to
new opportunities and competition.
• This requires software and rapid
development and delivery is not often the
UCSC - 2014 129

most critical requirement for software

systems.
• Businesses may be willing to accept lower
quality software if rapid delivery of essential
functionality is possible.
Rapid Software Development
• Requirements
UCSC - 2014 130

– Because of the changing environment, it is

often impossible to arrive at a stable, consistent
set of system requirements.
– Therefore a waterfall model of development is
impractical and an approach to development
based on iterative specification and delivery is the
only way to deliver software quickly.
UCSC - 2014 131

2.4.1 AGILE METHODS
UCSC - 2014 132

Agile Process
• Agile software engineering combines a philosophy
and a set of development guidelines.
• The philosophy encourages the customer
satisfaction and early incremental delivery of
software.
• small and highly motivated software teams,
informal methods, minimal software engineering
work products, and overall development simplicity.
UCSC - 2014 133

• The development guidelines stress delivery and

active and continuous communication between
developers and customers.
Agile Process
• An agile process adapt incrementally. To
accomplish incremental adaptation, an agile team
requires customer feedback.
• An effective tool to get customer feedback is an
operational prototype or a portion of an operational
system.
UCSC - 2014 134

• Software increments must be delivered in short

time periods so that the adaptation keep pace with
the change This iterative approach enables the
customer to evaluate the software increment
regularly and provide necessary feedback to the
software team.
2.4.2 EXTREME PROGRAMMING
UCSC - 2014 135

Extreme programming
• Extreme Programming (XP) is the most
widely used Agile Process model.
• XP uses an object oriented approach as its
development paradigm.
• XP encompasses a set of rules and practices
that occur within the context of four
UCSC - 2014 136

framework activities; planning, design , coding

and testing.
Extreme programming
• “Extreme Programming is a discipline of
software development based on values of
simplicity, communication, feedback and
courage”
– Ron Jeffries
UCSC - 2014 137

Extreme programming Process
UCSC - 2014 138

UCSC - 2014 139


1. Planning
– Begins with a set of stories (scenarios).
– Each story written by the customer is assigned a value depending on its
priority.
– The members of the XP team assess each story and assigned a cost
measured in development weeks.
– If a story has more that three weeks to develop the customer is asked to
split it.
– New stories can add any time.
– Customers and XP team work together to decide how to group stories for
next increment.
UCSC - 2014 140

– AS development work proceeds, the customers can add stories, split

stories and eliminate them.
– The XP team then reconsiders all remaining releases and modify its plan
accordingly.

2. Design
– A simple design is preferred
– Design only consider the given stories
– Extra functionality discouraged
– Identify the object oriented classes that are relavant to the current system.
– The output of the design process is a set of CRC ( Class Responsibility
Collaborator) cards.
UCSC - 2014 141

3. Coding
– XP recommends developing a series of unit tests for each of the story –
Once the code is complete, units should be unit tested.
– Pair programming – two people work together at one computer.

4. Testing
– The unit tests that has been created in the coding stage should be
implemented using a framework that can be implemented.
– This enables regression testing
– Integration and validation can occur on a daily basis
– This provides the XP team with a continual indication of the progress and
also raise flags early if things are going wrong.
UCSC - 2014 142

– Acceptance tests are derived from user stories that have been
implemented as parts of the software release.
Rapid Application Development

• Rapid Application Development (RAD) is
both a general term used to refer to
alternatives to the conventional waterfall
model of software development as well as the
name for James Martin's approach to rapid
development.
UCSC - 2014 143

• RAD is an incremental software

development process model that emphasizes
an extremely short development cycle.
• In general, RAD approaches to software
development put less emphasis on planning
tasks and more emphasis on development.
UCSC - 2014 144

• If requirements are well understood and

project scope is constrained, the RAD process
enables a development team to create a ‘fully
functional system’ within very short time
periods (eg. 60 to 90 days)
• In contrast to the waterfall model, which
emphasizes rigorous specification and planning, RAD
approaches emphasize the necessity of adjusting
UCSC - 2014 145

requirements in reaction to knowledge gained as the

project progresses.
• This causes RAD to use prototypes in addition to or
even sometimes in place of design specifications.
RAD approaches also emphasize a flexible process
that can adapt as the project evolves rather than
rigorously defining specifications and plans correctly
from the start.
UCSC - 2014 146

The RAD Model
UCSC - 2014 147

UCSC - 2014 148

Processes in the RAD Model

• Business modeling
– The information flow in a business system considering its
functionality.
• Data Modeling
– The information flow defined as part of the business
modeling phase is refined into a set of data objects that
are needed to support the business
UCSC - 2014 149

• Process Modeling
– The data objects defined in the data modeling phase are
transformed to achieve the information flow necessary to
implement business functions.
Processes in the RAD Model

• Application generation
– RAD assumes the use of 4GL or visual tools to generate the
system using reusable components.
UCSC - 2014 150

• Testing and turnover

– New components must be tested and all interfaces must
be fully exercised
Problems with the RAD model

• RAD requires sufficient human resources to create right
number of RAD teams.
• RAD requires developers and customers who are
committed to the rapid-fire activities necessary to get a
system completed in a much abbreviated time frame.
• If a system cannot be properly modularized, building the
components necessary for RAD will be problematic.
UCSC - 2014 151

• RAD is not applicable when technical risks are high. This

occurs when a new application makes heavy use of new
technology or when the new software requires a high degree
of interoperability with existing computer programs.
2.4.4 SOFTWARE PROTOTYPING
UCSC - 2014 152

Software Prototyping
• The first RAD alternative was developed by
Barry Boehm and was known as the spiral
model.
• Boehm and other subsequent RAD
approaches emphasized developing
prototypes as well as or instead of rigorous
design specifications.
UCSC - 2014 153

• Prototypes had several advantages over

traditional specifications:
Software Prototyping - Advantages
• Risk reduction: A prototype could test some of the
most difficult potential parts of the system early on
in the life-cycle. This can provide valuable
information as to the feasibility of a design and can
prevent the team from pursuing solutions that turn
out to be too complex or time consuming to
UCSC - 2014 154

implement. This benefit of finding problems earlier

in the life-cycle rather than later was a key benefit of
the RAD approach. The earlier a problem can be
found the cheaper it is to address.
• Users are better at using and reacting than at creating
specifications. In the waterfall model it was common
for a user to sign off on a set of requirements but
then when presented with an implemented system
to suddenly realize that a given design lacked some
UCSC - 2014 155

critical features or was too complex. In general most

users give much more useful feedback when they
can experience a prototype of the running system
rather than abstractly define what that system
should be.
• Prototypes can be usable and can evolve into the
completed product. One approach used in some RAD
methodologies was to build the system as a series of
prototypes that evolve from minimal functionality to
UCSC - 2014 156

moderately useful to the final completed system.

The advantage of this besides the two advantages
above was that the users could get useful business
functionality much earlier in the process.
UCSC - 2014 157

2.5 RATIONAL UNIFIED PROCESS

(RUP)
Unified Process
• The Unified Process or Rational Unified
Process (RUP) is a framework for object
oriented software engineering using UML.
UCSC - 2014 158

• This is a use-case driven, architecture

centric, iterative and incremental software
development model.
UCSC - 2014 159

Unified Process
UCSC - 2014 160

UCSC - 2014 161

Unified Process
• Inception Phase:
– The Inception Phase of UP includes both customer
communication and planning activities. By
collaborating with the customer and end-users,
business requirements for the software are
identified, a rough architecture for the system is
proposed, and a plan for the iterative,
incremental nature of the project is developed.
UCSC - 2014 162

Unified Process
• Elaboration Phase:
– The Elaboration Phase encompasses the
planning and modeling activities of the generic
process model. Elaboration refines and expands
the primary use-cases that were developed as
part of the inception phase and expands the
architectural representation to include five
different views of the software – the use-case
model, the analysis model, the design model, the
UCSC - 2014 163

implementation model and the deployment

model.
Unified Process •
Construction Phase:
– The construction phase of the UP is identical to
the construction activity defined in the generic
software process. Using the architectural model
as input, the construction phase develops or
acquires the software components that will make
each usecase operational for end-users. As
UCSC - 2014 164

components are developed unit tests are

designed and executed for each component.
Integration testing and acceptance testing are
carried out using use-cases to derive required test
cases.
Unified Process
• Transition Phase:
– The Transition Phase of the UP encompasses the
later stages of the generic construction activity
and the first part of the generic deployment
UCSC - 2014 165

activity. Software is given to end-users for beta

testing. The software team creates necessary
support information (user manual, installation
manual etc.). At the end of transition phase, the
software increment becomes a usable software
release.
Unified Process
• Production Phase:
– The production phase of the UP coincides with the
deployment activity of the generic process. During
UCSC - 2014 166

this phase, the on going use of the software is

monitored, support for operating environment is
provided, and defect reports and requests for
change are submitted and evaluated.
Unified Process
• It is likely that at the same time the
construction, transition and production
phases are being conducted, work may have
already begun on the next software
UCSC - 2014 167

increment. This means that the unified

process do not occur in a sequence, but rather
with staggered concurrency.
UCSC - 2014 168

Major work products produced for each UP phases
Inception Phase Elaboration Phase
Vision document Use-case model
Initial use-case model Requirements functional, non-functional
Initial risk assessment Analysis model
Project Plan Software architecture
Business model Preliminary design model
Prototypes Revised risk list, revised prototypes
IT3205: Fundamentals of Software Engineering - Introduction
Construction Phase Transition Phase

Design model Delivered software increment
Software components Beta test reports
Integrated software increment General user feedback
Test cases
Test Plan and Procedures
Support documentation
UCSC - 2014 83
2.6 COMPUTER AIDED SOFTWARE

ENGINEERING (CASE)
2.6.1
OVERVIEW OF CASE
APPROACH
Overview of CASE Approach
• Computer Aided Software Engineering
(CASE) is the use of computer-based support
in the software development process.
• Embedding CASE technology in software

process led improvements in software quality
and productivity.
CASE Automated Activities
• The development of graphical system
models
• Understanding a design using a data
dictionary
• Generation of user interfaces

• Program debugging
• The automated translation of programs from
an old version
CASE Limited Factors
• Providing artificial intelligence technology to
support design activities will be unsuccessful.
• Software engineering is a team based

activity that require interactivity among team
members. CASE technology does not support
for this.
2.6.2 CLASSIFICATION OF
CASE TOOLS
CASE Tools
• Tools used to assist the all aspects of the software
development lifecycle are known as CASE Tools.
• Some typical CASE tools are:

– Code generation tools
– Data modeling tools
– UML
– Refactoring tools
– QVT or Model transformation Tools
– Configuration management tools including revision
control
CASE Classification
• Help to understand the types of CASE tools and
their role in supporting software process activities.
• CASE tools can be classified in three perspectives.

1. Functional perspective: Classify according to the

specific function.
2. Process perspective: Classify according to the
process activities that they support.
3. Integration perspective: Classify according to how
they are organized into integrated units that provide
support for one or more process activities.
Functional Classification of CASE Tools

Tool Type Examples

Planning Tools PERT tools, ESTIMATION tools, Spreadsheets
Another Classification Dimension

• CASE tools can be classified according to the
support offered to software process.
– Tools : Support individual process tasks such as

checking consistency of a design etc.
– Workbenches : Support process phases or
activities such as specification etc.
– Environments : Support all or substantial part of

the software process
Tools Workbenches and Environments


Software Engineering 1 Fundamental Introduction PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering 1 Fundamental Introduction PDF

Uploaded by

Copyright:

Available Formats

IT3205: Fundamentals of

8. Software Project Management

6th edition, McGraw-Hill International edition,

• State some professional issues related to

1.2 Software Engineering

1.2.2 Software engineering costs

1.1.1 WHAT IS SOFTWARE?

Example - When you type in words via the

Main Types of Software

– set of one or more programs designed to carry out

System System System

General Purpose Application

Common Software Types

Common Software Types

unlimited software resources that can be accessed by

• Artificial intelligence software:

Common Software Types

They have been characterized by number crunching

• Personal computer software:

– One can change the product easily by re-implementing it

Cost of Hardware vs. Software

Failure curve for hardware (Pressman)

Failure curve for software (Pressman)

• The software should deliver the required

should be maintainable, dependable and

– Software should not make wasteful use of system

– The degree with which software adheres to its specified

• Expenditure on software represents a

• Contain millions of lines of code

Thus, need a systematic process to produce high

The Solution – Software Engineering

The Solution – Software Engineering

• Greater emphasis on development of error

• Software engineers should adopt a systematic

appropriate tools and techniques depending

Use of systematic, engineering approach in all

‘The practical application of scientific knowledge in the

Software Engineering - Definitions

that is reliable and works efficiently on real

‘The application of systematic, disciplined, quantifiable

What makes software special?

• The main difference in software engineering compared to

Members of a software engineering team

– Eg: Real-time software usually requires more

• Normally this is about 40% of the total

Bureau of Labour Statistics (2004)

– for every 6 new systems put into operation, 2 cancelled

Development Failures - Real Examples;

Reportis expected to reveal damning evidence that the

Development Failures - Real Examples;

Swanwick in Hampshire, even though the system doesn’t

Development Failures - Real Examples;

dispatching crews to answer calls. But within hours, during the

Development Failures - Real Examples;

Ariane 5 (June 1996)

Development Failures - Real Examples;

rocket – from a 64 bit format to a 16 bit format = overflow

1.2.3 KEY CHALLENGES FACING

– Developing techniques that lead to faster delivery of

3. The quality of software is not satisfactory

• Software engineering requires a great deal of

• The process of efficiently and effectively