SlideShare a Scribd company logo
1 of 62
The Software Process
• What? A software process – as a framework for the
tasks that are required to build high-quality software.
• Who does? Managers, software engineers, and customers.
• Why? Provides stability, control, and organization
otherwise chaotic(disorder) activity.
• Steps? General activities are common to all software
processes, details vary.
• Work product? Programs, documents, and data.
What is software Engg.?
• Definition :
– (1) The application of systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.
– (2) The study of approaches as in (1) above
• Its a discipline that is concerned with all aspects of software production.
• Software engineers should adopt
– Systematic and organized approach to their work
– Use appropriate tools and techniques depending on the problem
to be solved
– The development constraints and the resources available
• Apply Engineering Concepts to developing Software
• Challenge for Software Engineers is to produce high quality software with
finite amount of resources & within a predicted schedule
Software Engineering – Layered
Technology
Layered Technology
A quality focus: theA quality focus: the “bedrock“bedrock””
Process model: theProcess model: the “framework”“framework”
Methods: technicalMethods: technical “how to’s”“how to’s”
Tools: CASE preferredTools: CASE preferred
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 it is this culture ultimately leads to development
of increasingly more effective approaches to software engineering.
• The bedrock(foundation) 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 (KPA) 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
• Provides the glue that holds the layers together;
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)
Generic Process Framework
• A process framework establishes the
foundation for a complete software process
by identifying a small number of framework
activities.
• Frame work activities are applicable to all
software projects.
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, and others
are applied throughout the process.
 Next question is: how the framework activities and the
actions and tasks that occur within each activity are
organized with respect to sequence and time?
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.
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
– Encompasses requirements gathering and related activities
• Planning:
– Workflow that is to follow
– 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 Management or tracking and control
– Assessing progress against the project plan.
– Take adequate action(Sufficient) 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)
Capability Maturity Model
Integration (CMMI)
• The Software Engineering Institute (SEI) has developed
process meta-model to measure organization different level
of process capability and maturity.
• CMMI – developed by SEI
• The CMMI defines each process area in terms of “specific
goals” and the “specific practices” required to achieve these
goals.
• Specific goals establish the characteristics that must exist
if the activities implied by a process area are to be
effective.
• Specific practices refine a goal into a set of process-
related activities.
CMMI Level
Level 1: Initial. The software process is characterized as
ad hoc and occasionally even chaotic.
Few processes are defined, and success depends on individual effort.
Level 2: Repeatable. Basic project management processes
are established to track cost, schedule, and functionality.
The necessary process discipline is in place to repeat earlier successes on
projects with similar applications.
CMMI Level (cont.)
Level 3: Defined.
 The software process for both management and engineering activities is documented,
standardized, and integrated into an organization wide software process.
 All projects use a documented and approved version of the organization's process
for developing and supporting software.
 This level includes all characteristics defined for level 2.
Level 4 (Quantitatively Managed) -
– All level 3 criteria have been satisfied.
– Software process and products are quantitatively understood
– Controlled using detailed measures and assessment.
Level 5 (Optimized)
– This level includes all characteristics defined for level 4.
– Continuous process improvement is enabled by quantitative feedback from the
process and testing innovative ideas & technology
HemalKumar Rajyaguru
• The process model can be defined as the abstract representation of
process.
• 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.
Software process model /
SDLC
HemalKumar Rajyaguru
Waterfall Model or Classic Life
Cycle(CPMCD)
• Requirement Analysis and Definition: 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.
Waterfall Model or Classic Life
Cycle
Limitations of the waterfall model
 The nature of the requirements will not change very much During development;
during evolution
 The model implies that you should attempt to complete a given stage before
moving on to the next stage
 Does not account for the fact that requirements constantly change.
 It also means that customers can not use anything until the entire system is
complete.
 The model implies that once the product is finished, everything else is
maintenance.
 Surprises at the end are very expensive
 Some teams sit ideal for other teams to finish
 Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.
