Page 1 MCA302 SOFTWARE ENGINEERING UNIT I - SOFTWARE PROCESS Introduction S/W Engineering Paradigm life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, object oriented) - system engineering computer based system verification validation life cycle process development process system engineering hierarchy. References: 1. Roger S. Pressman, Software Engineering A Practitioners Approach, Sixth Edition, McGraw Hill, 2005. 2. Ian Sommerville, Software Engineering, 7th edition, Pearson Education 2004. 3. NPTEL Material-IIT Kharagpur http://nptel.iitm.ac.in/courses/webcourse-contents/iit%20kharagpur/ Soft%20Engg/pdf/m01L01.pdf Compiled By: A.Saleem Raja. MCA.,M.Phil.,(M.Tech) & R.Vinodini.MCA.,M.Phil., Lecturer Department of MCA
Page 2 MCA302 Objective At the end of this unit, students will learn Computer Software Software Engineering Software Process Software Process Model Software Life Cycle Introduction Software engineering is an engineering approach for software development. We can alternatively view it as a systematic collection of past experience. The experience is arranged in the form of methodologies and guidelines. A small program can be written without using software engineering principles. But if one wants to develop a large software product, then software engineering principles are indispensable to achieve a good quality software cost effectively. Need for software engineering principles Without using software engineering principles it would be difficult to develop large programs. In industry it is usually needed to develop large programs to accommodate multiple functions. A problem with developing such large commercial programs is that the complexity and difficulty levels of the programs increase exponentially. For example, a program of size 1,000 lines of code has some complexity. But a program with 10,000 LOC is not just 10 times more difficult to develop, but may as well turn out to be 100 times more difficult unless software engineering principles are used. In such situations software engineering techniques come to rescue. Software engineering helps to reduce the programming complexity. Software engineering principles use two important techniques to reduce problem complexity: abstraction and decomposition. Abstraction: The principle of abstraction (in fig.1.4) implies that a problem can be simplified by omitting irrelevant details. In other words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant for certain purpose and
Page 3 MCA302 suppress other aspects that are not relevant for the given purpose. Once the simpler problem is solved, then the omitted details can be taken into consideration to solve the next lower level abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the problem. Decomposition: The other approach to tackle problem complexity is decomposition. In this technique, a complex problem is divided into several smaller problems and then the smaller problems are solved one by one. The problem has to be decomposed such that each component of the decomposed problem can be solved independently and then the solution of the different components can be combined to get the full solution. A good decomposition of a problem should minimize interactions among various components. Software Software is defined by-roger S. Pressman Computer software is the product that software engineers design and build. It encompasses programs that execute within a computer of any size and architecture, documents that encompass hard-copy and virtual forms, and data that combine numbers and text but also includes representations of pictorial, video, and audio information. Software is defined by- Ian Sommerville
Page 4 MCA302 Computer programs and associated documentation such as requirements, design models and user manuals. Software products may be developed for a particular customer or may be developed for a general market. Software products may be Generic - developed to be sold to a range of different customers Example: PC software such as Excel or Word. Bespoke (custom) - developed for a single customer according to their specification. New software can be created by developing new programs, configuring generic software systems or reusing existing software. Software Characteristics Software is a logical rather than a physical system element. Therefore, software has characteristics that are considerably different than those of hardware: 1. Software is developed or engineered; it is not manufactured in the classical sense. 2. Software doesn't "wear out." When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. Therefore, software maintenance involves considerably more complexity than hardware maintenance. 3. Although the industry is moving toward component-based assembly, most software continues to be custom built. Generic categories for software applications Software may be applied in any situation for which a pre-specified set of procedural steps (i.e., an algorithm) has been defined. The following software areas indicate the breadth of potential applications:
Page 5 MCA302 System software. System software is a collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) process complex, but determinate, information structures. The system software area is characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing, and sophisticated process management; complex data structures; and multiple external interfaces. Real-time software. Software that monitors/analyzes/controls real-world events as they occur is called real time. Elements of real-time software include a data gathering component that collects and formats information from an external environment, an analysis component that transforms information as required by the application, a control/output component that responds to the external environment, and a monitoring component that coordinates all other components so that real-time response (typically ranging from 1 millisecond to 1 second) can be maintained. Business software. Business information processing is the largest single software application area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inventory) have evolved into management information system (MIS) software that accesses one or more large databases containing business information. Engineering and scientific software. Engineering and scientific software have been characterized by "number crunching" algorithms. Applications range from astronomy to volcanology, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing. Embedded software. Intelligent products have become commonplace in nearly every consumer and industrial market. Embedded software resides in read-only memory and is used to control products and systems for the consumer and industrial markets. Embedded software can perform very limited and esoteric functions (e.g., keypad control for a microwave oven) or provide significant function and control
Page 6 MCA302 capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems). Personal computer software. The personal computer software market has burgeoned over the past two decades. Word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business financial applications, external network, and database access are only a few of hundreds of applications. Web-based software. The Web pages retrieved by a browser are software that incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g., hypertext and a variety of visual and audio formats). In essence, the network becomes a massive computer providing an almost unlimited software resource that can be accessed by anyone with a modem. Artificial intelligence software. Artificial intelligence (AI) software makes use of non-numerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Expert systems, also called knowledge based systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing are representative of applications within this category. Software Engineering There are hundreds of authors have developed personal definitions of software engineering. The IEEE [IEE93] has developed a more comprehensive definition when it states: Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). Another definition by - Ian Sommerville Software engineering is an engineering discipline that is concerned with all aspects of software production.
Page 7 MCA302 Software engineers should adopt a systematic and organized approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available. The advantages of using software engineering for developing software are: Improved quality Improved requirement specification Improved cost and schedule estimates Better use of automated tools and techniques Less defects in final product Better maintenance of delivered software Well defined processes Improved productivity Improved reliability What is the difference between software engineering and computer science? Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. Computer science theories are still insufficient to act as a complete underpinning for software engineering (unlike e.g. physics and electrical engineering). System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system. System engineers are involved in system specification, architectural design, integration and deployment. Software Engineering Layers (Process, Methods, and Tools)
Page 8 MCA302 o Software engineering is a layered technology. Referring to below figure, any engineering approach (including software engineering) must rest on an organizational commitment to quality. Figure: Software engineering layers o The foundation for software engineering is the process layer. Software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. The key process areas form the basis for management control of software projects and establish the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed. o Software engineering methods provide the technical how-to's for building software. Methods encompass a broad array of tasks that include requirements analysis, design, program construction, testing, and support. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques. o Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another. Generic Phases in Software Engineering The work associated with software engineering can be categorized into three generic phases, regardless of application area, project size, or complexity. The definition phase focuses on what. That is, during definition, the software engineer attempts to identify what information is to be processed, what function and performance
Page 9 MCA302 are desired, what system behavior can be expected, what interfaces are to be established, what design constraints exist, and what validation criteria are required to define a successful system. The development phase focuses on how. That is, during development a software engineer attempts to define how data are to be structured, how function is to be implemented within a software architecture, how procedural details are to be implemented, how interfaces are to be characterized, how the design will be translated into a programming language (or nonprocedural language), and how testing will be performed. The methods applied during the development phase will vary, but three specific technical tasks should always occur: software design, code generation, and software testing. The support phase focuses on change associated with error correction, adaptations required as the software's environment evolves, and changes due to enhancements brought about by changing customer requirements. Software process Software process is a series of predictable steps a road map that helps to create a timely, high-quality product or system (or) a set of activities whose goal is the development or evolution of software. Generic activities in all software processes are: o Specification - what the system should do and its development constraints o Development - production of the software system o Validation - checking that the software is what the customer wants o Evolution - changing the software in response to changing demands. Capability Maturity Model (CMM) In recent years, there has been a significant emphasis on process maturity. The Software Engineering Institute (SEI) has developed a comprehensive model predicated on a set of software engineering capabilities that should be present as organizations reach different levels of process maturity. To determine an organization s current state of process maturity, the SEI uses an assessment that results in a five point grading scheme. The grading scheme
Page 10 MCA302 determines compliance with a capability maturity model (CMM) that defines key activities required at different levels of process maturity. Software Process Models (Or) Software Engineering Paradigm A development strategy that encompasses the process, methods, and tools layers and the generic phases. This strategy is often referred to as a process model or a software engineering paradigm. (Or) A simplified representation of a software process, presented from a specific perspective. Examples of process perspectives are o Workflow perspective - sequence of activities; o Data-flow perspective - information flow; o Role/action perspective - who does what. Generic process models o Waterfall o Iterative development o Component-based software engineering. A process model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required. Software Life Cycle Model
Page 11 MCA302 A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle. A life cycle model represents all the activities required to make a software product transit through its life cycle phases. It also captures the order in which these activities are to be undertaken. In other words, a life cycle model maps the different activities performed on a software product from its inception to retirement. Different life cycle models may map the basic development activities to phases in different ways. Thus, no matter which life cycle model is followed, the basic activities are included in all life cycle models though the activities may be carried out in different orders in different life cycle models. During any life cycle phase, more than one activity may also be carried out. For example, the design phase might consist of the structured analysis activity followed by the structured design activity. The need for a software life cycle model The development team must identify a suitable life cycle model for the particular project and then adhere to it. Without using of a particular life cycle model the development of a software product would not be in a systematic and disciplined manner. When a software product is being developed by a team there must be a clear understanding among team members about when and what to do. Otherwise it would lead to chaos and project failure. A software life cycle model defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So without software life cycle model the entry and exit criteria for a phase cannot be recognized. Without software life cycle models (such as classical waterfall model, iterative waterfall model, prototyping model, evolutionary model, spiral model etc.) it becomes difficult for software project managers to monitor the progress of the project. Different software life cycle models Linear sequential model (or) Waterfall Model Prototyping model Rad model
Page 12 MCA302 Evolutionary software process models Incremental model Spiral model WinWin spiral model Concurrent development model Component-based development Formal methods model Fourth generation techniques Linear Sequential Model (or) Waterfall Model Sometimes called the classic life cycle or the waterfall model, the linear sequential model suggests a systematic, sequential approach5 to software development that begins at the system level and progresses through analysis, design, coding, testing, and support Classical waterfall model divides the life cycle into the following phases as shown in figure o o o o o o Feasibility Study Requirements Analysis and Specification Design Coding and Unit Testing Integration and System Testing Maintenance
Page 13 MCA302 Figure: Classical Waterfall Model Activities in each phase of the life cycle Activities undertaken during feasibility study: - The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product. At first project managers or team leaders try to have a rough understanding of what is required to be done by visiting the client side. They study different input data to the system and output data to be produced by the system. They study what kind of processing is needed to be done on these data and they look at the various constraints on the behavior of the system. After they have an overall understanding of the problem they investigate the different solutions that are possible. Then they examine each of the solutions in terms of what kind of resources required, what would be the cost of development and what would be the development time for each solution.
Page 14 MCA302 Based on this analysis they pick the best solution and determine whether the solution is feasible financially and technically. They check whether the customer budget would meet the cost of the Activities undertaken during requirements analysis and specification: - The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely Requirements gathering and analysis Requirements specification The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed. This is done to clearly understand the customer requirements so that incompleteness and inconsistencies are removed. The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. For example, to perform the requirements analysis of a business accounting software required by an organization, the analyst might interview all the accountants of the organization to ascertain their requirements. The data collected from such a group of users usually contain several contradictions and ambiguities, since each user typically has only a partial and incomplete view of the system. Therefore it is necessary to identify all ambiguities and contradictions in the requirements and resolve them through further discussions with the customer. After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements properly understood, the requirements specification activity can start. During this activity, the user requirements are systematically organized into a Software Requirements Specification (SRS) document.
Page 15 MCA302 The customer requirements identified during the requirements gathering and analysis activity are organized into a SRS document. The important components of this document are functional requirements, the nonfunctional requirements, and the goals of implementation. Activities undertaken during design: - The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the software architecture is derived from the SRS document. Two distinctly different approaches are available: the traditional design approach and the object-oriented design approach. Traditional design approach Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. This is followed by a structured design activity. During structured design, the results of structured analysis are transformed into the software design. Object-oriented design approach In this technique, various objects that occur in the problem domain and the solution domain are first identified, and the different relationships that exist among these objects are identified. The object structure is further refined to obtain the detailed design. Activities undertaken during coding and unit testing:- The purpose of the coding and unit testing phase (sometimes called the implementation phase) of software development is to translate the software design into source code. Each component of the design is implemented as a program module. The end-product of this phase is a set of program modules that have been individually tested.
Page 16 MCA302 During this phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage. Activities undertaken during integration and system testing: - Integration of different modules is undertaken once they have been coded and unit tested. During the integration and system testing phase, the modules are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document. System testing usually consists of three different kinds of testing activities: α testing: It is the system testing performed by the development team. β testing: It is the system testing performed by a friendly set of customers. acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product. System testing is normally carried out in a planned manner according to the system test plan document. The system test plan identifies all testing-related activities that must be performed, specifies the schedule of testing, and allocates resources. It also lists all the test cases and the expected outputs for each test case. Activities undertaken during maintenance: - Maintenance of a typical software product requires much more than the effort necessary to develop the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in the 40:60 ratio.
Page 17 MCA302 Maintenance involves performing any one or more of the following three kinds of activities: o Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. o Improving the implementation of the system, and enhancing the functionalities of the system according to the customer s requirements. This is called perfective maintenance. o Porting the software to work in a new environment. For example, porting may be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance. Problems of the classical waterfall model The main drawback of the waterfall model is Difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase. Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. Phase-entry and Phase-exit criteria of each phase At the starting of the feasibility study, project managers or team leaders try to understand what the actual problem is by visiting the client side. At the end of that phase they pick the best solution and determine whether the solution is feasible financially and technically. At the starting of requirements analysis and specification phase the required data is collected. After that requirement specification is carried out. Finally, SRS document is produced.
Page 18 MCA302 At the starting of design phase, context diagram and different levels of DFDs are produced according to the SRS document. At the end of this phase module structure (structure chart) is produced. During the coding phase each module (independently compilation unit) of the design is coded. Then each module is tested independently as a stand-alone unit and debugged separately. After this each module is documented individually. The end product of the implementation phase is a set of program modules that have been tested individually but not tested together. After the implementation phase, different modules which have been tested individually are integrated in a planned manner. After all the modules have been successfully integrated and tested, system testing is carried out. Software maintenance denotes any changes made to a software product after it has been delivered to the customer. Maintenance is inevitable for almost any kind of product. Prototyping Paradigm A prototype usually turns out to be a very crude version of the actual system. The prototyping paradigm begins with requirements gathering. Developer and customer meet and define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A "quick design" then occurs. The quick design focuses on a representation of those aspects of the software that will be visible to the customer/user (e.g., input approaches and output formats). The quick design leads to the construction of a prototype. The prototype is evaluated by the customer/user and used to refine requirements for the software to be developed. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done. Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is built, the developer attempts to use existing program fragments or
Page 19 MCA302 applies tools (e.g., report generators, window managers) that enable working programs to be generated quickly. Figure: Prototyping paradigm Need for a prototype in software development There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the customer s needs: How the screens might look like How the user interface would behave How the system would produce outputs This is something similar to what the architectural designers of a building do; they show a prototype of the building to their customer. The customer can evaluate whether he likes it or not and the changes that he would need in the actual product. A similar thing happens in the case of a software product and its prototyping model. Another reason for developing a prototype is that it is impossible to get the perfect product in the first attempt. Many researchers and engineers advocate that if you want to develop a
Page 20 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & good product you must plan to throw away the first version. The experience gained in developing the prototype can be used to develop the final product. A prototyping model can be used when technical solutions are unclear to the development team. A developed prototype can help engineers to critically examine the technical issues associated with the product development. Often, major design decisions depend on issues like the response time of a hardware controller, or the efficiency of a sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way to resolve the technical issues. Examples for prototype model A prototype of the actual product is preferred in situations such as: User requirements are not complete Technical issues are not clear Let s see an example for each of the above category. Example 1: User requirements are not complete In any application software like billing in a retail shop, accounting in a firm, etc the users of the software are not clear about the different functionalities required. Once they are provided with the prototype implementation, they can try to use it and find out the missing functionalities. Example 2: Technical issues are not clear Suppose a project involves writing a compiler and the development team has never written a compiler. In such a case, the team can consider a simple language, try to build a compiler in order to check the issues that arise in the process and resolve them. After successfully building a small compiler (prototype), they would extend it to one that supports a complete language.
Page 21 MCA302 RAD Model Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a highspeed adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a fully functional system within very short time periods (e.g., 60 to 90 days). Used primarily for information systems applications, the RAD approach encompasses the following phases: Business modeling: The information flow among business functions is modeled. Data modeling: The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics (called attributes) of each object are identified and the relationships between these objects defined.
Page 22 MCA302 Process modeling: The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object. Application generation: RAD assumes the use of fourth generation techniques rather than creating software using conventional third generation programming languages, the RAD process works to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software. Testing and turnover: Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully exercised. Problems with RAD Model For large but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams. RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a system complete in a much abbreviated time frame. If commitment is lacking from either constituency, RAD projects will fail. Not all types of applications are appropriate for RAD. If a system cannot be properly modularized, building the components necessary for RAD will be problematic. 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. RAD is not appropriate when technical risks are high. This occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability with existing computer programs. Evolutionary Software Process Models There is growing recognition that software, like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds,
Page 23 MCA302 making a straight path to an end product unrealistic; tight market deadlines make completion of a comprehensive software product impossible, but a limited version must be introduced to meet competitive or business pressure; a set of core product or system requirements is well understood, but the details of product or system extensions have yet to be defined. In these and similar situations, software engineers need a process model that has been explicitly designed to accommodate a product that evolves over time. The linear sequential model is designed for straight-line development. In essence, this waterfall approach assumes that a complete system will be delivered after the linear sequence is completed. The prototyping model is designed to assist the customer (or developer) in understanding requirements. In general, it is not designed to deliver a production system. The evolutionary nature of software is not considered in either of these classic software engineering paradigms. Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software. Evolutionary software models are Incremental model Spiral model WinWin spiral model Concurrent development model Incremental Model The incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping. Referring to Figure 1, the incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces a deliverable increment of the software. For example, word-processing software developed using the incremental paradigm might deliver basic file management, editing, and document production functions in the first increment; more sophisticated editing and document production capabilities in the second
Page 24 MCA302 increment; spelling and grammar checking in the third increment; and advanced page layout capability in the fourth increment. It should be noted that the process flow for any increment can incorporate the prototyping paradigm. Figure 1: The incremental model When an incremental model is used, the first increment is often a core product. That is, basic requirements are addressed, but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer (or undergoes detailed review). As a result of use and/or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced. The incremental process model, like prototyping and other evolutionary approaches, is iterative in nature. But unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment. Early increments are stripped down versions of the final product, but they do provide capability that serves the user and also provide a platform for evaluation by the user.
Page 25 MCA302 Incremental development 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 the core product is well received, then additional staff (if required) can be added to implement the next increment. In addition, increments can be planned to manage technical risks. For example, a major system might require the availability of new hardware that is under development and whose delivery date is uncertain. It might be possible to 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. Spiral model The spiral model, originally proposed by Boehm, is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. It provides the potential for rapid development of incremental versions of the software. Using the spiral model, software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. A spiral model is divided into a number of framework activities, also called task regions. Typically, there are between three and six task regions. Figure 2 depicts a spiral model that contains six task regions:
Page 26 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & Figure 2 A typical spiral model Customer communication tasks required to establish effective communication between developer and customer. Planning tasks required to define resources, timelines, and other project related information. Risk analysis tasks required to assess both technical and management risks. Engineering tasks required to build one or more representations of the application. Construction and release tasks required to construct, test, install, and provide user support (e.g., documentation and training). Customer evaluation tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.
Page 27 MCA302 As this evolutionary process begins, the software engineering team moves around the spiral in a clockwise direction, beginning at the center. The first circuit around the spiral might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from customer evaluation. In addition, the project manager adjusts the planned number of iterations required to complete the software. The spiral model is a realistic approach to the development of large-scale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism but, more important, enables the developer to apply the prototyping approach at any stage in the evolution of the product. It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into an iterative framework that more realistically reflects the real world. The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic. But like other paradigms, the spiral model may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur. Finally, the model has not been used as widely as the linear sequential or prototyping paradigms. It will take a number of years before efficacy of this important paradigm can be determined with absolute certainty. WinWin Spiral Model This is an adaptation of the spiral model which emphasis is explicitly placed on the involvement of the client in a negotiation process at the genesis of the product
Page 28 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & development. Ideally, the developer would simply ask the customer what is required and the customer would provide sufficient detail to proceed. Unfortunately this rarely happens and significant negotiations between both parties are required to balance functionality, performance, etc with cost and time-to-market considerations. The model, shown in Fig. 3, derives its name from the objective of these negotiations, i.e. win-win. The client gets the product that satisfies the majority of his/her needs, and the developer wins by working to realistic and achievable budgets and deadlines. To achieve this objective the model defines a set of negotiation activities at the beginning of each pass around the spiral. Rather than a single customer communication activity the following activities are defined: Identification of the system stakeholders. That is the people on the organisation that have direct business interest in the product to be built and will be rewarded for a successful outcome or criticised if the effort fails (e.g. user, customer, developer, maintainer, interfacer, etc.). Determination of the stakeholder s win conditions Negotiations of the stakeholder s win conditions to reconcile them into a set of winwin conditions for all concerned (including the software project team).
Page 29 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & Figure 3: WINWIN Spiral Model In addition to the early emphasis placed on the win-win condition, the model also introduces three process milestones (anchor points), which help establish the completion of one cycle around the spiral and provide the decision milestones before the software project proceeds. These are, 1. Life Cycle Objectives (LCO) Defines a set of objectives for each major software activity (e.g. a set of objectives associated with the definition of top level product requirements) 2. Life Cycle Architecture (LCA) Establishes the objectives that must be met as the as the software architecture is defined. 3. Initial Operational Capability (IOC) represents a set of objectives associated with the preparation of the software for installation/distribution, site preparations prior to installations, and assistance required by all parties that will use or support the software.
Page 30 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & Advantages: Faster software production facilitated through collaborative involvement of the relevant stake holders. Cheaper software via rework and maintenance reductions Component Based Software Engineering In the majority of software projects, there is some software reuse. This usually happens informally when people working on the project know of designs or code which is similar to that required. They look for these, modify them as needed and incorporate them into their system. This informal reuse takes place irrespective of the development process that is used. However, in the last few years, an approach to software development called component-based software engineering (CBSE), which relies on reuse, has emerged and is becoming increasingly used. This reuse-oriented approach relies on a large base of reusable software components and some integrating framework for these components. Sometimes, these components are systems in their own right (COTS or commercial off-the-shelf systems) that may provide specific functionality such as text formatting or numeric calculation. The generic process model for CBSE is shown in Figure 3. Figure 3 Component-based software engineering While the initial requirements specification stage and the validation stage are comparable with other processes, the intermediate stages in a reuse-oriented process are different. These stages are:
Page 31 MCA302 1. Component analysis. Given the requirements specification, a search is made for components to implement that specification. Usually, there is no exact match, and the components that may be used only provide some of the functionality required. 2. Requirements modification. During this stage, the requirements are analyzed using information about the components that have been discovered. They are then modified to reflect the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions. 3. System design with reuse. During this phase, the framework of the system is designed or an existing framework is reused. The designers take into account the components that are reused and organize the framework to cater to this. Some new software may have to be designed if reusable components are not available. 4. Development and integration Software that cannot be externally procured is developed, and the components and COTS systems are integrated to create the new system. System integration, in this model, may be part of the development process rather than a separate activity. Component-based software engineering has the obvious advantage of reducing the amount of software to be developed and so reducing cost and risks. It usually also leads to faster delivery of the software. However, requirements compromises are inevitable and this may lead to a system that does not meet the real needs of users. Furthermore, some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them. System Engineering: Software engineering occurs as a consequence of system engineering System engineering may take on two different forms depending on the application domain
Page 32 MCA302 Business process engineering conducted when the context of the work focuses on a business enterprise Product engineering conducted when the context of the work focuses on a product that is to be built Both forms bring order to the development of computer-based systems Both forms work to allocate a role for computer software and to establish the links that tie software to other elements of a computer-based system System A set or arrangement of things so related as to form a unity or organic whole A set of facts, principles, rules. etc., to show a logical plan linking the various parts A method or plan of classification or arrangement An established way of doing something such as a method or procedure Computer-based System Defined: A set or arrangement of elements that are organized to accomplish some predefined goal by processing information The goal may be to support some business function or to develop a product that can be sold to generate business revenue A computer-based system makes use of system elements Elements constituting one system may represent one macro element of a still larger system Example A factory automation system may consist of a numerical control machine, robots, and data entry devices; each can be its own system At the next lower hierarchical level, a manufacturing cell is its own computerbased system that may integrate other macro elements The role of the system engineer is to define the elements of a specific computerbased system in the context of the overall hierarchy of systems
Page 33 MCA302 A computer-based system makes use of the following four system elements that combine in a variety of ways to transform information Software: computer programs, data structures, and related work products that serve to effect the logical method, procedure, or control that is required Hardware: electronic devices that provide computing capability, interconnectivity devices that enable flow of data, and electromechanical devices that provide external functions People: Users and operators of hardware and software Database: A large, organized collection of information that is accessed via software and persists over time The uses of these elements are described in the following: Documentation: Descriptive information that portrays the use and operation of the system Procedures: The steps that define the specific use of each system element or the procedural context in which the system resides Verification and validation Software testing is one element of a broader topic that is often referred to as Verification and validation (V&V). Verification refers to the set of activities that ensure that software correctly implements a specific function. Validation refers to a different set of activities ensure that the software that has been built is traceable to customer requirements. Verification: Are we building the product right? Validation: Are we building the right product? The definition of V&V encompasses many of the activities that we have referred to as software quality assurance (SQA).