Software Engineering Syllabus

UNIT1

• Introduction: What is software engineering? Software

Development Life Cycle.
• Software Requirements: Functional and Non-functional
requirements, User Requirements, System Requirements,
Interface Specification, Documentation of the software
requirements.
• Software Processes: Process and Project, Component
Software Processes, Process Improvement (CMM).
• Software Development Process Models: Waterfall Model,
Incremental, RAD Model, Evolutionary process models,
Unified process models.
• Agile software development: Agility, Agile process, Scrum,
Extreme Programming.
 Software Engineering Syllabus
UNIT2

• Requirements Engineering Processes: Feasibility study,

Requirements elicitation and analysis, Requirements
Validations, Requirements Management.
• System Models: Models and its types, Context Models,
Behavioural Models, Data Models, Object Models, Structured
Methods.
• User Interface Design: Need of UI design, Design issues, The
UI design Process, User analysis, User Interface Prototyping,
Interface Evaluation.
• Project Management: Software Project Management,
Management activities, Project Planning, Project Scheduling,
Risk Management.
 Software Engineering Syllabus
UNIT3

• Quality Management: Process and Product Quality, Quality

assurance and Standards, Quality Planning, Quality Control,
Software Measurement and Metrics.
• Software Measurement: Size-Oriented Metrics, Function-
Oriented Metrics, Extended Function Point Metrics.
• Software Cost Estimation: Software Productivity, Estimation
Techniques, Algorithmic Cost Modelling, Project Duration and
Staffing.
• Software Testing: Verification and Validation, Introduction to
testing, Principles of testing, Levels of testing, Black-Box
testing, White-Box testing, Test Case design.
 Reference Books

1. Software Engineering, A Practitioner’s

Approach , Roger S. Pressman
2. Software Engineering, Ian Somerville
3. A Concise Introduction to Software
Engineering, Pankaj Jalote
 Unit 1
• Introduction: What is software engineering? Software
Development Life Cycle.
• Software Requirements: Functional and Non-
functional requirements, User Requirements, System
Requirements, Interface Specification, Documentation
of the software requirements.
• Software Processes: Process and Project, Component
Software Processes, Process Improvement (CMM).
• Software Development Process Models: Waterfall
Model, Incremental, RAD Model, Evolutionary process
models, Unified process models.
• Agile software development: Agility, Agile process,
Scrum, Extreme Programming.
 Software & Software Engineering
• Software (s/w)– collection of programs, procedures,
data, rules, and associated documentation
• s/w is not just programs
• s/w is a product
• s/w categories—
• System software and Application software
• System software includes the programs that are
dedicated to managing the computer itself, such as
the operating system, file management utilities,
networking software, drivers, compilers etc
• Application software is a computer program used to
carry out a specific task (word processing s/w,
presentation s/w, database s/w, graphics s/w etc)
• Types of s/w product
• 1) Generic Product
• It is designed and developed by development
organization which is the stand-alone system.
• It sold in the market to anyone.
• Development organization has control.
• Developer can make changes
• It is made according to future updates and it's
for a limited period
• 2) Customized Product
• Custom software is commissioned by the
particular customer.
• The s/w is made according to users need
• Buying organization has control
• Developer can make changes according to
customer need
• It is made according to time, budget and
needs. So anytime customer can update it.
• Software Engineering (SE) is defined as a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance and retirement of
software
• In other words--- goals of s/w engineering—
• Take s/w development closer to science and
engineering and away from ad-hoc approaches for
development whose outcomes are not predictable but
have been used in the past for developing s/w.
• Quality, schedule, budget ---- 3 key terms in SE
• SE is about getting results of required quality within
the schedule and budget.
• SE focuses on ---
• 1. s/w development
• 2. s/w management
• SE is 4 layered technology
• Order of layers from bottom to top in pyramid are---
• 1. quality focus
• Backbone of the product
• Must meet customers specification
• 2. process
• Process forms the base for the management control of the
s/w project and defined the timely development of the s/w
• 3. methods
• It results into the tasks which includes communication,
analysis, design modeling, coding, testing and support,
where actual implementation of these tasks is carried out
• 4. tools
• Used to automate the development process which results
into an efficient implementation of methods according to
the process defined to deliver the quality focused s/w
• In short---

• Software(s/w) is important because it affects

nearly every aspect of our lives and is
spreading widely in our commerce, our
culture, and our everyday activities
• Software engineering(SE) is important
because it enables us to build complex
systems in a timely manner and with high
quality.
 Characteristics of s/w