• Problems:
1. Real projects are rarely follow the sequential
model.
2. Difficult for the customer to state all the
requirement in advance.
3. Assumes patience from customer - working
version of program will not available until
programs not getting change fully.
Problem
When to use waterfall model
• Requirements are very well known, clear and
fixed
• Product definition is stable
• Technology is understood
• There are no ambiguous requirements
• Ample resources with required expertise are
available freely
• The project is short
Pros Cons
•Simple and easy to understand and use
•Easy to manage due to the rigidity of
the model .
•Each phase has specific deliverables and
a review process.
•Phases are processed and completed
one at a time.
•Works well for smaller projects where
requirements are very well understood.
•Clearly defined stages.
•Well understood milestones.
•Easy to arrange tasks.
•Process and results are well
documented.
•No working software is produced until late during
the life cycle.
•High amounts of risk and uncertainty.
•Not a good model for complex and object-
oriented projects.
•Poor model for long and ongoing projects.
•Not suitable for the projects where requirements
are at a moderate to high risk of changing. So risk
and uncertainty is high with this process model.
•It is difficult to measure progress within stages.
•Cannot accommodate changing requirements.
•No working software is produced until late in the
life cycle.
•Adjusting scope during the life cycle can end a
project.
•Integration is done as a "big-bang. at the very
end, which doesn't allow identifying any
technological or business bottleneck or challenges
early.
Waterfall Model with Feedback
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
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
• 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 obtain requirements for later
increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most
testing.
The Incremental Model
• Generates working software quickly and early during
the software life cycle.
• This model is more flexible – less costly to change
scope and requirements.
• It is easier to test and debug during a smaller
iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are
identified and handled during iteration
Advantages Incremental Model
• Needs good planning and design.
• Needs a clear and complete definition of the whole
system before it can be broken down and built
incrementally.
• Total cost is higher than waterfall.
Disadvantages Incremental Model
• This model can be used when the requirements of
the complete system are clearly defined and
understood.
• Major requirements must be defined; however,
some details can evolve with time.
• There is a need to get a product to the market early.
• A new technology is being used
• Resources with needed skill set are not available
• There are some high risk features and goals.
When to use Incremental Model ?
Rapid Application Development
(RAD) Model
Makes heavy use of reusable software components with
an extremely short development cycle
RAD model
• Communication – to understand business problem.
• Planning – multiple s/w teams works in parallel on diff. system.
• Modeling –
– Business modeling – Information flow among business is working.
Ex. What kind of information drives?
Who is going to generate information?
From where information comes and goes?
– Data modeling – Information refine into set of data objects that are
needed to support business.
– Process modeling – Data object transforms to information flow
necessary to implement business.
RAD model
• Construction – it highlighting the use of pre-existing
software component.
• Deployment – Deliver to customer basis for subsequent
iteration.
• RAD model emphasize a short development cycle.
• “High speed” edition of linear sequential model.
• If requirement are well understood and project scope is
constrained then it enable development team to create “ fully
functional system” within a very short time period.
RAD Model
Drawback:
• For large but scalable projects
– RAD requires sufficient human resources
• Projects fail if developers and customers are not
committed in a much shortened time-frame
• Problematic if system can not be modularized
• Not appropriate when technical risks are high
( heavy use of new technology)
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
Evolutionary Process Models :
Prototyping
Prototyping Model
• Best approach when:
– Objectives defines by customer are general.
– Developer may be unsure of the efficiency of an algorithm,
O.S., etc.
• It assist engineer and customer to better understand what is to
be built when requirement are fuzzy.
• Planned quickly and modeling (software layout visible to the
customers/end-user) occurs.
• Feedback from customer/end user will refine requirement.
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.
Prototyping (cont..)
Problem Areas:
Customer demand that “a few fixes” be applied
to make the prototype a working product, due
to that software quality suffers as a result.
Developer often makes implementation in order
to get a prototype working quickly without
considering other factors in mind like OS,
Programming language, etc.
Advantages Prototype Model
• Users are actively involved in the development
• Since in this methodology a working model of the system is
provided, the users get a better understanding of the system being
developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified
Requirements validation, Quick implementation of, incomplete,
but
functional, application.
Disadvantages Prototype Model
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the
system as scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as
the
full system was designed
Incomplete or inadequate problem analysis.
When to Use Prototype Model?
• Prototype model should be used when the desired system needs
to have a lot of interaction with the end users.
• Typically, online systems, web interfaces have a very high amount
of interaction with end users, are best suited for Prototype model.
• Prototyping ensures that the end users constantly work with the
system and provide a feedback which is incorporated in the
prototype to result in a useable system.
Evolutionary Model: Spiral Model
Spiral Model
 Couples iterative nature of prototyping with the
controlled and systematic aspects.
• 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.
• Unlike other process models that end when software
is delivered.
Spiral Model
Spiral Model
Advantages of Spiral Model
• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.
Disadvantages of Spiral Model
• Can be a costly model 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.
When to use Spiral Model
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential
changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)
Selection of a Life Cycle Model
Selection of a model is based on:
a) Requirements
b) Development team
c) Users
d) Project type and associated risk
50
Based On Characteristics Of
RequirementsRequirements Waterfall Prototype Iterative
enhancement
Evolutionary
development
Spiral RAD
Are requirements
easily
understandable
and defined?
Do we change
requirements
quite often?
Can we define
requirements
early in the
cycle?
Requirements
are indicating a
complex system
to be built
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
No
No
No
No
No
No No
No
No
No
No
No
51
Development
Team
Waterfall Prototype Iterative
enhancement
Evolutionary
development
Spiral RAD
Based On Status Of Development
Team
Less experience
on similar
projects?
Less domain
knowledge (new
to the
technology)
Less experience
on tools to be
used
Availability of
training if
required
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
Ye
s
No
No
No
NoNo
No No No
No
No
No
NoNo
52
Based On User’s Participation
53
Concurrent Model
• Allow a software team to represent iterative and concurrent
elements of any of the process models.
• The Figure shows modeling may be in any one of the states at any
given time.
• For example, communication activity has completed its first
iteration and in the awaiting changes state. The modeling activity
was in inactive state, now makes a transition into the under
development state.
• Concurrent modeling is applicable to all types of software
development and provides an accurate picture of the current state
of a project.
• Each activity, action or task on the network exists simultaneously
with other activities, actions or tasks.
Concurrent Model
Agile Process Model
• Agile SDLC model is a combination of iterative and
incremental process models with focus on process
adaptability and customer satisfaction by rapid
delivery of working software product.
Agile Process Model
• Agile Methods break the product into small
incremental builds.
• Every iteration involves cross functional teams
working simultaneously on various areas like
planning, requirements analysis, design, coding,
unit testing, and acceptance testing.
Advantages Agile Process Model
• Customer satisfaction by rapid, continuous delivery of
useful software.
• Customers, developers and testers constantly interact
with each other.
• Close, daily cooperation between business people and
developers.
• Continuous attention to technical excellence and good
design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed
Disadvantages Agile Process Model
• In case of some software, it is difficult to assess the effort
required at the beginning of the software development
life cycle.
• There is lack of emphasis on necessary designing and
documentation.
• The project can easily get taken off track if the customer
representative is not clear what final outcome that they
want.
• Only senior programmers are capable of taking the kind
of decisions required during the development process.
Component-based Development Model
• Consists of the following process steps
– Available component-based products are researched and
evaluated for the application domain in question
– Component integration issues are considered
– A software architecture is designed to accommodate the
components
– Comprehensive testing is conducted to ensure proper
functionality
• Relies on a robust component library
• Capitalizes on software reuse, which leads to documented
savings in project cost and time
Intoduction to software engineering part 2

