Software Engineering

CS1502

Dr. Ramachandra Reddy

Text Books

• Roger S. Pressman, Software Engineering – A Practitioner‟s Approach,

Seventh Edition, Mc Graw-Hill International Edition, 2010.

• Ian Sommerville, Software Engineering, 9th Edition, Pearson Education

Asia, 2011.

• Rajib Mall, Fundamentals of Software Engineering, Prentice Hall India.

• Pankaj Jalote, An Integrated Approach to Software Engineering, Narosa

Publishing House.
 WELL-KNOWN SOFTWAREENGINEERING FAILURES
ariane 5 rocket

• int counter =
MAX_INT;counter++;

• Integer Over flow

Y2K (1999-2000)
• Cost–$500,000,000,000
• Disaster
• Businesses spent billions on programmers to fix a glitch in
old software
• Cause
• To save computer storage space, old software systems
often stored the years as two digit numbers
• The software interpreted “00” to mean 1900 rather than
2000
• All sorts of bugs were thought likely
What is Software ?

• A program is set of instructions.

• Software can define as:

• Set of Instructions/ programs – executed provide desire features, function &
performance.
• Documentation
• Operation Manuals
Software
• Documentation manuals:
• Requirement Analysis
• Formal specification, context-diagram, DFD
• Software Design
• Flow charts, ER
• Implementation
• Source code, Cross Reference listing
• Testing
• Test data, Test results
• Operation Manuals :
• User manuals
• System overview, Beginners user tutorial, reference guide, reference guide
• Operation manuals
• Installation guide, System administration guide
 Software Product Vs Process

• Software Product : what is delivered to the customer. It may include

source code, specification document, manuals, documentation, etc.

• Software products may be developed for a particular customer or

may be developed for a general market

• Software Process: Process is the way in which produce the software.

Software Application Domains

• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product line software
• Web applications
• Artificial intelligence software
Software Application Domains
• System Software:
• System software is a collection of programs written to service other
programs.
• It is characterized by heavy interaction with computer hardware; heavy
usage by multiple users; concurrent operation that requires scheduling,
resource sharing, and sophisticated process management; complex data
structures; and multiple external interfaces.
• Ex. Compilers, operating system, drivers etc.
• Business Software :
• Application software consists of standalone programs that solve a specific
business need.
• Application software is used to control the business function in real-time.
• Engineering /Scientific software:
• Characterized by "number crunching" algorithms.
• Applications range from astronomy to volcano logy, from automotive stress
analysis to space shuttle orbital dynamics, and from molecular biology to
automated manufacturing.
• Ex. Computer Aided Design (CAD), system stimulation etc.
 Software Application Domains
• Embedded Software:
• It resides in read-only memory and is used to control products and systems
• Embedded software can perform limited and esoteric functions.
• Ex. keypad control for a microwave oven.
• Personal Computer software:
• Designed to provide a specific capability for use by many different customers, product line software can
focus on a limited and esoteric marketplace.
• Ex. Word processing, spreadsheet, CG, multimedia, etc.
• Web Applications:
• Web apps can be little more than a set of linked hypertext files.
• It evolving into sophisticated computing environments that not only provide standalone features, functions
but also integrated with corporate database and business applications.
• Artificial Intelligence software
• AI software makes use of non-numerical algorithms to solve complex problems that are not amenable to
computation or straightforward analysis
• Ex. Robotics, expert system, game playing, pattern Recognition, ANN etc.
Software Applications – New
• Open world computing—pervasive, distributed computing
• Ubiquitous computing—wireless networks
• Netsourcing—the Web as a computing engine
• Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)
• And also …
• Data mining
• Grid computing
• Cognitive machines
• Software for nanotechnologies
Hardware vs. Software

Hardware Software

□ Manufactured □ Developed/ engineered

□ wear out □ deteriorate
□ Built using components □ Custom built
□ Relatively simple □ Complex
 Manufacturing vs. Development

• Once a hardware product has been manufactured, it is difficult or

impossible to modify. In contrast, software products are routinely
modified and upgraded.

• In hardware, hiring more people allows you to accomplish more work,

but the same does not necessarily hold true in software engineering.

• Unlike hardware, software costs are concentrated in design rather

than production.
Failure curve for Hardware
Failure curve for Software

