1

HNDIT ATI-AMPARA

SOFTWARE DEVELOPMENT PROCESS MODELS

MS.RUSAIK RUSNI (0080) ARM.RUSAN (0081) MT.AHAMED NAFAIS (0084) SM.LAREEF (0086) A.ATHHARUL HAQ (0087) SI.IHJAS (0088)

2

Group Members

What is a process model?

3

A structured set of activities required to develop a software system Specification; Design; Validation; Evolution.

A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

The software design process4

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

The debugging process5

Locateerror

Designerror repair

Repairerror

Re-testprogram

The testing process6

Componenttesting

Systemtesting

Acceptancetesting

Waterfall model (classic lifecycle)7

Requirements analysis and definitionSystem and software designImplementation and Coding Integration and system testingOperation and maintenanceThe main drawback of the waterfall model is

the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.

The waterfall model

8

Requirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation and

maintenance

Advantages of water fall model

9

The water fall model is easy to implementation.

For implementation of small systems water fall model is use full.

The project requires the fulfillment of one phase, before proceeding to the next.

It is easier to develop various software through this method in short span of time.

Disadvantages of water fall model10

The requirement analysis is done initially and sometimes it is not possible to state all the requirement explicitly in the beginning.

The customer can see working model of the project only at the end.

If we want to go backtrack then it is not possible in this model.

It is difficult to follow the sequential flow in software development process.

What is prototyping11

The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptableprototype is finally achieved from which the complete system or product can now be developed

Why prototype?

•Evaluation and feedback are central to interaction design•Stakeholders can see, hold, interact with a prototype more easily than a document or a drawing•Team members can communicate effectively•You can test out ideas for yourself •Is quick, cheap and easily changed

Types of prototyping

Throw-away PrototypingEvolutionary PrototypingLow Fidelity PrototypingHigh Fidelity Prototyping

Journey of the Prototyping process

Goals

Functionality Evaluate

Develop

Prototyping model15

Advantages Users can try the system and provide feedback during

development An operational prototype can be produced in weeks. Prototyping enables earlydetection of errors

Problems Lack of process visibility. Management is required. It’s a expensive method in creating. System performance and security issues can be

overlooked

Introduction of RAD

RAD-based methodologies adjust the SDLC phases to get some part of system developed quickly and into the hands of the users.

Rapid Application development focuses on gathering customer requirements through workshops or focus groups, early testing of the prototypes by the customer

using iterative concept, reuse of the existing prototypes (components), continuous integration and rapid delivery.

What is RAD?

Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the product.

In RAD model the functional modules are developed in parallel as prototypes and are integrated to make the complete product for faster product delivery.

The most important aspect for this model to be successful is to make sure that the prototypes developed are reusable.

RAD Vs. Waterfall

RAD-based methodologies are well suited for projects with short time schedules as they increase speed.

Waterfall-based methodologies are the worst choice when time is essential as they do not allow for easy schedule changes.

RAD Model Design PhasesFollowing are the phases of RAD Model:

Business Modeling:  The business model for the product under development is designed

in terms of flow of information and the distribution of information between various business channels.

A complete business analysis is performed to find the vital information for business,

how it can be obtained, how and when is the information processed and what are the

factors driving successful flow of information.

Data Modeling:  The information gathered in the Business Modeling phase is

reviewed and analyzed to form sets of data objects vital for the business.

The attributes of all data sets is identified and defined. The relation between these data objects are established and

defined in detail in relevance to the business model.

Process Modeling:  The data object sets defined in the Data Modeling phase are

converted to establish the business information flow needed to achieve specific business objectives as per the business model.

The process model for any changes or enhancements to the data object sets is defined in this phase.

Process descriptions for adding , deleting, retrieving or modifying a data object are given.

Application Generation:  The actual system is built and coding is done by using automation

tools to convert process and data models into actual prototypes.

Testing and Turnover: The overall testing time is reduced in RAD model as the prototypes

are independently tested during every iteration. However the data flow and the interfaces between all the

