21CSC303J - Software Engineering

and Project Management (SEPM)

UNIT - I

Disclaimer:
The lecture notes have been prepared by referring to many books and notes prepared by the teachers. This document does not claim
any originality and cannot be used as a substitute for prescribed textbooks.
 Topics
• The evolving role of software
• Changing nature of software
• Generic view of process: software engineering-
• A layered technology
• Software project management –
– life cycle activities
– process models:
– The waterfall model
• Incremental process models
• Evolutionary process models
• The unified process
• Conventional-
– agile
– XP
– Scrum
• Project initiation management –
– Project charter
– Project scope
– Project objectives
– Practical considerations

3
 SOFTWARE ENGINEERING
Software Engineering : The term is made of two words,
software and engineering.

• Software is more than just a program code. A program is

an executable code, which serves some computational
purpose.
• Software is considered to be collection of executable
programming code, associated libraries and
documentations. Software, when made for a specific
requirement is called software product.
• Engineering is the application of scientific and practical
knowledge to invent, design, build, maintain, and improve
frameworks, processes, etc.
SOFTWARE ENGINEERING
 Defining Software
A textbook description of software might take the following form:
Software is:
(1) instructions (computer programs) that when executed provide
desired features, function, and performance;
(2) data structures that enable the programs to adequately
manipulate information, and
(3) descriptive information in both hard copy and virtual forms
that describes the operation and use of the programs.
There is no question that other more complete definitions could be
offered.
Software is a logical rather than a physical system element.
Software Engineering and Project Management

Software is a set of instructions, data or programs used to

operate computers and execute specific tasks

Software engineering
Software engineering is defined as a process of analyzing
user requirements and then designing, building, and testing
software application which will satisfy those requirements.

Software Engineering and Project Management (SEPM) is a

proper way of planning and leading software projects. It is a part
of project management in which software projects are planned,
implemented, monitored and controlled.
 Introduction To Software Engineering
• The IEEE definition:
– Software Engineering: The application of a systematic,
disciplined, quantifiable approach to the development,
operation and maintenance of software.
• Some realities:
– To understand the problem before a software solution is
developed
– Design becomes a essential activity
– Software should exhibit high quality
– Software should be maintainable
 Software characteristics
Software characteristics
1. Software is developed or engineered; it is not
manufactured in the classical sense.
2. Although the industry is moving toward
component-based construction, most software
continues to be custom built.
3. Software doesn’t “wear out.” But it does deteriorate!
 Characteristics of Good Software
• Any software should be judged by what it offers and what
are the methods which help you to use it.
• Every software must satisfy the following attributes:
– Operational
– Transitional
– Maintenance
 Characteristics of Good Software
Operational
• This characteristic let us know about how well software
works in the operations which can be measured on:
• Budget
• Efficiency
• Usability
• Dependability
• Correctness
• Functionality
• Safety
• Security
 Characteristics of Good Software
Transitional
• This is an essential aspect when the software is moved from one
platform to another:
• Interoperability
• Reusability
• Portability
• Adaptability
Maintenance
• This aspect talks about how well software has the capabilities to
adapt itself in the quickly changing environment:
• Flexibility
• Maintainability
• Modularity
• Scalability
 THE EVOLVING ROLE OF SOFTWARE
Today, software takes on a dual role.
✔ It is a product and, at the same time,
✔ the vehicle for delivering a product.
• As a product,
– it delivers the computing potential embodied by computer
hardware or, more broadly, a network of computers that are
accessible by local hardware.
• Whether it resides within a cellular phone or operates
inside a mainframe computer, software is an information
transformer,
– producing, managing, acquiring, modifying, displaying, or
transmitting information that can be as simple as a single bit or as
complex as a multimedia presentation.
 THE EVOLVING ROLE OF SOFTWARE
• As the vehicle used to deliver the product,
✔ software acts as the basis for the control of the
computer (operating systems), the communication
of information (networks), and the creation and
control of other programs (software tools and
environments).
• Software delivers the most important product of our
time—information.
 THE EVOLVING ROLE OF SOFTWARE
• Software transforms personal data -
✔ it manages business information to enhance
competitiveness;
✔ it provides a gateway to worldwide information
networks (e.g., Internet) and provides the means for
acquiring information in all of its forms.
• The role of computer software has undergone significant
change over a time span of little more than 50 years.
✔ hardware performance,
✔ changes in computing architectures,
✔ vast increases in memory and storage capacity,
✔ input and output options
 THE EVOLVING ROLE OF SOFTWARE
The lone programmer of an earlier era has been replaced by a
team of software specialists, each focusing on one part of the
technology required to deliver a complex application. And
yet, the same questions asked of the lone programmer are
being asked when modern computer-based systems are built:
1) Why does it take so long to get software finished?
2) Why are development costs so high?
3) Why can't we find all the errors before we give the
software to customers?
4) Why do we continue to have difficulty in measuring
progress as software is being developed?
 CHANGING NATURE OF SOFTWARE:
