Unit 2: Software Processes Software process A frame work for the tasks that are required to produce a high

high quality software product. or The process followed by a software engineer to build, deliver, deploy and evolve a software product from inception to the delivery Each process is governed by a set of principles, goals, and carried out under some constraints like budget, time, tools etc. A structured set of activities required to develop a software system 1. Software Specification The functionality of the software, and constraints on its operation must be defined 2. Software Design & Implementation The software to meet the specification must be produced. 3. Software Validation The software must be validated to ensure that it does what the customer wants. 4. Software Evolution The software must evolve to meet changing customer needs Software Process Model A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

Need for process model: To understand the activities and constraints involved in developing a software product. To identify inconsistencies, redundancies and omissions in development process making the process more effective. To evaluate the appropriateness of various activities. Generic software process models : The Waterfall model Separate and distinct phases of specification and development. Evolutionary development Specification, development and validation are interleaved. Component-based software engineering The system is assembled from existing components. Formal Development: There are many variants of these models e.g. formal mathematical model of development where a waterfall-like process is used. MCA@ TOCE, Bangalore Page 1

Specifications are transformed using mathematical transformations that preserve consistency into executable code. The clean room process developed by IBM is one of the example of formal development and relies on incremental approach. ** 1.Waterfall model(or) Explain waterfall model with its merits & demerits This model separates process phases such as requirements specification, software design, implementation, testing and so on. Waterfall model remains one of the oldest strategies ever applied in development of a software There is a cascade from one phase to another phase this model is known as water fall model or software lifecycle. These model consists of phases like 1. Requirements analysis and definition 2. System and software design 3. Implementation and unit testing 4. Integration and system testing 5. Operation and maintenance Requirement analysis and definition: To gather requirements to be implemented To produce document i.e. Software requirements specification document. System and software design: Overall architecture of system: Identifying hardware, software components Detailed design: Design of functions in software components. To produce document i.e. Design description document. Implementation and unit testing: During this stage the software design is realized as a set of Program units Unit testing involves verifying that each unit meets its specification. Integration and system testing: Integrating Individual programs Testing to check interface between programs. Testing system meeting users requirement. Operations and maintenance: Delivery of software. Maintenance involves correcting errors which were not discovered earlier stages of life cycle. Capability enhancement and optimization.

Waterfall model or software life cycle:

MCA@ TOCE, Bangalore

Page 2

Requirement analysis and definition

System and software design Implementation and unit testing

Integration and system testing

**Merits of waterfall model (or) Advantages: Easy to understand. Even for a non-technical person. Produces clarity about software development process. Visibility of progress of process is high due to defined start and finish with document. Drawbacks of waterfall model(or)demerits: One phase has to be completed before moving onto the next phase. Results of each phase are frozen before moving to next phase which is practically not possible If errors are detected after delivery, correction is very expensive, thus iteration should be allowed. For large system, at delivery time, requirements may change and cost is high for rework. Working version is available only after completion of full product. Therefore, this model is only appropriate when the requirements are wellunderstood and changes will be fairly limited during the different phases Results of each phase are frozen before moving to next phase which is practically not possible. In practice, these steps overlap and feed information to each other. ***2.Evolutionary development(or)Evolutionary prototyping

Operation and maintenance

What is evolutionary prototyping? How does it differ from throw-away prototyping? List and explain major problems? A) In evolution model, a basic is developed and delivered to customer for his feedback. It is redesigned according to customer, likewise, many versions are created until a whole product is developed (or)

MCA@ TOCE, Bangalore

Page 3

This is based on the idea of developing an initial implementation, exposing this to the user comment and refining it through many versions until an adequate system has been developed. In this type of model before the original product is build a prototype which represents the original product will be shown to the customer If the customer is satisfied with the prototype then the original product will be build otherwise the second version of the prototype with the changes of the customer will be shown to the customer .The customer evaluate the prototype if it is totally satisfied then the original product is being built Types: 1. Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Development can be started even a part of the requirements are understood clearly. new features can be added User has an active participation. Process continues until final product is built 2. Throw-away prototyping Objective is to understand the system requirements. All requirements are to be understood and carry on the development. Developed part (prototype) is thrown way once requirements are gathered in full. Actual system development starts from scratch. Concurrentactivities Specificatio n Outline description of product