When a hardware component wears out, it is replaced by a spare part.

There are no software spare parts. Every software failure indicates an error in design or in
the process through which design was translated into machine executable code.
Software characteristics

• Software is developed or engineered; it is not manufactured.

• Software does not “wear out” but it does deteriorate.

• Software continues to be custom built, as industry is moving toward

component based construction.

• Reusability of components.

• Software is flexible.
Software Myths
• Software is easy to change.
• Software provide greater reliability than the devices they
replace.
• Testing software can remove all the errors.
• Reusing the software increases the safety.
• Software can work right the first time.
• Software can be designed thoroughly enough to avoid most
integration problems.
• Software with more features is better software.
• Addition of more software engineers will make up the delay.
• Aim to develop working programs.
What are the attributes of good software?

The software should deliver the required functionality

and performance to the user and should be
maintainable, dependable and usable
• Maintainability
• Software must evolve to meet changing needs
• Dependability
• Software must be trustworthy
• Efficiency
• Software should not make wasteful use of system resources
• Usability
• Software must be usable by the users for which it was designed
Engineering

• “The systematic and regular application of scientific and mathematical knowledge to

the design, construction, and operation of machines, systems, and so on of practical use
and, hence, of economic value.

• Particular characteristic of engineers is that they take seriously their responsibility for
correctness, suitability, and safety of the results of their efforts.
• In this regard they consider themselves to be responsible to their customer (including
their employers where relevant), to the users of their machines and systems, and to the
public at large.”
Engineering
Software Engineering
• Software engineering : the systematic use of many
disciplines, tools, and resources for the practical
application.
• This is a broad definition which includes everything except
hardware.
• According to Fritz Bauer :Software engineering is the
establishment and use of sound engineering principles in
order to obtain economically software that is reliable and
works efficiently on real machines.

• According to IEEE : Software Engineering is a a systematic,

disciplined, quantifiable approach to the development,
operation, and maintenance of software.
What is the difference between
software engineering and computer
science?
Computer Science Software Engineering
is concerned with
theory the practicalities of developing
fundamentals delivering useful software

Algorithms, date structures, SE deals with practical problems in

complexity theory, numerical methods complex software products

Computer science theories are currently insufficient to act as

a complete underpinning for software engineering, BUT it is
a foundation for practical aspects of software engineering
Software Engineering Vs System
Engineering
• Software engineering is part of System engineering
• System engineering is concerned with all aspects of
computer-based systems development including
• hardware,
• software and
• process engineering
• System engineers are involved in
system specification,
architectural design,
integration and deployment
Why need Software Engineering?

• It allows you to improve the quality of the software

products.
• To increase productivity & Provide job satisfaction to
software professionals.
• It will enable you to control software schedules and to plan
effectively.
• It helps to reduce the cost of software development.
• Allow you to meet the customers' needs and requirements.
• It helps you to support the engineers' activities
systematically and efficiently.
SOFTWARE ENGINEERING: A
LAYERED TECHNOLOGY
Layered Technology
A quality Focus
• Every organization is rest on its commitment to quality.
• Total quality management, Six Sigma, or similar continuous
improvement culture and the culture ultimately leads to
development of increasingly more effective approaches to software
engineering.
• The bedrock that supports software engineering is a quality focus.
Process:
• It’s a foundation layer for software engineering.
• It’s define framework for a set of key process areas (KRA) for
effectively manage and deliver quality software in a cost effective
manner
• The processes define the tasks to be performed and the order in
which they are to be performed
Layered Technology
Methods:
• It provide the technical how-to's for building software.
• Methods encompass a broad array of tasks that include
requirements analysis, design, program construction, testing, and
support.
• There could be more than one technique to perform a task and
different techniques could be used in different situations.
Tools:
• Provide automated or semi-automated support for the process,
methods and quality control.
• When tools are integrated so that information created by one tool
can be used by another, a system for the support of software
development, called computer-aided software engineering (CASE)
What is a software process?
A set of activities whose goal is the development
or evolution of software

Generic activities in all software processes are:

• Communication
• Planning
• Modeling
• Construction
• Testing
• Deployment
Process framework