The nature of software has changed a lot over the years.
[Link] software - —a collection of programs written to
service other programs.
• Some system software (e.g., compilers, editors, and file
management
2. Real time software: These software are used to monitor,
control and analyze real world events as they occur.
• An example may be software required for weather
forecasting. Such software will gather and process the
status of temperature, humidity and other environmental
parameters to forecast the weather.
 CHANGING NATURE OF SOFTWARE:
3. Embedded software: resides within a product or system
and is used to implement and control features and functions
for the end user and for the system itself .
• (Example : Digital functions in an automobile such as fuel
control, dashboard displays, and braking systems).
4. Business / Application software - stand-alone programs
that solve a specific business need. Applications in this area
process business or technical data in a way that facilitates
business operations or management/technical decision
making.
• Business software could be payroll, file monitoring
system, employee management, account management.
 CHANGING NATURE OF SOFTWARE:
5. Personal computer software: The software used in personal
computers are covered in this category.
• Examples are word processors, computer graphics,
multimedia and animating tools, database management,
computer games etc.

6. Artificial intelligence software: Artificial Intelligence

software makes use of non numerical algorithms to solve
complex problems that are not amenable to computation or
straight forward analysis.
• Examples are expert systems, artificial neural network,
signal processing software etc.
 CHANGING NATURE OF SOFTWARE:
7. Product-line software—designed to provide a specific
capability for use by many different customers.
• Product-line software can focus on a limited and esoteric
marketplace (e.g., inventory control products) or address
mass consumer markets (e.g., word processing,
spreadsheets, computer graphics, multimedia,
entertainment, database management, and personal and
business financial applications).
8. Web based software: The software related to web
applications come under this category.
– Examples are CGI, HTML, Java, Perl, DHTML etc.
 Layered Technology
• Software engineering is a layered technology.
• The foundation for software engineering is the process layer.
• Process defines a framework that must be established for effective delivery of
software.
• Software engineering methods provide the technical how-to’s for building
software.
• Methods encompass a broad array of tasks that include communication,
requirements analysis, design modeling, program construction, testing, and
support.
• Software engineering tools provide automated or semi automated support for
the process and the methods.

Tools

Methods

Process Model

“Quality” Focus
 Essence of Practice
Polya suggests: (four-step problem-solving process)
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
Understand the problem (Communication and Analysis)
- Who are the stakeholders?
- What are the unknowns?
- What data, functions, and features are
required to properly solve the problem?
- Can the problem be compartmentalized?
- Is it possible to represent smaller problems
that may be easier to understand?
- Can the problem be represented graphically?
- Can an analysis model be created?
 Essence of Practice
Plan the Solution
- Have you seen similar problems before? Are there patterns that are familiar in
a potential solution? Is there existing software that implements the data,
functions, and features that are required?
- Has a similar problem been solved? If so, are elements of the solution
reusable?
- Can sub problems be defined? If so, are solutions readily apparent for the sub
problems?
- Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created? Can an analysis model be
created?

Carry Out the Plan

- Does the solution conform to the plan? Is source code traceable to the design
model?
- Is each component part of the solution provably correct? Has the design and
code been reviewed, or better?
 Essence of Practice
• Examine the Result
- Is it possible to test each component part of the solution? Has a reasonable
testing strategy been implemented?
- Does the solution produce results that conform to the data, functions, and
features that are required? Has the software been validated against all
stakeholder requirements?

• How it all Starts – Safe Home:

– Every software project is precipitated ( lead to ) by some business need:
• The need to correct a defect in an existing application;
• The need to adapt a ‘legacy system’ to a changing business
environment;
• The need to extend the functions and features of an existing application,
or
• The need to create a new product, service, or system
 A GENERIC PROCESS MODEL
▪ The generic process model is an description of the
software development process.
▪ It is used in most software models since it provides a base
for them.
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 means to develop quality products by
using technical & management rules.
A GENERIC PROCESS MODEL

A software process framework

 A GENERIC PROCESS MODEL
❑ A generic process framework for software engineering defines five
framework activities—communication, planning, modeling, construction,
and deployment.
❑ In addition, a set of umbrella activities—project tracking and control, risk
management, quality assurance, configuration management, technical
reviews
❖ Defining a Framework Activity
-What actions are appropriate for a framework activity, given the nature of
the problem to be solved, the characteristics of the people doing the work,
and the stakeholders who are sponsoring the project?
- action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.

❖ Identifying a Task Set

- number of different task sets—each a collection of software engineering
work tasks, related work products, quality assurance points, and project
milestones
 A GENERIC PROCESS MODEL

process flow
(a) Linear process flow - Linear process flow executes each of the five
activities in sequence.

(b) Iterative process flow - An iterative process flow repeats one or more of
the activities before proceeding to the next.
 A GENERIC PROCESS MODEL
(c) Evolutionary process flow - An evolutionary process flow executes the
activities in a circular manner. Each circuit leads to a more complete
version of the software.

(d) Parallel process flow - A parallel process flow executes one or more
activities in parallel with other activities
 A GENERIC PROCESS MODEL
Process framework
• A generic process framework for software engineering defines five
framework activities-communication, planning, modeling, construction, and
deployment.
• Communication: to gather requirements that help define software features
and functions.
• Planning: describes the technical tasks to be conducted, the risks that are
likely, the resources that will be required, the work products to be produced,
and a work schedule.
• Modeling : create a “sketch” of the thing so that you’ll understand the big
picture. If required, you refine the sketch into greater and greater detail in an
effort to better understand the problem and how you’re going to solve it.
• Construction. This activity combines code generation and the testing that is
required to uncover errors in the code.
• Deployment: The software is delivered to the customer who evaluates the
delivered product and provides feedback based on the evaluation.
 A GENERIC PROCESS MODEL
Umbrella activities
• Software project tracking and control - allows the software
team to assess progress against the project plan and take any
necessary action to maintain the schedule.
• Risk management - assesses risks that may affect the outcome
of the project or the quality of the product.
•Software quality assurance - defines and conducts the
activities to monitoring the software engineering processes and
methods used to ensure quality.
• Technical reviews - assesses software engineering work
products in an effort to uncover and remove errors before they
are propagated to the next activity.
 A GENERIC PROCESS MODEL
• Software configuration management - is the task of tracking
and controlling changes in the software throughout the software
process
• Reusability management - defines criteria for work product
reuse and establishes mechanisms to achieve reusable
components.
• Work product preparation and production - encompasses
the activities required to create work products such as models,
documents, logs, forms, and lists..
• Measurement - defines and collects process, project, and
product measures that assist the team in delivering software that
meets stakeholders’ needs
 A GENERIC PROCESS MODEL
• Task set is the actual work to be done to achieve an objective of
each engineering module.
Consider communication activity task set:
• Prepare a list of stakeholders of the project.
• Organize a meeting for stakeholders.
• Discuss requirements.
• Finalize requirements list.
• Make a list of issues raised.
 Process Patterns
❖ Process Patterns A process pattern describes a process-related problem
that is encountered during software engineering work, identifies the
environment in which the problem has been encountered, and suggests one
or more proven solutions to the problem.
Ambler has proposed a template for describing a process pattern:
✔ Pattern Name
The pattern is given a meaningful name describing it within the context of
the software process (e.g., Technical Reviews).
✔ Forces
The environment in which the pattern is encountered and the issues that
make the problem visible and may affect its solution.
✔ Type-three types:
1. Stage pattern—defines a problem associated with a framework activity for
the process .
2. Task pattern—defines a problem associated with a software engineering
action or work task and relevant to successful software engineering
practice (e.g., Requirements Gathering is a task pattern).
3. Phase pattern—define the sequence of framework activities that occurs
within the process. Ex: Spiral Model or Prototyping.
 PROCESS ASSESSMENT AND IMPROVEMENT
✔ Standard CMMI(Capability Maturity Model Integration
Assessment Method) for Process Improvement (SCAMPI)
- provides a five-step process assessment model that incorporates five
phases: initiating, diagnosing, establishing, acting, and learning. The
SCAMPI method uses the SEI CMMI as the basis for assessment.
✔ CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
- provides a diagnostic technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the basis for the assessment.
✔ SPICE (ISO/IEC15504) - Software Process Improvement and
Capability dEtermination (SPICE)
- a standard that defines a set of requirements for software process
assessment. The intent of the standard is to assist organizations in
developing an objective evaluation of the efficacy of any defined software
process.
✔ ISO 9001:2000 for Software
- a generic standard that applies to any organization that wants to improve
the overall quality of the products, systems, or services that it provides
Software Development Life Cycle (SDLC)
• A framework that describes the activities performed at each
stage of a software development project.
• SDLC represents the process of developing quality software as
per customer requirements.
Need of SDLC process :
• Improved relation with client & development team.
• It offers basic project planning, scheduling & cost estimation.
• Provide standard set of activities & SE rules.
• Increase & enhance development speed.
• Maintain project tracking & control
• Decrease any type of project risk.
• Decide entry & exit criteria of each phase.
Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)
Planning:
▪ Review project requests
▪ Prioritize project requests
▪ Allocate resources
▪ Identify project development team
Analysis:
▪ Conduct preliminary investigation
▪ Perform detailed analysis activities:
– Study current system
– Determine user requirements
– Recommend solution
Software Development Life Cycle (SDLC)
Designing:
▪ Acquire hardware and software, if necessary
▪ Prepare the architecture of the system
▪ Most creative and challenging phase
▪ Translates the performance requirements into design specifications
Tasks
▪ How should the problem be solved
▪ Organisational and job designs prepared
▪ Information processing systems design
▪ Design of the database
▪ Design of the user interface
▪ Physical design
▪ Input data and master files are designed
▪ Output formats are designed
Development & Testing:
▪ Develop programs, if necessary
▪ Verifies each individual program works by itself
▪ Verifies all programs in application work together
▪ Verifies application works with other applications
Software Development Life Cycle (SDLC)
Implementation:
– Also known as the deployment phase, the
implementation phase is carried out right after the
successful testing of the software product.
– It is simply delivering the software to the
end-user or installing it onto the customer’s
system(s).
Maintenance:
▪ Conduct post-implementation system review
▪ Identify errors and enhancements
▪ Monitor system performance
 Software Development Life Cycle (SDLC)

