Chapter3 Software Process Model Software process model Process

Chapter-3 Software Process Model

Software process model Ø 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.

Build and Fix Model

Build and Fix Model The earlier approach Ø Product is constructed without specification or any attempt at design. Ø developers simply build a product that is reworked as many times as necessary to satisfy the client. Ø model may work for small projects but is totally unsatisfactory for products of any reasonable size. Ø Maintenance is high. Ø Source of difficulties and deficiencies — — impossible to predict impossible to manage

Why Models are needed? Ø Symptoms of inadequacy: the software crisis — scheduled time and cost exceeded — user expectations not met — poor quality

Process as a "black box" Quality? Uncertain / Incomplete requirement In the beginning

Problems Ø The assumption is that requirements can be fully understood prior to development Ø Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Ø Unfortunately the assumption almost never holds

Process as a "white box"

Advantages Ø Reduce risks by improving visibility Ø Allow project changes as the project progresses — based on feedback from the customer

Prescriptive Model Ø Prescriptive process models advocate an orderly approach to software engineering — Organize framework activities in a certain order Ø Each action in terms of a task set that identifies the work to be accomplished to meet the goals. Ø Software engineer choose process framework that includes activities like; — Communication — Planning — Modeling — Construction — Deployment

Prescriptive Model Ø Calling this model as “Prescribe” because it recommend a set of process elements, activities, action task, work product & quality. Ø Each elements are inter related to one another (called workflow).

SDLC - Overview Ø SDLC, Software Development Life Cycle is a process used by software industry to design, develop and test high quality softwares. Ø The SDLC aims to produce a high quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. Ø The software development life cycle (SDLC) is a framework defining tasks performed at each step in the software development process. Ø ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.

What is SDLC? Ø SDLC is a process followed for a software project, within a software organization. Ø The life cycle defines a methodology for improving the quality of software and the overall development process.

Waterfall Model

Waterfall Model q Requirement Gathering and Planning: Ø All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification doc. Ø It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. Ø This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational, and technical areas.

Waterfall Model ØPlanning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. ØThe outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.

Waterfall Model q System Design: Ø Software Requirement Specification (SRS)document which consists of all the product requirements to be designed and developed during the project life cycle. Ø The requirement specifications from first phase are studied in this phase and system design is prepared. Ø System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.

Waterfall Model q Designing the product architecture Ø SRS is the reference for product architects to come out with the best architecture for the product to be developed. Ø Based on SRS, usually more than one design approach for the product architecture is proposed and documented in a DDS Design Document Specification. Ø A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third party modules (if any). Ø The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS.

Waterfall Model q Implementation: Ø With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase. Ø Each unit is developed and tested for its functionality which is referred to as Unit Testing. Ø The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.

Waterfall Model q Integration and Testing: Ø All the units developed in the implementation phase are integrated into a system after testing of each unit. Ø This stage refers to the testing only stage of the product where products defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS. Ø Post integration the entire system is tested for any faults and failures.

Waterfall Model q Deployment of system: Ø Once the functional and non functional testing is done, the product is deployed in the customer environment or released into the market. Ø Sometime product deployment happens in stages as per the organizations. business strategy. Ø The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing).

Waterfall Model q Maintenance: Ø Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment. After the product is released in the market, its maintenance is done for the existing customer base. Ø Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

Waterfall Model-Applications Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Some situations where the use of Waterfall model is most appropriate are: Ø Requirements are very well documented, clear and fixed. Ø Product definition is stable. Ø Technology is understood and is not dynamic. Ø There are no ambiguous requirements. Ø Ample resources with required expertise are available to support the product.

Waterfall Model-Limitations Problems: 1. There is no scope for jumping backward or forward or performing two steps simultaneously. 2. It has many shortcomings since bugs and errors in the code are not discovered until and unless the testing stage is reached. 3. This can often lead to wastage of time, money and valuable resources 4. Difficult for the customer to state all the requirement explicitly. 5. Assumes patience from customer - working version of program will not available until programs not getting change fully. — Real projects are rarely follow the sequential model.

Waterfall Model-Advantages Ø Its simplistic, systematic and orthodox approach. Ø It allows for departmentalization and control. Ø A schedule can be set with deadlines for each stage of development Ø Product can proceed through the development process model phases one by one. Ø Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Ø Each phase of development proceeds in strict order.