components need to be fully tested with complete test coverage. Since most of the programming components have already been

tested, it reduces the risk of any major issues.

Following images illustrates the RAD Model:

When to Use RAD

RAD is used when The team includes programmers and analysts who

are experienced with it There are pressing reasons for speeding up

application development The project involves a new ecommerce application

and needs quick results Users are modern and highly engaged with the

goals of the company

Advantage & Disadvantage of RAD

Advantage Disadvantage

Changing requirements can be accommodated.

Progress can be measured.

Iteration time can be short with use of powerful RAD tools.

Productivity with fewer people in short time.

Reduced development time.

Increases reusability of components

Encourages customer feedback

Dependency on technically strong team members for identifying business requirements.

Only system that can be modularized can be built using RAD.

Requires highly skilled developers/designers.

High dependency on modeling skills.

Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.

Management complexity is more.

Incremental development]

24Rather 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.

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

Incremental development25

Validateincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Validatesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem

Incremental development advantages26

Customer value can be delivered with each increment so system functionality is available earlier.

Early increments act as a prototype to help elicit requirements for later increments.

Lower risk of overall project failure.The highest priority system services tend to

receive the most testing.

Spiral development27

Process is represented as a spiral rather than as a sequence of activities with backtracking.

Each loop in the spiral represents a phase in the process.

No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.

Risks are explicitly assessed and resolved throughout the process.

Spiral model sectors28Objective setting

Specific objectives for the phase are identified.Risk assessment and reduction

Risks are assessed and activities put in place to reduce the key risks.

Development and validation A development model for the system is chosen which

can be any of the generic models.Planning

The project is reviewed and the next phase of the spiral is planned.

Spiral model of the software process29

Rapid software development30Because of rapidly changing business

environments, businesses have to respond to new opportunities and competition.

Rapid software development and delivery is now often the most critical requirement for software systems.

Businesses may be willing to accept lower quality software if rapid delivery of essential functionality is possible.

Requirements31

Because of the changing environment, it is often impossible to arrive at a stable, consistent set of system requirements.

Therefore a waterfall model of development is impractical and an approach to development based on iterative specification and delivery is the only way to deliver software quickly.

Characteristics of rapid software development process

32The processes of specification, design and

implementation are concurrent. There is no detailed specification, and design documentation is minimized.

The system is developed in a series of increments. End users evaluate each increment and make proposals for later increments.

System user interfaces are usually developed using an interactive development system.

An iterative development process33

Validateincrement

Build systemincrement

Specify systemincrement

Design systemarchitecture

Define systemdeliverables

Systemcomplete?

Integrateincrement

Validatesystem

Deliver finalsystem

YES

NO

Advantages of incremental development34

Accelerated delivery of customer services. Each increment delivers the highest priority functionality to the customer.

User engagement with the system. Users have to be involved in the development which means the system is more likely to meet their requirements and the users are more committed to the system.

Problems with incremental development35Management problems

Progress can be hard to judge and problems hard to find because there is no documentation to demonstrate what has been done.

Contractual problems The normal contract may include a specification;

without a specification, different forms of contract have to be used.

Validation problems Without a specification, what is the system being

tested against?Maintenance problems

Continual change tends to corrupt software structure making it more expensive to change and evolve to meet new requirements.

Prototyping36

For some large systems, incremental iterative development and delivery may be impractical; this is especially true when multiple teams are working on different sites.

Prototyping, where an experimental system is developed as a basis for formulating the requirements may be used. This system is thrown away when the system specification has been agreed.

Incremental development and prototyping37

Incrementaldevelopment

Throw-awayprototyping

Delivered system

Executable prototype +System specification

Outlinerequirements

Conflicting objectives38

The objective of incremental development is to deliver a working system to end-users. The development starts with those requirements which are best understood.

The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood.

Agile methods 39Dissatisfaction with the overheads involved

in design methods led to the creation of agile methods. These methods: Focus on the code rather than the design; Are based on an iterative approach to software

development; Are intended to deliver working software quickly