• 1. Software is developed or engineered; it is
not manufactured
• Although some similarities exist between
software development and hardware
manufacturing, the two activities are
fundamentally different.
• In both activities, high quality is achieved
through good design
• software projects cannot be managed like
manufacturing projects.
• 2. Software doesn’t “wear out.” but it does deteriorate
• hardware exhibits relatively high failure rates early in
its life due to design or manufacturing defects
• These defects are corrected and the failure rate drops
to a steady-state level for some period of time.
• As time passes, the failure rate rises again as hardware
components suffer from the cumulative effects of dust,
vibration, temperature extremes, and many other
environmental maladies
• And hardware begins to wear out.
• This relationship is called bath tub curve….
• Software is not susceptible to the environmental
maladies that cause hardware to wear out.
• Due to undiscovered defects failure rates are high in
the early life of a program
• When these are corrected the curve flattens
• Software doesn’t wear out. But it does deteriorate!
• 3. Although the industry is moving toward
component-based construction, most software
continues to be custom built.
• World is slowly moving towards component
based development (component engineering)
• But still custom built software development is
preferred…
• During hardware manufacturing, it is
assembled using existing ICs, resistors,
capacitors etc. but software is developed
according to the specification of the user
 Attributes of a good s/w
• 1. maintainability---Software should be written in
such a way so that it can evolve to meet the
changing needs of customers. This is a critical
attribute because software change is an inevitable
requirement of a changing business environment.

• 2. dependability and security--Software dependability

includes a range of characteristics including
reliability, security and safety. Dependable
software should not cause physical or economic
damage in the event of system failure. Malicious
users should not be able to access or damage the
system.
• 3.Efficiency --Software should not make
wasteful use of system resources such as
memory and processor cycles. Efficiency
therefore includes responsiveness,
processing time, memory utilisation, etc.

• 4. Acceptability--Software must be
acceptable to the type of users for which it
is designed. This means that it must be
understandable, usable and compatible
with other systems that they use.
 s/w process
• The systematic approach used is SE is called s/w
process
• A s/w process is a sequence of activities that
leads to the production of a s/w product
• 4 fundamental activities common to all s/w
processes—
• 1) s/w specification– requirements and
constraints
• 2)s/w development – designing and programming
• 3)s/w validation –checking to ensure what
customer requires
• 4) s/w evolution– modification due to change and
market requirements
 s/w development life cycle (SDLC)
• SDLC is used to facilitate the development of a large s/w
project in a well defined, systematic and cost-effective way
• SDLC is a multistep iterative process
• SDLC is a generic process framework for software
engineering
• encompasses folowing activities:
• The phases (steps) in SDLC are
• 1. s/w specification
• 2. s/w designing
• 3. s/w coding
• 4. s/w testing
• 5. s/w deployment
• 6. s/w maintenance
• 1. s/w specification
• Communication with customer and stakeholders
(people involved directly or indirectly)
• The intent is to understand stakeholders’ objectives for
the project and to gather requirements that help
define software features and functions.
• Basically knowing all ‘what’ related questions
• Studying the feasibility
• 2. s/w designing
• Planning of a solution of a problem specified in 1st
phase
• Designing is a structure of the s/w to be implemented
• Different types of design documents
• Basically moving from problem domain to solution
domain
• From “what” to “how”…..the problem is solved
• 3. s/w coding –
• Implementation of design
• Writing programs which are easy to read and
understand
• Sometimes design and coding is called as
development
• 4. s/w testing—
• Is intended to show system meets customers
expectations and specification
• Testing Uncovers errors from requirements,
design and coding phases
• In other terms it is validation
• Different types of testing (component, system,
acceptance)
• 5. s/w deployment
• The software is delivered to the customer who
evaluates the delivered product and provides
feedback based on the evaluation
• Installation of the s/w
• 6. s/w maintenance
• s/w evolution
• This is due to changes in requirement,
changes is policy, rules, to remove errors
• Sometimes maintenance cost is higher that
development cost
 Software Requirements
• The requirements for a system are the descriptions of what the
system should do—
• The services that it provides and the constraints on its operation
• Requirements convey the expectations of users from the software
product.
• The requirements can be obvious or hidden, known or unknown,
expected or unexpected from client’s point of view.
• It is foundation for entire project
• They must be clear, correct, complete and well defined
• The requirements can be from two view points (different levels)—
• 1. User requirements
• 2. System requirements

• Different levels of requirements are useful because they

communicate information about the system to different types of
reader
• 1. User requirements are statements of what
services the system is expected to provide to
system users and the constraints under which it
must operate.
• they are in a natural language and diagrams
• 2. System requirements are more detailed
descriptions of the software system’s functions,
services, and operational constraints.
• The system requirements document (sometimes
called a functional specification) should define
exactly what is to be implemented.
• It may be part of the contract between the
system buyer and the software developers.
• The readers of the user requirements are not
usually concerned with how the system will be
implemented and may be managers who are not
interested in the detailed facilities of the system.
• The readers of the system requirements need to
know more precisely what the system will do
because they are concerned with how it will
support the business processes or because they
are involved in the system implementation.
• Software system requirements are often
classified as :
• Functional and non-functional requirements
• Functional and non-functional requirements