More Related Content

What's hot

Cost of software quality ( software quality assurance )
Cost of software quality ( software quality assurance )Cost of software quality ( software quality assurance )
Cost of software quality ( software quality assurance )Kiran Hanjar
 
Introduction to software engineering
Introduction to software engineeringIntroduction to software engineering
Introduction to software engineeringHitesh Mohapatra
 
Requirement Engineering Lec.1 & 2 & 3
Requirement Engineering Lec.1 & 2 & 3Requirement Engineering Lec.1 & 2 & 3
Requirement Engineering Lec.1 & 2 & 3Ahmed Alageed
 
Software Engineering- Crisis and Process Models
Software Engineering- Crisis and Process ModelsSoftware Engineering- Crisis and Process Models
Software Engineering- Crisis and Process ModelsNishu Rastogi
 
Software myths | Software Engineering Notes
Software myths | Software Engineering NotesSoftware myths | Software Engineering Notes
Software myths | Software Engineering NotesNavjyotsinh Jadeja
 
Software Engineering (Requirements Engineering & Software Maintenance)
Software Engineering (Requirements Engineering  & Software Maintenance)Software Engineering (Requirements Engineering  & Software Maintenance)
Software Engineering (Requirements Engineering & Software Maintenance)ShudipPal
 
Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Fadhil Ismail
 
Requirements Engineering Processes
Requirements Engineering ProcessesRequirements Engineering Processes
Requirements Engineering ProcessesRa'Fat Al-Msie'deen
 
Software Engineering Process Models
Software Engineering Process Models Software Engineering Process Models
Software Engineering Process Models Satya P. Joshi
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assuranceEr. Nancy
 
Quality Concept
Quality ConceptQuality Concept
Quality ConceptAnand Jat
 
Software Configuration Management
Software Configuration ManagementSoftware Configuration Management
Software Configuration ManagementChandan Chaurasia
 
Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville,  Software Engineering, 9th Edition Ch1Ian Sommerville,  Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1Mohammed Romi
 
Real time and distributed design
Real time and distributed designReal time and distributed design
Real time and distributed designpriyapavi96
 

What's hot (20)

Cost of software quality ( software quality assurance )
Cost of software quality ( software quality assurance )Cost of software quality ( software quality assurance )
Cost of software quality ( software quality assurance )
 
Software Verification & Validation
Software Verification & ValidationSoftware Verification & Validation
Software Verification & Validation
 
Introduction to software engineering
Introduction to software engineeringIntroduction to software engineering
Introduction to software engineering
 
Requirement Engineering Lec.1 & 2 & 3
Requirement Engineering Lec.1 & 2 & 3Requirement Engineering Lec.1 & 2 & 3
Requirement Engineering Lec.1 & 2 & 3
 
Quality concept
Quality concept Quality concept
Quality concept
 
Software Engineering- Crisis and Process Models
Software Engineering- Crisis and Process ModelsSoftware Engineering- Crisis and Process Models
Software Engineering- Crisis and Process Models
 
Software myths | Software Engineering Notes
Software myths | Software Engineering NotesSoftware myths | Software Engineering Notes
Software myths | Software Engineering Notes
 
Software Engineering (Requirements Engineering & Software Maintenance)
Software Engineering (Requirements Engineering  & Software Maintenance)Software Engineering (Requirements Engineering  & Software Maintenance)
Software Engineering (Requirements Engineering & Software Maintenance)
 
Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Software System Engineering - Chapter 1
Software System Engineering - Chapter 1
 
Requirements Engineering Processes
Requirements Engineering ProcessesRequirements Engineering Processes
Requirements Engineering Processes
 
Software Engineering Process Models
Software Engineering Process Models Software Engineering Process Models
Software Engineering Process Models
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance
 
Algorithmic Software Cost Modeling
Algorithmic Software Cost ModelingAlgorithmic Software Cost Modeling
Algorithmic Software Cost Modeling
 
Unit 5
Unit   5Unit   5
Unit 5
 
Quality Concept
Quality ConceptQuality Concept
Quality Concept
 
Unit 2
Unit 2Unit 2
Unit 2
 
