software engineering process model
-
Upload
nimmithegreat -
Category
Documents
-
view
225 -
download
2
description
Transcript of software engineering process model
![Page 1: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/1.jpg)
Text Books:1.Software Engineering, A practitioner’s approach Roger s. Pressman 6th edition McGraw-Hill
2.Software Engineering Somerville 7th edition
1
![Page 2: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/2.jpg)
Introduction to software Engineering
The Evolving role of software• Dual role of Software
A Product - Information transformer- producing, managing and displayingA Vehicle for delivering a product - Control of computer(operating system),the
communication of information(networks) and the creation of other programs
2
![Page 3: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/3.jpg)
Introduction to software Engineering
• Software is defined as1. Instructions
- Programs that when executed provide desired function
2. Data structures -Enable the programs to adequately manipulate information 3. Documents -Describe the operation and use of the
programs.
3
![Page 4: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/4.jpg)
Introduction to software Engineering
• Definition of Engineering -Application of science, tools and methods to find cost effective
solution to problems Definition of SOFTWARE ENGINEERING - SE is defined as systematic, disciplined and quantifiable
approach for the development, operation and maintenance of software
4
![Page 5: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/5.jpg)
Characteristics of software compared with hardware• Software is developed or engineered, it is not manufactured
in the classical sense.• Software does not wear out. However it deteriorates due to
change.• Software is custom built rather than assembling existing
components. -Although the industry is moving towards component based
construction, most software continues to be custom built
5
![Page 6: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/6.jpg)
CHARACTERISTICS OF HARDWARE
Failu
re ra
te
Time
“Infant mortality” “Wear out”
Fig: FAILURE CURVE FOR HARDWARE6
![Page 7: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/7.jpg)
CHARACTERISTICS OF SOFTWARE
Fig: FAILURE CURVE FOR SOFTWARE
7
![Page 8: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/8.jpg)
THE CHANGING NATURE OF SOFTWARE
• Seven Broad Categories of software are challenges for software engineers
System software Application software Engineering and scientific software Embedded software Product-line software Web-applications Artificial intelligence software
8
![Page 9: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/9.jpg)
THE CHANGING NATURE OF SOFTWARE
• System software. System software is a collection of programs written to service other programs
• Embedded software -- resides in read-only memory --is used to control products and systems for the consumer and
industrial markets.
• Artificial intelligence software. Artificial intelligence (AI) software makes use of nonnumeric algorithms to solve complex problems that are not amenable to computation or straightforward analysis
• Engineering and scientific software. Engineering and scientific software have been characterized by "number crunching" algorithms.
9
![Page 10: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/10.jpg)
LEGACY SOFTWARE
• Legacy software are older programs that are developed decades ago– quality of legacy software is poor
• inextensible design , convoluted code• poor and nonexistent documentation,• test cases and results that are not achieved.
10
![Page 11: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/11.jpg)
Legacy systems evolve due to following reasons:The software must be adapted to meet the needs of new
computing environment or technology.The software must be enhanced to implement new
business requirements.The software must be extended to make it interoperable
with more modern systems or databaseThe software must be rearchitected to make it viable
within a network environment.
11
![Page 12: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/12.jpg)
Software Evolution
• Software evolves due to changes• Changes occur due to correction,adaption and enhancement• 8 Laws of unified theory
The Law of Continuing Change. The Law of Increasing Complexity. The Law of Self-Regulation The Law of Conservation of Organizational Stability. The Law of Conservation of Familiarity The Law of Continuing Growth The Law of Declining Quality The Feedback System Law
12
![Page 13: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/13.jpg)
13
![Page 14: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/14.jpg)
• High rate of change of user requirements and environment on which software is working
• Large software• Cost• Scalability etc
14
![Page 15: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/15.jpg)
15
![Page 16: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/16.jpg)
![Page 17: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/17.jpg)
17
![Page 18: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/18.jpg)
• An activity – strives to achieve a broad objective and– applied regardless of the application domain
and size of the project• An action
– encompasses a set of tasks that produce a major work product
– (e.g., architectural design)
• A task– focuses on a small, but well-defined objective
that produces a tangible outcome– (e.g., conducting a unit test
18
![Page 19: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/19.jpg)
SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY
19
![Page 20: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/20.jpg)
SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY
• Quality focus - Bedrock that supports software Engineering
eg :Total quality management, Six Sigma• Process
– Foundation for software Engineering– The software process forms the basis for management control
of software projects and – establishes the context in which technical methods are applied, – work products are produced, – milestones are established,– quality is ensured, and – change is properly managed.
20
![Page 21: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/21.jpg)
• Methods - Provide 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.
• Tools - Provide semi-automatic and automatic support for
process and methods
21
![Page 22: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/22.jpg)
A PROCESS FRAMEWORK
• Establishes the foundation for a complete software process• Identifies a number of framework activities applicable to all
software projects• Also include a set of umbrella activities that are applicable
across the entire software process.
22
![Page 23: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/23.jpg)
23
![Page 24: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/24.jpg)
24
![Page 25: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/25.jpg)
25
![Page 26: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/26.jpg)
• Communication– Heavy Communication and collaboration with customer – Encompasses requirement gathering and other related
activity • Planning
– Establishes plan for software engineering work – It describe the technical task to be conducted – Risk that are likely to occur and the resource requirement– The work product to be produce and work schedule
26
![Page 27: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/27.jpg)
• Modeling – encompasses the creation of model that allow the developer
and customer to better understand software requirement– The deign that will achieve those requirement
• Construction– code generation – Testing required to un cover error in a code
• Deployment– The software is delivered to customer – Customers evaluate and give feedback based on evaluation
27
![Page 28: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/28.jpg)
process flow
• Describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time
– A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment
28
![Page 29: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/29.jpg)
• An iterative process flow repeats one or more of the activities before proceeding to the next
29
![Page 30: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/30.jpg)
• An evolutionary process flow executes the activities in a “circular”manner.
• Each circuit through the five activities leads to a more complete version of the software
30
![Page 31: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/31.jpg)
• A parallel process flow executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software might be executed in parallel with construction of another aspect of the software).
31
![Page 32: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/32.jpg)
32
![Page 33: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/33.jpg)
• Software project tracking and control—– allows the software team to assess progress against the project plan – take any necessary action to maintain the schedule.
33
![Page 34: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/34.jpg)
• Risk management—– assesses risks that may affect the outcome of the
project or the quality of the product.• Steps
– Risk identification – Risk prioritization– Risk treatment
34
![Page 35: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/35.jpg)
• Software quality assurance—defines and conducts the activities required to ensure software quality.
• Technical reviews—assesses software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity.
35
![Page 36: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/36.jpg)
• Measurement—– defines and collects process, project, and product
measures that assist the team in delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities.
• Software configuration management—– manages the effects of change throughout the
software process.
36
![Page 37: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/37.jpg)
• Reusability management—– defines criteria for work product reuse (including
software components) 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.
37
![Page 38: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/38.jpg)
![Page 39: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/39.jpg)
CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
• Developed by SEI(Software Engineering institute)
• CMMI process meta model that defines the process characteristics that should exist if an organization wants to establish a software process that is complete
• CMMI can be represented in different ways1.A continuous model2.A staged model
39
![Page 40: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/40.jpg)
40
Focus of CMMI
SW-CMM is applied here
CMMI is applied here
![Page 41: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/41.jpg)
41
Bridging the Divide
CMMI:•Integrates systems and
software disciplines into one process improvement framework.
•Provides a framework for introducing new disciplines as needs arise.
![Page 42: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/42.jpg)
42
Staged Representation• Provides a proven sequence of improvements, each serving
as a foundation for the next• Permits comparisons across and among organizations by the
use of maturity levels
Indicates maturity of an organization’s standard process -- to answer
“What is a good order for approaching improvement across the organization?”
![Page 43: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/43.jpg)
43
![Page 44: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/44.jpg)
44
Maturity Levels
• A maturity level is a well-defined evolutionary plateau of process improvement.
• There are five maturity levels.
• Each level is a layer in the foundation for continuous process improvement using a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels.
![Page 45: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/45.jpg)
45
The Maturity Levels
1
2
3
4
5
Process unpredictable, poorly controlled, and reactive
Process characterized for projects and is often reactive
Process characterized for the organization and is proactive
Process measuredand controlled
Focus on continuous process improvement
Optimizing
QuantitativelyManaged
Defined
Initial
Managed
Optimizing
Defined
![Page 46: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/46.jpg)
Continuous model:
• Lets organization select specific improvement that best meet its business objectives and minimize risk
• Levels are called capability levels.• Describes a process in 2 dimensions• Each process area is assessed against specific goals
and practices and is rated according to the following capability levels.
46
![Page 47: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/47.jpg)
47
Continuous Representation• Allows you to select the order of improvement that best meets
your organization’s business objectives and mitigates your organization’s areas of risk
• Enables comparisons across and among organizations on a process-area-by-process-area basis
• Provides an easy migration from other models with a continuous representation to CMMI
Indicates improvement within a single process area -- to answer,
“What is a good order for approaching improvement of this process area?”
![Page 48: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/48.jpg)
48
![Page 49: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/49.jpg)
49
Capability Levels• A capability level is a well-defined evolutionary plateau
describing the organization’s capability relative to a process area.
• There are six capability levels.• For capability levels 1-5, there is an associated generic
goal.• Each level is a layer in the foundation for continuous
process improvement.• Thus, capability levels are cumulative, i.e., a higher
capability level includes the attributes of the lower levels.
![Page 50: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/50.jpg)
50
The Capability Levels
5 Optimizing
4 Quantitatively Managed
3 Defined
2 Managed
1 Performed
0 Incomplete
![Page 51: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/51.jpg)
51
Model Components• Process Areas (PA)
– Specific Goals (SG) Required• Specific Practices (SP) Expected
– Typical Work Products Informative– Sub-practices Informative– Notes Informative– Discipline Amplifications Informative– References Informative
– Generic Goals (GG) Required• Generic Practices (GP) Expected
– Generic Practice Elaborations Informative
![Page 52: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/52.jpg)
Specific Practices (CL1 - “Base Practices”)
SP1.1-1:Estimate the Scope of the Project
SP1.2-1:Establish Estimates of Work Product and Task Attributes
SP1.3-1:Define Project Life CycleSP1.4-1:Determine Estimates of
Effort and CostSP2.1-1:Establish Budget and
ScheduleSP2.2-1:Identify Project RisksSP2.3-1:Plan for Data ManagementSP2.4-1:Plan for Project ResourcesSP2.5-1:Plan for Needed Knowledge
and SkillsSP2.6-1:Plan Stakeholder
Involvement
PP - Capability Level 1Project Planning
Generic Practices (CL1))
GP1.1: Perform Base Practices
If all of the base practices are performed,
Then, the associated Specific Goals and Generic Goal 1 are satisfied,
So, the Process Area is rated at Capability Level 1 (CL1) - Performed.
SP2.7-1:Establish the Project PlanSP3.1-1:Review Plans that Affect the
ProjectSP3.2-1:Reconcile Work and Resource
LevelsSP3.3-1:Obtain Plan Commitment
![Page 53: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/53.jpg)
CMMI
• INCOMPLETE -Process is adhoc.Objective and goal of process areas are not
known
• Performed -Goal,objective,work tasks,work products and other activities of
software process are carried out
• Managed -Activities are monitored, reviewed, evaluated and controlled
• Defined -Activities are standardized, integrated and documented
53
![Page 54: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/54.jpg)
• Quantitatively Managed -Metrics and indicators are available to measure the process
and quality - Defect Prevention
• Optimized - Continuous process improvement based on quantitative feed
back from the user -Use of innovative ideas and techniques, statistical quality
control and other methods for process improvement.
54
![Page 55: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/55.jpg)
Maturity levelsLEVEL FOCUS PROCESS AREAOptimizing Continuous process
Improvement-Organizational Innovation and Deployment -Causal Analysis and Resolution
Quantitatively managed
Quantitative management
-Organizational process performance-Quantitative project management
Defined Process standardized Requirements Development Technical Solution Product IntegrationVerification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management 55
![Page 56: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/56.jpg)
−Integrated Teaming−Integrated Supplier Management−Decision Analysis and Resolution−Organizational Environment for Integration
Managed Basic project management Requirements ManagementProject Planning Project Monitoring and Control Supplier Agreement Measurement and Analysis Process and Product Quality Assurance Configuration Management
Performed
56
![Page 57: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/57.jpg)
SW-CMM V1.1 vs. CMMI V1.1
Defect Prevention Causal Analysis and ResolutionTechnology Change Mgmt Organizational Innovation & DeploymentProcess Change Management
Quantitative Process Mgmt Organizational Process PerformanceSoftware Quality Mgmt Quantitative Project Management
Organization Process Focus Organization Process Focus Organization Process Definition Organization Process DefinitionTraining Program Organizational TrainingIntegrated Software Mgmt Integrated Project Management
Risk ManagementSoftware Product Engr Requirements Development
Technical SolutionProduct Integration
Intergroup Coordination VerificationPeer Reviews Validation
Decision Analysis and Resolution
Requirements Management Requirements ManagementSoftware Project Planning Project PlanningSoftware Project Tracking & Oversight Project Monitoring and ControlSoftware Subcontract Mgmt Supplier Agreement ManagementSoftware Quality Assurance Product & Process Quality Assurance Software Configuration Mgmt Configuration Management
Measurement and Analysis
LEVEL 5OPTIMIZING
LEVEL 4MANAGED
LEVEL 3DEFINED
LEVEL 2REPEATABLE
57
Key Process Areas (KPAs)
Process Areas (PAs)
![Page 58: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/58.jpg)
PROCESS ASSESSMENT
• Does not specify the quality of the software or whether the software will be delivered on time or will it stand up to the user requirements.
• It attempts to keep a check on the current state of the software process with the intention of improving it.
58
![Page 59: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/59.jpg)
PROCESS ASSESSMENT
Software Process
Software ProcessAssessment
Software Process improvement
Capability determinationMotivates
Lead
s to
Leads to
Identi
fies
Modific
ation
to
Identi
fies
Capabilities & Risk
Examined
by
![Page 60: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/60.jpg)
APPROACHES TO SOFTWRE ASSESSMENT
• Standard CMMI assessment (SCAMPI)• CMM based appraisal for internal process improvement• SPICE(ISO/IEC 15504)• ISO 9001:2000 for software
• Refer PROCESS ASSESSMENT.ppt• ProcessAssessmentMethod.ppt• process_assmnt.docx
60
![Page 61: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/61.jpg)
Personal and Team Software Process
• Personal software process PLANNING HIGH LEVEL DESIGN HIGH LEVEL DESIGN REVIEW DEVELOPMENT POSTMORTEM
61
![Page 62: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/62.jpg)
Personal and Team Software Process
• Team software process Goal of TSP- Build self-directed teams- Motivate the teams - Acceptance of CMM level 5 behavior as normal to accelerate
software process improvement- Provide improvement guidance to high maturity organization- Refer psp.doc- psp.docx
62
![Page 63: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/63.jpg)
CLASSICAL WATERFALL MODEL
63
Communication Planning
ModelingConstruction
Deployment analysis design code
test
project initiation requirement gathering estimating
scheduling tracking
delivery support feedback
By Royce:
![Page 64: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/64.jpg)
64
Sl no
advantages disadvantages When to use
1 It allows for departmentalization and managerial control.
it assumes that no development error is ever committed by the engineers during any of the life cycle phases. However, in practical development environments, the engineers do commit a large number of errors in almost every phase of the life cycle
Requirements are well understood
2 Simple and easy to understand and use
It is difficult for customer to state all requirements explicitly(without any change)
Automation of existing manual system
3 Phases are processed and completed one at a time.
Working version of software will not be available until late in project span
Short duration project
4 Works well for smaller projects where requirements are very well understood.
User feedback not encouragedNot a good model for complex and object-oriented projects.
5 A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a car-wash, and theoretically, be delivered on time.
. Once a defect is detected, the engineers need to go back to the phase where the defect had occurred and redo some of the work done during that phase and the subsequent phases to correct the defect and its effect on the later phases
![Page 65: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/65.jpg)
• Incremental Process Models• The Incremental Model• The RAD Model
65
![Page 66: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/66.jpg)
66
![Page 67: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/67.jpg)
67
5
Sl no advantages disadvantages When to use
1 Generates working software quickly and early during the software life cycle.
Needs good planning and design.
when the requirements of the complete system are clearly defined and understood.
2 Lowers initial delivery cost.
Total cost is higher than waterfall.
A new technology is being used
3 Easier to manage risk because risky pieces are identified and handled during individual iteration.
Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.
Staffing is not available for complete implementation of project
4 It is easier to test and debug during a smaller iteration.In this model customer can respond to each built.
There are some high risk features and goals.
5 This model is more flexible – less costly to change scope and requirements.
![Page 68: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/68.jpg)
68
Communication
Planning
Modelingbusiness modeling data modeling process modeling
Constructioncomponent reuse automatic code generation testing
Deployment
60 - 90 days
Team # 1
Modelingbusiness modeling data modeling process modeling
Constructioncomponent reuse automatic code generat ion test ing
Modelingbusiness modeling data modeling process modeling
Const ruct ioncomponent reuse automatic code generation testing
Team # 2
Team # n
integration delivery feedback
RAD
![Page 69: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/69.jpg)
69
Sl advantages disadvantages When to use
1 Progress can be measured.Iteration time can be short with use of powerful RAD tools.
Dependency on technically strong team members for identifying business requirements.
Sufficient human recourse is needed to create right no of RAD team
Suitable for project requiring shorter development times.
2 Integration from very beginning solves a lot of integration issues.
Only system that can be modularized can be built using RAD.
Sufficient human recourse is needed to create right no of RAD team
Requirements are understood and project scope is constrained
3 Encourages customer feedback, Changing requirements can be accommodated.
Requires highly skilled developers/designers.High dependency on modeling skills.
Performances issue
Fully functional system is to be delivered in short span of time
4 Reduced development time.Increases reusability of components
Management complexity is more.Suitable for systems that are component based and scalable
For large, but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams.
5 Productivity with fewer people in short time. Requires user involvement throughout the life cycle.
Inapplicable to cheaper projects as cost of modeling and automated code generation is very high
![Page 70: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/70.jpg)
• Evolutionary Process Model• Prototype• Spiral model
70
![Page 71: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/71.jpg)
Prototype
71
![Page 72: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/72.jpg)
Prototype
72
Communication
Quick plan
Construction of prototype
Modeling Quick design
Delivery & Feedback
Deployment
![Page 73: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/73.jpg)
73
Sl advantages disadvantages When to use
1 Provides a working model to the user early in the process, enabling early assessment and increasing user's confidence.
If the user is not satisfied by the developed prototype, then a new prototype is developed. This process goes on until a perfect prototype is developed. Thus, this model is time consuming and expensive.
User requirements are not complete
2 serves to clarify requirements, which are not clear, hence reducing ambiguity and improving communication between the developers and users.
The developer loses focus of the real purpose of prototype and hence, may compromise with the quality of the software. For example, developers may use some inefficient algorithms while developing the prototype.
Technical issues are not clear
3 Helps in reducing risks associated with the software.
Prototyping can lead to false expectations “customer sees what appears to be a working version of the Software”.
4 User feedback not encouraged The primary goal of prototyping is speedy development, thus, the system design can suffer as it is developed in series without considering integration of all other components
5 The developer gains experience and insight by developing a prototype there by resulting in better implementation of requirements.
![Page 74: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/74.jpg)
Spiral model:Invented by Dr. Barry Boehm
74
communication
planning
modeling
constructiondeployment delivery feedback
start
analysis design
code test
estimation scheduling risk analysis
![Page 75: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/75.jpg)
75
Sl advantages disadvantages When to use
1 Avoids the problems resulting in risk-driven approach in the softwareRe-evaluation after each step allows changes in user perspectives, technology advances, or financial perspectives.
Assessment of project risks and its resolution is not an easy task.
Spiral may go indefinitely
End of project may not be known early
suitable for development of technically challenging software products that are prone to several kinds of risks
2 Specifies a mechanism for software quality assurance activities
Difficult to estimate budget and schedule in the beginning as some of the analysis is not done until the design of the software is developed.
Projects build on untested assumptions
3 Development can be divided into smaller parts and more risky parts can be developed earlier which helps better risk management
It demands considerable risk assessment expertise and relies on this expertise for success
Is utilized by complex and dynamic projects
4 Allows for extensive use of prototypes
If risks is not uncovered and managed problems will surely occur
5 Estimation of budget and schedule gets realistic as the work progresses.
Large number of intermediate stages requires excessive documentation.
![Page 76: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/76.jpg)
76
![Page 77: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/77.jpg)
77
Under review
Baselined
Done
Underrevision
Awaitingchanges
Underdevelopment
none
Modeling activity
represents the stateof a software engineeringactivity or task
![Page 78: software engineering process model](https://reader036.fdocuments.us/reader036/viewer/2022062819/577c85551a28abe054bcb2d3/html5/thumbnails/78.jpg)
78