Initial Version

Developmen t

Intermediate version

Validation

Intermediate version

Merits (or) Advantages Requirements are not frozen in beginning. Users get better understanding about requirements, functionalities etc.Users can participate in system development indirectly. Page 4

MCA@ TOCE, Bangalore

Method is helpful for requirements elicitation and analysis (when requirements are not fully available). E.g. Artificial Intelligence System This development is useful when staff is not available for complete implementation by the business deadline. Demerits (or)problems Lack of process visibility The developer often makes implementation, comprinises in order to get a prototyping working quickly & in appropriate operating system. The customer seems what appears to be a working to version of the s/w. Systems are often poorly structured Special skills (e.g. skills 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

3. Component-based software engineering

Component-based development has many characteristics of spiral model. It is evolutionary in nature and includes iterative approach for software development. Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. This model leads to software reuse (i.e) Reusable components means software modules those are developed for specific application can be reused in development of other application projects Reusability provides many benefits for software development Process stages Requirements specification Component analysis Requirements modification System design with reuse Development and integration This approach is becoming increasingly used as component standards have emerged.

MCA@ TOCE, Bangalore

Page 5

Requirement sspecificatio n

Componen t analysi s

Requirement smodificatio n

System with reuse design System validatio n

Developmen and integration t

Requirements analysis and specification: Gather requirements Define specifications Component analysis: Selection of reusable components having similar functionality Requirements may match with the existing software components Usage of components reduces time and work efforts. Hence a search is made for components. If there is no exact match and the components that may be used only to provide some of the functionality required Requirements modification: During this stage requirements are analyzed using information about the components If exact match is not available, modify requirements If modifications not possible, component analysis is performed again System design with reuse: The framework of the system is designed or an existing framework is reused. Structured design considering reusable components Development and integration: The requirement which doesnt have existing components to replace, are developed. Newly developed components are integrated with COTS System validation: System as a whole is validated. Merits: Enhanced productivity due to less development. Saving of time and development cost. It improves system interoperability due to uniform interfaces between components. Performance and reliability of components is high due to extensive testing. MCA@ TOCE, Bangalore Page 6

Demerits: It requires modification in requirements. The proprietary and copyright issues may affect the evolution of system as reused components are the property of parent organization. Applicability: When requirements are general. Related components are available. Not applicable to very specific and customized product. Topic2-Process iteration System requirements of a large system always evolve during development process Repetition of a process is known as process iteration Iteration can be applied to any of the generic process models. Two approaches Incremental delivery Spiral development **1. Incremental delivery (or)Witha neat diagram explain the incremental development process? Using these models a limited set of customers requirements are implemented quickly and are delivered to customer. Rather than delivering system as a single unit, Specification&design,implementation is broken down in to increments In incremental development process customer identify, in outline, the services to be provided by the system. They identify which of the services are most important and which are least important to them. Each increment having part of the required functionality is developed and delivered. Once the system increments have been identified, the requirements for the services to be delivered in the first increment are defined in detail, and that increment is developed During development, further requirements analysis for later increments can take place. User requirements are prioritised and the highest priority requirements are included in early increments. Once an increment is completed and delivered, customers can put it into service As new increments are completed, they are integrated with existing increments so that system functionality improves with each delivered increment.

MCA@ TOCE, Bangalore

Page 7

Define outline requirement s

Assign requirements to increments

Design system Architecture

Develop system Increment

Validate Increme nt

Integrat e Increme nt

Validate System Fina l syste m

System incomplete Advantages (or)Merits First increment is available within a short time. No need to wait for entire system 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 most testing. Demerits (or) problems Increments being small, it may be difficult assigning a particular ser of requirements to an increment. As requirements are not defined in detail until an increment is to be implemented, it is difficult to identify common requirements of the increments. A variant of incremental approach is extreme programming. An approach to development based on the development and delivery of very small increments of functionality. Relies on constant code improvement, user involvement in the development team and pair wise programming. Products is delivered in parts, total cost is increasing or higher. Example: VCD cutter software: This software extracts any number of files from a large given video file. The main components of this software would be, 1. File extraction 2. Playing of file 3. Selecting the initial point. File extraction, playing can be developed in first increment, selection in the next increment

***2.Spiral Model
Describe the salient features of Boehms spiral model of software development process with a diagram. List the merits & demerits? The spiral model originally proposed by Boehm. Process is represented as a spiral rather than as a sequence of activities with backtracking.

MCA@ TOCE, Bangalore

Page 8

This model is combination of waterfall & prototyping & adds new additional features to the spiral model. The spiral model focuses on identifying and eliminating high-risk problems by careful process design rather than treating both smaller and severe problems uniformly. Each loop in the spiral represents a phase in the process. No fixed phases are defined such as specification or design Risks are potentially adverse circumstances that may damage the development process and quality of products. Loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process. The main characteristics of these model is that it is cyclic not linear like waterfall model. Each loop (or) cycle in the spiral is split in to four sectors (or)stages 1. Objective setting Specific objectives for the phase are identified. Constraints on the process and the product are identified and a detailed management plan is drawn up. Project risks are identified. Alternatives strategies, depending on these risks, may be planned. 2. Risk assessment and reduction Risks are assessed and steps are taken to reduce the risks. Identified risks of stage 1 are analyzed properly and careful measures are taken to reduce the risks If risks cannot be resolved, project is immediately terminated 3. Development and validation A development model for the system is chosen which can be any of the generic models on the basis of risk factor involved. E.g. formal development for the projects with high risks 4. Planning The project is reviewed and the next phase of the spiral is planned.

MCA@ TOCE, Bangalore

Page 9

Strengths (or)Merits It is most realistic model for software development It reduces the number of risks in software development Planning for next phase Verification & validation after each phase Easy to judge how much to test No distinction between development, maintenance Weaknesses (or) disadvantages (or) demerits -- If minor risk is not discovered in early iteration of spiral, in later stages it may become a major risk For large-scale software only Each iteration around the spiral leads to more completed version of software. But its difficult to convince the customer that the model is controllable For internal (in-house) software usually.

Topic3-Process Activities
The four basic process activities are MCA@ TOCE, Bangalore Page 10

Software specification Software design and implementation Software validation Software evolution

1 . Software specifications : Document that describes what the software will do (EX:how it works, what the screen a look like) The process of establishing what services are required and the constraints on the systems operation and development. The are four main phases in the Requirements engineering process Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation

Feasibility Study

Requirements Elicitation and Analysis

Requirements Specifications

Requirements Validation

Feasibility Report

System Models

User & system Requirements

Requirements document

1.Feasibility Studies : To check whether the system we are developing are the feasible one or not A feasibility study decides whether or not the proposed system is worthwhile to develop Necessary resources are there are not. Aims to conform Organizational objectives If the system contributes to organisational objectives Technical feasibility If the system can be engineered using current technology Economic feasibility If the system can be engineered within budget & time MCA@ TOCE, Bangalore Page 11

Operational feasibility If the system can be integrated with other systems that are used 2.Requirements elicitation and analysis : Process of gathering system requirements and constraints. Software developers interact with stakeholders (customers, end users, system, engineers, domain experts, business managers) It includes collection of functional and non-functional requirements 3.Requirements specifications: Gathered requirements are transformed into well structured document. It includes following requirements: High level statement of the requirements needed by users Detailed specifications of the system needed by software developers 4. Requirements validation: Checking of realism, consistency and completeness of requirements 2.Software design and implementation The process of converting the system specification into an executable system. Software design Design a software structure that realises the specification Implementation Translate this structure into an executable program The activities of design and implementation are closely related and may be interleaved.

The specific Design process activities are given below 1. Architectural design The sub-systems making up the system and their relationships are identifying and documented 2. Abstract specification For each sub-system, an abstract specification of its services and constraints under which subsystem must operate 3. Interface design For each sub-system its interface with other sub-system is designed and documented. Interface between subsystems 4. Component design Services are allocated to components and the interfaces of these Components are designed 5. Data structure design Data structure design in detail components are designed 6. Algorithm design MCA@ TOCE, Bangalore Page 12

Algorithms used to provide services are designed in detail and Specified

0 The last two stages of design data structure and algorithm design may be delayed until the implementation process. Structured methods: Systematic approaches to developing software design. The design is usually documented as a set of graphical models. Structured model supports Various models like Object model: Shows the object classes used in the system. Sequence model: Shows how objects in the system interact. State transition model: Shows system states and triggers for the transaction. Structural model: system components and their aggregations are documented. Data-flow model: Where the system is modeled using the data transformations that take place. The development of a program to implement the system follows naturally from the system design process. Programmers carry out some testing of code they have developed. This often reveals program defects that must be removed from the program. Programming and debugging: Translating a design into a program and removing errors from that program is knows as debugging. Programming is a personal activity and there is no generic programming process. Programmers carry out program testing to discover faults in the program and remove these faults in the debugging process.

The debugging process MCA@ TOCE, Bangalore Page 13

Defect testing and debugging are different processes Defects in the code must be located and the program modified to meet its requirements. Testing must then be repeated to ensure that changes has been made correctly. Thus the debugging process is part of both software development and software testing. 3.Software validation

Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. Involves checking and review processes and system testing. System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.

Testing process:

The stages in testing process are: Component or unit testing Individual components are tested independently Components may be functions or objects or coherent groupings of these entities. System testing Testing of the system as a whole. Testing of emergent properties is particularly important. The components are integrated to make up the system. This process is concerned with finding errors MCA@ TOCE, Bangalore Page 14

It is also concerned with validating that the system meets its functional and non functional requirements and testing the emergent system properties. Acceptance testing This the final stage in testing process before the system is accepted for operational use. Testing with customer data to check that the system meets the customers needs. This testing may reveal errors and omissions in the system requirements definition

Testing phases in the software process:

Testing involve integrating work from a number of programmers and must planned in advance An independent team of testers should work from preformulated test plans that are developed from system specification and design. The above fig shows how test plans are link between testing and development activities. Acceptance testing is sometimes called alpha testing. The alpha testing process continues until the system developer and the client agree that the delivered system is an acceptable implementation of the system requirements. When a system is to be marked as a software product, a testing process called beta testing often used. Beta testing involves delivering a system to a number of potential customers who agree to use that system. Page 15

MCA@ TOCE, Bangalore

4.Software evolution Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.

**Topic4-The Rational Unified Process Explain Rational Unified Process in detail? Rational Unified Process (RUP) is a hybrid process model bringing the elements from different generic process models. A modern process model derived from the work on the UML and associated process. Normally described from 3 perspectives A dynamic perspective that shows phases over time A static perspective that shows process activities A practice perspective that suggests good practice RUP phase model: There are five generic phases provided by unified process model. Every phase has to adopt of frame work activities that they are used to describe any s/w process model they are.

1. Inception MCA@ TOCE, Bangalore Page 16

The goal of the inception phase is to establish the business case for the system (baseline to meet business requirements) These phase encompulses both customer communication & planning activities By collaborating with customer & end-users business requirement for the s/w are identified. Identify all the entities and their interaction Cost and schedule analysis is made If project does not pass this milestone, project is cancelled. 2. Elaboration The goal of the Elaboration phase is to develop an understanding of the problem domain and the system architecture. Elaboration phase combines the features of planning & modeling tasks of the software development process At this stage the abstract information provided during the inception phase is refined and enlarged These phase establish the following points: Domain analysis Architectural framework Project plan Project risks Use case model 3. Construction The construction phase is concerned with System design, programming and testing. The primary aspect of this phase is to develop suitable code for each component of the software. For this purpose consider various models, designed during inception & elaboration phases of unified process. We usually proceed to perform unit testing for each component. Develop different parts of system in parallel and integrated We finally end up this session by acceptance tests. A working software with documentation is ready 4. Transition The final phase of the RUP is concerned with to deploy the system in its operating environment These phase marks the end of construction & the beginning of deployment phases. During this phase software developed shown to the end-users for better testing.(i.e) implementation of development phase After collecting the information on the number of defects & queries related to operation of the software, well defined modifications are made to it. Training to end users Check against quality goals set in Inception phase RUP supports iteration in two ways: Each phase may be performed in an iterative way MCA@ TOCE, Bangalore Page 17

 All phases may also be performed iteratively RUP: Workflows : Within each iteration, the tasks are categorized into nine disciplines, six "engineering disciplines 1. Business Modeling The business processes are modified using business cases 2. Requirements Actors are identified and use cases are developed to model system requirements 3. Analysis and Design A design model including architectural models, component models, object models and sequence models is created. 4. Implementation Subsystems and components are implemented. Code can be generated automatically. 5. Test Unit testing is carried out in conjunction with coding. System testing is realized after proper integration. 6. Deployment A product release is produced and delivered to its end users 7. Configuration and Change Management This workflow manages changes and keeps track of configurations 8. Project Management This workflow manages the work plan, schedule, cost and progress of development 9. Environment This workflow provides the software development environment (process & tools) that will support the development team RUP good practice : Six fundamental best practices 1. Develop software iteratively Increments are planned based on customers priorities and importance of the increment Highest priority increment is developed and delivered first 2. Manage requirements Customers requirements should be documented. Changes in requirements are analyzed for their impact on system 3. Use component-based architectures System architecture should be structured into the components 4. Visually model software System should be modeled using graphical UML to present static and dynamic views of the software 5. Verify software quality Organization quality standards can be followed in process and product both 6. Control changes to software

MCA@ TOCE, Bangalore

Page 18

Change management and configuration management procedures and tools should be used to manage and record the changes in software ***Topic5- Computer-aided software engineering

Write the activities that may be supported by CASE work and benches for analysis & design of software process? Computer-aided software engineering (CASE) is software used to support software development and evolution processes. These tools include design editors, data dictionaries, and compilers. Activity automation Graphical editors for system model development Data dictionary to manage design entities Graphical UI builder for user interface construction Debuggers to support program fault finding Automated translators to generate new versions of a program

Examples for Activity automation: Requirements Specification Graphical editors for system model development System Design Graphical editors and Data dictionary to manage design entities User Interface development Graphical UI builder for user interface construction Debugging Debuggers to support program fault finding Translation of Programs Automated translators to generate new versions of a program Case technology: Merits Case technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted Demerits Software engineering requires creative thought, which is not readily automated Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these. CASE classification: Functional perspective Tools are classified according to their specific function. Process perspective: Tools are classified according to process activities that are supported. MCA@ TOCE, Bangalore Page 19

Integration perspective Tools are classified according to their organisation into integrated units. ** CASE systems should be classified in to three categories : Tools Support individual process tasks such as design consistency checking, text editing, etc. Workbenches Support a process phase such as specification or design Normally include a number of integrated tools. Environments Support all or a substantial part of an entire software process. Normally include several integrated workbenches Tools, workbenches, environments:

Function-based CASE tool classification: These classification is a/c to function.

MCA@ TOCE, Bangalore

Page 20

Activity-based CASE tool classification: Alternative classification of CASEtools.

MCA@ TOCE, Bangalore

Page 21