Software Configuration Management
Software Configuration ManagementSoftware Configuration Management
Software Configuration Management
 
Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville,  Software Engineering, 9th Edition Ch1Ian Sommerville,  Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1
 
Real time and distributed design
Real time and distributed designReal time and distributed design
Real time and distributed design
 
The Waterfall Model
The Waterfall ModelThe Waterfall Model
The Waterfall Model
 

Similar to Intoduction to software engineering part 2

Software Engineering (Software Process: A Generic View)
Software Engineering (Software Process: A Generic View)Software Engineering (Software Process: A Generic View)
Software Engineering (Software Process: A Generic View)ShudipPal
 
eUnit 2 software process model
eUnit 2  software process modeleUnit 2  software process model
eUnit 2 software process modelPreeti Mishra
 
Software Process in software engineering
Software Process in software engineeringSoftware Process in software engineering
Software Process in software engineeringMuhammadTalha436
 
Software Development Life Cycle (SDLC )
Software Development Life Cycle (SDLC )Software Development Life Cycle (SDLC )
Software Development Life Cycle (SDLC )eshtiyak
 
Lect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPMLect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPMMubashir Ali
 
Chapter 1,2,3,4 notes
Chapter 1,2,3,4 notesChapter 1,2,3,4 notes
Chapter 1,2,3,4 notesAruna M
 
UNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptx
UNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptxUNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptx
UNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptxLeahRachael
 
Software engineering 3 software process
Software engineering 3 software processSoftware engineering 3 software process
Software engineering 3 software processVaibhav Khanna
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process ModelsAtul Karmyal
 
Capability maturity model cmm lecture 8
Capability maturity model cmm lecture 8Capability maturity model cmm lecture 8
Capability maturity model cmm lecture 8Abdul Basit
 
Software process Models
Software process ModelsSoftware process Models
Software process ModelsSADEED AMEEN
 
Java learn from basic part chapter_01 short notes to understand the java quic...
Java learn from basic part chapter_01 short notes to understand the java quic...Java learn from basic part chapter_01 short notes to understand the java quic...
Java learn from basic part chapter_01 short notes to understand the java quic...GaytriMate
 
process models- software engineering
process models- software engineeringprocess models- software engineering
process models- software engineeringArun Nair
 
Software development life cycle
Software development life cycle Software development life cycle
Software development life cycle ParikshitTaksande1
 

Similar to Intoduction to software engineering part 2 (20)

Software Engineering (Software Process: A Generic View)
Software Engineering (Software Process: A Generic View)Software Engineering (Software Process: A Generic View)
Software Engineering (Software Process: A Generic View)
 
Software Development
Software DevelopmentSoftware Development
Software Development
 
Unit 1.pdf
Unit 1.pdfUnit 1.pdf
Unit 1.pdf
 
eUnit 2 software process model
eUnit 2  software process modeleUnit 2  software process model
eUnit 2 software process model
 
Software Process in software engineering
Software Process in software engineeringSoftware Process in software engineering
Software Process in software engineering
 
Software Development Life Cycle (SDLC )
Software Development Life Cycle (SDLC )Software Development Life Cycle (SDLC )
Software Development Life Cycle (SDLC )
 
Lect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPMLect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPM
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
 
Chapter 1,2,3,4 notes
Chapter 1,2,3,4 notesChapter 1,2,3,4 notes
Chapter 1,2,3,4 notes
 
UNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptx
UNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptxUNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptx
UNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptx
 
Software engineering 3 software process
Software engineering 3 software processSoftware engineering 3 software process
Software engineering 3 software process
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
 
Capability maturity model cmm lecture 8
Capability maturity model cmm lecture 8Capability maturity model cmm lecture 8
Capability maturity model cmm lecture 8
 
ecse ppt.pptx
ecse ppt.pptxecse ppt.pptx
ecse ppt.pptx
 
ecse ppt.pptx
ecse ppt.pptxecse ppt.pptx
ecse ppt.pptx
 
Software process Models
Software process ModelsSoftware process Models
Software process Models
 
Seminar on Project Management by Rj
Seminar on Project Management by RjSeminar on Project Management by Rj
Seminar on Project Management by Rj
 
Java learn from basic part chapter_01 short notes to understand the java quic...
Java learn from basic part chapter_01 short notes to understand the java quic...Java learn from basic part chapter_01 short notes to understand the java quic...
Java learn from basic part chapter_01 short notes to understand the java quic...
 
process models- software engineering
process models- software engineeringprocess models- software engineering
process models- software engineering
 
Software development life cycle
Software development life cycle Software development life cycle
Software development life cycle
 

More from Rupesh Vaishnav

Software maintenance and configuration management, software engineering
Software maintenance and  configuration management, software engineeringSoftware maintenance and  configuration management, software engineering
Software maintenance and configuration management, software engineeringRupesh Vaishnav
 
Software design, software engineering
Software design, software engineeringSoftware design, software engineering
Software design, software engineeringRupesh Vaishnav
 
Software coding & testing, software engineering
Software coding & testing, software engineeringSoftware coding & testing, software engineering
Software coding & testing, software engineeringRupesh Vaishnav
 
Software as a service, software engineering
Software as a service, software engineeringSoftware as a service, software engineering
Software as a service, software engineeringRupesh Vaishnav
 