• The functional requirement is describing the behavior of the

system as it relates to the system's functionality.
• The non-functional requirement elaborates a performance
characteristic of the system
• In other words–
• Functional requirements - are what you want a system to do.
• Non-functional requirements - which impose constraints on the
design or implementation (such as performance requirements,
security, or reliability). Also known as quality requirements

• To understand the above concept -----

• An example of a functional requirement would be:
• A system must send an email whenever a certain condition is met
(e.g. an order is placed, a customer signs up, etc).
• A related non-functional requirement for the system may be:
• Emails should be sent with a latency of no greater than 12 hours
from such an activity.
 Functional requirements
• They define functions and functionality within and from the software
system
• Define a function of a system or its component, where a function is
described as a specification of behaviour between outputs and inputs
• Functional requirements specify
• Which outputs should be produced from the given inputs.
• Describe the relationship between the input and output of the system.
• Description of all the data inputs and their source, the units of measure,
and the range of valid inputs must be specified for each functional
requirement
• All the operations to be performed on the input data to obtain the output
• should be specified.
• This includes specifying the validity checks on the input and output data,
parameters affected by the operation, and equations or other logical
operations that must be used to transform the inputs into corresponding
outputs.
• For example, if there is a formula for computing the output, it should be
specified but don’t specify any algorithm
• specify the system behaviour in abnormal
situations, like invalid input (which can occur in
many ways) or error during computation.
• The functional requirement must clearly state
what the system should do if such situations
occur.
• It should specify the behaviour of the system for
invalid inputs and invalid outputs.
• Behaviour for situations where the input is valid
but the normal operation cannot be performed
should also be specified. (reservation---valid
input– but booking full)
• So the system behavior for all possible inputs and
all possible system states should be specified
 Non-functional requirements
• They are requirements that are not directly concerned with
the specific services delivered by the system to its users
• They may relate to emergent system properties such as
reliability, response time, and store occupancy
• They define constraints on the system implementation such
as the capabilities of I/O devices or the data
representations used in interfaces with other systems
• Non-functional requirements, such as performance,
security, or availability specify characteristics of the system
as a whole.
• Non-functional requirements are often more critical than
individual functional requirements
• If functional requirements are not fulfilled by system then
user may find some way to work around but
• If non-functional requirements are not fulfilled then whole
system is unusable
• Non-functional requirements arise through
user needs, because of budget constraints,
organizational policies, the need for
interoperability with other software or
hardware systems, or external factors such as
safety regulations or privacy legislation
• Non-functional requirements may come from
required characteristics of the software
(product requirements), the organization
developing the software (organizational
requirements), or from external sources
Classification of Non-Functional
Requirements
• 1. Product Requirements Specify or constrain
the behaviour of the software.
• Examples include performance requirements
on how fast the system must execute and how
much memory it requires, reliability
requirements that set out the acceptable
failure rate, security requirements, and
usability requirements.
• 2. Organizational Requirements are broad
system requirements derived from policies
and procedures in the customer’s and
developer’s organization.
• Examples include (a) Operational Process
Requirements that define how the system will
be used,
• (b)Development Process requirements that
specify the programming language, the
development environment or process
standards to be used, and
• (c) Environmental Requirements that specify
the operating environment of the system
• 3. External Requirements covers all
requirements that are derived from factors
external to the system and its development
process.
• These may include
• (a) Regulatory Requirements that set out what
must be done for the system to be approved
for use by a regulator, such as a central bank;
(b) Legislative Requirements that must be
followed to ensure that the system operates
within the law
• (c) Ethical Requirements that ensure that the
system will be acceptable to its users and the
general public
• Whenever possible, write non-functional
requirements quantitatively so that they can be
objectively tested.
• Metrics can be used to specify non-functional
system properties. (beyond the scope)
• You can measure these characteristics when the
system is being tested to check whether or not
the system has met its nonfunctional
requirements
• Many times it difficult to translate their goals into
measurable requirements.
• For some goals, such as maintainability, there are
no metrics that can be used
• Some typical non-functional requirements are:

• Performance – for example Response Time,

Throughput, Utilization, Static Volumetric
• Scalability
• Capacity
• Availability
• Reliability
• Recoverability
• Maintainability
• Serviceability
• Security
• Regulatory
• Manageability
• Usability
• Interoperability
 Interface Specification
• User Interface requirements
• UI is an important part of any software or hardware or hybrid
system.
• A software is widely accepted if it is ---
• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

