Process models
-
Upload
preeti-mishra -
Category
Software
-
view
114 -
download
0
description
Transcript of Process models
![Page 1: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/1.jpg)
Process ModelsProcess Models
(Unit 2)(Unit 2)
Preeti MishraCourse Incharge
![Page 2: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/2.jpg)
The Details
![Page 3: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/3.jpg)
Process Model
• A software process model is a standardised format for:
• planning• organising, and• Running
developing a project• Definition: A (software/system) process model
is a description of the sequence of activities carried out in an SE project, and the relative order of these activities.
![Page 4: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/4.jpg)
Project Plan
• project plan =process model + project parameters
• Project specific parameters will include:• Size, (person-years)• Budget,• Duration
![Page 5: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/5.jpg)
Hence..
• A process model covers the entire lifetime of a product
• From birth of a commercial idea to final de-installation of last release
• The three main phases:– design,– build,– maintain. (50% of IT activity goes here!)
![Page 6: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/6.jpg)
Process Models
• Several models exist to streamline the development process.
• Each one has its pros and cons• It is up to the development team to adopt
the most appropriate one for the project. • Sometimes a combination of the models may
be more suitable.
![Page 7: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/7.jpg)
Code and Fix
![Page 8: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/8.jpg)
Code and Fix
code firstversion
retirement
operations mode
modify untilclient is satisfied
![Page 9: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/9.jpg)
Advantages
• No planning whatsoever; little management overhead
• Applicable for very small projects and short-lived prototypes
• Signs of progress early• Low expertise- anyone can use it
![Page 10: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/10.jpg)
Disadvantages
• Dangerous!• No visibility/control• No resource Planning• No Deadline• Mistakes hard to detect and correct
• Code becomes expensive to fix (bugs are not found until late in the process)
• Code didn't match user's needs (no requirements!)
• Code was not planned for modification, not flexible
![Page 11: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/11.jpg)
The Waterfall Model
• The waterfall model is sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of
• Conception• Initiation• Analysis• Design• Construction• Testing• Production/Implementation• Maintenance
![Page 12: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/12.jpg)
![Page 13: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/13.jpg)
Advantages
• This model is simple and easy to understand and use.
• It is easy to manage• In this model phases are processed and
completed one at a time. Phases do not overlap.• Waterfall model works well for smaller
projects where requirements are very well understood.
![Page 14: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/14.jpg)
Disadvantages
• Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
![Page 15: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/15.jpg)
Disadvantages..
• 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.
![Page 16: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/16.jpg)
When to use Waterfall Model
• This model is used only when the 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.
![Page 17: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/17.jpg)
Incremental and Iterative Development models
![Page 18: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/18.jpg)
Approach for developing a system
• Incremental Development Model
• Iterative Development Model
![Page 19: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/19.jpg)
Incremental Development-staging and scheduling strategy
• Incrementally add software a time. • Each increment adds more software.• Its like adding bricks to a wall. After
lots of increments, you've got a big wall.
![Page 20: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/20.jpg)
Incremental Development
• Various parts of the system are developed at different times or rates, and integrated as they are completed
• Develop the entire system with a “big bang” integration.”
![Page 21: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/21.jpg)
Iterative Development-rework scheduling strategy
• We build something, then evaluate whether it'll work for us, then we make changes to it.
• We are expecting to change it.• We never expected it to be right. If it was,
it's a happy accident• Iterative” development helps you improve
your product. Each time around the process you get to change and improve the product itself
![Page 22: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/22.jpg)
Remember..
• Incremental fundamentally means add onto. – Incremental development helps you improve
your process. •
Iterative fundamentally means re-do. – Iterative development helps you improve
your product.
![Page 23: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/23.jpg)
![Page 24: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/24.jpg)
Spiral ModelSpiral Model
•This model was first described This model was first described by Barry Boehm in his 1986by Barry Boehm in his 1986
![Page 25: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/25.jpg)
Spiral Model
• The spiral is simply a sequence of waterfall increments;
• All project activities follow a single spiral sequence; and
• Every activity in the diagram must be performed
![Page 26: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/26.jpg)
Phases of Spiral Development
• Planning Phase• Risk Analysis Phase• Engineering Phase• Coding and Implementation Phase• Evaluation Phase
![Page 27: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/27.jpg)
Perform 4 basic activities in every cycle
– Consider the win conditions of all success-critical stakeholders.
– Identify and evaluate alternative approaches for satisfying the win conditions.
– Identify and resolve risks that stem from the selected approach(es).
– Obtain approval from all success-critical stakeholders, plus commitment to pursue the next cycle.
![Page 28: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/28.jpg)
![Page 29: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/29.jpg)
Hence
• Thus, the incremental, waterfall, prototyping, and other process models are special cases of the spiral model that fit the risk patterns of certain projects.
![Page 30: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/30.jpg)
Advantages
• 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.• .
![Page 31: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/31.jpg)
Disadvantages
• Management is more complex.• 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.
![Page 32: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/32.jpg)
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)
![Page 33: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/33.jpg)
Rapid Application Development (RAD) Model
– Starting with the ideas of Barry Boehm and others, James Martin developed the rapid application development approach during the 1980s at IBM and finally formalized it by publishing a book in 1991
![Page 34: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/34.jpg)
Rapid Application Development (RAD) Model
• RAD approaches to software development put less emphasis on planning tasks and more emphasis on development.
• knowledge gained from the development process itself can feed back to the requirements and design of the solution
![Page 35: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/35.jpg)
Phases
– The James Martin approach to RAD divides the process into four distinct phases:• Requirements Planning phase • User design phase • Construction phase • Cutover phase
![Page 36: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/36.jpg)
Requirements Planning Phase
– combines elements of the system planning and systems analysis phases
– Users, managers, and IT staff members discuss and agree on:• business needs, • project scope, • constraints, • system requirements.
– It ends when the team agrees on the key issues and obtains management authorization to continue.
![Page 37: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/37.jpg)
User Design Phase
– users interact with systems analysts and develop models and prototypes that represent all system processes
– User Design is a continuous interactive process that allows users to understand, modify, and eventually approve a working model of the system that meets their needs.
![Page 38: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/38.jpg)
Construction Phase
– focuses on program and application development– users continue to participate and can still
suggest changes or improvements as actual screens or reports are developed.
– Its tasks are programming and application development, coding, unit-integration and system testing.
![Page 39: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/39.jpg)
Cutover Phase
– testing, changeover to the new system, and user training.
– the entire process is compressed. As a result, the new system is built, delivered, and placed in operation much sooner.
![Page 40: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/40.jpg)
![Page 41: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/41.jpg)
Advantages
• Risk reduction. A prototype could test some of the most difficult potential parts of the system early on in the life-cycle.
• users give much more useful feedback when they can experience a prototype of the running system rather than abstractly define what that system should be.
• users could get useful business functionality much earlier in the process.
• More projects completed on time and within budget
![Page 42: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/42.jpg)
Limitations
• The risk of a new approach- developers not willing to accept this
• Requires time of scarce resources. – Less control- due to flexibility of design
• Poor design- as we are incorporating changes many times
• Very large systems could not be handled
![Page 43: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/43.jpg)
![Page 44: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/44.jpg)
Where to use RAD
• RAD should be used only when a system can be modularized to be delivered in incremental manner.
• It should be used if there's high availability of designers for modeling.
• It should be used only if the budget permits use of automated code generating tools.
• Should be used where the requirements change during the course of the project and working prototypes are to be presented to customer in small iterations of 2-3 months.
![Page 45: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/45.jpg)
Concurrent Development Model
– The activity – modeling- may be in any one of the states noted at any given time.
– All activities exist concurrently but reside in different states.
– The concurrent process model defines a series of events that will trigger transitions from state to state for each of the Software engineering activities, actions, or tasks.
![Page 46: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/46.jpg)
Under review
Baselined
Done
Under
revision
Await ing
changes
Under
development
none
Modeling act ivit y
represents the stateof a sof tware engineeringact ivity or task
![Page 47: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/47.jpg)
• It defines s/w engg as network of activities each in different state, each dependent on one another and each going on concurrently
• Awaiting changes state- after completion of the 1st iteration • None state- while initial communication is carried out • Underdevelopment state- after communication is completed• Awaiting changes state- if any changes in the requirements
must be made
![Page 48: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/48.jpg)
Concurrency is achieved in two ways
• system and component activities occur simultaneously and can be modeled using the state-oriented approach described previously;
• a typical client/server application is implemented with many components, each of which can be designed and realized concurrently.
![Page 49: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/49.jpg)
Disadvantages
– Movement of a process among states inside activity is confusing sometimes.
– Besides it requires more Resource (intellectual).
![Page 50: Process models](https://reader033.fdocuments.net/reader033/viewer/2022052908/55944d2f1a28ab396f8b4698/html5/thumbnails/50.jpg)