+ All Categories
Home > Education > Software Process Models

Software Process Models

Date post: 17-Dec-2014
Category:
Upload: atul-karmyal
View: 268 times
Download: 1 times
Share this document with a friend
Description:
Description of different models along with their multiple phases to design a software.
Popular Tags:
34
SOFTWARE PROCESS MODELS
Transcript
Page 1: Software Process Models

SOFTWARE PROCESS

MODELS

Page 2: Software Process Models

NEED FOR MODELING A PROCESS• When a team writes down a description of its

development process it forms a commonunderstanding of the activities, resources andconstraints involved in software development.

• Creating a process model helps the team find

inconsistencies, redundancies and removals in theprocess, as these problems are noted and correctedthe process becomes more effective.

• The model reflects the goals of development andshows explicitly how the product characteristics areto be achieved.

Page 3: Software Process Models

• Each development is different and a process has tobe tailored for different situations, the model helpspeople to understand these differences.

Page 4: Software Process Models

PRESCRIPTIVE MODELS

• Advocates an orderly approach to software engineering.

• They prescribes

– A set of process elements,

– Framework activities,

– Software engineering actions,

– Tasks,

– Work products,

– Quality assurance and change control mechanism for each project.

Page 5: Software Process Models

WATER FALL MODEL• ADVANTAGES

• The model suggests that software engineers should work in a series of stages.

• Before completing each stage, they should perform quality assurance (verification and validation).

• The waterfall model also recognizes, to a limited extent, that you sometimes have to step back to earlier stages.

Page 6: Software Process Models

WHEN TO USE• Requirements of the complete system are clearly

defined and understood.

• Major requirements must be defined.

• 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.

Page 7: Software Process Models
Page 8: Software Process Models

DISADVANTAGES• 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 makes no allowances for prototyping.

• It implies that you can get the requirements right by simply writing them down and reviewing them.

• The entire functionality is developed and then tested all together at the end.

• Major design problems may not be detected till very late.

• The model implies that once the product is finished, everything else is maintenance.

Page 9: Software Process Models

INCREMENTAL PROCESS MODEL• Development occurs as a succession of releases

with increasing functionality.

• Combines elements of the water fall model applied in an iterative fashion.

• Each linear sequence produces deliverables of the software.

• Customers provide feedback on each release, used in deciding requirements and improvements for next release.

• There is no “maintenance” phase – each version includes both problem fixes as well as new features.

Page 10: Software Process Models

ADVANTAGES• Customers get usable functionality earlier than with

waterfall.

• Early feedback improves likelihood of producing a product that satisfies customers.

• The quality of the final product is better

– The core functionality is developed early and tested multiple times (during each release)

– Only a relatively small amount of functionality added in each release: easier to get it right and test it thoroughly

– Detect design problems early and get a chance to redesign

Page 11: Software Process Models
Page 12: Software Process Models

DISADVANTAGES• 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.

Page 13: Software Process Models

RAD DEVELOPMENT MODEL• RAD is an incremental software process model that

emphasizes a short development cycle.

• Using Component based construction approach.

Page 14: Software Process Models

Communicat ion

Planning

Mode lingbusiness modeling

dat a modeling

process modeling

Const ruct ioncomponent reuse

aut omat ic code

generat ion

t est ing

De ployme nt

6 0 - 9 0 days

Team # 1

Modelingbusiness m odel ing

dat a m odel ing

process m odel ing

Const ruct ioncom ponent reuse

aut om at ic code

generat ion

t est ing

M o d e lin gbusiness m odeling

data m odeling

process m odeling

Co n st ru ct io ncom ponent reuse

autom at ic code

generat ion

test ing

Team # 2

Team # n

int egrat ion

delivery

feedback

Page 15: Software Process Models

ADVANTAGES & DISADVANTAGES

• RAD reduces the development time

• Reusability of components help to speed up development.

• All functions are modularized so it is easy to work with.

• For large projects RAD require highly skilled engineers in the team.

• Both end customer and developer should be committed to complete the system in a much abbreviated time frame

• If commitment is lacking RAD will fail.

• RAD is based on Object Oriented approach and if it is difficult to modularize the project the RAD may not work well.

Page 16: Software Process Models

EVOLUTIONARY SOFTWARE

PROCESS MODELS

Page 17: Software Process Models

• Business and product requirement often change as development proceed.

• Software engineer need a process model that has been explicitly designed to accommodate a product that evolves over time.

• Evolutionary models are iterative.

• Enables software engineers to develop increasingly more complete version of the software.

• There are two types of evolutionary development:– Exploratory development

• Start with requirements that are well defined