Requirement analysis and specification, software engineering
Requirement analysis and specification, software engineeringRequirement analysis and specification, software engineering
Requirement analysis and specification, software engineeringRupesh Vaishnav
 
Quality assurance and management, software engineering
Quality assurance and management, software engineeringQuality assurance and management, software engineering
Quality assurance and management, software engineeringRupesh Vaishnav
 
Managing software project, software engineering
Managing software project, software engineeringManaging software project, software engineering
Managing software project, software engineeringRupesh Vaishnav
 
Intoduction to software engineering part 1
Intoduction to software engineering part 1Intoduction to software engineering part 1
Intoduction to software engineering part 1Rupesh Vaishnav
 
Agile development, software engineering
Agile development, software engineeringAgile development, software engineering
Agile development, software engineeringRupesh Vaishnav
 
Advanced topics in software engineering
Advanced topics in software engineeringAdvanced topics in software engineering
Advanced topics in software engineeringRupesh Vaishnav
 

More from Rupesh Vaishnav (10)

Software maintenance and configuration management, software engineering
Software maintenance and  configuration management, software engineeringSoftware maintenance and  configuration management, software engineering
Software maintenance and configuration management, software engineering
 
Software design, software engineering
Software design, software engineeringSoftware design, software engineering
Software design, software engineering
 
Software coding & testing, software engineering
Software coding & testing, software engineeringSoftware coding & testing, software engineering
Software coding & testing, software engineering
 
Software as a service, software engineering
Software as a service, software engineeringSoftware as a service, software engineering
Software as a service, software engineering
 
Requirement analysis and specification, software engineering
Requirement analysis and specification, software engineeringRequirement analysis and specification, software engineering
Requirement analysis and specification, software engineering
 
Quality assurance and management, software engineering
Quality assurance and management, software engineeringQuality assurance and management, software engineering
Quality assurance and management, software engineering
 
Managing software project, software engineering
Managing software project, software engineeringManaging software project, software engineering
Managing software project, software engineering
 
Intoduction to software engineering part 1
Intoduction to software engineering part 1Intoduction to software engineering part 1
Intoduction to software engineering part 1
 
Agile development, software engineering
Agile development, software engineeringAgile development, software engineering
Agile development, software engineering
 
Advanced topics in software engineering
Advanced topics in software engineeringAdvanced topics in software engineering
Advanced topics in software engineering
 

Recently uploaded

Input Output Management in Operating System
Input Output Management in Operating SystemInput Output Management in Operating System
Input Output Management in Operating SystemRashmi Bhat
 
US Department of Education FAFSA Week of Action
US Department of Education FAFSA Week of ActionUS Department of Education FAFSA Week of Action
US Department of Education FAFSA Week of ActionMebane Rash
 
"Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ..."Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ...Erbil Polytechnic University
 
IVE Industry Focused Event - Defence Sector 2024
IVE Industry Focused Event - Defence Sector 2024IVE Industry Focused Event - Defence Sector 2024
IVE Industry Focused Event - Defence Sector 2024Mark Billinghurst
 
welding defects observed during the welding
welding defects observed during the weldingwelding defects observed during the welding
welding defects observed during the weldingMuhammadUzairLiaqat
 
Correctly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleCorrectly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleAlluxio, Inc.
 
Autonomous emergency braking system (aeb) ppt.ppt
Autonomous emergency braking system (aeb) ppt.pptAutonomous emergency braking system (aeb) ppt.ppt
Autonomous emergency braking system (aeb) ppt.pptbibisarnayak0
 
Class 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm SystemClass 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm Systemirfanmechengr
 
Work Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvvWork Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvvLewisJB
 
Virtual memory management in Operating System
Virtual memory management in Operating SystemVirtual memory management in Operating System
Virtual memory management in Operating SystemRashmi Bhat
 
Crystal Structure analysis and detailed information pptx
Crystal Structure analysis and detailed information pptxCrystal Structure analysis and detailed information pptx
Crystal Structure analysis and detailed information pptxachiever3003
 
home automation using Arduino by Aditya Prasad
home automation using Arduino by Aditya Prasadhome automation using Arduino by Aditya Prasad
home automation using Arduino by Aditya Prasadaditya806802
 
TechTAC® CFD Report Summary: A Comparison of Two Types of Tubing Anchor Catchers
TechTAC® CFD Report Summary: A Comparison of Two Types of Tubing Anchor CatchersTechTAC® CFD Report Summary: A Comparison of Two Types of Tubing Anchor Catchers
TechTAC® CFD Report Summary: A Comparison of Two Types of Tubing Anchor Catcherssdickerson1
 
Crushers to screens in aggregate production
Crushers to screens in aggregate productionCrushers to screens in aggregate production
Crushers to screens in aggregate productionChinnuNinan
 
Mine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptxMine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptxRomil Mishra
 
Internet of things -Arshdeep Bahga .pptx
Internet of things -Arshdeep Bahga .pptxInternet of things -Arshdeep Bahga .pptx
Internet of things -Arshdeep Bahga .pptxVelmuruganTECE
 
Indian Dairy Industry Present Status and.ppt
Indian Dairy Industry Present Status and.pptIndian Dairy Industry Present Status and.ppt
Indian Dairy Industry Present Status and.pptMadan Karki
 