Who participates
in the Software
development life
cycle?

Some of the
popular Software
development
lifecycle
methodologies
• Agile
• Lean
• Waterfall
• Iterative
• Spiral
• DevOps
 Software Project Management
Introduction
• Concerned with activities involved in ensuring that software is delivered on time
and on schedule and in accordance with the requirements of the organisations
developing and procuring the software.
• Project management is needed because software development is always subject
to budget and schedule constraints that are set by the organisation developing
the software.

Success Criteria
• Deliver the software to the customer at the agreed time.
• Keep overall costs within budget.
• Deliver software that meets the customer’s expectations.
• Maintain a coherent and well-functioning development team.
 Software Project Management
Software Management Distinctions
• The product is intangible.
– Software cannot be seen or touched.
– Software project managers cannot see progress by simply looking at the
artefact that is being constructed.
• Many software projects are 'one-off' projects.
– Large software projects are usually different in some ways from previous
projects.
– Even managers who have lots of previous experience may find it difficult to
anticipate problems.
• Software processes are variable and organization specific.
– We still cannot reliably predict when a particular software process is likely to
lead to development problems.
 Software Project Management
Factors Influencing Project Management
• Company size
• Software customers
• Software size
• Software type
• Organizational culture
• Software development processes (a series of actions that you do for a
particular purpose)
• These factors mean that project managers in different organizations may work in
quite different ways.
Software Management Lifecycle Activities
• Proposal writing
– The first stage in a software project may involve writing a proposal to win a
contract to carry out an item of work.
– The proposal describes the objectives of the project and how it will be
carried out.
• Project planning
– Project managers are responsible for planning, estimating and scheduling
project development and assigning people to tasks.
 Software Project Management