Why process :
• A process defines who is doing what, when and how to reach a certain goal.
• To build complete software process.
• Identified a small number of framework activities that are applicable to all
software projects, regardless of their size or complexity.
• It encompasses a set of umbrella activities that are applicable across the entire
software process.
Software Process
A software process – as a framework for the tasks that are required to build
high-quality software.
Process Framework

•Each framework activities

is populated by a set for
software engineering
actions – a collection of
related tasks.
• Each action has
individual work task.
Generic Process Framework Activities
• Communication:
• Heavy communication with customers, stakeholders, team members
• Encompasses requirements gathering and related activities
• Planning:
• Workflow that is to follow
• Software project plan- Describe technical task, likely risk, resources will
require, work products to be produced and a work schedule.
• Modeling:
• Help developer and customer to understand requirements (Analysis of
requirements) & Design of software
• Construction
• Code generation: either manual or automated or both
• Testing – to uncover error in the code.
• Deployment:
• Delivery to the customer for evaluation
• Customer provide feedback
Umbrella Activities
• Software project tracking and control
• Assessing progress against the project plan.
• Take adequate action to maintain schedule.
• Formal technical reviews
• Assessing software work products in an effort to uncover and remove errors before goes into next
action or activity.
• Software quality assurance
• Define and conducts the activities required to ensure software quality.
• Software configuration management
• Manages the effects of change.
• Document preparation and production
• Help to create work products such as models, documents, logs, form and list.
• Reusability management
• Define criteria for work product reuse
• Mechanisms to achieve reusable components.
• Measurement
• Define and collects process, project, and product measures
• Assist the team in delivering software that meets customer’s needs.
• Risk management
• Assesses risks that may effect that outcome of project or quality of product (i.e. software)
Software Process

• Reasons why it is difficult to improve the process

• No enough time
• Lack of knowledge
• Wrong motivations
• Insufficient commitment
Software Process Improvement
A Generic Process Model
Process Flow
Software process model
• Process models prescribe a distinct set of activities, actions,
tasks, milestones, and work products required to engineer
high quality software.
• Process models are not perfect, but provide roadmap for
software engineering work.
• Software models provide stability, control, and organization to
a process that if not managed can easily get out of control
• Software process models are adapted to meet the needs of
software engineers and managers for a specific project.
Build and Fix Model
Build and Fix Model
The earlier approach
• Product is constructed without specification or any attempt at design.
• developers simply build a product that is reworked as many times as necessary to satisfy the
client.
• model may work for small projects but is totally unsatisfactory for products of any reasonable size.
• Maintenance is high.
• Source of difficulties and deficiencies
• impossible to predict
• impossible to manage
Prescriptive Process Models
• Prescriptive process models advocate an orderly approach to software
engineering
• Organize framework activities in a certain order
• Process framework activity with set of software engineering actions.
• Each action in terms of a task set that identifies the work to be accomplished
to meet the goals.
• The resultant process model should be adapted to accommodate the nature
of the specific project, people doing the work, and the work environment.
• Software engineer choose process framework that includes activities like;
• Communication
• Planning
• Modeling
• Construction
• Deployment
The Waterfall Model/Classical Model/
Linear Model
Waterfall Model or Classic Life Cycle
• Requirement Analysis and Definition: What - The systems services, constraints and goals are
defined by customers with system users.
• Scheduling tracking -
• Assessing progress against the project plan.
• Require action to maintain schedule.
• System and Software Design: How –It establishes and overall system architecture. Software
design involves fundamental system abstractions and their relationships.
• Integration and system testing: The individual program unit 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.
• Operation and Maintenance: Normally this is the longest phase of the software life cycle.
The system is installed and put into practical use. Maintenance involves correcting errors
which were not discovered in earlier stages of the life-cycle.
 The V-Model

V
E V
R A Verification: Are we building the product right?
I L
F Verification is Static Testing.
I
I D
Validation: Are we building the right product?
C A Validation is the Dynamic Testing.
A T
T I
I O
O N
N
Advantages of Waterfall model

• Advantages of Waterfall model

• All phases are clearly defined
• One of the most systemic methods for software development
• Being oldest, this is one of the time tested models
• It is simple and easy to use
Drawbacks of waterfall model

Drawbacks of waterfall model

• Difficult to define the all the requirements at the beginning of the
project
• Model is not suitable for accommodating any change
• A working version of the system is not seen until late in the project’s
life
• It does not scale up well to large projects
• Real projects are rarely sequential
Incremental Process Model