Risk Management in Engineering Construction Project
Risk Management in Engineering Construction ProjectRisk Management in Engineering Construction Project
Risk Management in Engineering Construction ProjectErbil Polytechnic University
 

Recently uploaded (20)

Input Output Management in Operating System
Input Output Management in Operating SystemInput Output Management in Operating System
Input Output Management in Operating System
 
US Department of Education FAFSA Week of Action
US Department of Education FAFSA Week of ActionUS Department of Education FAFSA Week of Action
US Department of Education FAFSA Week of Action
 
Designing pile caps according to ACI 318-19.pptx
Designing pile caps according to ACI 318-19.pptxDesigning pile caps according to ACI 318-19.pptx
Designing pile caps according to ACI 318-19.pptx
 
"Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ..."Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ...
 
IVE Industry Focused Event - Defence Sector 2024
IVE Industry Focused Event - Defence Sector 2024IVE Industry Focused Event - Defence Sector 2024
IVE Industry Focused Event - Defence Sector 2024
 
welding defects observed during the welding
welding defects observed during the weldingwelding defects observed during the welding
welding defects observed during the welding
 
Correctly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleCorrectly Loading Incremental Data at Scale
Correctly Loading Incremental Data at Scale
 
Autonomous emergency braking system (aeb) ppt.ppt
Autonomous emergency braking system (aeb) ppt.pptAutonomous emergency braking system (aeb) ppt.ppt
Autonomous emergency braking system (aeb) ppt.ppt
 
Class 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm SystemClass 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm System
 
Work Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvvWork Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvv
 
Virtual memory management in Operating System
Virtual memory management in Operating SystemVirtual memory management in Operating System
Virtual memory management in Operating System
 
Crystal Structure analysis and detailed information pptx
Crystal Structure analysis and detailed information pptxCrystal Structure analysis and detailed information pptx
Crystal Structure analysis and detailed information pptx
 
home automation using Arduino by Aditya Prasad
home automation using Arduino by Aditya Prasadhome automation using Arduino by Aditya Prasad
home automation using Arduino by Aditya Prasad
 
TechTAC® CFD Report Summary: A Comparison of Two Types of Tubing Anchor Catchers
TechTAC® CFD Report Summary: A Comparison of Two Types of Tubing Anchor CatchersTechTAC® CFD Report Summary: A Comparison of Two Types of Tubing Anchor Catchers
TechTAC® CFD Report Summary: A Comparison of Two Types of Tubing Anchor Catchers
 
Crushers to screens in aggregate production
Crushers to screens in aggregate productionCrushers to screens in aggregate production
Crushers to screens in aggregate production
 
Mine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptxMine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptx
 
Internet of things -Arshdeep Bahga .pptx
Internet of things -Arshdeep Bahga .pptxInternet of things -Arshdeep Bahga .pptx
Internet of things -Arshdeep Bahga .pptx
 
Indian Dairy Industry Present Status and.ppt
Indian Dairy Industry Present Status and.pptIndian Dairy Industry Present Status and.ppt
Indian Dairy Industry Present Status and.ppt
 
Risk Management in Engineering Construction Project
Risk Management in Engineering Construction ProjectRisk Management in Engineering Construction Project
Risk Management in Engineering Construction Project
 
young call girls in Green Park🔝 9953056974 🔝 escort Service
young call girls in Green Park🔝 9953056974 🔝 escort Serviceyoung call girls in Green Park🔝 9953056974 🔝 escort Service
young call girls in Green Park🔝 9953056974 🔝 escort Service
 