• User acceptance majorly depends upon how user can use the
software.
• UI is the only way for users to perceive the system.
• A well performing software system must also be equipped with
attractive, clear, consistent and responsive user interface.
• Otherwise the functionalities of software system can not be used in
convenient way.
• A system is said be good if it provides means to use it efficiently.
• User interface requirements are briefly mentioned
below –

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of colour and texture.
• Provide help information
• User centric approach
• Group based view settings.
 Documentation of the s/w
requirements
• The software requirements document is the official statement of
what is required of the system developers.
• Should include both a definition of user requirements and a
specification of the system requirements.
• It is NOT a design document. As far as possible, it should set of
WHAT the system should do rather than HOW it should do it.
• It is also termed as Software Requirements Specification (SRS)
document

• Correct and complete are two most important characteristics of SRS

• correctness ensures that which is specified is done correctly,
completeness ensures that everything is indeed specified.
• Correctness is an easier property to establish than completeness as
it basically involves examining each requirement to make sure it
represents the user requirement
 Structure of SRS
1. Introduction 3. System Features
1.1 Purpose 3.1 System Feature 1
1.2 Document Conventions 3.2 System Feature 2 (and so on)
1.3 Intended Audience and Reading 4. External Interface Requirements
Suggestions 4.1 User Interfaces
1.4 Project Scope 4.2 Hardware Interfaces
1.5 References 4.3 Software Interfaces
2. Overall Description 4.4 Communications Interfaces
2.1 Product Perspective 5. Other Nonfunctional Requirements
2.2 Product Features 5.1 Performance Requirements
2.3 User Classes and Characteristics 5.2 Safety Requirements
2.4 Operating Environment 5.3 Security Requirements
2.5 Design and Implementation 5.4 Software Quality Attributes
Constraints 6. Other Requirements
2.6 User Documentation
2.7 Assumptions and Dependencies
 Importance (need) of SRS
• 1. An SRS establishes the basis for agreement
between the client and the supplier on what
the software product will do
• 2. An SRS provides a reference for validation
of the final product.
• 3. A high-quality SRS is a prerequisite to high-
quality software
• 4. A high quality SRS reduces the development
cost.
• (explain each point in answer)
 S/W processes
• A software process is a set of activities, together with
ordering constraints among them, such that if the
activities are performed properly and in accordance
with the ordering constraints, the desired result is
produced
• The process that deals with the technical and
management issues of software development is called
a software process
• Different activities are performed by different people
• So software process is viewed as consisting of many
component processes, each consisting of a certain type
of activity
• Each component process has different objective but
they cooperate with each other to achieve SE goals
 Process and project
• A successful project is the one that satisfies
the expectations on all the three goals of cost,
schedule, and quality
• A project's process specification defines the
tasks the project should perform,
• and the order in which they should be done.
• The actual process exists when the project is
actually executed.
• Often the actual process being followed in the
project may be very different from the
project’s process specification.
 Process models
• A process model specifies a general process, usually as
a set of stages in which a project should be divided, the
order in which the stages should be executed, and any
other constraints and conditions on the execution of
stages
• A process is a means to reach the goals of high quality,
low cost, and low cycle time, and
• A process model provides generic guidelines for
developing a suitable process for a project.
• What we need to understand is that a project’s process
may be obtained from a process model, by tailoring the
process model to suit the project needs.
• a process specifies the steps, the project executes
these steps, and during the course of execution
products are produced.
 Component software processes
• Two major components in a software process—
• 1. a development process
• 2. project management process

• The development process specifies the

development and quality assurance activities that
need to be performed
• The management process specifies how to plan
and control these activities so that cost, schedule,
quality, and other objectives are met
• As development processes generally do not focus on
evolution and changes, to handle them another
process called software configuration control process,
is often used.
• The objective of this component process is to primarily
deal with managing change, so that the integrity of the
products is not violated despite changes.
• Sometimes, changes in requirements may be handled
separately by a requirements change management
process.
• These three constituent processes focus on the
projects and the products and can be considered as
comprising the product engineering processes, as their
main objective is to produce the desired product
• The whole process of understanding the current
process, analyzing its properties, determining how to
improve, and then affecting the improvement is dealt
with by the process management process.
Relationship between major
component processes
• In a typical project, development activities are
performed by programmers, designers,
testers, etc.
• The project management process activities are
performed by the project management
• Configuration control process activities are
performed by a group generally called the
configuration controller
• The process management process activities
are performed by the software engineering
process group (SEPG)
 S/w development process models
