Software Process Models

A software process model is a simplified description of a software process which is presented from a particular perspective. Models, by their very nature, are simplifications so a software process model is an abstraction of the actual process which is being described. Process models may include activities which are part of the software process, software products and the roles of people involved in software engineering.

Process model
What is it? They define a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high-quality software They are not perfect but they provide a useful roadmap for SW engineering work Who does it? SW engineers, and their managers adopts it, also the people who requested the software Why it is important? They are important because they provide stability, control, and organization to an activity that can, if left uncontrolled, become quite chaotic What are the steps? The process guides a SW team through a set of framework activities that are organized into a process flow that may be linear, incremental, or evolutionary What is the work product? The work products are the programs, documents, and data that are produced as a consequence of the activities and tasks defined by the process How do I ensure that I have done it right? The quality, timeliness, and long term viability of the product you build are the best indicators of the efficacy of the process that you use Prescriptive Models Every SW engineering organization should describe a unique set of framework activities for the SW process it adopts Each framework activity is populated with a set of SW engineering actions Each action is defined in terms of a task set that identifies the work (and work products) to be accomplished to meet development goals Resultant process model is adapted to accommodate specific nature of each project, people who do the work, environment in which work is conducted SW engineers have traditionally chosen a generic process framework that encompasses the following framework activities: communication, planning, modeling, construction, and deployment All SW process models can accommodate the generic framework activities, but each applies a different emphasis to these activities and defines a workflow that invokes each framework activity in a different manner The Waterfall Model Used when requirements well understood, when work flows from communication through deployment in a reasonably linear fashion Waterfall model, sometimes called classic life cycle, suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through various phases, culminating in on-going support of the completed software Problems with Waterfall Model Real projects rarely follow the sequential flow that the model proposes It is often difficult for the customer to state all requirements explicitly

The customer must have patience. A working version of the program will not be available until late in the project time-span

The Incremental process Models They are used when initial requirement are reasonably well-defined but the over all scope precludes a purely linear process , and need to provide software functionality to user quickly The Incremental Model It combines elements of the waterfall model applied in an iterative fashion It delivers a series of releases, called increments, that provide progressively more functionality for customer as each increment is delivered When it is used, the first increment is often a core product. That is, basic requirements are addressed, but many supplementary features remain undelivered The core product is used by customer. As a result, a plan is developed for next increment Unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline. Early increments can be implemented with fewer people, and additional staff can be added to later increments Increments can be planned to manage technical risks The RAD Model Rapid application development is a software development methodology, which involves iterative development and the construction of prototypes. It is a merger of various structured techniques, especially the data driven Information Engineering with prototyping techniques to accelerate software systems development The main objective of Rapid Application Development is to avoid extensive pre-planning, generally allowing software to be written much faster and making it easier to change requirements. The Rapid Application Development methodology was developed to respond to the need to deliver systems very fast. The RAD approach is not appropriate to all projects - an air traffic control system based on RAD would not instill much confidence. Project scope, size and circumstances all determine the success of a RAD approach. The following categorize indicates suitability for a RAD approach: PROJECT SCOPE Suitable for RAD - Focused scope where the business objectives are well defined and narrow. Unsuitable for RAD - Broad scope where the business objectives are obscure or broad. PROJECT DATA Suitable for RAD - Data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data. Unsuitable for RAD - Complex and voluminous data must be analyzed, designed and created within the scope of the project. PROJECT DECISIONS Suitable for RAD - Decisions can be made by a small number of people who are available and preferably co-located. Unsuitable for RAD - Many people must be involved in the decisions on the project, the decision makers are not available on a timely basis or they are geographically dispersed. PROJECT TEAM Suitable for RAD - The project team is small (preferably six people or less). Unsuitable for RAD - The project team is large or there are multiple teams whose work needs to be coordinated.

RAD is an incremental SW process model that emphasizes a short development cycle RAD model is a high-speed adaptation of the waterfall model, in which rapid development is achieved by using a component-based construction approach If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a fully functional system within a very short time period Time constraints imposed on a RAD project demand scalable scope If a business application can be modularized in a way that enables each major function to be completed in less than 3 months, it is a candidate for RAD Each major function can be addressed by a separate RAD team and then integrated to form a whole Drawback of RAD 1. For large, but scalable projects, RAD requires sufficient human resources to create right number of RAD teams 2. If developers and customers are not committed to the rapid-fire activities necessary, RAD projects will fail 3. If a system cannot be properly modularized, building the components necessary for RAD will be problematic 4. RAD may not be appropriate when technical risks are high

Evolutionary Process Models Evolutionary models are iterative. They are characterized in a manner that enables SW engineers to develop increasingly more complete versions of the software Evolutionary Models: Prototyping Although it can be used as a standalone process model, it is more commonly used as a technique that can be implemented within the context of other process models The prototyping paradigm assists the SW engineer and the customer to better understand what is to be built when requirements are fuzzy(customer identify general objective but not defines the details of input ,processing , and processing so the developer becomes unsure about efficiency , algorithms and so on to solve this problem prototype is used ) Ideally, the prototype serves as a mechanism for identifying SW requirement Drawbacks of Prototyping The customer sees what appears to be a working version of SW, unaware that in the rush to get it working we havent considered overall quality or long-term maintainability The developer often makes implementation compromises in order to get prototype working quickly The Spiral It is an evolutionary SW process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model It is a risk-driven process model generator that is used to guide multi-stakeholder concurrent engineering of SW intensive systems Using this model software is developed in a series of evolutionary releases. The releases might be paper model, or prototype. The model is divided into a set of framework activities defined by SE team It has distinguishing features: (1) A cyclic approach for incrementally growing the systems degree of definition & implementation while decreasing its degree of risk, (2) a set of anchor point milestones(combination of work product and conditions that are attained along the path of the spiral) Unlike other models that ends when software delivered, but it can be adapted to apply through out the life of software. So the first circle represents "concept development project", the later represents "new product development" and "product enhancement" It a realistic model that can be used to be used to develop large scale system and software

Problems with Spiral Model Difficult to convince customers that evolutionary approach is controllable Demands considerable risk assessment expertise and relies on this expertise for success If major risks are uncovered and managed, problems will occur Specialized process models Component based development the process to apply when reuse is a development objective o CBM incorporate the following steps o Available component product are researched and evaluated for the application domain in the question o Component integration issue are considered o Software architecture is designed to accommodate the component o Component are integrated with the architecture o Comprehensive testing is conducted to ensure proper functionality Formal methods o It emphasizes the mathematical specification of requirements o The formal methods model encompasses a set of activities that leads to formal mathematical specification of computer software. o Formal methods enable a software engineer to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation. A variation on this approach, called cleanroom software engineering [MIL87, DYE92], is currently applied by some software development organizations. o Although it is not destined to become a mainstream approach, the formal methods model offers the promise of defect-free software. Yet, the following concerns about its applicability in a business environment have been voiced: 1. The development of formal models is currently quite time consuming and expensive. 2. Because few software developers have the necessary background to apply formal methods, extensive training is required. 3. It is difficult to use the models as a communication mechanism for technically unsophisticated customers.