Intoduction to software engineering part 2

  • 1. The Software Process • What? A software process – as a framework for the tasks that are required to build high-quality software. • Who does? Managers, software engineers, and customers. • Why? Provides stability, control, and organization otherwise chaotic(disorder) activity. • Steps? General activities are common to all software processes, details vary. • Work product? Programs, documents, and data.
  • 2. What is software Engg.? • Definition : – (1) The application of systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. – (2) The study of approaches as in (1) above • Its a discipline that is concerned with all aspects of software production. • Software engineers should adopt – Systematic and organized approach to their work – Use appropriate tools and techniques depending on the problem to be solved – The development constraints and the resources available • Apply Engineering Concepts to developing Software • Challenge for Software Engineers is to produce high quality software with finite amount of resources & within a predicted schedule
  • 3. Software Engineering – Layered Technology Layered Technology A quality focus: theA quality focus: the “bedrock“bedrock”” Process model: theProcess model: the “framework”“framework” Methods: technicalMethods: technical “how to’s”“how to’s” Tools: CASE preferredTools: CASE preferred
  • 4. 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 it is this culture ultimately leads to development of increasingly more effective approaches to software engineering. • The bedrock(foundation) 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 (KPA) 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 • Provides the glue that holds the layers together;
  • 5. 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)
  • 6. Generic Process Framework • A process framework establishes the foundation for a complete software process by identifying a small number of framework activities. • Frame work activities are applicable to all software projects.
  • 7. 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, and others are applied throughout the process.  Next question is: how the framework activities and the actions and tasks that occur within each activity are organized with respect to sequence and time?
  • 8. 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.
  • 9. 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.
  • 10. Generic Process Framework Activities • Communication: – Heavy communication with customers, stakeholders, team – Encompasses requirements gathering and related activities • Planning: – Workflow that is to follow – 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
  • 11. Umbrella Activities • Software project Management or tracking and control – Assessing progress against the project plan. – Take adequate action(Sufficient) 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)
  • 12. Capability Maturity Model Integration (CMMI) • The Software Engineering Institute (SEI) has developed process meta-model to measure organization different level of process capability and maturity. • CMMI – developed by SEI • The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals. • Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective. • Specific practices refine a goal into a set of process- related activities.
  • 13. CMMI Level Level 1: Initial. The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends on individual effort. Level 2: Repeatable. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
  • 14. CMMI Level (cont.) Level 3: Defined.  The software process for both management and engineering activities is documented, standardized, and integrated into an organization wide software process.  All projects use a documented and approved version of the organization's process for developing and supporting software.  This level includes all characteristics defined for level 2. Level 4 (Quantitatively Managed) - – All level 3 criteria have been satisfied. – Software process and products are quantitatively understood – Controlled using detailed measures and assessment. Level 5 (Optimized) – This level includes all characteristics defined for level 4. – Continuous process improvement is enabled by quantitative feedback from the process and testing innovative ideas & technology
  • 16. • The process model can be defined as the abstract representation of process. • 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. Software process model / SDLC
  • 17. HemalKumar Rajyaguru Waterfall Model or Classic Life Cycle(CPMCD)
  • 18. • Requirement Analysis and Definition: 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. Waterfall Model or Classic Life Cycle
  • 19. Limitations of the waterfall model  The nature of the requirements will not change very much During development; during evolution  The model implies that you should attempt to complete a given stage before moving on to the next stage  Does not account for the fact that requirements constantly change.  It also means that customers can not use anything until the entire system is complete.  The model implies that once the product is finished, everything else is maintenance.  Surprises at the end are very expensive  Some teams sit ideal for other teams to finish  Therefore, this model is only appropriate when the requirements are well- understood and changes will be fairly limited during the design process.
  • 20. • Problems: 1. Real projects are rarely follow the sequential model. 2. Difficult for the customer to state all the requirement in advance. 3. Assumes patience from customer - working version of program will not available until programs not getting change fully. Problem
  • 21. When to use waterfall model • Requirements are very well known, clear and fixed • Product definition is stable • Technology is understood • There are no ambiguous requirements • Ample resources with required expertise are available freely • The project is short
  • 22. Pros Cons •Simple and easy to understand and use •Easy to manage due to the rigidity of the model . •Each phase has specific deliverables and a review process. •Phases are processed and completed one at a time. •Works well for smaller projects where requirements are very well understood. •Clearly defined stages. •Well understood milestones. •Easy to arrange tasks. •Process and results are well documented. •No working software is produced until late during the life cycle. •High amounts of risk and uncertainty. •Not a good model for complex and object- oriented projects. •Poor model for long and ongoing projects. •Not suitable for the projects where requirements are at a moderate to high risk of changing. So risk and uncertainty is high with this process model. •It is difficult to measure progress within stages. •Cannot accommodate changing requirements. •No working software is produced until late in the life cycle. •Adjusting scope during the life cycle can end a project. •Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.
  • 23. Waterfall Model with Feedback (Diagram) Communication Project initiation Requirements gathering Planning Estimating Scheduling Tracking Modeling Analysis Design Construction Code Test Deployment Delivery Support Feedback
  • 24. 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
  • 25. • 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
  • 26. • 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 obtain requirements for later increments. • Lower risk of overall project failure. • The highest priority system services tend to receive the most testing. The Incremental Model
  • 27. • Generates working software quickly and early during the software life cycle. • This model is more flexible – less costly to change scope and requirements. • It is easier to test and debug during a smaller iteration. • In this model customer can respond to each built. • Lowers initial delivery cost. • Easier to manage risk because risky pieces are identified and handled during iteration Advantages Incremental Model
  • 28. • Needs good planning and design. • Needs a clear and complete definition of the whole system before it can be broken down and built incrementally. • Total cost is higher than waterfall. Disadvantages Incremental Model
  • 29. • This model can be used when the requirements of the complete system are clearly defined and understood. • Major requirements must be defined; however, some details can evolve with time. • There is a need to get a product to the market early. • A new technology is being used • Resources with needed skill set are not available • There are some high risk features and goals. When to use Incremental Model ?
  • 30. Rapid Application Development (RAD) Model Makes heavy use of reusable software components with an extremely short development cycle
  • 31. RAD model • Communication – to understand business problem. • Planning – multiple s/w teams works in parallel on diff. system. • Modeling – – Business modeling – Information flow among business is working. Ex. What kind of information drives? Who is going to generate information? From where information comes and goes? – Data modeling – Information refine into set of data objects that are needed to support business. – Process modeling – Data object transforms to information flow necessary to implement business.
  • 32. RAD model • Construction – it highlighting the use of pre-existing software component. • Deployment – Deliver to customer basis for subsequent iteration. • RAD model emphasize a short development cycle. • “High speed” edition of linear sequential model. • If requirement are well understood and project scope is constrained then it enable development team to create “ fully functional system” within a very short time period.
  • 33. RAD Model Drawback: • For large but scalable projects – RAD requires sufficient human resources • Projects fail if developers and customers are not committed in a much shortened time-frame • Problematic if system can not be modularized • Not appropriate when technical risks are high ( heavy use of new technology)
  • 34. 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
  • 36. Prototyping Model • Best approach when: – Objectives defines by customer are general. – Developer may be unsure of the efficiency of an algorithm, O.S., etc. • It assist engineer and customer to better understand what is to be built when requirement are fuzzy. • Planned quickly and modeling (software layout visible to the customers/end-user) occurs. • Feedback from customer/end user will refine requirement.
  • 37. 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.
  • 38. Prototyping (cont..) Problem Areas: Customer demand that “a few fixes” be applied to make the prototype a working product, due to that software quality suffers as a result. Developer often makes implementation in order to get a prototype working quickly without considering other factors in mind like OS, Programming language, etc.
  • 39. Advantages Prototype Model • Users are actively involved in the development • Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed. • Errors can be detected much earlier. • Quicker user feedback is available leading to better solutions. • Missing functionality can be identified easily • Confusing or difficult functions can be identified Requirements validation, Quick implementation of, incomplete, but functional, application.
  • 40. Disadvantages Prototype Model • Leads to implementing and then repairing way of building systems. • Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans. • Incomplete application may cause application not to be used as the full system was designed Incomplete or inadequate problem analysis.
  • 41. When to Use Prototype Model? • Prototype model should be used when the desired system needs to have a lot of interaction with the end users. • Typically, online systems, web interfaces have a very high amount of interaction with end users, are best suited for Prototype model. • Prototyping ensures that the end users constantly work with the system and provide a feedback which is incorporated in the prototype to result in a useable system.
  • 43. Spiral Model  Couples iterative nature of prototyping with the controlled and systematic aspects. • 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. • Unlike other process models that end when software is delivered.
  • 46. Advantages of Spiral Model • High amount of risk analysis hence, avoidance of Risk is enhanced. • Good for large and mission-critical projects. • Strong approval and documentation control. • Additional Functionality can be added at a later date. • Software is produced early in the software life cycle.
  • 47. Disadvantages of Spiral Model • Can be a costly model 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.
  • 48. When to use Spiral Model • When costs and risk evaluation is important • For medium to high-risk projects • Long-term project commitment unwise because of potential changes to economic priorities • Users are unsure of their needs • Requirements are complex • New product line • Significant changes are expected (research and exploration)
  • 49. Selection of a Life Cycle Model Selection of a model is based on: a) Requirements b) Development team c) Users d) Project type and associated risk
  • 50. 50 Based On Characteristics Of RequirementsRequirements Waterfall Prototype Iterative enhancement Evolutionary development Spiral RAD Are requirements easily understandable and defined? Do we change requirements quite often? Can we define requirements early in the cycle? Requirements are indicating a complex system to be built Ye s Ye s Ye s Ye s Ye s Ye s Ye s Ye s Ye s Ye s Ye s Ye s No No No No No No No No No No No No
  • 51. 51 Development Team Waterfall Prototype Iterative enhancement Evolutionary development Spiral RAD Based On Status Of Development Team Less experience on similar projects? Less domain knowledge (new to the technology) Less experience on tools to be used Availability of training if required Ye s Ye s Ye s Ye s Ye s Ye s Ye s Ye s Ye s Ye s Ye s No No No NoNo No No No No No No NoNo
  • 52. 52 Based On User’s Participation
  • 53. 53
  • 54. Concurrent Model • Allow a software team to represent iterative and concurrent elements of any of the process models. • The Figure shows modeling may be in any one of the states at any given time. • For example, communication activity has completed its first iteration and in the awaiting changes state. The modeling activity was in inactive state, now makes a transition into the under development state. • Concurrent modeling is applicable to all types of software development and provides an accurate picture of the current state of a project. • Each activity, action or task on the network exists simultaneously with other activities, actions or tasks.
  • 56. Agile Process Model • Agile SDLC model is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product.
  • 57. Agile Process Model • Agile Methods break the product into small incremental builds. • Every iteration involves cross functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing, and acceptance testing.
  • 58.
  • 59. Advantages Agile Process Model • Customer satisfaction by rapid, continuous delivery of useful software. • Customers, developers and testers constantly interact with each other. • Close, daily cooperation between business people and developers. • Continuous attention to technical excellence and good design. • Regular adaptation to changing circumstances. • Even late changes in requirements are welcomed
  • 60. Disadvantages Agile Process Model • In case of some software, it is difficult to assess the effort required at the beginning of the software development life cycle. • There is lack of emphasis on necessary designing and documentation. • The project can easily get taken off track if the customer representative is not clear what final outcome that they want. • Only senior programmers are capable of taking the kind of decisions required during the development process.
  • 61. Component-based Development Model • Consists of the following process steps – Available component-based products are researched and evaluated for the application domain in question – Component integration issues are considered – A software architecture is designed to accommodate the components – Comprehensive testing is conducted to ensure proper functionality • Relies on a robust component library • Capitalizes on software reuse, which leads to documented savings in project cost and time

Editor's Notes

  1. Provides the glue that holds the layers together; enables rational and timely development; provides a framework for effective delivery of technology; forms the basis for management; provides the context for technical methods, work products, milestones, quality measures, and change management
  2. Process Provides the glue that holds the layers together; enables rational and timely development; provides a framework for effective delivery of technology; forms the basis for management; provides the context for technical methods, work products, milestones, quality measures, and change management