• Each process model represents a process from
a particular perspective
• Each process model also prescribes a process
flow (also called a work flow)this means the
manner in which the process elements are
interrelated to one another
• There are many process models
• These models accommodate basic
activities(specification, design, coding,
evolution) but each model applies a different
emphasis to these activities
• Process models are based on---
• 1) Plan driven development
– all of the process activities are planned in advance and progress is
measured against this plan
• 2) Incremental and iterative (evolutionary) development
– Specification, development and validation are interleaved
– S/W developed in small increments and then integrated
– At each iteration, design modifications are made and new functional
capabilities are added.
– The basic idea behind this method is to develop a system through
repeated cycles (iterative) and in smaller portions at a time
(incremental).
• 3) Reuse oriented software engineering
– The system is assembled from existing components
• 4) Agile development --- planning is incremental and it is easier to
change the process to reflect changing customer requirements
(covered later)

• In practice, most large systems are developed using a process that

incorporates elements from all of these models
S/W development process models—
1. Waterfall Model
2. Incremental Model
3. RAD Model
4. Evolutionary Process Models (Iterative
Model, Incremental Model, Spiral Model)
5. Unified Process Models (RUP)
 The Waterfall model
• Based on plan driven process approach
• So we must plan and schedule all of the process activities before
starting work on them.
• Called as classic life cycle model or linear model
• The principal stages of the waterfall model directly reflect the
fundamental development activities: ( like SDLC)

• 1. Requirements analysis and definition The system’s services,

constraints, and goals are established by consultation with system
users. They are then defined in detail and serve as a system
specification.

• 2. System and software design The systems design process

allocates the requirements to either hardware or software systems
by establishing an overall system architecture. Software design
involves identifying and describing the fundamental software
system abstractions and their relationships.
• 3. Implementation and unit testing During this stage,
the software design is realized as a set of programs or
program units. Unit testing involves verifying that each
unit meets its specification.
• 4. Integration and system testing The individual
program units or programs are integrated and tested as
a complete system to ensure that the software
requirements have been met. After testing, the
software system is delivered to the customer.
• 5. Operation and maintenance Normally this is the
longest life cycle phase. The system is installed and put
into practical use. Maintenance involves correcting
errors which were not discovered in earlier stages of
the life cycle, improving the implementation of system
units and enhancing the system’s services as new
requirements are discovered.
• The result of each phase is one or more
documents that are approved
• The following phase should not start until the
previous phase has finished.
• In practice, these stages overlap and feed
information to each other.
• During design, problems with requirements are
identified.
• During coding, design problems are found and so
on.
• Feedback from one phase is given to another
phase
• Documents produced in each phase may then
have to be modified to reflect the changes made.
• Model is suitable for simple projects where
requirements are well known
• Following documents are produced during
waterfall model…
– Requirements document
– Project plan
– Design documents (architecture, system, detailed)
– Test plan and test reports
– Final code
– Software manuals (e.g., user, installation)
 Advantages
• Simple to implement and understand
• Conceptually straightforward
• Divides large task into number of phases
• Similar to SDLC
 Disadvantages
• It assumes that requirements are frozen before
the design begins, so not suitable for new
systems or for systems where requirements are
not well known
• Freezing requirement means choosing hardware
also as it is part of SRS
• This means final system may use obsolete
hardware technology
• It follows big-bang approach, means either a
success or a failure.. Will come to know at the
end..as s/w is delivered in one shot at the end
• Heavy documentation required as after each
phase formal documentation (work product) is
required
 The Prototyping model
• Suitable when requirements are not completely known
• Complex project
• Prototype is a working model of a s/w with limited
functionality
• It helps to understand the requirements which are not
known earlier
• There are two approaches—
• 1. Throwaway 2. Evolutionary

• Throwaway prototype---
– A dummy s/w
– Many iterations of prototype
– After each prototype– feedback from customer
– Prototyping is done till Unknown requirements are now known
– Then discard prototype
– Build s/w from scratch
Throwaway prototype
• Evolutionary ----
• Building actual functional prototypes with
minimal functionality in the beginning.
• The prototype developed forms the heart of
the future prototypes on top of which the
entire system is built.
• By using evolutionary prototyping, the well-
understood requirements are included in the
prototype and the requirements are added as
and when they are understood.
• Advantages–
– no frozen requirements like waterfall model
– No big bang approach
– Customers feedback
– Reduces time and cost as defects detected earlier

• problems–
– while developing prototype may be wrong choice of
os, algorithm, programming language used
– Later developer is comfortable with these choices and
may forget reasons why these choices are not
appropriate
– The effort invested in building prototypes may be too
much if it is not monitored properly
 The Incremental model