Software Management Lifecycle Activities
• Risk management
– Project managers assess the risks that may affect a project, monitor these
risks and take action when problems arise.
– proactive (before risk happen )/ reactive (past incident evaluation)
• People management
– Project managers have to choose people for their team and establish ways of
working that leads to effective team performance.
• Reporting
– Project managers are usually responsible for reporting on the progress of a
project to customers and to the managers of the company developing the
software.
 PROCESS MODELS
• 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 process models are adapted to meet the needs
of software engineers and managers for a specific
project.
 PROCESS MODELS:
The most used, popular and important SDLC models are given below:
1. Prescriptive models
– Waterfall model (well defined and reasonably stable)
– V model (quality assurance , series of test)
– Incremental model (broken down into increments )
2. Evolutionary Software Process Models
• Iterative model (customer feedback of each module)
• Prototype model (quick plan for prototyping and modeling )
• Spiral model (risk-driven process model )
3. The Unified Process (object-oriented software engineering using UML)
4. RAD model (rapid delivery, use of database tools, components )
5. Conventional Software Process Models
– Agile model (continuous improvement)
– XP (creation of user stories )
– SCRUM (set of software process patterns,sprint )
 PROCESS MODELS:
Prescriptive Model
• Calling this model as “Prescribe” because it
recommend a set of process elements, activities, action
task, work product & quality.
• Each elements are inter related to one another (called
workflow).
 Traditional / Prescriptive models
Software Process Models - Waterfall
Waterfall
• It is the oldest paradigm for Software Engineering.
• When requirements are well defined and reasonably stable, it leads to a linear
fashion.
• The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development that begins with
customer specification of requirements and progresses through planning,
modeling, construction and deployment, culminating in ongoing support of the
completed software.
When to select?
• There are times when the requirements for a problem are well
understood—when work flows from communication through deployment in a
reasonably linear fashion.
 Waterfall Model with Feedback

Communication
Project initiation
Requirements
gathering

Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
 Traditional / Prescriptive models
Waterfall - Problems Software Process Models
• Inflexible partitioning of the project into distinct stages makes it difficult to
respond to changing customer requirements.
– Therefore, this model is only appropriate when the requirements are
well-understood and changes will be fairly limited during the design
process.
– Few business systems have stable requirements.
• The waterfall model is mostly used for large system engineering projects where a
system is developed at several sites.
– In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.
Waterfall - Advantages
1. Simple
2. Easy to understand even for non-technical customers
3. Oldest, widely used
4. Base for all other models by including feed back loops, iterations etc.
Waterfall - Disadvantages
1. Real projects rarely follow this linear sequence.
2. Difficult for customer to state all requirements at one shot
3. Customer must have patience - - working version of program will not available
 Traditional / Prescriptive models
