SOFTWARE ENGINEERING: I-M.

Tech(CSE) I-Sem
UNIT II PROCESS MODELS Prescriptive Process Models: Definition: * It is a distinct set of activities, actions, tasks, milestones and work products that are required to engineer high quality software *These process models are not perfect but they provide a useful roadmap for software engineering work * Help in the software development * Guide the software team through a set of framework activities * Process Models may be linear, incremental or evolutionary The Water Fall Model: * It is sometimes called the classic life cycle * It suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progress through => Communication => Planning => Modeling => Construction and => Deployment * Used when requirements are well understood in the beginning * Also called classic life cycle model * A systematic, sequential approach to Software development * Begins with customer specification of Requirements and progresses through planning, modeling, construction and deployment * This Model suggests a systematic, sequential approach to SW development that begins at the system level and progresses through analysis, design, code and testing

R.G.Kumar/Asst.,Prof/CSE/SIETK

Page 1

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Problems encountered in waterfall model: (1) Real projects rarely follow the sequential flow. As a result changes cause confusion as the project team proceeds (2) It is difficult for the customer to state all requirements explicitly (3) The customer must have patience * The linear nature of the water fall model leads to Blocking State in which some project team members must wait for other members of the team to complete dependent task * The water fall model can serve as a useful process model in situations where => Requirements are fixed and work is to proceed to completion in a linear manner Incremental Process Models * Linear sequential model is not suited for projects which are iterative in nature * Incremental model suits such projects * Used when initial requirements are reasonably well-defined and compelling needs to provide limited functionality quickly * Functionality expanded further in later releases * Software is developed in increments * The incremental model combines elements of the water fall model applied in an iterative fashion * This model applies linear sequences in a staggered fashion as calendar time progresses * Each linear sequence produces deliverable increments of the software Main Idea: * When an incremental model is used the first increment is called CORE PRODUCT i.e. the basic requirements are addressed but main supplementary features remain undelivered. * The core product is used by customer (Or) undergoes detailed evaluation * As a result of evaluation a plan is developed for next increment

R.G.Kumar/Asst.,Prof/CSE/SIETK

Page 2

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

* The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of the additional features and functionality * This process is repeated for each increment delivery, until the complete product is developed * Unlike prototyping model, the incremental model focuses on the delivery of an operational product with each increment * This model is particularly useful, when staffing is unavailable for a complete implementation by the business deadline that has been established for the project * Early increments can be implemented with fewer people. If core product is well received additional staff can be added to implement the next increment * Increments can be planned to manage technical risks * For example a major availability of new hardware is under development, whose delivery date is uncertain * So plan early increments in a way that avoids the use of this hardware, thereby enabling partial functionality to be delivered to end-users without inordinate delay Rapid Application Development Model [RAD] * The RAD model is a high speed adaptation of the water fall model, in which rapid development is achieved by using a component based construction approach * The RAD process enables a development team to create a fully functional system within a very short period [e.g.60 to 90 days], if the requirements are well understood and project scope is constrained.

60 90 days
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 3

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Communication: * It works to understand the business problem and the information characteristics that the software must accommodate Planning: * It is essential because multiple software teams work in parallel on different system functions Modeling: * It encompasses three major phases; =>Business modeling => Data modeling => Process modeling * It establishes design representation that serves as the basis for RADs construction activity Construction: * It emphasizes the use of pre-existing software components and the application of the automatic code generation Deployment: * It establishes a basis for subsequent iterations, if required RAD Drawbacks: (1) For large but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams (2) If developers and the customers are not committed to rapid fire activities necessary to complete the system in a much abbreviated time frame, RAD projects will fail (3)If a system cannot be properly modularized, building the component necessary for RAD will be problematic (4) If high performance is an issue and performance is to be achieved through tuning the interfaces to system components the RAD approach may not work (5) RAD may not be appropriate, when technical risks are high [e.g. when a new application heavy use of new technology] Evolutionary Process Models * Like all computer systems software also evolve over a period of time * Making a straight line path to an end-product is unrealistic, if business and product requirements often change as development proceeds * Suppose if a set of core product (Or) system requirement is well understood, but the details of product (Or) system extensions have not yet to be defined. * These case, a software engineer needs a process model that has been designed to accommodate a product that evolves over time. * The evolutionary process modes are more suitable for the above case Types: (1) Prototyping Model (2) Spiral Model (3) Concurrent Development Model
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 4

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