• Suitable for projects where basic requirements are
known, wants to meet early deadline and staff is not
sufficient, for this situatin waterfall model not suitable
• Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
• User requirements are prioritised and the highest
priority requirements are included in early increments.
• The incremental model delivers a series of releases,
called increments, that provide progressively more
functionality for the customer as each increment is
delivered
• word-processing software developed using the
incremental paradigm might deliver basic file
management, editing, and document production
functions in the first increment
• More sophisticated editing and document
production capabilities in the second increment
• Spelling and grammar checking in the third
increment
• Advanced page layout capability in the fourth
increment.
• In incremental model, the first increment is often
a core product
• The incremental model focuses on the delivery of
an operational product with each increment
• Suitable for large projects
• Advantages—
– Results are obtained early and periodically.
– Parallel development can be planned
– Testing and debugging during smaller iteration is
easy
– Customer evaluation and feedback possible after
every increment
– Lower risk of overall project failure
• Problems—
– Not suitable for changing requirements
– More management skills, attention is required
– Not suitable for smaller projects
– Defining increments may require definition of the
complete system.
 The Spiral model
• Developed by Boehm
• Is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of
the waterfall model
• software is developed in a series of evolutionary releases
• During later iterations more sophisticated version of s/w is
developed
• Model handles risk analysis (risk driven process framework)
• The software process is represented as a spiral, rather than a
sequence of activities with some backtracking from one activity to
another.

• Each loop in the spiral represents a phase of the software process

• So, the innermost loop might be concerned with system feasibility,
the next loop with requirements definition, the next loop with
system design, and so on.
 Spiral model sectors
• Objective setting
– Specific objectives for the phase are identified.
• Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the
key risks.
• Development and validation
– A development model for the system is chosen which can
be any of the generic models.
• Planning
– The project is reviewed and the next phase of the spiral is
planned.
• Spiral model has been very influential in helping people
think about iteration in software processes and
introducing the risk-driven approach to development
The Rational Unified Process (RUP)
• RUP is described from three perspectives:
• 1. A dynamic perspective, which shows the
phases of the model over time.
• 2. A static perspective, which shows the process
activities that are enacted.
• 3. A practice perspective, which suggests good
practices to be used during the process
• It is a phased model that identifies four discrete
phases in the software process
• The waterfall model phases are equated with
process activities but,
• The phases in the RUP are more closely related to
business rather than technical concerns
RUP Phases (Dynamic perspective)
• 1. Inception
• Establishes a business case for the system.
• Identify all external entities (people and systems) that
will interact with the system and define these
interactions and using this assess the contribution that
the system makes to the business.
• If this contribution is minor, then the project may be
cancelled after this phase.
• 2. Elaboration
• Develop an understanding of the problem domain,
establish an architectural framework for the system,
develop the project plan, and identify key project risks.
• On completion of this phase a development plan is
ready
• 3. Construction
• The construction phase involves system design,
programming, and testing.
• On completion of this phase, you should have a
working software system and associated
documentation that is ready for delivery to users.
• 4. Transition
• Deploy the system in its operating environment.
• On completion of this phase, you should have a
documented software system that is working
correctly in its operational environment.
 RUP iteration
• In-phase iteration
– Each phase is iterative with results developed
incrementally.
• Cross-phase iteration
– As shown by the loop in the RUP model, the
whole set of phases may be enacted
incrementally.
 Static perspective
• Focuses on the activities that take place during the
development process.
• These are called workflows in the RUP description.
• There are six core process workflows identified in the
process and three core supporting workflows.
• The advantage in presenting dynamic and static views
is that phases of the development process are not
associated with specific workflows.
• Some or the other workflow is active at all stages of
the development process
• In other way, phases of development process
(inception etc..) are not associated with specific
workflow
• Workflow description is associated with UML models
 Static workflows
• 1) Business modelling
• 2) Requirements
• 3) Analysis and design
• 4) Implementation
• 5) Testing
• 6) Deployment
• 7) Configuration and change management
• 9) Project management
• 10) Environment
• 1 to 6 are process workflow
• 7 to 9 are supporting workflow
 Practice perspective
• Describes good software engineering practices
that are recommended for use in systems
development.
• Six fundamental best practices are recommended
• 1) Develop software iteratively
– Plan increments based on customer priorities and
deliver highest priority increments first.
• 2) Manage requirements
– Explicitly document customer requirements and keep
track of changes to these requirements.
• 3) Use component-based architectures
– Organize the system architecture as a set of reusable
components
• 4) Visually model software
– Use graphical UML models to present static and
dynamic views of the software.
• 5) Verify software quality
– Ensure that the software meet’s organizational
quality standards.
• 6) Control changes to software
– Manage software changes using a change
management system and configuration
management tools.
 Key points of RUP
• Modern process model
• Separation of phases and workflows
• Phases are dynamic and have goals
• Workflows are static
• Deployment at user’s environment
• Workflows are technical activities– not
associated with a single phase– may be used
throughout the development to achieve goal
of the phase
 The RAD model
• RAD--Rapid Application Development
• Model is based on prototyping and iterative development
with no specific planning involved
• RAD focuses on gathering customer requirements through
workshops , early testing of the prototypes by the
customer using iterative concept, reuse of the existing
prototypes (components), continuous integration and
rapid delivery
• RAD features--
• Minimal planning for rapid development of reusable
prototype (not throwaway)
• The functional modules are developed in parallel as
prototypes and are integrated to make the complete
product for faster product delivery
• Small teams comprising of developers, domain experts,
customer representatives
 Phases of RAD (SDLC RAD)