C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment

Delivers software in small but usable pieces, each

piece builds on pieces already delivered
The Incremental Model
• 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.
• First Increment is often core product
• Includes basic requirement
• Many supplementary features (known & unknown) remain undelivered
• A plan of next increment is prepared
• Modifications of the first increment
• Additional features of the first increment
• It is particularly useful when enough staffing is not available for the whole project
• Increment can be planned to manage technical risks.
• Incremental model focus more on delivery of operation product with each
increment.
The Incremental Model

• User requirements are prioritised and the highest priority requirements are included in
early increments.
• Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve.
• Customer value can be delivered with each increment so system functionality is available
earlier.
• Early increments act as a prototype to help elicit requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most testing.
Advantages
• Rigid nature of sequential approach.
• This method is great help when organization is low on staffing.
• Generate working software quickly and early during the
software life cycle.
• More flexible – less costly to change scope and requirements.
• Easier to test and debug during a small iteration.
• Easier to manage risk because risky pierces are identified and
handled during its iteration.
• Each increment is an easily managed milestone.
Disadvantages

• This model could be time consuming.

• Each phase of an increment is rigid and do not overlap each other.
• Problems may arise in system architecture, all the requirements are not
gathered up entire software life cycle.
Evolutionary Process Model

• Produce an increasingly more complete version of the software with

each iteration.
• Evolutionary Models are iterative.
• Evolutionary models are:
• Prototyping
• Spiral Model
• Concurrent Development Model
Incremental vs. Iterative
• Iterative
• Develop through repeated cycles
• Start simple, expecting to change
• Used to find the right solution
• Used to improve candidate solution

• Incremental
• Develop some portions at a time
• Gradually build up functionality
• Allows value to be delivered early
Evolutionary Models:
Prototyping
Quick
plan
communication

Modeling
Quick design

Deployment
delivery & Constructio
feedback Construction
n
ofofprototype
prototype
Prototyping Model
• Best approach when:
• Objectives defines by customer are general but does not have details like input,
processing, or output requirement.
• Developer may be unsure of the efficiency of an algorithm, O.S., or the form that
human machine interaction should take.
• It can be used as standalone process model.
• Model assist software engineer and customer to better understand what is to be built
when requirement are fuzzy.
• Prototyping start with communication, between a customer and software engineer to
define overall objective, identify requirements and make a boundary.
• Going ahead, planned quickly and modeling (software layout visible to the
customers/end-user) occurs.
• Quick design leads to prototype construction.
• Prototype is deployed and evaluated by the customer/user.
• Feedback from customer/end user will refine requirement and that is how iteration
occurs during prototype to satisfy the needs of the customer.
 Prototyping (cont..)
• Prototype can be serve as “the first system”.
• Both customers and developers like the prototyping paradigm.
• Customer/End user gets a feel for the actual system
• Developer get to build something immediately.

Problem Areas:
• Developer often makes implementation in order to get a prototype working
quickly without considering other factors in mind like OS, Programming
language, etc.
• Customer cries foul and demand that “a few fixes” be applied to make the
prototype a working product, due to that software quality suffers as a
result.

Customer and developer both must be agree that the prototype is built to
serve as a mechanism for defining requirement.
Evolutionary Models: The
Spiral
Spiral Model
• Couples iterative nature of prototyping with the controlled and systematic
aspects of the linear sequential model
• It provide potential for rapid development of increasingly more complete version
of the software.
• Using spiral, software developed in as series of evolutionary release.
• Early iteration, release might be on paper or prototype.
• Later iteration, more complete version of software.
• Divided into framework activities (C,P,M,C,D). Each activity represent one
segment.
• Evolutionary process begins in a clockwise direction, beginning at the center risk.
• First circuit around the spiral might result in development of a product
specification. Subsequently, develop a prototype and then progressively more
sophisticated version of software.
• Unlike other process models that end when software is delivered.
• It can be adapted to apply throughout the life of software.
Spiral Model