(1) Prototyping Model Mock up or model( throw away version) of a software product Used when customer defines a set of objective but does not identify input, output, or processing requirements Developer is not sure of: efficiency of an algorithm adaptability of an operating system human/machine interaction

Steps in Prototyping Begins with requirement gathering Identify whatever requirements are known Outline areas where further definition is mandatory A quick design occur Quick design leads to the construction of prototype Prototype is evaluated by the customer Requirements are refined Prototype is turned to satisfy the needs of customer Limitation of Prototyping In a rush to get it working Overall software quality or long term maintainability are generally overlooked Use of inappropriate OS or PL Use of inefficient algorithm (2) Spiral Model An evolutionary model which combines the best feature of the classical life cycle and the iterative nature of prototype model Include new element : Risk element Starts in middle and continually visits the basic tasks of communication, planning, modeling, construction and deployment

R.G.Kumar/Asst.,Prof/CSE/SIETK

Page 5

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Two main features A cyclic approach for incrementally growing a systems degree of definition and implementation while decreasing its degree of risk An anchor point mile stones for ensuring stake holders commitment to feasible and mutually satisfactory system solutions Main idea: Realistic approach to the development of large scale system and software Software evolves as process progresses Better understanding between developer and customer The first circuit might result in the development of a product specification Subsequent circuits develop a prototype And sophisticated version of software Advantages: It is a realistic approach to the development of large-scale system and software It enables the developer to apply the prototyping approach at any stage in th evolution of the product It maintains the systematic stepwise approach suggested by classic life cycle and incorporates it into iterative framework
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 6

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

(3) Concurrent Development Model * It is also called as Concurrent Engineering * It can be represented schematically as a series of framework activities, software engineering actions and tasks and their associated states

* At any given time the modeling activity may be in any one of the states * All activities exist concurrently, but reside in different states Ex: * Initially in a project, the communication activity has completed its first iteration and exists in awaiting change state * When initial communication was completed, the modeling activity exists in none state, makes a transition from none state into the under development state * If customer indicates changes in requirements, the modeling activity moves from under development into awaiting change state * A series of events will trigger transition from state to state for each of the software engineering activities, actions (Or) tasks * During early stages of design [a software engineering action that occurs during the modeling activity] an inconsistency in the analysis model will trigger the analysis action from the done state into the awaiting change state Advantages: (1) The concurrent process model provides an accurate picture of the current state of a project (2) It defines the software engineering activities, actions and tasks as a network, instead of sequence of events (3) Each activity, action (Or) tasks on network exists simultaneously with other activities
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 7

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

The Unified Process: Evolved by Rumbaugh, Booch, Jacobson Combines the best features their OO models Adopts additional features proposed by other experts Resulted in Unified Modeling Language(UML) Unified process developed Rumbaugh and Booch A framework for Object-Oriented Software Engineering using UML

Phases of the Unified Process: (1) Inception Phase: * This phase combines both customer communication and planning activities * By combining these the => Business requirements for the software are identified => A rough architecture for the system is proposed => A plan for the iterative, incremental nature of the ensuring project is developed * In general a use-case describes a sequence of actions that are performed by an actor [e.g. a person, a machine] * Use-case helps to identify the scope of the project and provide a basis for project planning (2) Elaboration Phase: * It refines and expands the preliminary use-cases that were developed on inception phase * It expands the architectural representation to include five different views of the software: => Use-case model => Analysis Model => Design Model => Implementation Model => Deployment Model * The modification to the plan may be made at this time
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 8

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