Software Process Models
V-Model
• A variation of waterfall model depicts
the relationship of quality assurance
actions to the actions associated with
communication, modeling and early
code construction activities.
• Team first moves down the left side of
the V to refine the problem
requirements.
• Once code is generated, the team moves
up the right side of the V, performing
a series of tests that validate each of
the models created as the team moved
down the left side.
 The Incremental Model
• 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 prioritized 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.
• 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.
 Evolutionary Process Models
• Evolutionary model is also referred to as the successive versions
model.

Communicatio
n
Modeling
Quick design

Constructio
n
of prototype
 Evolutionary Process Models
• It is a combination of Iterative & Incremental model.
• In this model, the software requirement is first broken down into
several modules.
• That can be incrementally constructed means it take customer
feedback of each module.
• Delivered product module by module to the customer.

Communicatio
n
Modeling
Quick design

Constructio
n
of prototype
 Evolutionary Process Models
Prototyping
• Begins with communication
• A quick plan for prototyping and modeling occur.
• Quick design focuses on the representation of those aspects the software will be
visible to end users. (Interface and output).
• Design leads to the construction of
a prototype which will be deployed
and evaluated. Quick
plan
• Stakeholder’s comments will be Communicatio
n
used to refine requirements. Modeling
Quick design

Deployment
delivery &
feedback Constructio
n
of prototype
 Evolutionary Process Models
Prototyping – When to Select
• Customer defines a set of general objectives
• Does not identify detailed requirements
• Developer may be unsure of the efficiency of an algorithm, the form that human
computer interaction should take.
• When your customer has a legitimate need, but is clueless about the details,
develop a prototype as a first step.

Prototyping - Advantages
1. Provides working model.
2. Customer is highly satisfied with such a modeling at initial stages
3. Developer gains business insight, reducing ambiguity
4. Great involvement of users
5. Reduce risks
 Evolutionary Process Models
Prototyping - Disadvantages
1. Customer - not aware that only interface or appearance is concentrated much
and long term quality is at stake.
2. False expectations from customer that end software modelling is finished or will
have the same behavior/pace of the prototype.
3. Inappropriate choices of technology
4. Various iterations to a prototype that is to be discarded is expensive
 Evolutionary Process Models
Spiral
• It couples the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model and is a risk-driven process model generator that
is used to guide multi-stakeholder concurrent engineering of software intensive
systems.
• Two main distinguishing features: one is cyclic approach for incrementally
growing a system’s degree of definition and implementation while decreasing its
degree of risk. The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually satisfactory system solutions.
• A series of evolutionary releases are delivered.
• During the early iterations, the release might be a model or prototype.
• During later iterations, increasingly more complete version of the engineered
system are produced.
• The first circuit in the clockwise direction might result in the product
specification; subsequent passes around the spiral might be used to develop a
prototype and then progressively more sophisticated versions of the software.
• Each pass results in adjustments to the project plan.
• Cost and schedule are adjusted based on feedback.
 Evolutionary Process Models
Spiral
• Also, the number of iterations will be adjusted by project manager.
• Good to develop large-scale system as software evolves as the process
progresses and risk should be understood and properly reacted to.

• Begin with design model

and ends with client reviewing

1. Concept
developments
1 2 2. System developments
3 4 3. System
enhancements
4. System Maintenances

• Prototyping is used to reduce risk.

• However, it may be difficult to convince customers that it is controllable as it
demands considerable risk assessment expertise.
Evolutionary Process Models

1 2
3 4
 Evolutionary Process Models
Spiral - Advantages
1. Applies throughout lifecycle
• Concept Development
• New Product Development
• Product Enhancement
2. Risk is considered at each pass
3. Uses prototyping as risk reduction mechanism
4. Customer and developer understand and better react to risks

Spiral - Disadvantages
1. Difficult to convince customers that it is controllable
2. Demands considerable risk assessment expertise
3. Major risk is not uncovered/managed, problem will occur
The Unified Process
 Background
• Birthed during the late 1980's and early 1990s when
object-oriented languages were gaining wide-spread use
• Many object-oriented analysis and design methods were
proposed; three top authors were Grady Booch, Ivar
Jacobson, and James Rumbaugh
• They eventually worked together on a unified method, called
the Unified Modeling Language (UML)
– UML is a robust notation for the modeling and
development of object-oriented systems
– UML became an industry standard in 1997
– However, UML does not provide the process framework,
only the necessary technology for object-oriented
development
 Background (continued)

• Booch, Jacobson, and Rumbaugh later developed the unified

process, which is a framework for object-oriented software
engineering using UML
– Draws on the best features and characteristics of
conventional software process models
– Emphasizes the important role of software architecture
– Consists of a process flow that is iterative and
incremental, thereby providing an evolutionary feel
• Consists of five phases: inception, elaboration, construction,
transition, and production
 Phases of the Unified Process
(Expands use cases, sequence of
(Rough architecture, use actions, executable architectural )
case, sequence of actions)
Inceptio Elaboratio
n n