Waterfall Model- Pros and cons

V-Model

V-Model Ø V Model is an enhanced version of the classic waterfall model whereby each level of the development life-cycle is verified before moving on to the next level. Ø With this model, software testing explicitly starts at the very beginning, i. e. as soon as the requirements are written. Ø The left side of the "V" represents the decomposition of requirements, and creation of system specifications Ø The right side of the V represents integration of parts and their validation

V-Model Ø "Validation. The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification. “ Ø "Verification. The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation. " Ø It is sometimes said that validation can be expressed by the query "Are you building the right thing? " and verification by "Are you building it right? "

Verification Phases q Business Requirement Analysis: Ø This phase involves detailed communication with the customer to understand his expectations and exact requirement. Ø This is a very important activity and need to be managed well, as most of the customers are not sure about what exactly they need. Ø The acceptance test design planning is done at this stage as business requirements can be used as an input for acceptance testing.

Verification Phases q System Design: Ø System design would comprise of understanding and detailing the complete hardware and communication setup for the product under development. Ø System test plan is developed based on the system design. Ø Doing this at an earlier stage leaves more time for actual test execution later.

Verification Phases q Architectural Design: Ø Usually more than one technical approach is proposed and based on the technical and financial feasibility the final decision is taken. Ø System design is broken down further into modules taking up different functionality. This is also referred to as High Level Design (HLD). Ø The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined Ø With this information, integration tests can be designed and documented during this stage.

Verification Phases q Module Design: Ø The detailed internal design for all the system modules is specified, referred to as Low Level Design (LLD). Ø It is important that the design is compatible with the other modules in the system architecture and the other external systems. Ø Unit tests can be designed at this stage based on the internal module designs. Ø Unit tests are an essential part of any development process and helps eliminate the maximum faults and errors at a very early stage.

Validation Phases q Unit Testing: Ø Unit tests designed in the module design phase are executed on the code during this validation phase. Ø Unit testing is the testing at code level and helps eliminate bugs at an early stage Ø Though all defects cannot be uncovered by unit testing.

Validation Phases q Integration Testing: Integration testing is associated with the architectural design phase. Ø Integration tests are performed to test the coexistence and communication of the internal modules within the system. Ø q System Testing: System testing is directly associated with the System design phase. Ø System tests check the entire system functionality and the communication of the system under development with external systems. Ø Most of the software and hardware compatibility issues can be uncovered during system test execution. Ø

Validation Phases q Acceptance Testing: Ø Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. Ø Acceptance tests uncover the compatibility issues with the other systems available in the user environment. Ø It also discovers the non functional issues such as load and performance defects in the actual user environment.

V-Model-Advantages Ø In V Model, Each phase has specific deliverables. Ø Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. Ø Time concern in comparison with the waterfall model is low or even we can say 50% less. Ø Works well for small projects where requirements are easily understood. Ø Utility of the resources is high

V Model-Limitations Ø Very rigid, like the waterfall model. Ø Little flexibility and adjusting scope is difficult and expensive. Ø Software is developed during the implementation phase, so no early prototypes of the software produced.

Incremental Process Model CCommunication P - Planning M – Modeling C - Construction D - Deployment

Incremental Process Model Ø Ø Ø 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 Incremental model focus more on delivery of operation product with each increment.

Incremental Model-Applications Ø Major requirements must be defined; however, some functionalities or requested enhancements may evolve with time. Ø A new technology is being used and is being learnt by the development team while working on the project. Ø Resources with needed skill set are not available and are planned to be used on contract basis for specific iterations.

Incremental Process Model-Benefits Ø The cost of accommodating changing customer requirements is reduced. — Finding issues at an early stage of development enables to take corrective measures in a limited budget. — The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. Ø It is easier to get customer feedback on the development work that has been done. — Customers can comment on demonstrations of the software and see how much has been implemented. Ø More rapid delivery and deployment of useful software to the customer is possible. — Customers are able to use and gain value from the software earlier than is possible with a waterfall process.

Incremental Process Model-Limitations Ø The process is not visible. — Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. Ø System structure tends to degrade as new increments are added. — Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.