• Advantages:
• It is realistic approach for development for large scale system
• High amount of risk analysis
• Good for large and mission-critical projects
• Software is produced early in the software life cycle
Spiral Model
Disadvantages
• It is not widely used.
• Can be a costly to use
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk
analysis phase.
• Doesn’t work well for smaller projects.
• It demands considerable risk assessment expertise and
relies on this expertise for success.
• It may be difficult to convince customers that the
evolutionary approach is controllable.
Waterfall vs Spiral Model
 Concurrent Development Model
• It represented schematically as series of major technical activities, tasks, and their
associated states.
• It is often more appropriate for system engineering projects where different
engineering teams are involved.
• The activity-modeling may be in any one of the states for a given time.
• All activities exist concurrently but reside in different states.
E.g.
• The analysis activity (existed in the none state while initial customer
communication was completed) now makes a transition into the under
development state.
• Analysis activity moves from the under development state into the awaiting
changes state only if customer indicates changes in requirements.
• Series of event will trigger transition from state to state.
E.g. During initial stage there was inconsistency in design which was uncovered. This
will triggers the analysis action from the Done state into Awaiting Changes state.
Evolutionary Models: Concurrent
Evolutionary Processes

• The first concern is that prototyping poses a problem to project

planning.
• Evolution Processes do not establish the maximum speed of
evolution.
• The Evolution Processes should be focused on flexibility and
extendibility than on high quality,
Still Other Process
Models
• Component based development—the process to apply
when reuse is a development objective
• Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely
aligned with the Unified Modeling Language (UML)
• Formal methods—emphasizes the mathematical
specification of requirements
• AOSD—provides a process and methodological approach
for defining, specifying, designing, and constructing
aspects
 Component Based Development

• component-based development (CBD) model incorporates many of

the characteristics of the spiral model.
• It is evolutionary by nature and iterative approach to create software.
• CBD model creates applications from prepackaged software
components (called classes).
SDLC: Component Based Development
CBD model (cont.)

• Modeling and construction activities begin with identification of

candidate components.
• Classes created in past software engineering projects are stored in
a class library or repository.
• Once candidate classes are identified, the class library is searched
to determine if these classes already exist.
• If class is already available in library extract and reuse it.
• If class is not available in library, it is engineered or developed
using object-oriented methods.
• Any new classes built to meet the unique needs of the application.
• Now process flow return to the spiral activity.
CBD model (cont.)

• CBD model leads to software reusability.

• Based on studies, CBD model leads to 70 %

reduction in development cycle time.

• 84% reduction in project cost.

• Productivity is very high.

Unified Process

• Good Start => Unified Process (UP) is a standard

development process within the object-oriented and
component-based software communities.

• Product => Rational Unified Process (RUP)

• More Needed => Enterprise Unified Process (EUP) is a

software process that reflects the full lifecycle of
software-based systems.
3 Key Aspects of UP

• Use-case driven

• Architecture-centric

• Iterative and incremental

Use-Case Driven

• Use-Case driven means:

• Development process proceeds through a series of workflows that

derive from use cases.
3 Terminologies

• Users: someone or something that interact with system.

• Use Case: interaction between users and system,---what is the system
supposed to do for each user?
• Use Case Model: collection of use cases; description of complete
functionality
Initiate AND bind

• Tool for specifying requirements

• Driving design

• Source for testing

II. Architecture-Centric

• Architecture is the view of the whole design with key Characteristics

and without too many details
• Only 5-10% use cases
• growth with use case in parallel (structure and function)
Use case & Architecture

Use case

drive influence

System
architecture
 III. Iterative and Incremental ??

• Iteration: Steps in the workflow (mini-project)

• Create a design for relevant use cases
• Implement with components
• Required iteration in logical order for economy

• Increments: Growth in the product (might not be additive)

Benefits to controlled iteration

• Reduce the cost risk to the expenditures on a single increment

• Reduce the risk of delayed product delivery (find the risks earlier)
• Speed up the tempo of the whole development effort
• Easier to adapt to the requirement modification
The Unified Process (UP)
elaboration

inception
UP Phases
UP Work Products
Inception Phase

• Encompasses both customer communication and planning activities of the

generic process
• Business requirements for the software are identified
• A rough architecture for the system is proposed
• A plan is created for an incremental, iterative development
• Fundamental business requirements are described through preliminary use
cases
• A use case describes a sequence of actions that are performed by a user

83
 Elaboration Phase
