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 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 Concurrent development model The concurrent process model defines a series of events that will trigger transition from state to state for each of the SW engineering activities, actions or tasks. All activities exist concurrently but reside in different states E. g. The modeling activity which existed in none state while initial communication was completed, now makes a transition into under development state. If customer indicates that changes in requirements must be made, modeling activity moves from under development state into awaiting changes state Is applicable to all types of software development and provides an accurate picture of the current state of project Each activity, action, or task on the network exists simultaneously with other activities, actions, or tasks. Events generated at one point in the process network trigger transitions among the states 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. Aspect oriented software development Often referred to as aspect oriented programming Its anew software paradigm that provides and methodologies approaches for defining, specifying, designing and construct aspect Aspect mechanism beyond subroutines and inheritance for localizing the expression of crosscutting concerns[ function, feature, and information content] It adopts characteristics of spiral and concurrent process model Evolutionary nature of the spiral model is appropriate aspect are identified and then constructed Aspect are engineering independently of localizing software components Unified process it recognizes the importance of customer communication and streamlined methods for describing the customer view of a system it emphasizes the important role of architecture that help to understand the system and reliance to future changes and reuses it suggest a process flow that is iterative or incremental Phases of UP 1inception phase, encompasses both customer communication and planning activities 2elaboration phase, encompasses customer communication and generic activities of process model - It refines use case that were developed as a part of inception phase 3Construction phase is similar to construction phase in generic process 4Transition phase, encompasses the latter stage of the generic construction activity and first part of deployment 5production, encompasses deployment activity of generic process o the ongoing use of software is monitored, and reports fro effect and change are submitted and evaluated workflow identifies the tasks required to accomplish an important software engineering action and work product its distributed across all UP phases UP work product work product is produced as a consequence of the four technical UP phases as in the following Figure[3.8]