and evolve this quickly to meet changing requirements.

Agile methods are probably best suited to small/medium-sized business systems or PC products.

Principles of agile methods40

Principle Description

Customer involvement The customer should be closely involved throughout thedevelopment process. Their role is provide and prioritise newsystem requirements and to evaluate the iterations of the system.

Incremental delivery The software is developed in increments with the customerspecifying the requirements to be included in each increment.

People not process The skills of the development team should be recognised andexploited. The team should be left to develop their own ways ofworking without prescriptive processes.

Embrace change Expect the system requirements to change and design the systemso that it can accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and inthe development process used. Wherever possible, actively workto eliminate complexity from the system.

Problems with agile methods41

It can be difficult to keep the interest of customers who are involved in the process.

Team members may be unsuited to the intense involvement that characterizes agile methods.

Prioritizing changes can be difficult where there are multiple stakeholders.

Maintaining simplicity requires extra work.Contracts may be a problem as with other

approaches to iterative development

Extreme programming42Perhaps the best-known and most widely used

agile method.Extreme Programming (XP) takes an ‘extreme’

approach to iterative development. New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is

only accepted if tests run successfully.

The XP release cycle43

Break downstories to tasks

Select userstories for this

releasePlan release

Releasesoftware

Evaluatesystem

Develop/integrate/test software

Extreme programming practices 144

Incremental planning Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these Stories into development ‘Tasks’.

Small Releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.

Simple Design Enough design is carried out to meet the current requirements and no more.

Test first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.

Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.

Extreme programming practices 245

Pair Programming Developers work in pairs, checking each otherÕs work andproviding the support to always do a good job.

Collective Ownership The pairs of developers work on all areas of the system, so thatno islands of expertise develop and all the developers own all thecode. Anyone can change anything.

Continuous Integration As soon as work on a task is complete it is integrated into thewhole system. After any such integration, all the unit tests in thesystem must pass.

Sustainable pace Large amounts of over-time are not considered acceptable as thenet effect is often to reduce code quality and medium termproductivity

On-site Customer A representative of the end-user of the system (the Customer)should be available full time for the use of the XP team. In anextreme programming process, the customer is a member of thedevelopment team and is responsible for bringing systemrequirements to the team for implementation.

2.11. Rapid Application Development (RAD)

46Agile methods have received a lot of attention

but other approaches to rapid application development have been used for many years.

These are designed to develop data-intensive business applications and rely on programming and presenting information from a database.

RAD environment tools47Database programming language

Interface generatorLinks to office applicationsReport generators

A RAD environment48

DBprogramming

language

Interfacegenerator

Officesystems

Reportgenerator

Database management system

Rapid applicationdevelopment environment

Evolutionary development

Exploratory development Objective is to work with customers and to evolve a

final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.

Throw-away prototyping Objective is to understand the system requirements.

Should start with poorly understood requirements to clarify what is really needed.

Evolutionary development

Concurrentactivities

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

Evolutionary developmentProblems

Lack of process visibility; Systems are often poorly structured; Special skills (e.g. in languages for rapid prototyping)

may be required.Applicability

For small or medium-size interactive systems; For parts of large systems (e.g. the user interface); For short-lifetime systems.

FORMAL METHODS MODEL52

Comprises set of activities that leads to formal mathematical specification of computer software. Enables a software engineer to specify, develop

and verify a computer based system by applying mathematical notation. Problems of ambiguity, incompleteness

and inconsistency can be managed by this method. Provides a base for verification therefore enable a

UNIFIED PROCESS MODEL53

Comprises best features and characteristics of conventional software process models. Emphasize importance of customer communication and streamlined methods for describing the customers view of system. Phases of Unified Process Inception = Involves customer communication and planning activities. Elaboration = Encompasses the customer communication and modeling activities of the generic process model. Architectural representation using Use Case Model, Analysis Model, Design Model, Implementation Model and Deployment Model.

UNIFIED PROCESS MODEL54

55

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.

56

Thank you...