planning

modeling
communication (Develops or
acquires the
software
components )
construction
(Software is Constructio
monitored, deployment n
Defect reports and
requests for (Software is given
changes) Productio Transition to end users with
user manual )
n
 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
 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
 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
 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
 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
 Unified Process Work Products
• Work products are produced in each of the first four
phases of the unified process
• 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
 Traditional Software Process Models
Rapid Application Development (RAD)
• An approach to software development aimed at rapid delivery of the software.
• It often involves the use of database programming and development support
tools such as screen and report generators.
• There are three broad phases to RAD:
– Requirements planning
– RAD design workshop
– Implementation
• Requirements planning
- Users and analysts meet to identify
objectives of the application or system
oriented toward solving business problems
• RAD Design Workshop
– Design and refine phase
– Use group decision support systems to help users agree on designs
– Programmers and analysts can build and show visual representations of the
designs and workflow to users
 Traditional Software Process Models
Rapid Application Development
• RAD Design Workshop
– Users respond to actual working prototypes
– Analysts refine designed modules based on user responses
• Implementation Phase
- As the systems are built and refined, the new systems or partial systems are
tested and introduced to the organization
- When creating new systems, there is no need to run old systems in parallel

• The Martin approach to RAD includes four phases:

– Requirements planning
– User design
– Construction
– Cutover
 Traditional Software Process Models
Rapid Application Development – When to Select
• The team includes programmers and analysts who are experienced with it
• There are pressing reasons for speeding up application development
• The project involves a novel ecommerce application and needs quick results
• Users are sophisticated and highly engaged with the goals of the company

Rapid Application Development – Advantages

• RAD is very powerful when used within the SDLC
• It can be used as a tool to update, improve or innovate selected portions of the
system
 Traditional Software Process Models
Rapid Application Development – Disadvantages
• May try and hurry the project too much
• Loosely documented
• May not address pressing business problems
• Potentially steep(vertical) learning curve for programmers
inexperienced with RAD tools
• Depends on strong team and individual performances for
identifying business requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.
 Conventional Software Process Models
Agile
• Agile software development is a group of software development methods in
which requirements and solutions evolve through collaboration between
self-organizing, cross-functional teams.
• It promotes adaptive planning, evolutionary development, early delivery,
continuous improvement, and encourages rapid and flexible response to change.
• What is Agility?
– Effective (rapid and adaptive) response to change
– Effective communication among all stakeholders
– Drawing the customer onto the team
– Organizing a team so that it is in control of the work performed
– Yielding …Rapid, incremental delivery of software
• Agile Process is driven by customer descriptions of what is required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy emphasis on construction activities
• Delivers multiple ‘software increments’
• Adapts as changes occur
Conventional Software Process Models
 The principles of agile methods
Principle Description

Customers should be closely involved throughout the development

Customer involvement process. Their role is provide and prioritize new system
requirements and to evaluate the iterations of the system.

The software is developed in increments with the customer

Incremental delivery
specifying the requirements to be included in each increment.

The skills of the development team should be recognized and

People not process exploited. Team members should be left to develop their own ways
of working without prescriptive processes.

Expect the system requirements to change and so design the

Embrace change
system to accommodate these changes.

Focus on simplicity in both the software being developed and in

Maintain simplicity the development process. Wherever possible, actively work to
eliminate complexity from the system.
 Conventional Software Process Models
Agile - Principles
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face–to–face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
(working smarter, not harder. It requires discipline, focus, and a commitment to
delivering value efficiently)
 Conventional Software Process Models
Agile – Principles
11. The best architectures, requirements, and designs emerge from self–organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
Human Factors
• The process moulds to the needs of the people and team, not the other way
around
• Key personalities must exist among the people on an agile team and the team
itself:
– Competence
– Common focus
– Collaboration
– Decision-making ability
– Fuzzy problem-solving ability ( can vary instead of being fixed once)
– Mutual trust and respect
– Self-organization
 Conventional Software Process Models