Evolutionary Process Models Ø 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

Prototype Model Ø Best approach when: — Objectives defines by customer are general but does not have details like input, processing, or output requirement. — Developer may be unsure of the efficiency of an algorithm, O. S. , or the form that human machine interaction should take. Ø It can be used as standalone process model. Ø Model assist software engineer and customer to better understand what is to be built when requirement are fuzzy. Ø Prototyping start with communication, between a customer and software engineer to define overall objective, identify requirements and make a boundary. Ø Going ahead, planned quickly and modeling (software layout visible to the customers/end-user) occurs

Prototype Model Ø Quick design leads to prototype construction. Ø Prototype is deployed and evaluated by the customer/user. Ø Feedback from customer/end user will refine requirement and that is how iteration occurs during prototype to satisfy the needs of the customer. o Prototype can be serve as “the first system”. o Both customers and developers like the prototyping paradigm. n Customer/End user gets a feel for the actual system n Developer get to build something immediately.

Types of prototyping- Throwaway prototyping Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software Ø The most obvious reason for using Throwaway Prototyping is that it can be done quickly Ø Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test.

Types of prototyping- Throwaway prototyping In this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch. The steps in this approach are: Ø Write preliminary requirements Ø Design the prototype Ø User experiences/uses the prototype, specifies new requirements Ø Repeat if necessary Ø Write the final requirements

Types of prototyping- Evolutionary Prototyping Ø Evolutionary Prototyping is quite different from Throwaway Prototyping. Ø The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. Ø The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built. Ø When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt. "…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood”

Types of prototyping-Incremental Prototyping Ø The final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design. Ø By the help of incremental prototyping we can reduce the time gap between user and software developer

Software Prototyping Application Ø Software Prototyping is most useful in development of systems having high level of user interactions such as online systems. Systems which need users to fill out forms or go through various screens before data is processed can use prototyping very effectively to give the exact look and feel even before the actual software is developed. Ø Software that involves too much of data processing and most of the functionality is internal with very little user interface does not usually benefit from prototyping. Prototype development could be an extra overhead in such projects and may need lot of extra efforts

Prototyping-Advantages Ø The software designer and implementer can obtain feedback from the users early in the project. Ø The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. Ø It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met.

Prototyping-Limitations Ø Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished Ø Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture. Ø Developer often makes implementation in order to get a prototype working quickly without considering other factors in mind like OS, Programming language, etc.

Spiral Model Couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model Ø It provide potential for rapid development of increasingly more complete version of the software. Ø 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. Ø Evolutionary process begins in a clockwise direction, beginning at the center risk.

Spiral Model Ø First circuit around the spiral might result in development of a product specification. Subsequently, develop a prototype and then progressively more sophisticated version of software.

Spiral Model q Identification Øbusiness requirements in the baseline spiral. ØIn the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase. ØThis also includes understanding the system requirements by continuous communication between the customer and the system analyst. Ø At the end of the spiral the product is deployed in the identified market.

Spiral Model q. Design: ØIt starts with the conceptual design in the baseline spiral and involves the following designs in the subsequent spirals. • architectural design, • logical design of modules, • physical product design • final design

Spiral Model q. Construct or Build ØProduction of the actual software product at every spiral. ØIn the baseline spiral when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed to get customer feedback. ØIn the subsequent spirals with higher clarity on requirements and design details a working model of the software called build is produced with a version number. Ø These builds are sent to customer for feedback.

Spiral Model q. Evaluation and Risk Analysis: ØRisk Analysis includes identifying, estimating, and monitoring technical feasibility and management risks, such as schedule slippage and cost overrun.

Spiral Model Applications ØIt is in synch with the natural development process of any product i. e. learning with maturity and involves minimum risk for the customer as well as the development firms. Following are the typical uses of Spiral model: • When costs there is a budget constraint. • For medium to high-risk projects. • Long-term project commitment because of potential changes to economic priorities as the requirements change with time. • Customer is not sure of their requirements which is usually the case. • Requirements are complex and need evaluation to get clarity. • New product line which should be released in phases to get enough customer feedback. • Significant changes are expected in the product during the development cycle.

Spiral Model

Spiral Model