(3) Construction Phase: * This phase develops (or) acquires the software components that will make each use-case operational for end users * All necessary and required features and functions of software release are implemented in source code * After implementing components, unit tests are designed and executed for each * In addition (4) Transition Phase: * The software is given to end-users for Beta testing * The users feedback the reports both defects and necessary changes * This phase allow software team creates the necessary support information Ex: => User Manuals => Trouble shooting guides => Installation procedures (5) Production Phase: * During these phase the => Ongoing use of the software is monitored => Support for the operating environment [infrastructure] is provided => Defect reports and requests for changes are submitted and evaluated Aspect Oriented Software Development(AOSD): In computing, AOSD is an emerging software development technology that seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main program's business logic AOSD is a relatively new software development paradigm that complements and improves on many contemporary development paradigms. The implementation of software applications using AOSD techniques results in a better implementation structure which has an impact on many important software qualities such as enhanced reusability and reduced complexity. AOSD focuses on the identification, specification and representation of cross-cutting concerns and their modularization into separate functional units as well as their automated composition into a working system. AOSD provides unique and advanced program structuring and modularization techniques AOSD allows multiple concerns to be expressed separately and automatically unified into working systems. It contains the following steps 1. Separation of concerns 2. Aspectual Decomposition 3. Binding Models 4. Weavers 1. Separation of Concerns The principle of separation of concerns promotes good design and reusable implementations and essentially states that each concern that is relevant to the software
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 9

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

application is best treated separately from the other concerns. Separation of concerns is achieved by decomposing an application into individual objects.

Crosscutting Concerns Crosscutting Concerns are those system concerns which take effect over multiple artifacts within a design or program. Artifact = any tangible object at any level of the software development process. Concern = system property Functional property Constraint of system behavior Constraints on a system refer to conditions that need to be satisfied when the system runs Logging of read/write operations on all pumps Authorization Synchronization 2. Aspectual Decomposition To modularize the crosscutting concerns, software developers need a different decomposition technique. Modules in contemporary programming languages and paradigms are all based on some form of functional (de)composition (e.g. subroutines, functions, objects, components). Aspects An aspect is a module that can localize the implementation of a crosscutting concern. In the context of AOSD, Aspects are a new modularity mechanism with which crosscutting concerns can be expressed. An aspect holds all the information (operations and data) that a crosscutting concern uses/manipulates. An aspect is bound to a context. Better modularity. Crosscutting concerns are now localized in an aspect.

R.G.Kumar/Asst.,Prof/CSE/SIETK

Page 10

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Easier understanding. The information about a concern is localized. It is less scattered and tangled with other information. Easier modifiability. Look at one aspect and its binding.

3. Binding Model (Modularization) Separating the operations and data which a crosscutting concern deals with is the first step: aspectual data type. One needs to define at which points within your design implementation an aspect gets to execute its code. Binding of an aspect. A join point model provides the glue between aspectual data types and the binding of them. 4. Weavers Aspect languages rely on a specific kind of compilers (or interpreters), called weavers that compose the aspects implementation with the other modules. Compilers for aspect languages are called weavers because they need to weave the aspect code into the modules that are crosscut by the aspect. Some weavers use source code or byte code transformation to achieve this (e.g. AspectJ), while other weavers use reflection to achieve the same result (e.g. AspectS). General Steps to perform AOSD 1. Aspect-oriented Requirements Engineering 2. Aspect-oriented Architecture 3. Aspect-oriented Design 4. Aspect-oriented Programming 5. Verification of Aspect-oriented Programs 6. Aspect-oriented Middleware
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 11

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Agile Development:

(ASSIGNMENT TOPIC)

R.G.Kumar/Asst.,Prof/CSE/SIETK

Page 12