Agile – Extreme Programming (XP)
• The most widely used agile process, originally proposed by Kent Beck
• XP Planning
– Begins with the creation of “user stories (Listening leads to creation of set of
“stories” (also called user stories that describe required output, features and
functionality for software to be built).”
– Agile team assesses each story and assigns a cost
– Stories are grouped, for a deliverable increment
– A commitment is made on delivery date
– After the first increment “project velocity” is used to help define subsequent
delivery dates for other increments
• XP Design
– Follows the KIS(Keep It Simple) principle (states that designs and/or systems
should be as simple as possible)
– Encourage the use of CRC cards (Class-Responsibility-Collaboration cards are a
brainstorming tool used in the design of object-oriented software)
– For difficult design problems, suggests the creation of “spike solutions (a
technical investigation)”—a design prototype
– Encourages “refactoring”—an iterative refinement of the internal program design
 Conventional Software Process Models
Agile – Extreme Programming (XP)

two programmers work together

at one workstation.- (code and
review)
 Conventional Software Process Models
Agile – Extreme Programming (XP)
• XP Coding
– Recommends the construction of a unit test for a store before coding
commences
– Encourages “pair programming” (XP recommends that two people work
together at one computer workstation to create code for a story)

• XP Testing
– All unit tests are executed daily
– “Acceptance tests” are defined by the customer and executed to assess
customer visible functionality
 Conventional Software Process Models
Agile – Scrum
• Scrum is an agile software development method that was conceived by Jeff
Sutherland and his development team in the early 1990s.
• In recent years, further development on the scrum methods has been performed
by Schwaber and Beedle.
• Scrum principles are consistent with the agile manifesto and are used to guide
development activities within a process that incorporates the following
framework activities: Requirements, Analysis, Design, Evolution and delivery.
• Within each framework activity, work tasks occur within a process pattern called
a sprint.
• The work conducted within a sprint is adapted to the problem at hand and is
defined and often modified in real time by the Scrum team.
• The overall flow of the Scrum process is illustrated in figure below.
• Scrum emphasizes the use of a set of software process patterns that have proven
effective for projects with tight timelines, changing requirements and business
criticality.
• Each of these process patterns defines a set of development actions:
1. Backlog – a prioritized list of project managements or features that provide
business value for the customer. Items can be added to the backlog at any time.
The product manager assess the backlog and updates priorities as required.
 Conventional Software Process Models
Agile – Scrum
• Each of these process patterns defines a set of development actions:
2. Sprints – consist of work units that are required to achieve a requirement
defined in the backlog that must be fit into a predefined time-box (typically 30
days). Changes (e.g., backlog work items) are not introduced during the sprint.
Hence, the sprint allows team members to work in a short term, but stable
environment.
3. Scrum meetings – are short (typically 15 minutes) meetings held daily by the
Scrum team. Three key questions are asked and answered by all team members:
a. What did you do since the last team meeting?
b. What obstacles are you encountering?
c. What do you plan to accomplish by the next team meeting?
• A team leader, called a Scrum master, leads the meeting and assesses the
responses from each person.
• The Scrum meeting helps the team to uncover potential problems as early as
possible.
• Also, these daily meetings lead to “knowledge socialization” and thereby
promote a self-organizing team structure.
 Conventional Software Process Models
Agile – Scrum
• Demos – deliver the software increment to the customer so that functionality
that has been implemented can be demonstrated and evaluated by the
customer.
• It is important to note that the demo may not contain all planned functionality,
but rather those functions that can be delivered within the time-box that was
established.
• Beedle(head) and his colleagues present a comprehensive discussion of these
patterns in which they state: “Scrum assumes up-front the existence of chaos…”
• The Scrum process patterns enable a software team to work successfully in a
world where the elimination of uncertainty is impossible.
 Conventional Software Process Models
Agile – Scrum
 Conventional Software Process Models
Agile – Scrum

stand up meeting
Conventional Software Process Models
Conventional Software Process Models
Project Initiation Management

• Introduction
Reference book :
• Project Charter Software Project
• Project Scope Management A
Process-Driven Approach by
• Project Objectives Ashfaque Ahmed
• Practical Considerations (Chapter 2 : 2.1 – 2.5)
 Project Initiation Management -
Introduction
• In-house software projects : Software projects often
face initial challenges and false starts, typically due to
an unclear project charter, scope, and requirements.
• Many project stakeholders, particularly top
management, recognize their urgent need for a
software system but struggle to specify what they
want.
• Although a project team is assembled at this stage,
there is a lack of clarity about the tasks at hand,
resulting in many projects failing before they even
begin.
 Project Initiation Management -
Introduction
• An experienced project manager can effectively
manage the situation, create a plan, negotiate, and
identify stakeholders and their needs.
• For this to happen, the project manager must have a
good idea of the business situation, hard to think
about the software solution.
• He can then engage a project team for the task.
In the case of outsourced projects, things are different.
• The project manager from the service provider’s side
may have participated in project negotiation along
with the marketing team to bag the project.
 Project Initiation Management -
Introduction
• In such cases, the project charter and project scope
are much better defined as compared to the previous
situation, and thus, the project has much better
chances of going forward.
• During project initiation,
– the project manager has to do a lot of ground work
– will provide initial and rough effort estimation
– identify risks and make risk mitigation strategies
– define the project scope, prepare a project charter,
etc., after consultation with the project
stakeholders.
 Project Initiation Management -
Project Charter
• Most projects start on a high note. Stakeholders
have high hopes.
• Accordingly, lofty project charters are made.
Unfortunately, as the project progresses, all the
enthusiasm vanishes quickly. So what could be
done to avoid such situations?
• The project stakeholders need to set their
expectations with grounded realities.
• All their hopes should be aligned with practical
limitations and achievable goals. If this is not done
right from the inception of the project, the project
is going to falter all the way.
 Project Initiation Management -
Project Charter
• The project charter should include things like,
– project goals,
– project objectives,
– major responsibilities allocation, etc.

But a simple project charter may be a simple

statement from the top management,
Example : The project will provide a cutting edge
software solution to our sales team to provide
excellent customer service for our customers so that
all customer issues can be solved within 24 hours of
lodging of a complaint.
 Project Initiation Management -
Project Scope
• After analyses of failed projects, it has been found
that most of the projects fail because of an increase in
the scope of the project over time. An increase in
project scope happens primarily due to two factors.
• One factor is that as, So they keep making change
requests throughout the development cycle. This not
only disrupts development activity, it also makes the
application susceptible to defects.
• But the most important impact over the project,
– to increase in the volume of the project work, which results
in the escalation of costs and an elongation of the schedule
 Project Initiation Management -
Project Scope
• The other factor that results in change in the project
scope is a poor requirements definition.
• A poor understanding of requirements or a poor
definition of requirements leads to changes required
later on in the software design or software build to
rectify this problem.
• In any case, the project scope increases due to these
factors.
• Project effort estimation and project schedule are
accurate, and level of quality.
• The impact of the change on the project and this
should be communicated to the stakeholders.
 Project Initiation Management -
Project Scope
Sample Project Scope Definition :
The project will be delivered within 15 months from the
date of start of the project. The software product that
will be made through this project will have features for
customer complaint logging, issue resolution, and issue
closure. The software product should have the capability
of supporting our customer base of 10,000, who will be
using the service through an Internet connection by
logging into our web portal.
 Project Initiation Management -
Project Scope
• Suppose you need to build a defense application for national
surveillance for detecting attacks by an enemy.
• This kind of system requires confidential and limited access control,
a sophisticated and bullet-proof information system, fast and
accurate access to information, and extreme reliability.
• Definitely, such a software system needs to be of very high quality
in terms of reliability, security, correctness, and efficiency. A high
level of quality for such a software system translates into high effort
required for building this application
• In contrast, a game built for kids does not need to have such quality
requirements, and thus, the effort required to build that game will be
much less.
• So, a combination of a number of features and the quality level
determines the total volume of work. It is very important, early on in
the project, to clearly lay out these aspects so that the volume of
work can be determined.
 Project Initiation Management -
Project Objectives
• The project should have a set of well-defined
objectives that must be met. If any of these objectives
are not met upon completion of the project, then the
project will be considered to be a failure.
• The stakeholders state and set the project objectives.
• The objectives should be stated in clear language and
the set of objectives should be kept as small as
possible.
 Project Initiation Management -
Project Objectives
• Examples of project objectives could be,
– reducing/completely eliminating paper-based transactions
after implementation of the product
– to reduce transaction processing time, centralization of
marketing function across the organization
– to reduce costs, etc.
Sample Project Objectives :
• The organization will be able to increase customer
satisfaction to 99.5% from the existing level of 92%.
• This will help in reducing customer attrition,
increasing repeat business from existing customers,
and enhancing our brand value.
 Project Initiation Management -
Project Objectives
• If clear project objectives are set at the project
initiation, it would help the project team to
understand the importance of the project and will help
the team to do its best to achieve the goals.
 Project Initiation Management -
Practical Considerations
• One size does not fit all! You cannot have a cookie
cutter to create a project plan from a simple template.
• Different kinds of projects need different approaches.
• If you have a Web project, then you have entirely
different activities and tasks required to be completed
for the project, compared to a project to make a
software application for a mainframe computer.
• Similarly, the quality required for making a
surveillance application for a defense project will be of
higher quality, compared to an application made for
viewing information on the Web.
• Some of the factors that make project management
vary for different projects are as follows:
 Project Initiation Management -
Practical Considerations
▪ Project size: Project size is the single-most important
factor that makes the approach to handling one
project different from another. Smaller projects need
less formal project management than the larger ones.
• Product quality: If the software product to be made
requires stringent quality measures, then an elaborate
quality control mechanism will be required
throughout the project process to ensure that defects
are prevented in the product at each stage of
development.
• On the other hand, if the software product to be made
does not need stringent quality norms, then a cursory
quality control mechanism will be enough.
 Project Initiation Management -
Practical Considerations
▪ Technology: Technology plays an important role in
determining productivity on any project. If the
platform is some older technology, like a client
server, and the programming language is, say Ada,
then the project effort will be considerably more than
if a newer and more productive technology, say Java,
is used.
▪ Code reuse: Code reuse can considerably reduce the
required project effort.
▪ So, the effort on two projects will be very different if
one project code reuse has been extensively used,
compared to some other project where code reuse has
not been used.
 Project Initiation Management -
Practical Considerations
• Due to these factors, each project has different needs
for quality levels and has different productivity levels.
• Understanding these factors and taking them into
account when project initiation takes place will give a
proper start for the project.
• Project initiation is the right time when project
expectations, project scope, project deliverables,
quality standards, cost estimates, etc., should be
correctly set so that a good project plan can be made,
which in turn can lead to smooth project execution.
Example : Project Charter