• Add new features when customers propose new requirements

– Throw-away prototyping• Objective is to understand customer’s requirements (i.e. they often don’t know what they

want, hence poor requirements to start

• Use means such as prototyping to focus on poorly understood requirements, redefine requirements as you progress

Page 18: Software Process Models

ADVANTAGES & DISADVANTAGES• Advantages:

– Happier customers since we help them by defining requirements

– Flexibility in modifying requirements

– Prototypes are very visual, hence no ambiguities

• Disadvantages:

– Hard to trace the “process” due to the ad-hoc nature

– Systems are often poorly structured

– Special tools and techniques may be required (for rapid development) that may be incompatible

– Not cost-effective to produce documents

Page 19: Software Process Models

PROTOTYPING MODEL

• Customer defines a set of general objectives for software but doesn’t identify the detail.

• Assist the software engineer and the customer to better understand what is to be built when requirement are fuzzy.

Page 20: Software Process Models
Page 21: Software Process Models
Page 22: Software Process Models

SPRIAL PROCESS MODEL• A hybrid model where the development of the system spirals

outward from an initial outline through to the final developed system.

• Each loop in the spiral represents a phase of the software process.

• Like the innermost loop might be concerned with systemfeasibility, next loop with system requirements, next loop withsystem design and so on.

• Each loop in the spiral is split into four sectors:

– Object Setting: set specific object for that phase.

– Risk assessment and reduction.

– Development and validation: select a development model based on risk levels.

– Planning: decide if a next loop is required

Page 23: Software Process Models
Page 24: Software Process Models

ADVANTAGES & DISADVANTAGES

• Advantages

– Explicit consideration of risks (alternative solutions are evaluated in each cycle).

– More detailed processes for each development phase.

• Disadvantages

– Cost is high.

– Sometime difficult to implement or too time consuming.

Page 25: Software Process Models

SPECIALIZED PROCESS MODELS

Page 26: Software Process Models

COMPONENT BASED DEVELOPMENT

• COTS (Commercial Off The Shelf) software components,developed by vendors who offer them as products canbe used when software is to built.

• Provides targeted functionality with well definedinterfaces.

• Incorporates many of the characteristics of spiralmodel.

• Regardless of technology to be used, it must follow thesteps like –

– Available component based products are researched andevaluated for the current application.

Page 27: Software Process Models

– Component integration issues is to dealt.

– A software architecture is designed to accommodate thecomponents.

– Components are integrated into the architecture.

– Comprehensive testing is conducted to ensure properfunctionality.

• This model leads to software reuse.

• Provides software engineers with a number ofmeasureable benefits.

Page 28: Software Process Models

FORMAL METHODS MODEL• Comprises set of activities that leads to formal

mathematical specification of computer software.

• Enables a software engineer to specify, develop andverify a computer based system by applyingmathematical notation.

• Problems of ambiguity, incompleteness andinconsistency can be managed by this method.

• Provides a base for verification therefore enable asoftware engineer to discover and correct undetectederrors also.

• But using this method in current scenario is timeconsuming and expensive.

Page 29: Software Process Models

• Extensive training is required for applying thismethod as few developers have the necessarybackground to work with this method.

• It is difficult to use the models as a communicationmechanism for technically unsophisticatedcustomers.

Page 30: Software Process Models

ASPECT ORIENTED SOFTWARE DEVELOPMENT

• Complex software are being implemented as set oflocalized features, functions and informationcontent referred as components.

• But it becomes crosscutting concerns when it flowsacross multiple systems.

• Aspectual requirements define these crosscuttingconcerns that have impact across the softwarearchitecture.

• AOSD provides a process and methodologicalapproach for defining, specifying, designing andconstructing aspects.

Page 31: Software Process Models

UNIFIED PROCESS MODEL• Comprises best features and characteristics of conventional

software process models.

• Emphasize importance of customer communication andstreamlined methods for describing the customers view ofsystem.

• Phases of Unified Process

– Inception = Involves customer communication andplanning activities.

– Elaboration = Encompasses the customercommunication and modeling activities of the genericprocess model. Architectural representation using UseCase Model, Analysis Model, Design Model,Implementation Model and Deployment Model.

Page 32: Software Process Models
Page 33: Software Process Models

– Construction = Develops or acquires the software components that will make each use case operational for end users.

– Transition = Software is given to end user for beta testing and user feedback reports both defects and necessary changes.

– Production = Coincides with the deployment activity of process. The on going use of software is monitored, support for the operating environment is provided, and defect reports and requests for changes are submitted and evaluated.

Page 34: Software Process Models

Thanks


Recommended