• RAD model distributes the analysis, design, build and test phases into a series of
short, iterative development cycles.
• Following are the various phases of the RAD Model
• 1. Business Modeling– On basis of the flow of information and distribution
between various business channels, the product is designed

• 2. Data Modeling-- The information collected from business modeling is refined

into a set of data objects that are significant for the business

• 3. Process Modeling-- The data object that is declared in the data modeling phase
is transformed to achieve the information flow necessary to implement a business
function
• Process descriptions for adding, deleting, retrieving or modifying a data object are
given

• 4. Application generation-- Automated tools are used for the construction of the
software, to convert process and data models into prototypes

• 5. Testing and turnover-- testing time is reduced in the RAD model as the
prototypes are independently tested during every iteration
• The data flow and the interfaces between all the components need to be
thoroughly tested with complete test coverage
• RAD focuses on iterative and incremental delivery of
working models to the customer.
• This results in rapid delivery to the customer and
customer involvement during the complete
development cycle of product reducing the risk of non-
conformance with the actual user requirements
• RAD should be used only when a system can be
modularized to be delivered in an incremental manner
• RAD should be used if there is a high availability of
designers for modelling
• RAD should be used only if the budget permits use of
automated code generating tools.
• RAD should be used where the requirements change
during the project and working prototypes are to be
presented to customer in small iterations of 2-3
months
 The Timeboxing model
• In this model iterative development is done in a set of fixed
duration time boxes.
• That is, in each iteration, functionality developed is what can be
“fit” into the time box.
• Each time box is divided into stages of approximately equal duration
• The work of each stage is done by a dedicated team.
• In general, let us consider a time box with duration T and consisting
of n stages – S1, S2, …, Sn.
• The team of each stage has T/n time available to finish their task for
a time box, that is, the duration of each stage is T/n
• Multiple iterations are executed concurrently by employing
pipelining – as the first stage of the first time box completes, the
team for that stage starts its activities for the next time box, while
the team for the next stage carries on with the execution of the first
time box

• The first output comes after time T, each subsequent delivery

happens after T/n time interval, delivering software that has been
developed in time T.
• With a time box of three stages, the project proceeds
as follows--------
• When the requirement team has finished requirements
for timebox-1, the requirements are given to the build-
team for building the software.
• Meanwhile, the requirement team goes on and starts
preparing the requirements for timebox-2.
• When the build for the timebox-1 is completed, the
code is handed over to the deployment team, and the
build team moves on to build code for requirements
for timebox-2, and the requirements team moves on to
doing requirements for timebox-3
• With a three-stage time box, at most three iterations
can be concurrently in progress.
• If the time box is of size T days, then the first software
delivery will occur after T days.
• The subsequent deliveries, however, will take place
after every T/3 days
Comparison between models
 Agile S/W development
• Rapid development and delivery is now often the
most important requirement for software
systems
• Businesses operate in a fast –changing
requirement and it is practically impossible to
produce a set of stable software requirements
• Software has to evolve quickly to reflect changing
business needs
• Specification, design and implementation are
inter-leaved
• Agile method is one of the rapid s/w
development technique
 Agile methods
• Focus on the code rather than the design
• Are based on an iterative approach to software
development
• Are intended to deliver working software
quickly and evolve this quickly to meet
changing requirements
• The aim of agile methods is to reduce
overheads in the software process and to
be able to respond quickly to changing
requirements without excessive rework.
 The principles of agile methods
• 1. Customer involvement
• Customers should be closely involved throughout the
development process. Their role is provided and
prioritize new system requirements and to evaluate the
iterations of the system.
• 2. Incremental delivery
• The software is developed in increments with the
customer specifying the requirements to be included in
each increment.
• 3. People not process
• The skills of the development team should be
recognized and exploited. Team members should be
left to develop their own ways of working without
prescriptive processes.
• 4. Embrace change
• Expect the system requirements to change
and so design the system to accommodate
these changes.
• 5. Maintain simplicity
• Focus on simplicity in both the software being
developed and in the development process.
Wherever possible, actively work to eliminate
complexity from the system.
 Problems with agile methods
• It can be difficult to keep the interest of
customers who are involved in the process.
• Prioritizing changes can be difficult where
there are multiple stakeholders.
• Maintaining simplicity requires extra work.
 Plan-driven and Agile development
• Most software projects include practices from plan-driven and agile
approaches.
• Many companies who claim to have used agile methods have adopted
some agile practices and have integrated these with their plan-driven
processes.