• Encompasses both the planning and modeling activities of the generic process
• Refines and expands the preliminary use cases
• Expands the architectural representation to include five views
• Use-case model
• Analysis model
• Design model
• Implementation model
• Deployment model
• Often results in an executable architectural baseline that represents a first cut
executable system
• The baseline demonstrates the viability of the architecture but does not provide
all features and functions required to use the system

84
 Construction Phase

• Encompasses the construction activity of the generic process

• Uses the architectural model from the elaboration phase as input
• Develops or acquires the software components that make each use-case
operational
• Analysis and design models from the previous phase are completed to reflect the
final version of the increment
• Use cases are used to derive a set of acceptance tests that are executed prior to
the next phase

85
 Transition Phase

• Encompasses the last part of the construction activity and the first part of the
deployment activity of the generic process
• Software is given to end users for beta testing and user feedback reports on
defects and necessary changes
• The software teams create necessary support documentation (user manuals,
trouble-shooting guides, installation procedures)
• At the conclusion of this phase, the software increment becomes a usable
software release

86
 Production Phase

• Encompasses the last part of the deployment activity of the generic process
• On-going use of the software is monitored
• Support for the operating environment (infrastructure) is provided
• Defect reports and requests for changes are submitted and evaluated

87
UP strengths

• Strength of RUP:

• Based on sound SWE principles

• Mechanisms that provide management visibility into the
development process
• HTML-based description of the RUP
UP weaknesses

• Only developing process, not the entire software

process
• Not supporting multi-system infrastructure
development efforts
• Iterative nature foreign to experienced
developers
• Tool-driven approach, not sufficient for complex
system
Unified Process Work Products

• Work products are produced in each of the first four phases of the
unified process
• In this course, we will concentrate on the analysis model and the
design model work products
• Analysis model includes
• Scenario-based model, class-based model, and behavioral model
• Design model includes
• Component-level design, interface design, architectural design, and
data/class design

90
☺
Workflows of the UP
• A workflow is a sequence of activities that produces a result of discernible value.
In the UP, there are nine core process workflows. They are:
• Business Modeling Workflow
• Requirements Workflow
• Design Workflow
• Implementation Workflow
• Test Workflow
• Deployment Workflow
• Project Management Workflow
• Configuration and Change management Workflow
• Environment Workflow
Business Modeling Workflow

• Main aim: Evolve a common understanding among various

stakeholders about what the project will deliver.
• Unified Process provides a common language and process for various
stakeholders.
Requirements Workflow

• The aim: To achieve the above task by eliciting the functional

requirements as well as the constraints.

• A document describing the vision and scope of the project is created.

• Actors and use cases are identified and described in detail.

• The constraints are also documented.

Design Workflow
• The main aim : Deliver the design model.
• The identification and validation of core architecture is
done in an iterative manner.
• Initially, only the core architectural design is done without
paying much attention to details.
• This is followed by detailed design of the core
architecture.
• Other facets of the design like the databases, networking
etc. are also designed.
Implementation Workflow

• Main aim:To program and build the system.

• Unit tests are also carried out and the unit-tested units are integrated
into a complete system.
Test Workflow
• Actually, testing is done throughout the project in an
iterative manner.
• Testing includes
• the verification whether software has been developed
according to the user requirements and
• whether the components of the software are properly
integrated and defects addressed prior to the
deployment of the software.
Project Management Workflow
• The aim: To simplify these tasks by providing a
framework for managing the overall project, managing
risks and providing guidelines for formulating a project
plan, allocating staff and monitoring the course of the
project.
• To manage a software project, it is necessary for the
project manager to
• Manage risks,
• Overcome difficulties in course of the project,
• Balance the objectives of different people and
• Ultimately deliver a product to the customer of high
quality, reasonable cost and within the estimated
schedule.
Configuration and Change Management
Workflow
• Gives guidelines on how to manage the various
problems that are inherent when teamwork is
performed.
• Guidelines can be in regard to:
• Maintaining different variants of software,
• Enforcing organizational development policies,
• Managing change requests,
• Tracking changes and
• Keeping an audit of the changes made.
Environment Workflow

• Main aim: To provide the software development organization the

processes and the tools that are needed to support the development
team.

• A detailed guide is provided to implement a customized process for a

particular project in the organization.