• Plan-driven development
– A plan-driven approach to software engineering is based around separate
development stages with the outputs to be produced at each of these stages
planned in advance.
– Iteration occurs within activities.
– The outputs from one stage are used as a basis for planning the following
process activity

• Agile development
– Specification, design, implementation and testing are inter-leaved and the
outputs from the development process are decided through a process of
negotiation during the software development process
– Iteration occurs across activities
– So the requirements and the design are developed together, rather than
separately.
• Plan driven and Agile specification
 Extreme programming (XP)
• The best-known and most widely used agile
method.
• Extreme Programming (XP) takes an ‘extreme’
approach to iterative development.
– New versions may be built several times per day;
– Increments are delivered to customers every 2
weeks;
– All tests must be run for every build and the build
is only accepted if tests run successfully
 XP principles
• Incremental development is supported through
small, frequent system releases.
• Customer involvement means full-time customer
engagement with the team.
• People not process through pair programming,
collective ownership and a process that avoids
long working hours.
• Change supported through regular system
releases.
• Maintaining simplicity through constant
refactoring of code
 Requirements scenario
• In XP, a customer or user is part of the XP team
and is responsible for making decisions on
requirements.
• User requirements are expressed as scenarios or
user stories.
• These are written on cards and the development
team break them down into implementation
tasks. These tasks are the basis of schedule and
cost estimates.
• The customer chooses the stories for inclusion in
the next release based on their priorities and the
schedule estimates
The XP release cycle
 XP practices
• 1. Incremental planning
• Requirements are recorded on story cards and the
stories to be included in a release are determined by
the time available and their relative priority. The
developers break these stories into development
‘Tasks’.
• 2. Small releases
• The minimal useful set of functionality that provides
business value is developed first. Releases of the
system are frequent and incrementally add
functionality to the first release.
• 3. Simple design
• Enough design is carried out to meet the current
requirements and no more.
• 4. Test-first development
• An automated unit test framework is used to write
tests for a new piece of functionality before that
functionality itself is implemented.
• 5. Refactoring
• All developers are expected to refactor the code
continuously as soon as possible code improvements
are found. This keeps the code simple and
maintainable.
• 6. Pair programming
• Developers work in pairs, checking each other’s work
and providing the support to always do a good job.
• 7. Collective ownership
• The pairs of developers work on all areas of the system,
so that no islands of expertise develop and all the
developers take responsibility for all of the code.
Anyone can change anything.
• 8. Continuous integration
• As soon as the work on a task is complete, it is
integrated into the whole system. After any such
integration, all the unit tests in the system must pass.
• 9. Sustainable pace
• Large amounts of overtime are not considered
acceptable as the net effect is often to reduce code
quality and medium term productivity
• 10. On-site customer
• A representative of the end-user of the system (the
customer) should be available full time for the use of
the XP team. In an extreme programming process, the
customer is a member of the development team and is
responsible for bringing system requirements to the
team for implementation.
 Scrum
• The Scrum approach is a general agile method
but its focus is on managing iterative
development rather than specific agile practices.
• There are three phases in Scrum.
– The initial phase is an outline planning phase where
you establish the general objectives for the project
and design the software architecture.
– This is followed by a series of sprint cycles, where
each cycle develops an increment of the system.
– The project closure phase wraps up the project,
completes required documentation such as system
help frames and user manuals and assesses the
lessons learned from the project
The Scrum process
 The sprint cycle
• Sprints are fixed length, normally 2–4 weeks. They correspond to the
development of a release of the system in XP.

• The starting point for planning is the product backlog, which is the list of
work to be done on the project.

• The selection phase involves all of the project team who work with the
customer to select the features and functionality to be developed during
the sprint.

• Once these are agreed, the team organize themselves to develop the
software. During this stage the team is isolated from the customer and the
organization, with all communications channelled through the so-called
‘Scrum master’.

• The role of the Scrum master is to protect the development team from
external distractions.

• At the end of the sprint, the work done is reviewed and presented to
stakeholders. The next sprint cycle then begins.
 Teamwork in Scrum
• The ‘Scrum master’ is a facilitator who arranges
daily meetings, tracks the backlog of work to be
done, records decisions, measures progress
against the backlog and communicates with
customers and management outside of the team.
• The whole team attends short daily meetings
where all team members share information,
describe their progress since the last meeting,
problems that have arisen and what is planned
for the following day.
– This means that everyone on the team knows what is
going on and, if problems arise, can re-plan short-
term work to cope with them.
 Scrum benefits
• The product is broken down into a set of
manageable and understandable chunks.
• Unstable requirements do not hold up progress.
• The whole team have visibility of everything and
consequently team communication is improved.
• Customers see on-time delivery of increments
and gain feedback on how the product works.
• Trust between customers and developers is
established and a positive culture is created in
which everyone expects the project to succeed