0

ISBN: 978-81-963532-2-3 (E-BOOK) Software Engineering Prof KEERTHANA P Prof MANASA KN Prof GANGA D BENAL Publisher’sName InternationalSocietyfor Green,SustainableEngineeringandManagement ISO9001:2015 certifiedforResearch,Development&Training An Autonomous Organization, Under Public Trust Act,GovernmentofWest Bengal,India Member The Indian Science Congress Association Indian Statistical Institute Indian Meteorological Society Certificate of Enlistment as Research Organization ,KMC 2023

SOFTWARE ENGINEERING

SOFTWARE ENGINEERING By KEERTHANA P Assistant Professor REVA UNIVERSITY MANASA KN Assistant Professor REVA UNIVERSITY GANGA D BENAL Assistant Professor Cambridge Institute of Technology Publisher’s Name International Society for Green, Sustainable Engineering and Management ISO 9001:2015 certified for Research, Development &Training (Certified as Research Organization, Under Section 199 Rule 435/435A Act 1980 Kolkata Municipal Corporation) An Autonomous Organization, Under Public Trust Act, Government of West Bengal, India Member The Indian Science Congress Association Indian Statistical Institute Indian Meteorological Society Certificate of Enlistment as Research Organization, KMC 2023

© International Society for Green, Sustainable Engineering and Management Editor in Chief: Dr.Debaprayag Chaudhuri, Chairman Production Editor: Mrs.Soma Das Chaudhuri Published in India by International Society for Green, Sustainable Engineering and Management 94,Garfa Main Road, Ground Floor, Jadavpur, Kolkata-700 075,West Bengal India Mobile:0091 96 74 76 61 80 Email: isgsem.research.kolkata@gmail.com Website: http://isgsemkolkata.blogspot.com Copyright © 2023.All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical or photocopying, recording, or otherwise without the prior permission of the publisher. The society names used in this set are for identification purposes only. 1st Edition: Augut’2023 ISBN : 978-81-963532-2-3 750

Author details Prof. KEERTHANA P, is an Science and Engineering, Be Computer Science and Engin her Master of Engineering in Currently pursuing a Phd in c Assistant Professor at Reva University, Sc ngaluru, India. She has earned a Bachelor eering from Visvesvaraya Technology Univ computer science and engineering from RE computer science and engineering at REVA chool of Computer or of Engineering in versity. She earned EVA University and A University. She is conducting research in the field of Machine Learning and Deep Learning and Artificial Intelligence. Prof. Manasa KN, is an Assist and Engineering, Bengaluru, Science and Engineering f ant Professor at Reva University, School of India. She earned a Bachelor of Enginee rom Nitte Meenakshi Karnataka in 2012. She earn University Visvesvaraya Colle field of Image Processing, Com Institute of Techn omputer Vision, Machine Learning and Deep L f Computer Science eering in Computer nology, Bengaluru, ned her Master of Engineering in Information Technology from ege of Engineering in 2015. She is conductit ng research in the Learning. Prof. Ganga D Benal Bengaluru, , is an India. She earn University in 2021. She is co Learning. Engineering from Atria Institu earned her Master of Tech Assistant professor at Cambridge Institute ed a Bachelor of Engineering in Informa te of Technology (VTU), Bengaluru, Karna hnology in computer te Of Technology , ation Science and ataka in 2019. She science and engineering from REVA onducting research in the field of Machine Learning and Deep

ISBN : 978-81-963532-2-3 (E-Book) SOFTWARE ENGINEERING BY KEERTHANA P Assistant Professor REVA UNIVERSITY MANASA KN Assistant Professor REVA UNIVERSITY GANGA D BENAL Assistant Professor Cambridge Institute of Technology 1 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) SYLLABUS Module I: Introductory concepts: Introduction, definition, objectives, Life cycle – Requirements analysis and specification. Design and Analysis: Cohesion and coupling, Data flow oriented Design: Transform centered design, Transaction centered design. Analysis of specific systems like Inventory control, Reservation system. Module II: Object-oriented Design: Object modeling using UML, use case diagram, class diagram, activity diagram, unified development process. Module III: Implementing and Testing: Programming language characteristics, fundamentals, languages, classes, coding style efficiency. Testing: Objectives, black box and white box testing, various testing strategies, Art of debugging. Maintenance, Reliability and Availability: Maintenance: Characteristics, controlling factors, maintenance tasks, side effects, preventive maintenance – Re Engineering – Reverse Engineering – configuration management – Maintenance tools and techniques. Reliability: Concepts, Errors, Faults, Repair and availability, reliability and availability models. Recent trends and developments. Module IV: Software quality: SEI CMM and ISO-9001. Software reliability and fault-tolerance, software project planning, monitoring, and control. Computer-aided software engineering (CASE), Component model of software development, Software reuse. Text Book: 1. Mall Rajib, Fundamentals of Software Engineering, PHI. 2. Pressman, Software Engineering Practitioner’s Approach, TMH. 2 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) CONTENTS Module 1: 1: Introduction to Software Engineering 2: Software Development Life Cycle- Classical Waterfall Model 3: Iterative Waterfall Model, Prototyping Model, Evolutionary Model 4: Spiral Model 5: Requirements Analysis and Specification 6: Problems without a SRS document, Decision Tree, Decision Table 7: Formal System Specification 8: Software Design 9: Software Design Strategies 10: Software Analysis & Design Tools 11: Structured Design Module 2: 12: Object Modelling Using UML 13: Use Case Diagram 14: Class Diagrams 15: Interaction Diagrams 16: Activity and State Chart Diagram 5 8 14 17 20 22 28 34 38 43 48 56 59 68 72 75 3 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Module 3: 17: Coding 18: Testing 19: Black-Box Testing 20: White-Box Testing 21: White-Box Testing (cont..) 22: Debugging, Integration and System Testing 23: Integration Testing 24: Software Maintenance 25: Software Maintenance Process Models 26: Software Reliability and Quality Management 27: Reliability Growth Models Module 4: 28: Software Quality 29: SEI Capability Maturity Model 30: Software Project Planning 31: Metrics for Software Project Size Estimation 32: Heuristic Techniques, Analytical Estimation Techniques 33: COCOMO Model 34: Intermediate COCOMO Model Lecture 35: Staffing Level Estimation 36: Project Scheduling 37: Organization Structure 38: Risk Management 39: Computer Aided Software Engineering 40: Software Reuse 41: Reuse Approach Software Engineering Keerthana P, Manasa KN, Ganga D Bengal 80 88 90 91 99 103 109 112 125 134 143 147 154 161 168 171 176 183 191 199 212 217 4

ISBN : 978-81-963532-2-3 (E-Book) MODULE 1 INTRODUCTION TO SOFTWARE ENGINEERING The term software engineering is composed of two words, software and engineering. Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be a collection of executable programming code, associated libraries and documentations. Software, when made for a specific requirement is called software product. Engineering on the other hand, is all about developing products, using well-defined, scientific principles and methods. So, we can define software engineering as an engineering branch associated with theprocedures. The outcome of software engineering is an efficient and reliable software product. IEEE defines software engineering as: The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. 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 absolutely necessary to achieve a good quality software cost effectively. 5 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 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 with their sizes. Software engineering helps to reduce this programming complexity. Software engineering principles use two important techniques to reduce problem complexity: abstraction and decomposition. The principle of abstraction 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 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. 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. However, in this technique any random decomposition of a problem into smaller parts will not help. 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. If the different subcomponents are interrelated, then the different components cannot be solved separately and the desired reduction in complexity will not be realized. NEED OF SOFTWARE ENGINEERING The need of software engineering arises because of higher rate of change in user requirements and environment on which the software is working. • Large software - It is easier to build a wall than to a house or building, likewise, as the size of software become large engineering has to step to give it a scientific process. • Scalability- If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one. • Cost- As hardware industry has shown its skills and huge manufacturing has lower 6 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) down the price of computer and electronic hardware. But the cost of software remains high if proper process is not adapted. • Dynamic Nature- The always growing and adapting nature of software hugely depends upon the environment in which the user works. If the nature of software is always changing, new enhancements need to be done in the existing one. This is where software engineering plays a good role. • Quality Management- Better process of software development provides better and quality software product. CHARACTERESTICS OF GOOD SOFTWARE A software product can be judged by what it offers and how well it can be used. This software must satisfy on the following grounds: • Operational • Transitional • Maintenance Well-engineered and crafted software is expected to have the following characteristics: Operational This tells us how well software works in operations. It can be measured on: • Budget • Usability • Efficiency • Correctness • Functionality • Dependability • Security • Safety Transitional This aspect is important when the software is moved from one platform to another: 7 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • Portability • Interoperability • Reusability • Adaptability Maintenance This aspect briefs about how well a software has the capabilities to maintain itself in the ever- changing environment: • Modularity • Maintainability • Flexibility • Scalability In short, Software engineering is a branch of computer science, which uses well-defined engineering concepts required to produce efficient, durable, scalable, in-budget and ontime software products SOFTWARE DEVELOPMENT LIFE CYCLE LIFE CYCLE MODEL 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. 8 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 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. This problem can be illustrated by using an example. Suppose a software development problem is divided into several parts and the parts are assigned to the team members. From then on, suppose the team members are allowed the freedom to develop the parts assigned to them in whatever way they like. It is possible that one member might start writing the code for his part, another might decide to prepare the test documents first, and some other engineer might begin with the design phase of the parts assigned to him. This would be one of the perfect recipes for 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 it becomes difficult for software project managers to monitor the progress of the project. Different software life cycle models Many life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages. A few important and commonly used life cycle models are as follows: • Classical Waterfall Model • Iterative Waterfall Model • Prototyping Model • Evolutionary Model • Spiral Model 1. CLASSICAL WATERFALL MODEL 9 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) The classical waterfall model is intuitively the most obvious way to develop software. Though the classical waterfall model is elegant and intuitively obvious, it is not a practical model in the sense that it cannot be used in actual software development projects. Thus, this model can be considered to be a theoretical way of developing software. But all other life cycle models are essentially derived from the classical waterfall model. So, in order to be able to appreciate other life cycle models it is necessary to learn the classical waterfall model. Classical waterfall model divides the life cycle into the following phases as shown in fig.2.1: Fig 2.1: Classical Waterfall Model 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 10 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) would be the development time for each solution. • 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 product and whether they have sufficient technical expertise in the area of development. 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. 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. Design: - The goal of the design phase is to transform the requirements specified in the 11 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 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. Coding and unit testing:-The purpose of the coding 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. 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. 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. 12 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • β –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. 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 ratios. Maintenance involves performing any one or more of the following three kinds of activities: • Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. • Improving the implementation of the system, and enhancing the functionalities of the system according to the customer’s requirements. This is called perfective maintenance. • 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. Shortcomings of the classical waterfall model The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the engineers during any of the life cycle phases. However, in practical development environments, the engineers do commit a large number of errors in almost every phase of the life cycle. The source of the defects can be many: oversight, wrong assumptions, use of inappropriate technology, communication gap among the project engineers, etc. These defects usually get detected much later in the life cycle. For example, a design defect might go unnoticed till we reach the coding or testing phase. 13 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 9 Once a defect is detected, the occurred and redo some of th correct the defect and its eff development work, it is not p 978-81-963532-2-3 (E-Book) engineers need to go back to the phas e work done during that phase and the ect on the later phases. Therefore, in possible to strictly follow the classical w 2.ITERATIVE WATERFALL MODEL To overcome the major shor the iterative waterfall model. rtcomings of the classical waterfall mo odel, we come up with se where the defect had he subsequent phases to any practical software waterfall model. Fig 3.1: Iterative Waterfall Model Here, we provide feedback p Though errors are inevitable, but it is desirable to detect them in the they occur. If so, this can red paths for error correction as & when de duce the effort to correct the bug. The advantage of this model stage of development which is that there is a working model of the makes it easier to find functional or issues at an early stage of development enables to take corrective budget. The disadvantage with this SDLC model is that it is applicable c Software Engineering Keerthana P, Manasa KN, Ganga D Bengal e system at a very early design flaws. Finding e measures in a limited software development proje ts. This is because it is hard to break a small software system ly to large and bulky on 14 etected later in a phase. he same phase in which

ISBN : 978-81-963532-2-3 (E-Book) into further small serviceable increments/modules. 3. PRTOTYPING MODEL Prototype A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low reliability, and inefficient performance compared to the actual software. A prototype is usually built using several shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. The shortcut implementation of a function, for example, may produce the desired results by using a table look-up instead of performing the actual computations. A prototype usually turns out to be a very crude version of the actual system. 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 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 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. 15 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) A prototype of the actual product is preferred in situations such as: • User requirements are not complete • Technical issues are not clear Fig 3.2: Prototype Model 4. EVOLUTIONARY MODEL It is also called successive versions model or incremental model. At first, a simple working model is built. Subsequently it undergoes functional improvements & we keep on adding new functions till the desired system is built. Applications: • Large projects where you can easily find modules for incremental implementation. Often used when the customer wants to start using the core features rather than waiting for the full software. • Also used in object oriented software development because the system can be 16 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) easily portioned into units in terms of objects. Advantages: • User gets a chance to experiment partially developed system • Reduce the error because the core modules get tested thoroughly. Disadvantages: • It is difficult to divide the problem into several versions that would be acceptable to the customer which can be incrementally implemented & delivered. Fig 3.3: Evolutionary Model 5. SPIRAL MODEL The Spiral model of software development is shown in fig. 4.1. The diagrammatic representation of this model appears like a spiral with many loops. The exact number of 17 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study, the next loop with requirements specification, the next one with design, and so on. Each phase in this model is split into four sectors (or quadrants) as shown in fig. 4.1. The following activities are carried out during each phase of a spiral model. Fig 4.1: Spiral Model First quadrant (Objective Setting) • During the first quadrant, it is needed to identify the objectives of the phase. • Examine the risks associated with these objectives. Second Quadrant (Risk Assessment and Reduction) • A detailed analysis is carried out for each identified project risk. • Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed. Third Quadrant (Development and Validation) • Develop and validate the next level of the product after resolving the identified risks. Fourth Quadrant (Review and Planning) • Review the results achieved so far with the customer and plan the next iteration around the spiral. • Progressively more complete version of the software gets built with each iteration 18 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) around the spiral. Circumstances to use spiral model The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models – this is probably a factor deterring its use in ordinary projects. Comparison of different life-cycle models The classical waterfall model can be considered as the basic model and all other life cycle models as embellishments of this model. However, the classical waterfall model cannot be used in practical development projects, since this model supports no mechanism to handle the errors committed during any of the phases. This problem is overcome in the iterative waterfall model. The iterative waterfall model is probably the most widely used software development model evolved so far. This model is simple to understand and use. However this model is suitable only for well-understood problems; it is not suitable for very large projects and for projects that are subject to many risks. The prototyping model is suitable for projects for which either the user requirements or the underlying technical aspects are not well understood. This model is especially popular for development of the user-interface part of the projects. The evolutionary approach is suitable for large problems which can be decomposed into a set of modules for incremental development and delivery. This model is also widely used for object- oriented development projects. Of course, this model can only be used if the incremental delivery of the system is acceptable to the customer. 19 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models – this is probably a factor deterring its use in ordinary projects. The different software life cycle models can be compared from the viewpoint of the customer. Initially, customer confidence in the development team is usually high irrespective of the development model followed. During the lengthy development process, customer confidence normally drops off, as no working product is immediately visible. Developers answer customer queries using technical slang, and delays are announced. This gives rise to customer resentment. On the other hand, an evolutionary approach lets the customer experiment with a working product much earlier than the monolithic approaches. Another important advantage of the incremental model is that it reduces the customer’s trauma of getting used to an entirely new system. The gradual introduction of the product via incremental phases provides time to the customer to adjust to the new product. Also, from the customer’s financial viewpoint, incremental development does not require a large upfront capital outlay. The customer can order the incremental versions as and when he can afford them. REQUIREMENTS ANALYSIS AND SPECIFICATION Before we start to develop our software, it becomes quite essential for us to understand and document the exact requirement of the customer. Experienced members of the development team carry out this job. They are called as system analysts. The analyst starts requirements gathering and analysis activity by collecting all information from the customer which could be used to develop the requirements of the system. He then analyzes the collected information to obtain a clear and thorough understanding of the product to be developed, with a view to remove all ambiguities and inconsistencies from the initial customer perception of the problem. The following basic questions pertaining to the project should be clearly understood by the analyst in order to obtain a good grasp of the problem: 20 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • What is the problem? • Why is it important to solve the problem? • What are the possible solutions to the problem? • What exactly are the data input to the system and what exactly are the data output by the system? • What are the likely complexities that might arise while solving the problem? • If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be? After the analyst has understood the exact customer requirements, he proceeds to identify and resolve the various requirements problems. The most important requirements problems that the analyst has to identify and eliminate are the problems of anomalies, inconsistencies, and incompleteness. When the analyst detects any inconsistencies, anomalies or incompleteness in the gathered requirements, he resolves them by carrying out further discussions with the end- users and the customers. Parts of a SRS document •The important parts of SRS document are: Functional requirements of the system Non-functional requirements of the system, and Goals of implementation Functional requirements:The functional requirements part discusses the functionalities required from the system. The system is considered to perform a set of high-level functions {f }. The functional view of the system is shown in fig. 5.1. Each function f of the system can be considered as a transformation of a set of input data (ii) to the corresponding set of output data (o). The user can get some meaningful piece of work done using a high-level function. 21 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig. 5.1: View of a system performing a set of functions Nonfunctional requirements:Nonfunctional requirements deal with the characteristics of the system which cannot be expressed as functions - such as the maintainability of the system, portability of the system, usability of the system, etc. Goals of implementation:The goals of implementation part documents some general suggestions regarding development. These suggestions guide trade-off among design goals. The goals of implementation section might document issues such as revisions to the system functionalities that may be required in the future, new devices to be supported in the future, reusability issues, etc. These are the items which the developers might keep in their mind during development so that the developed system may meet some aspects that are not required immediately. Identifying functional requirements from a problem description The high-level functional requirements often need to be identified either from an informal 22 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) problem description document or from a conceptual understanding of the problem. Each high- level requirement characterizes a way of system usage by some user to perform some meaningful piece of work. There can be many types of users of a system and their requirements from the system may be very different. So, it is often useful to identify the different types of users who might use the system and then try to identify the requirements from each user’s perspective. Example: - Consider the case of the library system, where – F1: Search Book function Input: an author’s name Output: details of the author’s books and the location of these books in the library So the function Search Book (F1) takes the author's name and transforms it into book details. Functional requirements actually describe a set of high-level requirements, where each high-level requirement takes some data from the user and provides some data to the user as an output. Also each high-level requirement might consist of several other functions. Documenting functional requirements For documenting the functional requirements, we need to specify the set of functionalities supported by the system. A function can be specified by identifying the state at which the data is to be input to the system, its input data domain, the output data domain, and the type of processing to be carried on the input data to obtain the output data. Let us first try to document the withdraw-cash function of an ATM (Automated Teller Machine) system. The withdraw-cash is a high-level requirement. It has several sub-requirements corresponding to the different user interactions. These different interaction sequences capture the different scenarios. Example: - Withdraw Cash from ATM R1: withdraw cash Description: The withdraw cash function first determines the type of account that the user has and the account number from which the user wishes to withdraw cash. It checks the balance to determine whether the requested amount is available in the account. If enough 23 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) balance is available, it outputs the required cash; otherwise it generates an error message. R1.1 select withdraw amount option Input: “withdraw amount” option Output: user prompted to enter the account type R1.2: select account type Input: user option Output: prompt to enter amount R1.3: get required amount Input: amount to be withdrawn in integer values greater than 100 and less than 10,000 in multiples of 100. Output: The requested cash and printed transaction statement. Processing: the amount is debited from the user’s account if sufficient balance is available, otherwise an error message displayed Properties of a good SRS document The important properties of a good SRS document are the following: • Concise. The SRS document should be concise and at the same time unambiguous, consistent, and complete. Verbose and irrelevant descriptions reduce readability and also increase error possibilities. • Structured. It should be well-structured. A well-structured document is easy to understand and modify. In practice, the SRS document undergoes several revisions to cope up with the customer requirements. Often, the customer requirements evolve over a period of time. Therefore, in order to make the modifications to the SRS document easy, it is important to make the document well-structured. • Black-box view. It should only specify what the system should do and refrain from stating how to do these. This means that the SRS document should specify the external behavior of the system and not discuss the implementation issues. The SRS document should view the system to be developed as black box, and should specify the externally 24 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) visible behavior of the system. For this reason, the SRS document is also called the black-box specification of a system. • Conceptual integrity. It should show conceptual integrity so that the reader can easily understand it. • Response to undesired events. It should characterize acceptable responses to undesired events. These are called system response to exceptional conditions. • Verifiable. All requirements of the system as documented in the SRS document should be verifiable. This means that it should be possible to determine whether or not requirements have been met in an implementation. Problems without a SRS document The important problems that an organization would face if it does not develop a SRS document are as follows: • Without developing the SRS document, the system would not be implemented according to customer needs. • Software developers would not know whether what they are developing is what exactly required by the customer. • Without SRS document, it will be very much difficult for the maintenance engineers to understand the functionality of the system. • It will be very much difficult for user document writers to write the users’ manuals properly without understanding the SRS document. Problems with an unstructured specification • It would be very much difficult to understand that document. • It would be very much difficult to modify that document. • Conceptual integrity in that document would not be shown. • The SRS document might be unambiguous and inconsistent. DECISION TREE 25 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) A decision tree gives a graphic view of the processing logic involved in decision making and the corresponding actions taken. The edges of a decision tree represent conditions and the leaf nodes represent the actions to be performed depending on the outcome of testing the condition. Example: - Consider Library Membership Automation Software (LMS) where it should support the following three options: • New member • Renewal • Cancel membership New member optionDecision: When the 'new member' option is selected, the software asks details about the member like the member's name, address, phone number etc. Action: If proper information is entered then a membership record for the member is created and a bill is printed for the annual membership charge plus the security deposit payable. Renewal optionDecision: If the 'renewal' option is chosen, the LMS asks for the member's name and his membership number to check whether he is a valid member or not. Action: If the membership is valid then membership expiry date is updated and the annual membership bill is printed, otherwise an error message is displayed. Cancel membership optionDecision: If the 'cancel membership' option is selected, then the software asks for member's name and his membership number. Action: The membership is cancelled, a cheque for the balance amount due to the member is printed and finally the membership record is deleted from the database. The following tree (fig. 6.1) shows the graphical representation of the above example. 26 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig 6.1: Decision Tree of LMS DECISION TABLE A decision table is used to represent the complex processing logic in a tabular or a matrix form. The upper rows of the table specify the variables or conditions to be evaluated. The lower rows of the table specify the actions to be taken when the corresponding conditions are satisfied. A column in a table is called a rule. A rule implies that if a condition is true, then the corresponding action is to be executed. Example: - 27 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Consider the previously discussed LMS example. The following decision table (fig. 6.2) shows how to represent the LMS problem in a tabular form. Here the table is divided into two parts, the upper part shows the conditions and the lower part shows what actions are taken. Each column of the table is a rule. Fig. 6.2: Decision table for LMS From the above table you can easily understand that, if the valid selection condition is false then the action taken for this condition is 'display error message'. Similarly, the actions taken for other conditions can be inferred from the table. FORMAL SYSTEM SPECIFICATION 28 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Formal Technique A formal technique is a mathematical method to specify a hardware and/or software system, verify whether a specification is realizable, verify that an implementation satisfies its specification, prove properties of a system without necessarily running the system, etc. The mathematical basis of a formal method is provided by the specification language. Formal Specification Language A formal specification language consists of two sets syn and sem, and a relation sat between them. The set syn is called the syntactic domain, the set sem is called the semantic domain, and the relation sat is called the satisfaction relation. For a given specification syn, and model of the system sem, if sat (syn, sem), then syn is said to be the specification of sem, and sem is said to be the specificand of syn. Syntactic Domains The syntactic domain of a formal specification language consists of an alphabet of symbols and set of formation rules to construct well-formed formulas from the alphabet. The well-formed formulas are used to specify a system. Semantic Domains Formal techniques can have considerably different semantic domains. Abstract data type specification languages are used to specify algebras, theories, and programs. Programming languages are used to specify functions from input to output values. Concurrent and distributed system specification languages are used to specify state sequences, event sequences, state- transition sequences, synchronization trees, partial orders, state machines, etc. Satisfaction Relation Given the model of a system, it is important to determine whether an element of the semantic domain satisfies the specifications. This satisfaction is determined by using a homomorphism known as semantic abstraction function. The semantic abstraction function maps the elements of the semantic domain into equivalent classes. There can be different specifications describing different aspects of a system model, possibly using 29 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) different specification languages. Some of these specifications describe the system’s behavior and the others describe the system’s structure. Consequently, two broad classes of semantic abstraction functions are defined: those that preserve a system’s behavior and those that preserve a system’s structure. Model-oriented vs. property-oriented approaches Formal methods are usually classified into two broad categories – model – oriented and property – oriented approaches. In a model-oriented style, one defines a system’s behavior directly by constructing a model of the system in terms of mathematical structures such as tuples, relations, functions, sets, sequences, etc. In the property-oriented style, the system's behavior is defined indirectly by stating its properties, usually in the form of a set of axioms that the system must satisfy. Example:Let us consider a simple producer/consumer example. In a property-oriented style, it is probably started by listing the properties of the system like: the consumer can start consuming only after the producer has produced an item; the producer starts to produce an item only after the consumer has consumed the last item, etc. A good example of a producer-consumer problem is CPU-Printer coordination. After processing of data, CPU outputs characters to the buffer for printing. Printer, on the other hand, reads characters from the buffer and prints them. The CPU is constrained by the capacity of the buffer, whereas the printer is constrained by an empty buffer. Examples of property-oriented specification styles are axiomatic specification and algebraic specification. In a model-oriented approach, we start by defining the basic operations, p (produce) and c (consume). Then we can state that S1 + p → S, S + c → S1. Thus the modeloriented approaches essentially specify a program by writing another, presumably simpler program. Examples of popular model-oriented specification techniques are Z, CSP, CCS, etc. Model-oriented approaches are more suited to use in later phases of life cycle because 30 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) here even minor changes to a specification may lead to drastic changes to the entire specification. They do not support logical conjunctions (AND) and disjunctions (OR). Property-oriented approaches are suitable for requirements specification because they can be easily changed. They specify a system as a conjunction of axioms and you can easily replace one axiom with another one. Operational Semantics Informally, the operational semantics of a formal method is the way computations are represented. There are different types of operational semantics according to what is meant by a single run of the system and how the runs are grouped together to describe the behavior of the system. Some commonly used operational semantics are as follows: Linear Semantics:In this approach, a run of a system is described by a sequence (possibly infinite) of events or states. The concurrent activities of the system are represented by non-deterministic interleavings of the automatic actions. For example, a concurrent activity a║b is represented by the set of sequential activities a;b and b;a. This is simple but rather unnatural representation of concurrency. The behavior of a system in this model consists of the set of all its runs. To make this model realistic, usually justice and fairness restrictions are imposed on computations to exclude the unwanted interleavings. Branching Semantics:In this approach, the behavior of a system is represented by a directed graph. The nodes of the graph represent the possible states in the evolution of a system. The descendants of each node of the graph represent the states which can be generated by any of the atomic actions enabled at that state. Although this semantic model distinguishes the branching points in a computation, still it represents concurrency by interleaving. Maximally parallel semantics:In this approach, all the concurrent actions enabled at any state are assumed to be taken together. This is again not a natural model of concurrency since it implicitly assumes the availability of all the required computational resources. 31 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Partial order semantics:Under this view, the semantics ascribed to a system is a structure of states satisfying a partial order relation among the states (events). The partial order represents a precedence ordering among events, and constraints some events to occur only after some other events have occurred; while the occurrence of other events (called concurrent events) is considered to be incomparable. This fact identifies concurrency as a phenomenon not translatable to any interleaved representation. Formal methods possess several positive features, some of which are discussed below. • Formal specifications encourage rigor. Often, the very process of construction of a rigorous specification is more important than the formal specification itself. The construction of a rigorous specification clarifies several aspects of system behavior that are not obvious in an informal specification. • Formal methods usually have a well-founded mathematical basis. Thus, formal specifications are not only more precise, but also mathematically sound and can be used to reason about the properties of a specification and to rigorously prove that an implementation satisfies its specifications. • Formal methods have well-defined semantics. Therefore, ambiguity in specifications is automatically avoided when one formally specifies a system. • The mathematical basis of the formal methods facilitates automating the analysis of specifications. For example, a tableau-based technique has been used to automatically check the consistency of specifications. Also, automatic theorem proving techniques can be used to verify that an implementation satisfies its specifications. The possibility of automatic verification is one of the most important advantages of formal methods. • Formal specifications can be executed to obtain immediate feedback on the features of the specified system. This concept of executable specifications is related to rapid prototyping. Informally, a prototype is a “toy” working model of a system that can provide immediate feedback on the behavior of the specified system, and is especially useful in checking the completeness of specifications. 32 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Limitations of formal requirements specification It is clear that formal methods provide mathematically sound frameworks within large, complex systems can be specified, developed and verified in a systematic rather than in an ad hoc manner. However, formal methods suffer from several shortcomings, some of which are the following: • Formal methods are difficult to learn and use. • The basic incompleteness results of first-order logic suggest that it is impossible to check absolute correctness of systems using theorem proving techniques. • Formal techniques are not able to handle complex problems. This shortcoming results from the fact that, even moderately complicated problems blow up the complexity of formal specification and their analysis. Also, a large unstructured set of mathematical formulas is difficult to comprehend. Axiomatic Specification In axiomatic specification of a system, first-order logic is used to write the pre and postconditions to specify the operations of the system in the form of axioms. The preconditions basically capture the conditions that must be satisfied before an operation can successfully be invoked. In essence, the pre-conditions capture the requirements on the input parameters of a function. The post-conditions are the conditions that must be satisfied when a function completes execution for the function to be considered to have executed successfully. Thus, the post- conditions are essentially constraints on the results produced for the function execution to be considered successful. The following are the sequence of steps that can be followed to systematically develop the axiomatic specifications of a function: • Establish the range of input values over which the function should behave correctly. Also find out other constraints on the input parameters and write it in the form of a predicate. • Specify a predicate defining the conditions which must hold on the output of the function if it behaved properly. 33 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • Establish the changes made to the function’s input parameters after execution of the function. Pure mathematical functions do not change their input and therefore this type of assertion is not necessary for pure functions. • Combine all of the above into pre and post conditions of the function. Example1: - Specify the pre- and post-conditions of a function that takes a real number as argument and returns half the input value if the input is less than or equal to 100, or else returns double the value. f (x : real) : real pre : x ∈ R post : {(x≤100)  (f(x) = x/2)} ∨ {(x>100)  (f(x) = 2∗x)} Example2: - Axiomatically specify a function named search which takes an integer array and an integer key value as its arguments and returns the index in the array where the key value is present. search(X : IntArray, key : Integer) : Integer pre : ∃ i ∈ [Xfirst….Xlast], X[i] = key post : {(X′[search(X, key)] = key)  (X = X′)} Here the convention followed is: If a function changes any of its input parameters and if that parameter is named X, and then it is referred to as X′ after the function completes execution faster. SOFTWARE DESIGN Software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. For assessing user requirements, an SRS (Software Requirement Specification) document is created whereas for coding and implementation, there is a need of more specific and detailed requirements in software terms. The output of this process can directly be used into implementation in programming languages. 34 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Software design is the first step in SDLC (Software Design Life Cycle), which moves the concentration from problem domain to solution domain. It tries to specify how to fulfill the requirements mentioned in SRS. Software Design Levels Software design yields three levels of results: • Architectural Design - The architectural design is the highest abstract version of the system. It identifies the software as a system with many components interacting with each other. At this level, the designers get the idea of proposed solution domain. • High-level Design- The high-level design breaks the ‘single entity-multiple component’ concept of architectural design into less-abstracted view of sub-systems and modules and depicts their interaction with each other. High-level design focuses on how the system along with all of its components can be implemented in forms of modules. It recognizes modular structure of each sub-system and their relation and interaction among each other. • Detailed Design- Detailed design deals with the implementation part of what is seen as a system and its sub-systems in the previous two designs. It is more detailed towards modules and their implementations. It defines logical structure of each module and their interfaces to communicate with other modules. Modularization Modularization is a technique to divide a software system into multiple discrete and independent modules, which are expected to be capable of carrying out task(s) independently. These modules may work as basic constructs for the entire software. Designers tend to design modules such that they can be executed and/or compiled separately and independently. Modular design unintentionally follows the rules of ‘divide and conquer’ problemsolving strategy this is because there are many other benefits attached with the modular design of a software. Advantage of modularization: 35 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • Smaller components are easier to maintain • Program can be divided based on functional aspects • Desired level of abstraction ca n be brought in the program • Components with high cohesion can be re-used again. • Concurrent execution can be made possible • Desired from security aspect Concurrency Back in time, all softwares were meant to be executed sequentially. By sequential execution we mean that the coded instruction will be executed one after another implying only one portion of program being activated at any given time. Say, a software has multiple modules, then only one of all the modules can be found active at any time of execution. In software design, concurrency is implemented by splitting the software into multiple independent units of execution, like modules and executing them in parallel. In other words, concurrency provides capability to the software to execute more than one part of code in parallel to each other. It is necessary for the programmers and designers to recognize those modules, which can be made parallel execution. Example The spell check feature in word processor is a module of software, which runs alongside the word processor itself. Coupling and Cohesion When a software program is modularized, its tasks are divided into several modules based on some characteristics. As we know, modules are set of instructions put together in order to achieve some tasks. They are though, considered as single entity but may refer to each other to work together. There are measures by which the quality of a design of modules and their interaction among them can be measured. These measures are called coupling and cohesion. 36 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Cohesion Cohesion is a measure that defines the degree of intra-dependability within elements of a module. The greater the cohesion, the better is the program design. There are seven types of cohesion, namely – • Co-incidental cohesion - It is unplanned and random cohesion, which might be the result of breaking the program into smaller modules for the sake of modularization. Because it is unplanned, it may serve confusion to the programmers and is generally not-accepted. • Logical cohesion - When logically categorized elements are put together into a module, it is called logical cohesion. • Temporal Cohesion - When elements of module are organized such that they are processed at a similar point in time, it is called temporal cohesion. • Procedural cohesion - When elements of module are grouped together, which are executed sequentially in order to perform a task, it is called procedural cohesion. • Communicational cohesion - When elements of module are grouped together, which are executed sequentially and work on same data (information), it is called communicational cohesion. • Sequential cohesion - When elements of module are grouped because the output of one element serves as input to another and so on, it is called sequential cohesion. • Functional cohesion - It is considered to be the highest degree of cohesion, and it is highly expected. Elements of module in functional cohesion are grouped because they all contribute to a single well-defined function. It can also be reused. Coupling Coupling is a measure that defines the level of inter-dependability among modules of a program. It tells at what level the modules interfere and interact with each other. The lower the coupling, the better the program. There are five levels of coupling, namely - • Content coupling - When a module can directly access or modify or refer to the content 37 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) of another module, it is called content level coupling. • Common coupling- When multiple modules have read and write access to some global data, it is called common or global coupling. • Control coupling- Two modules are called control-coupled if one of them decides the function of the other module or changes its flow of execution. • Stamp coupling- When multiple modules share common data structure and work on different part of it, it is called stamp coupling. • Data coupling- Data coupling is when two modules interact with each other by means of passing data (as parameter). If a module passes data structure as parameter, then the receiving module should use all its components. Ideally, no coupling is considered to be the best. Design Verification The output of software design process is design documentation, pseudo codes, detailed logic diagrams, process diagrams, and detailed description of all functional or nonfunctional requirements. The next phase, which is the implementation of software, depends on all outputs mentioned above. It is then becomes necessary to verify the output before proceeding to the next phase. The early any mistake is detected, the better it is or it might not be detected until testing of the product. If the outputs of design phase are in formal notation form, then their associated tools for verification should be used otherwise a thorough design review can be used for verification and validation.By structured verification approach, reviewers can detect defects that might be caused by overlooking some conditions. A good design review is important for good software design, accuracy and quality. SOFTWARE DESIGN STRATEGIES Software design is a process to conceptualize the software requirements into software implementation. Software design takes the user requirements as challenges and tries to find optimum solution. While the software is being conceptualized, a plan is chalked out 38 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) to find the best possible design for implementing the intended solution. Software design is a process to conceptualize the software requirements into software implementation. Software design takes the user requirements as challenges and tries to find optimum solution. While the software is being conceptualized, a plan is chalked out to find the best possible design for implementing the intended solution. There are multiple variants of software design. Let us study them briefly: Structured Design Structured design is a conceptualization of problem into several well-organized elements of solution. It is basically concerned with the solution design. Benefit of structured design is, it gives better understanding of how the problem is being solved. Structured design also makes it simpler for designer to concentrate on the problem more accurately. Structured design is mostly based on ‘divide and conquer’ strategy where a problem is broken into several small problems and each small problem is individually solved until the whole problem is solved. The small pieces of problem are solved by means of solution modules. Structured design emphasis that these modules be well organized in order to achieve precise solution. These modules are arranged in hierarchy. They communicate with each other. A good structured design always follows some rules for communication among multiple modules, namely - Cohesion - grouping of all functionally related elements. Coupling - communication between different modules. A good structured design has high cohesion and low coupling arrangements. Function Oriented Design In function-oriented design, the system is comprised of many smaller sub-systems known as functions. These functions are capable of performing significant task in the system. 39 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) The system is considered as top view of all functions. Function oriented design inherits some properties of structured design where divide and conquer methodology is used. This design mechanism divides the whole system into smaller functions, which provides means of abstraction by concealing the information and their operation. These functional modules can share information among themselves by means of information passing and using information available globally. Another characteristic of functions is that when a program calls a function, the function changes the state of the program, which sometimes is not acceptable by other modules. Function oriented design works well where the system state does not matter and program/functions work on input rather than on a state. Design Process • The whole system is seen as how data flows in the system by means of data flow diagram. • DFD depicts how functions change the data and state of entire system. • The entire system is logically broken down into smaller units known as functions on the basis of their operation in the system. • Each function is then described at large. Object Oriented Design Object oriented design works around the entities and their characteristics instead of functions involved in the software system. This design strategy focuses on entities and its characteristics. The whole concept of software solution revolves around the engaged entities. Let us see the important concepts of Object Oriented Design: 40 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • Objects - All entities involved in the solution design are known as objects. For example, person, banks, company and customers are treated as objects. Every entity has some attributes associated to it and has some methods to perform on the attributes. • Classes - A class is a generalized description of an object. An object is an instance of a class. Class defines all the attributes, which an object can have and methods, which defines the functionality of the object. In the solution design, attributes are stored as variables and functionalities are defined by means of methods or procedures. • Encapsulation - In OOD, the attributes (data variables) and methods (operation on the data) are bundled together is called encapsulation. Encapsulation not only bundles important information of an object together, but also restricts access of the data and methods from the outside world. This is called information hiding. • Inheritance - OOD allows similar classes to stack up in hierarchical manner where the lower or sub-classes can import, implement and re-use allowed variables and methods from their immediate super classes. This property of OOD is known as inheritance. This makes it easier to define specific class and to create generalized classes from specific ones. • Polymorphism - OOD languages provide a mechanism where methods performing similar tasks but vary in arguments, can be assigned same name. This is called polymorphism, which allows a single interface performing tasks for different types. Depending upon how the function is invoked, respective portion of the code gets executed. Design Process Software design process can be perceived as series of well-defined steps. Though it varies according to design approach (function oriented or object oriented, yet It may have the following steps involved: • A solution design is created from requirement or previous used system and/or system sequence diagram. 41 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • Objects are identified and grouped into classes on behalf of similarity in attribute characteristics. • Class hierarchy and relation among them are defined. • Application framework is defined. Software Design Approaches There are two generic approaches for software designing: Top down Design We know that a system is composed of more than one sub-systems and it contains a number of components. Further, these sub-systems and components may have their one set of sub-system and components and creates hierarchical structure in the system. Top-down design takes the whole software system as one entity and then decomposes it to achieve more than one sub-system or component based on some characteristics. Each sub-system or component is then treated as a system and decomposed further. This process keeps on running until the lowest level of system in the top-down hierarchy is achieved. Top-down design starts with a generalized model of system and keeps on defining the more specific part of it. When all components are composed the whole system comes into existence. Top-down design is more suitable when the software solution needs to be designed from scratch and specific details are unknown. Bottom-up Design The bottom up design model starts with most specific and basic components. It proceeds with composing higher level of components by using basic or lower level components. It keeps creating higher level components until the desired system is not evolved as one single component. With each higher level, the amount of abstraction is increased. Bottom-up strategy is more suitable when a system needs to be created from some 42 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) existing system, where the basic primitives can be used in the newer system. Both, top-down and bottom-up approaches are not practical individually. Instead, a good combination of both is used. SOFTWARE ANALYSIS & DESIGN TOOLS Software analysis and design includes all activities, which help the transformation of requirement specification into implementation. Requirement specifications specify all functional and non-functional expectations from the software. These requirement specifications come in the shape of human readable and understandable documents, to which a computer has nothing to do. Software analysis and design is the intermediate stage, which helps human-readable requirements to be transformed into actual code. Let us see few analysis and design tools used by software designers: Data Flow Diagram Data flow diagram is a graphical representation of data flow in an information system. It is capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not mention anything about how data flows through the system. There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of control in program modules. DFDs depict flow of data in the system at various levels. DFD does not contain any control or branch elements. Types of DFD Data Flow Diagrams are either Logical or Physical. • Logical DFD - This type of DFD concentrates on the system process and flow of data in the system. For example in a Banking software system, how data is moved between different entities. 43 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • Physical DFD - This type of DFD shows how the data flow is actually implemented in the system. It is more specific and close to the implementation. DFD Components DFD can represent Source, destination, storage and flow of data using the following set of components – Fig 10.1: DFD Components • Entities - Entities are source and destination of information data. Entities are represented by rectangles with their respective names. • Process - Activities and action taken on the data are represented by Circle or Roundedged rectangles. • Data Storage - There are two variants of data storage - it can either be represented as a rectangle with absence of both smaller sides or as an open-sided rectangle with only one side missing. • Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the base of arrow as its source towards head of the arrow as destination. Importance of DFDs in a good software design 44 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) The main reason why the DFD technique is so popular is probably because of the fact that DFD is a very simple formalism – it is simple to understand and use. Starting with a set of high-level functions that a system performs, a DFD model hierarchically represents various sub-functions. In fact, any hierarchical model is simple to understand. Human mind is such that it can easily understand any hierarchical model of a system – because in a hierarchical model, starting with a very simple and abstract model of a system, different details of the system are slowly introduced through different hierarchies. The data flow diagramming technique also follows a very simple set of intuitive concepts and rules. DFD is an elegant modeling technique that turns out to be useful not only to represent the results of structured analysis of a software problem, but also for several other applications such as showing the flow of documents or items in an organization. Data Dictionary A data dictionary lists all data items appearing in the DFD model of a system. The data items listed include all data flows and the contents of all data stores appearing on the DFDs in the DFD model of a system. A data dictionary lists the purpose of all data items and the definition of all composite data items in terms of their component data items. For example, a data dictionary entry may represent that the data grossPay consists of the components regularPay and overtimePay. grossPay = regularPay + overtimePay For the smallest units of data items, the data dictionary lists their name and their type. Composite data items can be defined in terms of primitive data items using the following data definition operators: +: denotes composition of two data items, e.g. a+b represents data a and b. [,,]: represents selection, i.e. any one of the data items listed in the brackets can occur. For example, [a,b] represents either a occurs or b occurs. (): the contents inside the bracket represent optional data which may or may not appear. e.g. a+(b) represents either a occurs or a+b occurs. {}: represents iterative data definition, e.g. {name}5 represents five name data. {name}* represents zero or more instances of name data. 45 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) =: represents equivalence, e.g. a=b+c means that a represents b and c. /* */: Anything appearing within /* and */ is considered as a comment. Example 1: Tic-Tac-Toe Computer Game Tic-tac-toe is a computer game in which a human player and the computer make alternative moves on a 3×3 square. A move consists of marking previously unmarked square. The player who first places three consecutive marks along a straight line on the square (i.e. along a row, column, or diagonal) wins the game. As soon as either the human player or the computer wins, a message congratulating the winner should be displayed. If neither player manages to get three consecutive marks along a straight line, but all the squares on the board are filled up, then the game is drawn. The computer always tries to win a game. (a) 46

ISBN : 978-81-963532-2-3 (E-Book) Fig 10.2 (a) Level 0 (b) Level 1 DFD for Tic-Tac-Toe game It may be recalled that the DFD model of a system typically consists of several DFDs: level 0, level 1, etc. However, a single data dictionary should capture all the data appearing in all the DFDs constituting the model. Figure 10.2 represents the level 0 and level 1 DFDs for the tic-tac- toe game. The data dictionary for the model is given below. Data Dictionary for the DFD model in Example 1 move: integer /*number between 1 and 9 */ display: game+result game: board board: {integer}9 result: [“computer won”, “human won” “draw”] It may be recalled that the DFD model of a system typically consists of several DFDs: level 0, level 1, etc. However, a single data dictionary should capture all the data appearing in all the DFDs constituting the model. Figure 10.2 represents the level 0 and level 1 DFDs for the tic-tac- toe game. The data dictionary for the model is given below. Data Dictionary for the DFD model in Example 1 move: integer /*number between 1 and 9 */ display: game+result game: board board: {integer}9 result: [“computer won”, “human won” “draw”] Importance of Data Dictionary A data dictionary plays a very important role in any software development process because of the following reasons: • A data dictionary provides a standard terminology for all relevant data for use by the engineers working in a project. A consistent vocabulary for data items is very important, since in large projects different engineers of the project have a tendency to use different terms to refer to the same data, which unnecessary causes confusion. • The data dictionary provides the analyst with a means to determine the definition of different data structures in terms of their component elements. 47 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) STRUCTUREDDESIGN The aim of structured design is to transform the results of the structured analysis (i.e. a DFDrepresentation)intoastructurechart.Structureddesignprovidestwostrategiestoguidetransforma tionof a DFDinto astructurechart. • Transformanalysis • Transactionanalysis Normally, one starts with the level 1 DFD, transforms it into module representation using eitherthe transform or the transaction analysis and then proceeds towards the lower-level DFDs. Ateach level of transformation, it is important to first determine whether the transform or thetransaction analysis is applicable to a particular DFD. These are discussed in the subsequent sub-sections. StructureChart 48 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) A structure chart represents the software architecture, i.e. the various modules making up thesystem, the dependency (which module calls which other modules), and the parameters that arepassed among the different modules. Hence, the structure chart representation can be easilyimplemented using someprogramming language.Since the mainfocusina structure chartrepresentation is on the module structure of the software and the interactions among differentmodules,theproceduralaspects(e.g.howaparticularfunctionalityisachieved)arenotreprese nted. Thebasic buildingblocks which areusedto design structurecharts arethefollowing:  Rectangularboxes:Representsamodule.  Moduleinvocationarrows:Controlispassedfromononemoduletoanothermodulein thedirection ofthe connectingarrow.  Dataflowarrows:Arrowsareannotatedwithdataname;nameddatapassesfromone module to another module in thedirection ofthe arrow.  Librarymodules:Representedbyarectangle withdoubleedges.  Selection:Representedbyadiamondsymbol.  Repetition:Represented byalooparoundthecontrol flowarrow. StructureChartvs. FlowChart We are all familiar with the flow chart representation of a program. Flow chart is a convenienttechnique to represent the flow of control in a program. A structurechart differs from a flowchartin threeprincipal ways: • It is usually difficult to identify the different modules of the software from its flow chartrepresentation. • Datainterchange amongdifferent modulesisnotrepresentedinaflowchart. • Sequentialorderingoftasksinherentinaflowchartissuppressedinastructurechart. TransformAnalysis Transform analysis identifies the primary functional components (modules) and the high levelinputs and outputs for these components. The first step in transform analysis is to divide the DFDinto3 types of parts: • Input • Logicalprocessing • Output 49 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) The input portion of the DFD includes processes that transform input data from physical (e.g.character from terminal) to logical forms (e.g. internal tables, lists, etc.). Each input portion iscalledanafferent branch. The output portion of a DFD transforms output data from logical to physical form. Each outputportion is calledanefferent branch.The remaining portion of a DFD is calledthe centraltransform. In the next step of transform analysis, the structure chart is derived by drawing one functionalcomponentforthecentraltransform, and theafferent and efferentbranches. These are drawn below a root module, which would invoke these modules.Identifying thehighest level input and output transforms requires experience and skill. One possible approach isto trace the inputs until a bubble is found whose output cannot be deduced from its inputs alone.Processes which validate input or add information to them are not central transforms. Processeswhichsortinputorfilterdatafromitare.Thefirstlevelstructurechartisproducedbyrepresenti ngeachinputandoutputunitasboxesandeachcentraltransformasasinglebox.Inthethirdstepoftransfor manalysis,thestructurechartisrefinedbyaddingsub-functionsrequired by each of the high-level functional components. Many levels of functional componentsmay be added. This process of breaking functional components into subcomponents is calledfactoring.Factoringincludesaddingreadandwritemodules,errorhandlingmodules,initializationandterminationprocess,identifyingcustomermodules,etc.Thefactor ingprocessiscontinued until all bubblesin theDFDarerepresented in the structurechart. 50 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Example:StructurechartfortheRMS software Forthisexample,thecontextdiagramwasdrawnearlier. Todrawthelevel1DFD(fig.11.1),fromacursoryanalysisoftheproblemdescription, we can see that there are four basic functions that the system needs toperform – accept the input numbers from the user, validate the numbers, calculate therootmean squareof theinput numbers and, then displaythe result. Fig.11.1:Level1DFD By observing the level 1 DFD, we identify the validate-input as the afferent branch and writeoutputastheefferentbranch.Theremainingportion(i.e.compute-rms)formsthecentraltransform. By applying the step 2 and step 3 of transform analysis, we get the structure chartshownin fig.11.2. 51 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 52 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.11.2:StructureChart TransactionAnalysis A transaction allows the user to perform some meaningful piece of work. Transaction analysisis useful while designing transaction processing programs. In a transaction-driven system, oneof several possible paths through the DFD is traversed depending upon the input data item.This is in contrast to a transform centered system which is characterized by similar processingsteps for each data item. Each different way in which input data is handled is a transaction. Asimple way to identify a transaction is to check the input data. The number of bubbles onwhich the input data to the DFD are incident defines the number of transactions. However,some transaction may not require any input data. These transactions can be identified from theexperienceof solvingalargenumber ofexamples. For each identified transaction, trace the input data to the output. All the traversed bubblesbelongtothetransaction.Thesebubblesshouldbemappedtothesamemoduleonthestructure 53 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) chart. In the structure chart, draw a root module and below this module draw eachidentifiedtransactionamodule.Everytransactioncarriesatag,whichidentifiesitstype. 54 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Transactionanalysisusesthistagtodividethesystemintotransactionmodulesandatransactioncentermodule. Thestructurechartforthesupermarketprizeschemesoftwareis showninfig.11.3. Fig.11.3:StructureChartforthesupermarketprizescheme 55 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) MODULE2 OBJECTMODELLINGUSINGUML Model A model captures aspects important for some application while omitting (or abstracting) the rest.A model in the context of software development can be graphical, textual, mathematical, orprogram code-based. Models are very useful in documenting the design and analysis results.Models also facilitate the analysis and design procedures themselves. Graphical models are verypopularbecausetheyareeasytounderstandandconstruct.UMLisprimarilyagraphicalmodelingto ol. However, it oftenrequires textexplanations toaccompanythegraphical models. Needforamodel An important reason behind constructing a model is that it helps manage complexity. Oncemodels of a system have been constructed, these can be used for a variety of purposes duringsoftwaredevelopment, includingthe following: • Analysis • Specification • Codegeneration • Design • Visualizeandunderstandtheproblemandtheworkingof asystem • Testing,etc. Inalltheseapplications,theUMLmodelscannotonlybeusedtodocumenttheresultsbutalsoto arrive at the results themselves. Since a model can be used for a variety of purposes, it isreasonable to expect that the model would vary depending on the purpose for which it is beingconstructed. For example, a model developed for initial analysis and specification should be verydifferent from the one used for design. A model that is being used for analysis and specificationwould not show any of the design decisions that would be made later on during the design stage.On the other hand, a model used for design purposes should capture all the design decisions.Therefore, it is a 56 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) good idea to explicitly mention the purpose for which a model has beendeveloped, alongwith themodel. Unified Modeling Language (UML) UML, as the name implies, is a modeling language. It may be used to visualize, specify, construct, and document the artifacts of a software system. It provides a set of notations (e.g. rectangles, lines, ellipses, etc.) to create a visual model of the system. Like any other language, UML has its own syntax (symbols and sentence formation rules) and semantics (meanings of symbols and sentences). Also, we should clearly understand that UML is not a system design or development methodology, but can be used to document objectoriented and analysis results obtained using some methodology. Origin of UML In the late 1980s and early 1990s, there was a proliferation of object-oriented design techniques and notations. Different software development houses were using different notations to document their object-oriented designs. These diverse notations used to give rise to a lot of confusion. UML was developed to standardize the large number of object-oriented modeling notations that existed and were used extensively in the early 1990s. The principles ones in use were: • Object Management Technology [Rumbaugh 1991] • Booch’s methodology [Booch 1991] • Object-Oriented Software Engineering [Jacobson 1992] • Odell’s methodology [Odell 1992] • Shaler and Mellor methodology [Shaler 1992] It is needless to say that UML has borrowed many concepts from these modeling techniques. Especially, concepts from the first three methodologies have been heavily 57 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) drawn upon. UML was adopted by Object Management Group (OMG) as a de facto standard in 1997. OMG is an association of industries which tries to facilitate early formation of standards. We shall see that UML contains an extensive set of notations and suggests construction of many types of diagrams. It has successfully been used to model both large and small problems. The elegance of UML, its adoption by OMG, and a strong industry backing have helped UML find widespread acceptance. UML is now being used in a large number of software development projects worldwide. UML Diagrams UML can be used to construct nine different types of diagrams to capture five different views of a system. Just as a building can be modeled from several views (or perspectives) such as ventilation perspective, electrical perspective, lighting perspective, heating perspective, etc.; the different UML diagrams provide different perspectives of the software system to be developed and facilitate a comprehensive understanding of the system. Such models can be refined to get the actual implementation of the system. The UML diagrams can capture the following five views of a system: • User’s view • Structural view • Behavioral view • Implementation view • Environmental view 58 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.12.1:Different typesofdiagrams andviewssupported inUML User’s view: This view defines the functionalities (facilities) made available by the system to its users. The users’ view captures the external users’ view of the system in terms of the functionalities offered by the system. The users’ view is a black-box view of the system where the internal structure, the dynamic behavior of different system components, the implementation etc. are not visible. The users’ view is very different from all other views in the sense that it is a functional model compared to the object model of all other views. The users’ view can be considered as the central view and all other views are expected to conform to this view. This thinking is in fact the crux of any user centric development style. Structural view: The structural view defines the kinds of objects (classes) important to the understanding of the working of a system and to its implementation. It also captures the relationships among the classes (objects). The structural model is also called the static model, since the structure of a system does not change with time. Behavioral view: The behavioral view captures how objects interact with each other to realize the system behavior. The system behavior captures the time-dependent (dynamic) behavior of the system. Implementation view: This view captures the important components of the system and their dependencies. Environmental view: This view models how the different components are implemented on different pieces of hardware. USECASE DIAGRAM UseCaseModel The use case model for any system consists of a set of “use cases”. Intuitively, use 59 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) casesrepresent the different ways in which a system can be used by the users. A simple way to find allthe use cases of a system is to ask the question: “What the users can do using the system?” ThusfortheLibraryInformation System (LIS), theusecasescould be: • issue-book • query-book • return-book • create-member • add-book,etc Use cases correspond to the high-level functional requirements. The use cases partition thesystem behavior into transactions, such that each transaction performs some useful action fromthe user’s point of view. To complete each transaction may involve either a single message ormultiplemessageexchanges betweentheuser andthe system tocomplete. Purposeofusecases The purpose of a use case is to define a piece of coherent behavior without revealing the internalstructure of the system. The use cases do not mention any specific algorithm to be used or theinternaldatarepresentation,internalstructureofthesoftware,etc.Ausecasetypicallyrepresents a sequence of interactions between the user and the system. These interactions consistof one mainline sequence. The mainline sequence represents the normal interaction between auser and the system. The mainline sequence is the most occurring sequence of interaction. Forexample, the mainline sequence of the withdraw cash use case supported by a bank ATM drawn,complete the transaction, and get the amount. Several variations to the main line sequence mayalsoexist.Typically,avariationfromthemainlinesequenceoccurswhensomespecificconditions hold. For the bank ATM example, variations or alternate scenarios may occur, if thepassword is invalid or the amount to be withdrawn exceeds the amount balance. The variationsare also called alternative paths. A use case can be viewed as a set of related scenarios tiedtogetherbyacommongoal. Themainlinesequenceandeachofthevariationsarecalledscenarios or instances of the use case. Each scenario is a single path of user events and systemactivitythroughthe usecase. Representation of Use Cases Use cases can be represented by drawing a use case diagram and writing an accompanying text 60 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) elaborating the drawing. In the use case diagram, each use case is represented by an ellipse with the name of the use case written inside the ellipse. All the ellipses (i.e. use cases) of a system are enclosed within a rectangle which represents the system boundary. The name of the system being modeled (such as Library Information System) appears inside the rectangle. The different users of the system are represented by using the stick person icon. Each stick person icon is normally referred to as an actor. An actor is a role played by a user with respect to the system use. It is possible that the same user may play the role of multiple actors. Each actor can participate in one or more use cases. The line connecting the actor and the use case is called the communication relationship. It indicates that the actor makes use of the functionality provided by the use case. Both the human users and the external systems can be represented by stick person icons. When a stick person icon represents an external system, it is annotated by the stereotype <<external system>>. Example 1: Tic-Tac-Toe Computer Game Tic-tac-toe is a computer game in which a human player and the computer make alternative moves on a 3×3 square. A move consists of marking previously unmarked square. The player who first places three consecutive marks along a straight line on the square (i.e. along a row, column, or diagonal) wins the game. As soon as either the human player or the computer wins, a message congratulating the winner should be displayed. If neither player manages to get three consecutive marks along a straight line, but all the squares on the board are filled up, then the game is drawn. The computer always tries to win a game. The use case model for the Tic-tac-toe problem is shown in fig. 13.1. This software has only one use case “play move”. Note that the use case “get-user- move” is not used here. The name “get-user-move” would be inappropriate because the use cases should be named from the user’s perspective. Fig.13.1:Usecasemodelfortic-tac-toegame Text Description Each ellipse on the use case diagram should be accompanied by a text description. The text description 61 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) should define the details of the interaction between the user and the computer and other aspects of the use case. It should include all the behavior associated with the use case in terms of the mainline sequence, different variations to the normal behavior, the system responses associated with the use case, the exceptional conditions that may occur in the behavior, etc. The behavior description is often written in a conversational style describing the interactions between the actor and the system. The text description may be informal, but some structuring is recommended. The following are some of the information which may be included in a use case text description in addition to the mainline sequence, and the alternative scenarios. Contact persons: This section lists the personnel of the client organization with whom the use case was discussed, date and time of the meeting, etc. Actors: In addition to identifying the actors, some information about actors using this use case which may help the implementation of the use case may be recorded. Pre-condition: The preconditions would describe the state of the system before the use case execution starts. Post-condition: This captures the state of the system after the use case has successfully completed. Non-functional requirements: This could contain the important constraints for the design and implementation, such as platform and environment conditions, qualitative statements, response time requirements, etc. Exceptions, error situations: This contains only the domain-related errors such as lack of user’s access rights, invalid entry in the input fields, etc. Obviously, errors that are not domain related, such as software errors, need not be discussed here. Sample dialogs: These serve as examples illustrating the use case. Specific user interface requirements: These contain specific requirements for the user interface of the use case. For example, it may contain forms to be used, screen shots, interaction style, etc. Document references: This part contains references to specific domain-related documents which may be useful to understand the system operation Example 2: A supermarket needs to develop the following software to encourage regular customers. For this, the customer needs to supply his/her residence address, telephone number, and the driving license number. Each customer who registers for this scheme is assigned a unique customer number (CN) by the computer. A customer can present his CN to the checkout staff when he makes any purchase. In this case, the value of his purchase is credited against his CN. At the end of each year, the supermarket intends to award surprise gifts to 10 customers who make the highest total purchase over the year. Also, it intends to award a 22 caret gold coin to every customer whose purchase exceeded Rs.10,000. The entries against the CN are the reset on the day of every year after the prize winners’ lists are generated. 62 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) The use case model for the Supermarket Prize Scheme is shown in fig. 13.2. As discussed earlier, the use cases correspond to the high-level functional requirements. From the problem description, we can identify three use cases: “register-customer”, “register-sales”, and “select- winners”. As a sample, the text description for the use case “register-customer” is shown. Fig.13.2UsecasemodelforSupermarketPrizeScheme Text description U1: register-customer: Using this use case, the customer can register himself by providing the necessary details. Scenario 1: Mainline sequence 1. Customer: select register customer option. 2. System: display prompt to enter name, address, and telephone number. 3. Customer: enter the necessary values. 4. System: display the generated id and the message that the customer has been successfully registered. 63 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Scenario 2: at step 4 of mainline sequence 1. System: displays the message that the customer has already registered. Scenario 2: at step 4 of mainline sequence 1. System: displays the message that some input information has not been entered. The system displays a prompt to enter the missing value. The description for other use cases is written in a similar fashion. Utility of use case diagrams From use case diagram, it is obvious that the utility of the use cases are represented by ellipses. They along with the accompanying text description serve as a type of requirements specification of the system and form the core model to which all other models must conform. But, what about the actors (stick person icons)? One possible use of identifying the different types of users (actors) is in identifying and implementing a security mechanism through a login system, so that each actor can involve only those functionalities to which he is entitled to. Another possible use is in preparing the documentation (e.g. users’ manual) targeted at each category of user. Further, actors help in identifying the use cases and understanding the exact functioning of the system. Factoring of use cases It is often desirable to factor use cases into component use cases. Actually, factoring of use cases are required under two situations. First, complex use cases need to be factored into simpler use cases. This would not only make the behavior associated with the use case much more comprehensible, but also make the corresponding interaction diagrams more tractable. Without decomposition, the interaction diagrams for complex use cases may become too large to be accommodated on a single sized (A4) paper. Secondly, use cases need to be factored whenever there is common behavior across different use cases. Factoring would make it possible to define such behavior only once and reuse it whenever required. It is desirable to factor out common usage such as error handling from a set of use cases. This makes analysis of the class design much simpler and elegant. However, a word of caution here. Factoring of use cases should not be done except for achieving the above two objectives. From the design point of view, it is not advantageous to break up a use case into many smaller parts just for the sake of it. 64 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) UML offers three mechanisms for factoring of use cases as follows: 1. Generalization Use case generalization can be used when one use case that is similar to another, but does something slightly differently or something more. Generalization works the same way with use cases as it does with classes. The child use case inherits the behavior and meaning of the parent use case. The notation is the same too (as shown in fig. 13.3). It is important to remember that the base and the derived use cases are separate use cases and should have separate text descriptions. Fig.13.3:Representationofusecasegeneralization 65

ISBN : 978-81-963532-2-3 (E-Book) Includes The includes relationship in the older versions of UML (prior to UML 1.1) was known as the uses relationship. The includes relationship involves one use case including the behavior of another use case in its sequence of events and actions. The includes relationship occurs when a chunk of behavior that is similar across a number of use cases. The factoring of such behavior will help in not repeating the specification and implementation across different use cases. Thus, the includes relationship explores the issue of reuse by factoring out the commonality across use cases. It can also be gainfully employed to decompose a large and complex use cases into more manageable parts. As shown in fig. 13.4 the includes relationship is represented using a predefined stereotype <<include>>.In the includes relationship, a base use case compulsorily and automatically includes the behavior of the common use cases. As shown in example fig. 13.5, issuebook and renew-book both include check-reservation use case. The base use case may include several use cases. In such cases, it may interleave their associated common use cases together. The common use case becomes a separate use case and the independent text description should be provided for it. Fig.13.4Representationofusecaseinclusion 66

ISBN : 978-81-963532-2-3 (E-Book) Fig.13.5:Exampleusecaseinclusion Extends The main idea behind the extends relationship among the use cases is that it allows you to show optional system behavior. An optional system behavior is extended only under certain conditions. This relationship among use cases is also predefined as a stereotype as shown in fig. 13.6. The extends relationship is similar to generalization. But unlike generalization, the extending use case can add additional behavior only at an extension point only when certain conditions are satisfied. The extension points are points within the use case where variation to the mainline (normal) action sequence may occur. The extends relationship is normally used to capture alternate paths or scenarios. Fig.13.6:Exampleusecaseextension Organizationofusecases When the use cases are factored, they are organized hierarchically. The high-level use cases arerefinedintoasetofsmallerandmorerefinedusecasesasshowninfig.13.7.Top-levelusecases are superordinate to the refined use cases. The refined use cases are sub-ordinate to thetoplevelusecases.Notethatonlythecomplexusecasesshouldbedecomposedandorganizedin a hierarchy. It is not necessary to decompose simple use cases. The functionality of the superordinateusecasesistraceabletotheirsub-ordinateusecases.Thus,thefunctionalityprovidedby the superordinate use cases is composite of the functionality of the sub-ordinate use cases. Inthe highest level of the use case model, only the fundamental use cases are shown. The focus ison the application context. Therefore, this level is also referred to as the context diagram. In thecontext diagram, the system limits are emphasized.In the top-level diagram, only those usecaseswithwhichexternalusersofthesystem.Thesubsystem-levelusecasesspecify theservices offered by the subsystems. Any number of levels involving the subsystems may beutilized. In the lowest level of the use case hierarchy, the class-level use cases specify thefunctionalfragments or operations offered 67 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) bytheclasses. Fig.13.7:Hierarchicalorganizationofusecases CLASSDIAGRAMS A class diagram describes the static structure of a system. It shows how a system is structured rather than how it behaves. The static structure of a system comprises of a number of class diagrams and their dependencies. The main constituents of a class diagram are classes and their relationships: generalization, aggregation, association, and various kinds of dependencies. Classes 68 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) The classes represent entities with common features, i.e. attributes and operations. Classes are represented as solid outline rectangles with compartments. Classes have a mandatory name compartment where the name is written centered in boldface. The class name is usually written using mixed case convention and begins with an uppercase. The class names are usually chosen to be singular nouns. Classes have optional attributes and operations compartments. A class may appear on several diagrams. Its attributes and operations are suppressed on all but one diagram. Attributes An attribute is a named property of a class. It represents the kind of data that an object might contain. Attributes are listed with their names, and may optionally contain specification of their type, an initial value, and constraints. The type of the attribute is written by appending a colon and the type name after the attribute name. Typically, the first letter of a class name is a small letter. An example for an attribute is given. bookName : String Operation Operation is the implementation of a service that can be requested from any object of the class to affect behaviour. An object’s data or state can be changed by invoking an operation of the object. A class may have any number of operations or no operation at all. Typically, the first letter of an operation name is a small letter. Abstract operations are written in italics. The parameters of an operation (if any), may have a kind specified, which may be ‘in’, ‘out’ or ‘inout’. An operation may have a return type consisting of a single return type expression. An example for an operation is given. issueBook(in bookName):Boolean Association Associations are needed to enable objects to communicate with each other. An association describes a connection between classes. The association relation between two objects is called object connection or link. Links are instances of associations. A link is a physical or conceptual connection between object instances. For example, suppose Amit has borrowed the book Graph Theory. Here,borrowed is the connection between the objects Amit and Graph Theory book. Mathematically, a link can be considered to be a tuple, i.e. an ordered list of object instances. An association describes a group of links with a common structure and common semantics. For example, consider the statement that Library Member borrows Books. 69 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Here, borrows is the association between the class LibraryMember and the class Book. Usually, an association is a binary relation (between two classes). However, three or more different classes can be involved in an association. A class can have an association relationship with itself (called recursive association). In this case, it is usually assumed that two different objects of the class are linked by the association relationship. Association between two classes is represented by drawing a straight line between the concerned classes. Fig. 14.1 illustrates the graphical representation of the association relation. The name of the association is written alongside the association line. An arrowhead may be placed on the association line to indicate the reading direction of the association. The arrowhead should not be misunderstood to be indicating the direction of a pointer implementing an association. On each side of the association relation, the multiplicity is noted as an individual number or as a value range. The multiplicity indicates how many instances of one class are associated with each other. Value ranges of multiplicity are noted by specifying the minimum and maximum value, separated by two dots, e.g. 1.5. An asterisk is a wild card and means many (zero or more). The association of fig. 14.1 should be read as “Many books may be borrowed by a Library Member”. Observe that associations (and links) appear as verbs in the problem statement. Fig. Association between two classes Associations are usually realized by assigning appropriate reference attributes to the 70 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) classes involved. Thus, associations can be implemented using pointers from one object class to another. Links and associations can also be implemented by using a separate class that stores which objects of a class are linked to which objects of another class. Some CASE tools use the role names of the association relation for the corresponding automatically generated attribute. Aggregation Aggregation is a special type of association where the involved classes represent a wholepart relationship. The aggregate takes the responsibility of forwarding messages to the appropriate parts. Thus, the aggregate takes the responsibility of delegation and leadership. When an instance of one object contains instances of some other objects, then aggregation (or composition) relationship exists between the composite object and the component object. Aggregation is represented by the diamondsymbol at the composite end of a relationship. The number of instances of the component class aggregated can also be shown as in fig. 14.2 Fig:Representationofaggregation Aggregation relationship cannot be reflexive (i.e. recursive). That is, an object cannot contain objects of the same class as itself. Also, the aggregation relation is not symmetric. That is, two classes A and B cannot contain instances of each other. However, the aggregation relationship can be transitive. In this case, aggregation may consist of an arbitrary number of levels. Composition Composition is a stricter form of aggregation, in which the parts are existence-dependent on the whole. This means that the life of the parts closely ties to the life of the whole. When the whole is created, the parts are created and when the whole is destroyed, the parts are destroyed. A typical example of composition is an invoice object with invoice items. As soon as the invoice object is created, all the invoice items in it are created and as soon as the invoice object is destroyed, all invoice items in it are also destroyed. The composition relationship is represented as a filled diamond drawn at the composite-end. An example of the composition relationship is shown in fig. 14.3 71 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig : Representation of composition Association vs. Aggregation vs. Composition • Association is the most general (m:n) relationship. Aggregation is a stronger relationship where one is a part of the other. Composition is even stronger than aggregation, ties the lifecycle of the part and the whole together. • Association relationship can be reflexive (objects can have relation to itself), but aggregation cannot be reflexive. Moreover, aggregation is anti-symmetric (If B is a part of A, A cannot be a part of B). • Composition has the property of exclusive aggregation i.e. an object can be a part of only one composite at a time. For example, a Frame belongs to exactly one Window,whereas in simple aggregation, a part may be shared by several objects. For example, a Wall may be a part of one or more Room objects. •  in general, the lifetime of parts and composite coincides  parts with non-fixed multiplicity may be created after composite itself  parts might be explicitly removed before the death of the composite For example, when a Frame is created, it has to be attached to an enclosing Window. Similarly, when the Window is destroyed, it must in turn destroy its Frame parts. Inheritance vs. Aggregation/Composition • Inheritance describes ‘is a’ / ‘is a kind of’ relationship between classes (base class - derived class) whereas aggregation describes ‘has a’ relationship between classes. Inheritance means that the object of the derived class inherits the properties of the base class; aggregation means that the object of the whole has objects of the part. For example, the relation “cash payment is a kind of payment” is modeled using inheritance; “purchase 72 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal In addition, in composition, the whole has the responsibility for the disposition of all its parts, i.e. for their creation and destruction.

ISBN : 978-81-963532-2-3 (E-Book) order has a few items” is modeled using aggregation. • Inheritance is used to model a “generic-specific” relationship between classes whereas aggregation/composition is used to model a “whole-part” relationship between classes. • Inheritance means that the objects of the subclass can be used anywhere the super class may appear, but not the reverse; i.e. wherever we could use instances of ‘payment’ in the system, we could substitute it with instances of ‘cash payment’, but the reverse cannot be done. • Inheritance is defined statically. It cannot be changed at run-time. Aggregation is defined dynamically and can be changed at run-time. Aggregation is used when the type of the object can change over time. For example, consider this situation in a business system. A BusinessPartner might be a Customer or a Supplier or both. Initially we might be tempted to model it as in Fig 14.4(a). But in fact, during its lifetime, a business partner might become a customer as well as a supplier, or it might change from one to the other. In such cases, we prefer aggregation instead (see Fig 14.4(b). Here, a business partner is a Customer if it has an aggregated Customer object, a Supplier if it has an aggregated Supplier object and a "Customer_Supplier" if it has both. Here, we have only two types. Hence, we are able to model it as inheritance. But what if there were several different types and combinations thereof? The inheritance tree would be absolutely incomprehensible. Also, the aggregation model allows the possibility for a business partner to be neither - i.e. has neither a customer nor a supplier object aggregated with it. 73 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.a) Representation of BusinessPartner, Customer, Supplier relationship using inheritance 74 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.b) Representation of BusinessPartner, Customer, Supplier relationship using aggregation • The advantage of aggregation is the integrity of encapsulation. The operations of an object are the interfaces of other objects which imply low implementation dependencies. The significant disadvantage of aggregation is the increase in the number of objects and their relationships. On the other hand, inheritance allows for an easy way to modify implementation for reusability. But the significant disadvantage is that it breaks encapsulation, which implies implementation dependence. ACTIVITYANDSTATECHARTDIAGRAM Theactivitydiagramispossiblyonemodelingelementwhichwasnotpresentinanyofthepredec essors of UML. No such diagrams were present either in the works of Booch, Jacobson, orRumbaugh. It is possibly based on the event diagram of Odell [1992] through the notation is verydifferent from that used by Odell. The activity diagram focuses on representing activities or chunksof processing which may or may not correspond to the methods of classes. An activity is a state withan internal action and one or moreoutgoing transitions which automatically follow the terminationof the internal activity. If an activity has more than one outgoing transitions, then these must beidentified through conditions. An interesting feature of the activity diagrams is the swim lanes. Swimlanes enable you to group activities based on who is performing them, e.g. academic department vs.hostel office. Thus swim lanes subdivide activities based on the responsibilities of some components.Theactivitiesinaswimlanecanbeassignedtosomemodelelements,e.g.classesor somecomponent,etc. Activity diagrams arenormally employed in business process modeling. This is carried out duringthe initial stages of requirements analysis and specification. Activity diagrams can be very useful tounderstand complex processing activities involving many components. Later these diagrams can beusedtodevelopinteractiondiagramswhichhelptoallocateactivities(responsibilities)toclas ses. Thestudentadmissionprocessinauniversityisshownasanactivitydiagraminfig.16.1.Thissho 75 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) ws the part played by different components of the Institute in the admission procedure. After thefees are received at the account section, parallel activities start at the hostel office, hospital, and theDepartment. After all these activities complete (this synchronization is represented as a horizontalline),theidentitycard canbe issued to astudent bythe Academicsection. Fig. Activitydiagramforstudent admission procedure at a university 76 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Activitydiagramsvs.proceduralflow charts Activity diagrams are similar to the procedural flow charts. The difference is that activity diagramssupportdescriptionofparallelactivitiesandsynchronizationaspectsinvolvedindiffe rentactivities. STATECHARTDIAGRAM A state chart diagram is normally used to model how the state of an object changes in its lifetime.State chart diagrams are good at describing how the behavior of an object changes across several usecase executions. However, if we are interested in modeling some behavior that involves severalobjects collaborating with each other, state chart diagram is not appropriate. State chart diagrams arebasedon the finite statemachine (FSM)formalism. A FSM consists of a finite number of states corresponding to those of the object being modeled. Theobject undergoes state changes when specific events occur. The FSM formalism existed long beforethe object-oriented technology and has been used for a wide variety of applications. Apart frommodeling,ithasevenbeenusedintheoreticalcomputerscienceasageneratorforregularlan guages. A major disadvantage of the FSM formalism is the state explosion problem. The number of statesbecomes too many and the model too complex when used tomodel practical systems. This problemis overcome in UML by using state charts. The state chart formalism was proposed by David Harel[1990]. A state chart is a hierarchical model of a system and introduces the concept of a compositestate(alsocalled nested state). Actions are associated with transitions and are considered to be processes that occur quickly and arenotinterruptible.Activitiesareassociatedwithstatesandcantakelonger.Anactivity canbeinterruptedbyan event. Thebasicelementsofthestatechartdiagramareasfollows:  Initialstate-Thisisrepresentedasafilledcircle. Software Engineering Keerthana P, Manasa KN, Ganga D Bengal 77

ISBN : 978-81-963532-2-3 (E-Book)    Finalstate-Thisisrepresentedbyafilledcircleinsidealargercircle. State-Thesearerepresentedbyrectangleswithroundedcorners. Transition- A transition is shown as an arrow between two states. Normally, the name of theevent which causes the transition is places alongside the arrow. A guard to the transition canalso be assigned. A guard is a Boolean logic condition. The transition can take place only ifthe grade evaluates to true. The syntax for the label of the transition is shown in 3 parts: event[guard]/action. An example state chart for the order object of the Trade House Automation software is shown in fig.16.2. 78 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.State chartdiagramforanorder object Activitydiagramvs.Statechart diagram  flowofcontrolfromstatetostate.  Both activity and state chart diagrams model the dynamic behavior of the system. Activitydiagram is essentially a flowchart showing flow of control from activity to activity. A statechartdiagramshowsastatemachineemphasizingthe An activity diagram is a special case of a state chart diagram in which all or most of the statesare activity states and all or most of the transitions are triggered by completion of activities executionwithina statemachine). inthesourcestate(Anactivityisanongoingnon-atomic 79 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book)  Activity diagrams may stand alone to visualize, specify, and document the dynamics of asociety of objects or they may be used to model the flow of control of an operation. Statechart diagrams may be attached to classes, use cases, or entire systems in order to visualize,specify,and document thedynamicsofan individualobject. MODULE-3 Coding- The objective of the coding phase is to transform the design of a system into code in a high level language and then to unit test this code. The programmers adhere to standard and well defined style of coding which they call their coding standard. The main advantages of adhering to a standard style of coding are as follows: • A coding standard gives uniform appearances to the code written by different engineers • It facilitates code of understanding. • Promotes good programming practices. For implementing our design into a code, we require a good high level language. A programming language should have the following features: Characteristics of a Programming Language • Readability: A good high-level language will allow programs to be written in some ways that resemble a quite-English description of the underlying algorithms. If care is taken, the coding may be done in a way that is essentially self-documenting. • Portability: High-level languages, being essentially machine independent, should be able to develop portable software. • Generality: Most high-level languages allow the writing of a wide variety of programs, thus relieving the programmer of the need to become expert in many diverse languages. • Brevity: Language should have the ability to implement the algorithm with less amount of code. Programs expressed in high-level languages are often considerably shorter than their low-level equivalents. • Error checking: Being human, a programmer is likely to make many mistakes in the 80 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) development of a computer program. Many high-level languages enforce a great deal of error checking both at compile-time and at run-time. • Cost: The ultimate cost of a programming language is a function of many of its characteristics. • Familiar notation: A language should have familiar notation, so it can be understood by most of the programmers. • Quick translation: It should admit quick translation. • Efficiency: It should permit the generation of efficient object code. • Modularity: It is desirable that programs can be developed in the language as a collection of separately compiled modules, with appropriate mechanisms for ensuring selfconsistency between these modules. • Widely available: Language should be widely available and it should be possible to provide translators for all the major machines and for all the major operating systems. A coding standard lists several rules to be followed during coding, such as the way variables are to be named, the way the code is to be laid out, error return conventions, etc. Coding standards and guidelines Good software development organizations usually develop their own coding standards and guidelines depending on what best suits their organization and the type of products they develop. The following are some representative coding standards. 1. Rules for limiting the use of global: These rules list what types of data can be declared global and what cannot. 2. Contents of the headers preceding codes for different modules: The information contained in the headers of different modules should be standard for an organization. The 81 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) exact format in which the header information is organized in the header can also be specified. The following are some standard header data: • Name of the module. • Date on which the module was created. • Author’s name. • Modification history. • Synopsis of the module. • Different functions supported, along with their input/output parameters. • Global variables accessed/modified by the module. 3. Naming conventions for global variables, local variables, and constant identifiers: A possible naming convention can be that global variable names always start with a capital letter, local variable names are made of small letters, and constant names are always capital letters. 4. Error return conventions and exception handling mechanisms: The way error conditions are reported by different functions in a program are handled should be standard within an organization. For example, different functions while encountering an error condition should either return a 0 or 1 consistently. The following are some representative coding guidelines recommended by many software development organizations. 1. Do not use a coding style that is too clever or too difficult to understand: Code should be easy to understand. Many inexperienced engineers actually take pride in writing cryptic and incomprehensible code. Clever coding can obscure meaning of the code and hamper understanding. It also makes maintenance difficult. 2. Avoid obscure side effects: The side effects of a function call include modification of parameters passed by reference, modification of global variables, and I/O operations. An obscure side effect is one that is not obvious from a casual examination of the code. Obscure side effects make it difficult to understand a piece of code. For example, if a global variable is changed obscurely in a called module or some file I/O is performed 82 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) which is difficult to infer from the function’s name and header information, it becomes difficult for anybody trying to understand the code. 3. Do not use an identifier for multiple purposes: Programmers often use the same identifier to denote several temporary entities. For example, some programmers use a temporary loop variable for computing and a storing the final result. The rationale that is usually given by these programmers for such multiple uses of variables is memory efficiency, e.g. three variables use up three memory locations, whereas the same variable used in three different ways uses just one memory location. However, there are several things wrong with this approach and hence should be avoided. Some of the problems caused by use of variables for multiple purposes as follows: • Each variable should be given a descriptive name indicating its purpose. This is not possible if an identifier is used for multiple purposes. Use of a variable for multiple purposes can lead to confusion and make it difficult for somebody trying to read and understand the code. • Use of variables for multiple purposes usually makes future enhancements more difficult. 4. The code should be well-documented: As a rule of thumb, there must be at least one comment line on the average for every three-source line. 5. The length of any function should not exceed 10 source lines: A function that is very lengthy is usually very difficult to understand as it probably carries out many different functions. For the same reason, lengthy functions are likely to have disproportionately larger number of bugs. 6. Do not use goto statements: Use of goto statements makes a program unstructured and very difficult to understand. Code Review Code review for a model is carried out after the module is successfully compiled and the all the syntax errors have been eliminated. Code reviews are extremely cost-effective 83 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) strategies for reduction in coding errors and to produce high quality code. Normally, two types of reviews are carried out on the code of a module. These two types code review techniques are code inspection and code walk through. Code Walk Throughs Code walk through is an informal code analysis technique. In this technique, after a module has been coded, successfully compiled and all syntax errors eliminated. A few members of the development team are given the code few days before the walk through meeting to read and understand code. Each member selects some test cases and simulates execution of the code by hand (i.e. trace execution through each statement and function execution). The main objectives of the walk through are to discover the algorithmic and logical errors in the code. The members note down their findings to discuss these in a walk through meeting where the coder of the module is present. Even though a code walk through is an informal analysis technique, several guidelines have evolved over the years for making this naïve but useful analysis technique more effective. Of course, these guidelines are based on personal experience, common sense, and several subjective factors. Therefore, these guidelines should be considered as examples rather than accepted as rules to be applied dogmatically. Some of these guidelines are the following: • The team performing code walk through should not be either too big or too small. Ideally, it should consist of between three to seven members. • Discussion should focus on discovery of errors and not on how to fix the discovered errors. • Inder to foster cooperation and to avoid the feeling among engineers that they are being evaluated in the code walk through meeting, managers should not attend the walk through meetings. 84 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Code Inspection In contrast to code walk through, the aim of code inspection is to discover some common types of errors caused due to oversight and improper programming. In other words, during code inspection the code is examined for the presence of certain kinds of errors, in contrast to the hand simulation of code execution done in code walk throughs. For instance, consider the classical error of writing a procedure that modifies a formal parameter while the calling routine calls that procedure with a constant actual parameter. It is more likely that such an error will be discovered by looking for these kinds of mistakes in the code, rather than by simply hand simulating execution of the procedure. In addition to the commonly made errors, adherence to coding standards is also checked during code inspection. Good software development companies collect statistics regarding different types of errors commonly committed by their engineers and identify the type of errors most frequently committed. Such a list of commonly committed errors can be used during code inspection to look out for possible errors. Following is a list of some classical programming errors which can be checked during code inspection: • Use of uninitialized variables. • Jumps into loops. • Nonterminating loops. • Incompatible assignments. • Array indices out of bounds. • Improper storage allocation and deallocation. • Mismatches between actual and formal parameter in procedure calls. • Use of incorrect logical operators or incorrect precedence among operators. • Improper modification of loop variables. • Comparison of equally of floating point variables, etc. Clean Room Testing Clean room testing was pioneered by IBM. This type of testing relies heavily on walk throughs, inspection, and formal verification. The programmers are not allowed to test any of their code by executing the code other than doing some syntax testing using a compiler. The software development philosophy is based on avoiding software defects by using a rigorous inspection process. The objective of this software is zero-defect software. The 85 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) name ‘clean room’ was derived from the analogy with semi-conductor fabrication units. In these units (clean rooms), defects are avoided by manufacturing in ultra-clean atmosphere. In this kind of development, inspections to check the consistency of the components with their specifications has replaced unit-testing. This technique reportedly produces documentation and code that is more reliable and maintainable than other development methods relying heavily on code execution-based testing. The clean room approach to software development is based on five characteristics: • Formal specification: The software to be developed is formally specified. A statetransition model which shows system responses to stimuli is used to express the specification. • Incremental development: The software is partitioned into increments which are developed and validated separately using the clean room process. These increments are specified, with customer input, at an early stage in the process. • Structured programming: Only a limited number of control and data abstraction constructs are used. The program development process is process of stepwise refinement of the specification. • Static verification: The developed software is statically verified using rigorous software inspections. There is no unit or module testing process for code components • Statistical testing of the system: The integrated software increment is tested statistically to determine its reliability. These statistical tests are based on the operational profile which is developed in parallel with the system specification. The main problem with this approach is that testing effort is increased as walk throughs, inspection, and verification are time-consuming. Software Documentation When various kinds of software products are developed then not only the executable files and the source code are developed but also various kinds of documents such as users’ manual, software requirements specification (SRS) documents, design documents, test documents, installation manual, etc are also developed as part of any software engineering process. All these documents are a vital part of good software development practice. Good 86 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) documents are very useful and server the following purposes: o Good documents enhance understandability and maintainability of a software product. They reduce the effort and time required for maintenance. o Use documents help the users in effectively using the system. o Good documents help in effectively handling the manpower turnover problem. Even when an engineer leaves the organization, and a new engineer comes in, he can build up the required knowledge easily. o Production of good documents helps the manager in effectively tracking the progress of the project. The project manager knows that measurable progress is achieved if a piece of work is done and the required documents have been produced and reviewed. Different types of software documents can broadly be classified into the following: • Internal documentation • External documentation Internal documentation is the code comprehension features provided as part of the source code itself. Internal documentation is provided through appropriate module headers and comments embedded in the source code. Internal documentation is also provided through the useful variable names, module and function headers, code indentation, code structuring, use of enumerated types and constant identifiers, use of user-defined data types, etc. Careful experiments suggest that out of all types of internal documentation meaningful variable names is most useful in understanding the code. This is of course in contrast to the common expectation that code commenting would be the most useful. The research finding is obviously true when comments are written without thought. For example, the following style of code commenting does not in any way help in understanding the code. a = 10; /* a made 10 */ But even when code is carefully commented, meaningful variable names still are more helpful in understanding a piece of code. Good software development organizations usually ensure good internal documentation by appropriately formulating their coding standards and coding guidelines. External documentation is provided through various types of supporting documents such 87 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) as users’ manual, software requirements specification document, design document, test documents, etc. A systematic software development style ensures that all these documents are produced in an orderly fashion. TESTING Program Testing Testing a program consists of providing the program with a set of test inputs (or test cases) and observing if the program behaves as expected. If the program fails to behave as expected, then the conditions under which failure occurs are noted for later debugging and correction. Some commonly used terms associated with testing are:  Failure: This is a manifestation of an error (or defect or bug). But, the mere presence of an error may not necessarily lead to a failure.  Test case: This is the triplet [I,S,O], where I is the data input to the system, S is the state of the system at which the data is input, and O is the expected output of the system.  Test suite: This is the set of all test cases with which a given software product is to be tested. Aim of Testing The aim of the testing process is to identify all defects existing in a software product. However for most practical systems, even after satisfactorily carrying out the testing phase, it is not possible to guarantee that the software is error free. This is because of the fact that the input data domain of most software products is very large. It is not practical to test the software exhaustively with respect to each value that the input data may assume. Even with this practical limitation of the testing process, the importance of testing should not be underestimated. It must be remembered that testing does expose many defects existing in a software product. Thus testing provides a practical way of reducing defects in 88 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) a system and increasing the users’ confidence in a developed system. Verification Vs Validation Verification is the process of determining whether the output of one phase of software development conforms to that of its previous phase, whereas validation is the process of determining whether a fully developed system conforms to its requirements specification. Thus while verification is concerned with phase containment of errors, the aim of validation is that the final product be error free. Design of Test Cases Exhaustive testing of almost any non-trivial system is impractical due to the fact that the domain of input data values to most practical software systems is either extremely large or infinite. Therefore, we must design an optional test suite that is of reasonable size and can uncover as many errors existing in the system as possible. Actually, if test cases are selected randomly, many of these randomly selected test cases do not contribute to the significance of the test suite, i.e. they do not detect any additional defects not already being detected by other test cases in the suite. Thus, the number of random test cases in a test suite is, in general, not an indication of the effectiveness of the testing. In other words, testing a system using a large collection of test cases that are selected at random does not guarantee that all (or even most) of the errors in the system will be uncovered. Consider the following example code segment which finds the greater of two integer values x and y. This code segment has a simple programming error. if (x>y) max = x; else max = x; For the above code segment, the test suite, {(x=3,y=2);(x=2,y=3)} can detect the error, whereas a larger test suite {(x=3,y=2);(x=4,y=3);(x=5,y=1)} does not detect the error. So, it would be incorrect to say that a larger test suite would always detect more errors than a smaller one, unless of course the larger test suite has also been carefully designed. This implies that the test suite should be carefully designed than picked randomly. Therefore, 89 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) systematic approaches should be followed to design an optimal test suite. In an optimal test suite, each test case is designed to detect different errors. Functional Testing Vs. Structural Testing In the black-box testing approach, test cases are designed using only the functional specification of the software, i.e. without any knowledge of the internal structure of the software. For this reason, black-box testing is known as functional testing. On the other hand, in the white-box testing approach, designing test cases requires thorough knowledge about the internal structure of software, and therefore the white-box testing is called structural testing. Fig.Unit testingwiththehelp of driverandstub modules BLACK-BOX TESTING Testing in the large vs. testing in the small Software products are normally tested first at the individual component (or unit) level. This is referred to as testing in the small. After testing all the components individually, the components are slowly integrated and tested at each level of integration (integration testing). Finally, the fully integrated system is tested (called system testing). Integration and system testing are known as testing in the large. 90 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Unit Testing Unit testing is undertaken after a module has been coded and successfully reviewed. Unit testing (or module testing) is the testing of different units (or modules) of a system in isolation. In order to test a single module, a complete environment is needed to provide all that is necessary for execution of the module. That is, besides the module under test itself, the following steps are needed in order to be able to test the module: • The procedures belonging to other modules that the module under test calls. • Nonlocal data structures that the module accesses. • A procedure to call the functions of the module under test with appropriate parameters. Modules are required to provide the necessary environment (which either call or are called by the module under test) is usually not available until they too have been unit tested, stubs and drivers are designed to provide the complete environment for a module. The role of stub and driver modules is pictorially shown in fig. A stub procedure is a dummy procedure that has the same I/O parameters as the given procedure but has a highly simplified behavior. For example, a stub procedure may produce the expected behavior using a simple table lookup mechanism. A driver module contain the nonlocal data structures accessed by the module under test, and would also have the code to call the different functions of the module with appropriate parameter values. white-box testing 91 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) One white-box testing strategy is said to be stronger than another strategy, if all types of errorsdetected by thefirst testing strategy is also detected by the second testing strategy, and thesecondtestingstrategyadditionallydetectssomemoretypesoferrors.Whentwotestingstrategiesdet ecterrorsthataredifferentatleastwithrespecttosometypesoferrors,thentheyare called complementary. The concepts of stronger and complementary testing are schematicallyillustratedin fig.. Fig.Strongerand complementarytestingstrategies StatementCoverage The statement coverage strategy aims to design test cases so that every statement in a program isexecutedatleastonce.The principalidea governing thestatementcoveragestrategy isthatunless a statement is executed, it is very hard to determine if an error exists in that statement.Unlessastatementisexecuted,itisverydifficulttoobservewhetheritcausesfailureduetosome illegal memory access, wrong result computation, etc. However, executing some statementonceandobservingthatitbehavesproperlyforthatinputvalueisnoguaranteethatitwillbehavecorre ctlyforallinputvalues.Inthefollowing,designingof testcasesusingthestatementcoveragestrategyhavebeen shown. Example:ConsidertheEuclid’sGCDcomputationalgorithm:intc ompute_gcd(x,y) 92 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) intx, y; { 1while(x!=y) { 2if(x>y)then 3x=x– y;4elsey=y–x; 5 } 6return x; } By choosing the test set {(x=3, y=3), (x=4, y=3), (x=3, y=4)}, we can exercise the program suchthatall statements are executed at least once. BranchCoverage In the branch coverage-based testing strategy, test cases are designed to make each branchcondition to assume true and false values in turn. Branch testing is also known as edge testing asinthistestingscheme,eachedgeof aprogram’scontrolflow graphistraversedatleast once. It is obvious that branch testing guarantees statement coverage and thus is a stronger testingstrategycomparedtothestatementcoveragebasedtesting.ForEuclid’sGCDcomputationalgorithm, the test cases for branch coverage can be {(x=3, y=3), (x=3, y=2), (x=4, y=3), (x=3,y=4)}. ConditionCoverage Inthisstructuraltesting,testcasesaredesignedtomakeeachcomponentofacompositeconditional expression to assume both true and false values. For example, in the conditionalexpression ((c1.and.c2).or.c3), the components c1, c2 and c3 are each made to assume both trueand falsevalues.Branchtesting is probably thesimplest condition testing strategy where onlythe compound conditions appearing in the different branch statements are made to assume thetrue and false values. Thus, condition testing is a stronger testing strategy than branch testing andbranchtestingisstrongertestingstrategy thanthestatementcoverage-basedtesting.Foracomposite conditional expression of n components, for condition coverage, 2ⁿ test cases arerequired. Thus, for condition coverage, the number of test cases increases exponentially with thenumber of component conditions. Therefore, a condition coverage-based testing technique ispractical onlyif n (thenumberof conditions) is small. PathCoverage The path coverage-based testing strategy requires us to design test cases such that all linearlyindependent paths in the program are executed at least once. A linearly independent path 93 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) can bedefinedin terms ofthecontrol flow graph (CFG)ofaprogram. ControlFlow Graph(CFG) A control flow graph describes the sequence in which the different instructions of a program getexecuted. In other words, a control flow graph describes how the control flows through theprogram. In order to draw the control flow graph of a program, all the statements of a programmust be numbered first. The different numbered statements serve as nodes of the control flowgraph (as shown in fig. 20.2). An edge from one node to another node exists if the execution ofthestatementrepresentingthefirst nodecanresultinthetransferof controltotheothernode. The CFG for any program can be easily drawn by knowing how to represent the sequence,selection, and iteration type of statements in the CFG. After all, a program is made up from thesetypes of statements. Fig. 20.2summarizes how the CFG for these three types of statements canbe drawn. It is important to note that for the iteration type of constructs such as the whileconstruct, the loop condition is tested only at the beginning of the loop and therefore the controlflow from the last statement of the loop is always to the top of the loop. Using these basic ideas,theCFGofEuclid’sGCDcomputationalgorithmcan bedrawnas shown infig. 20.3. Sequence: a=5; b=a*2-1; Fig.(a):CFGforsequenceconstructs Selection: if(a>b) c=3; else 94 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) c=5; c=c*c; Fig.(b):CFG forselectionconstructs Iteration: while(a>b) { b=b-1;b=b*a; } c=a+b; Fig.(c):CFGfor anditerationtypeofconstructs 95 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) EUCLID’SGCDComputationAlgorithm Fig.:Controlflowdiagram Path A path through a program is a node and edge sequence from the starting node to a terminal nodeof the control flow graph of a program. There can be more than one terminal node in a 96 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) program.Writing test cases to cover all the paths of a typical program is impractical. For this reason, coveragetestingdoesnotrequirecoverageofallpathsbutonlycoverageoflinearlyindependentpaths. Linearlyindependentpath Alinearlyindependentpathisanypaththroughtheprogramthatintroducesatleastonenewedge that is not included in any other linearly independent paths. If a path has one new nodecompared to all other linearly independent paths, then the path is also linearly independent. This isbecause;anypathhavinganewnodeautomaticallyimpliesthatithasanewedge.Thus,apaththatissub-path ofanother pathisnot considered tobe alinearlyindependent path. ControlFlowGraph Inordertounderstandthepathcoverage-basedtestingstrategy,itisverymuchnecessarytounderstand the control flow graph (CFG) of a program. Control flow graph (CFG) of a program hasbeendiscussed earlier. LinearlyIndependentPath The path-coverage testing does not require coverage of all paths but only coverage of linearlyindependentpaths. Linearlyindependent pathshavebeen discussedearlier. CyclomaticComplexity For more complicated programs it is not easy to determine the number of independent paths of theprogram.McCabe’scyclomaticcomplexity definesanupperboundforthenumberoflinearlyindependent paths through a program. Also, the McCabe’s cyclomatic complexity is very simple tocompute. Thus, the McCabe’s cyclomatic complexity metric provides a practical way of determiningthe maximum number of linearly independent paths in a program. Though the McCabe’s metric doesnot directly identify the linearly independent paths, but it informs approximately how many paths tolookfor. There are three different ways to compute the cyclomatic complexity. The answers computed by thethreemethodsare guaranteed toagree. thepathMethod1: GivenacontrolflowgraphGofaprogram,thecyclomaticcomplexityV(G)canbecomputedas: 97 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) V(G)= E– N + 2 where N is the number of nodes of the control flow graph and E is the number of edges in thecontrolflowgraph. FortheCFGofexampleshowninfig.20.3,E=7andN=6.Therefore,thecyclomaticcomplexity= 76+2=3. Method2: An alternative way of computing the cyclomatic complexity of a program from an inspectionofitscontrol flowgraph isasfollows: V(G)=Total numberof boundedareas+1 In the program’s control flow graph G, any region enclosed by nodes and edges can be calledasaboundedarea.Thisisan easywayto determinetheMcCabe’scyclomaticcomplexity. But, what if the graph G is not planar, i.e. however you draw the graph, two or more edgesintersect? Actually, it can be shown that structured programs always yield planar graphs. But,presenceofGOTO’scaneasilyaddintersectingedges.Therefore,fornonstructuredprograms,thiswayofcomputingtheMcCabe’scyclomaticcomplexitycannotbe used. Thenumberofboundedareasincreaseswiththenumberofdecisionpathsandloops.Therefore, the McCabe’s metric provides a quantitative measure of testing difficulty and theultimate reliability. Forthe CFG example shown in fig. 20.3, from a visual examination ofthe CFG the number of bounded areas is 2. Therefore the cyclomatic complexity, computingwith this method is also 2+1 = 3. This method provides a very easy way of computing thecyclomatic complexity of CFGs, just from a visual examination of the CFG. On the otherhand, the other method of computing CFGs is more amenable to automation, i.e. it can beeasily coded into a program which can be used to determine the cyclomatic complexities ofarbitraryCFGs. Method3: The cyclomatic complexity of a program can also be easily computed by computing thenumber of decision statements of the program. If N is the number of decision statement of aprogram,thenthe McCabe’smetricisequalto N+1. DataFlow-BasedTesting Data flow-based testing method selects test paths of a program according to the locations of thedefinitionsand usesofdifferent variablesina program. ForastatementnumberedS,let DEF(S)={X/statementScontainsadefinitionofX},andUSE 98 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) S(S)={X/statementScontainsause ofX} For the statement S:a=b+c;, DEF(S) = {a}. USES(S) = {b,c}. The definition of variable X atstatement S is said to be live at statement S1, if there exists a path from statement S to statement S1whichdoesnot contain anydefinition ofX. The definition-use chain (or DU chain) of a variable X is of form [X, S, S1], where S and S1 arestatement numbers, such that X Є DEF(S) and X Є USES(S1), and the definition of X in thestatement S is live at statement S1. One simple data flow testing strategy is to require that every DUchain be covered at least once. Data flow testing strategies are useful for selecting test paths of aprogramcontainingnestedifand loop statements. MutationTesting In mutation testing, the software is first tested by using an initial test suite built up from the differentwhitebox testing strategies. After theinitial testing is complete, mutation testing is taken up. Theidea behind mutation testing is to make few arbitrary changes to a program at a time. Each time theprogram is changed, it is called as a mutated program and the change effected is called as a mutant. Amutated programis tested againstthefull testsuite of theprogram.If there exists atleast one testcase in the test suite for which a mutant gives an incorrect result, then the mutant is said to be dead. Ifa mutant remains alive even after all the test cases have been exhausted, the test data is enhanced tokill the mutant. The process of generation and killing of mutants can be automated by predefining asetofprimitivechangesthatcanbeappliedtotheprogram.Theseprimitivechangescanbealterations such as changing an arithmetic operator, changing the value of a constant, changing a datatype, etc. A major disadvantage of the mutation-based testing approach is that it is computationallyveryexpensive, since alarge number ofpossible mutantscanbe generated. Sincemutationtestinggeneratesalargenumberofmutantsandrequiresustocheckeachmutantwith the full test suite, it is not suitable for manual testing. Mutation testing should be used inconjunctionofsome testingtoolwhich wouldrun allthetest casesautomatically. DEBUGGING,INTEGRATION ANDSYSTEMTESTING NeedforDebugging Once errors are identified in a program code, it is necessary to first identify the precise programstatements responsible for the errors and then to fix them. Identifying errors in a program codeandthen fixthem up are known as debugging. DebuggingApproaches 99 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Thefollowingaresomeoftheapproachespopularlyadopted byprogrammers fordebugging. BruteForceMethod: This is the most common method of debugging but is the least efficient method. In thisapproach,theprogramisloadedwithprintstatementstoprinttheintermediatevalueswith the hope that some of the printed values will help to identify the statement in error.This approach becomes more systematic with the use of a symbolic debugger (also calleda source code debugger), because values of different variables can be easily checked andbreakpoints andwatch pointscan beeasilyset totest thevalues ofvariables effortlessly. Backtracking: This is also a fairly common approach. In this approach, beginning from the statement atwhich an error symptom has been observed, the source code is traced backwards until theerrorisdiscovered.Unfortunately,asthenumberofsourcelinestobetracedbackincreases,the numberofpotentialbackwardpathsincreasesandmaybecomeunmanageablylargethuslimiting the useof this approach. CauseEliminationMethod: In this approach, a list of causes which could possibly have contributed to the errorsymptom is developed and tests are conducted to eliminate each. A related technique ofidentificationofthe errorfromthe errorsymptomis thesoftwarefault tree analysis. ProgramSlicing: This technique is similar to back tracking. Here the search space is reduced by definingslices. A slice of a program for a particular variable at a particular statement is the set ofsourcelines precedingthis statement that can influencethevalue ofthat variable DebuggingGuidelines Debugging is often carried out by programmers based on their ingenuity. The following are somegeneralguidelinesforeffectivedebugging:  Many times debugging requires a thorough understanding of the program design. Tryingto debug based on a partial understanding of the system design and implementation mayrequirean inordinateamount ofeffort tobeputinto debuggingeven simpleproblems.  Debugging may sometimes even require full redesign of the system. In such cases, acommon mistake that novice programmers often make is attempting not to fix the errorbutits symptoms.  One must be beware of the possibility that an error correction may introduce new errors.Thereforeaftereveryround oferror-fixing, regressiontestingmustbecarriedout. 100 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) ProgramAnalysis Tools A program analysis tool means an automated tool that takes the source code or the executablecodeofaprogramasinputandproducesreportsregardingseveralimportantcharacteristicsoft he program, such as its size, complexity, adequacy of commenting, adherence to programmingstandards,etc. Wecan classifytheseintotwo broadcategories ofprogram analysis tools:  StaticAnalysistools  DynamicAnalysistools  Staticprogramanalysistools StaticAnalysisToolisalsoaprogramanalysistool.Itassessesandcomputesvariouscharacteristics of a software product without executing it. Typically, static analysis tools analyzesome structural representation of a program to arrive at certain analytical conclusions, e.g. thatsomestructural properties hold. Thestructural properties that areusuallyanalyzed are:  Whetherthecodingstandards havebeenadheredto?  Certainprogrammingerrorssuchasuninitializedvariablesandmismatchbetweenact ualandformalparameters,variablesthataredeclaredbutneverusedare also checked. Codewalkthroughsandcodeinspectionsmightbeconsideredasstaticanalysismethods.But,the term static program analysis is used to denote automated analysis tools. So, a compiler can beconsideredto beastaticprogram analysis tool. Dynamic program analysis tools - Dynamic program analysis techniques require the program tobe executed and its actual behavior recorded. A dynamic analyzer usually instruments the code(i.e. adds additional statements in the source code to collect program execution traces). Theinstrumented code when executed allows us to record the behavior of the software for differenttestcases.Afterthesoftwarehasbeentestedwithitsfulltestsuiteanditsbehaviorrecorded,the 101 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) dynamic analysis tool caries out a post execution analysis and produces reports which describethe structural coverage that has been achieved by the complete test suite for the program. Forexample, the post execution dynamic analysis report might provide data on extent statement,branchand path coverageachieved. Normally the dynamic analysis results are reported in the form of a histogram or a pie chart todescribe the structural coverage achieved for different modules of the program. The output of adynamic analysis tool can be stored and printed easily and provides evidence that thoroughtesting has been done. The dynamic analysis results the extent of testing performed in white-boxmode. If the testing coverage is not satisfactory more test cases can be designed and added to thetest suite. Further, dynamic analysis results can help to eliminate redundant test cases from thetest suite. 102 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 23 INTEGRATIONTESTING Theprimaryobjectiveofintegrationtestingistotestthemoduleinterfaces,i.e.therearenoerrors in the parameter passing, when one module invokes another module. During integrationtesting, different modules of a system are integrated in a planned manner using an integrationplan. The integration plan specifies the steps and the order in which modules are combined torealize the full system. After each integration step, the partially integrated system is tested. Animportant factor that guides the integration plan is the module dependency graph. The structurechart(ormoduledependencygraph)denotestheorderinwhichdifferentmodulescalleachother .Byexaminingthestructurechart theintegrationplancan bedeveloped. Integrationtestapproaches There are four types of integration testing approaches. Any one (or a mixture) of the followingapproachescanbeusedtodevelop arethefollowing: theintegrationtestplan.Thoseapproaches  Bigbangapproach  Bottom-upapproach  Top-downapproach  Mixed-approach Big-BangIntegrationTesting It is the simplest integration testing approach, where all the modules making up a system areintegrated in a single step. In simple words, all the modules of the system are simply put togetherandtested.However,thistechniqueispracticableonlyforverysmallsystems.Themainproblem with this approach is that once an error is found during the integration testing, it is verydifficult to localize the error as the error may potentially belong to any of the modules beingintegrated. Therefore, debugging errors reported during big bang integration testing are veryexpensive to fix. Bottom-UpIntegrationTesting In bottom-up testing, each subsystem is tested separately and then the full system is tested. Asubsystem might consist of many modules which communicate among each other through well-defined interfaces. The primary purpose of testing each subsystem is to test the interfaces amongvarious modules making up the subsystem. Both control and data interfaces are tested. 103 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) The testcases must be carefully chosen to exercise the interfaces in all possible manners Large softwaresystemsnormallyrequireseverallevelsofsubsystemtesting;lowerlevelsubsystemsaresuccessively combined to form higher-level subsystems. A principal advantage of bottom-upintegration testing is that several disjoint subsystems can be tested simultaneously. In a purebottom-up testing no stubs are required, only test-drivers are required. A disadvantage of bottom-up testing is the complexity that occurs when the system is made up of a large number of smallsubsystems.Theextreme casecorrespondsto thebig-bangapproach. Top-DownIntegrationTesting Top-down integration testing starts with the main routine and one or two subordinate routines inthe system. After the top-level ‘skeleton’ has been tested, the immediately subroutines of the‘skeleton’ are combined with it and tested. Top-down integration testing approach requires theuse of program stubs to simulate the effect of lower-level routines that are called by the routinesunder test. A pure top-down integration does not require any driver routines. A disadvantage ofthe top-down integration testing approach is that in the absence of lower-level routines, manytimes it may become difficult to exercise the top-level routines in the desired manner since thelower-levelroutines perform several low-levelfunctions such asI/O. MixedIntegration Testing A mixed (also called sandwiched) integration testing follows a combination of top-down andbottom-up testing approaches. In top-down approach, testing can start only after the toplevelmodules have been coded and unit tested. Similarly, bottom-up testing can start only after thebottom level modules are ready. The mixed approach overcomes this shortcoming of the topdown and bottom-up approaches. In the mixed testing approaches, testing can start as and whenmodules become available. Therefore, this is one of the most commonly used integration testingapproaches. PhasedVs.Incremental Testing Thedifferentintegrationtestingstrategiesareeitherphasedorincremental.Acomparisonofthesetwo strategies is asfollows: o Inincrementalintegrationtesting,onlyonenewmoduleisaddedtothepartialsystemeach time. o Inphasedintegration,agroupofrelatedmodulesareaddedtothepartialsystemeachtime. Phasedintegrationrequireslessnumberofintegrationstepscomparedtotheincrementalintegrationappr oach.However,whenfailuresaredetected,itiseasiertodebugthesystemintheincrementaltestingapproa chsinceitisknownthattheerroriscausedbyadditionofasinglemodule. In fact, big bang testing is a degenerate case of the phased integration testing approach.Systemtesting Systemtestsaredesignedtovalidateafullydevelopedsystemtoassurethatitmeetsitsrequirements.There 104 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) are essentiallythreemain kinds of systemtesting:  AlphaTesting.Alphatestingreferstothesystemtestingcarriedoutbythetestteamwithinthe developingorganization.  Betatesting.Betatestingisthesystemtestingperformedbyaselectgroupoffriendlycustomers.  AcceptanceTesting.Acceptancetestingisthesystemtestingperformedbythecustomertodeter mine whether he should accept thedeliveryofthe system. 105 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) In each of the above types of tests, various kinds of test cases are designed by referring to theSRS document. Broadly, these tests can be classified into functionality and performance tests.The functionality test tests the functionality of the software to check whether it satisfies thefunctional requirements as documented in the SRS document. The performance test tests theconformanceof thesystem with thenonfunctional requirements of thesystem. PerformanceTesting Performancetestingiscarriedouttocheckwhetherthesystemneedsthenon-functionalrequirements identified in the SRS document. There are several types of performance testing.Among of them nine types are discussed below. The types of performance testing to be carriedoutonasystemdependonthedifferentnonfunctionalrequirementsofthesystemdocumentedintheSRS document. All performancetests can beconsidered as black-boxtests. • Stresstesting • Volumetesting • Configurationtesting • Compatibilitytesting • Regressiontesting • Recoverytesting • Maintenancetesting • Documentationtesting • Usabilitytesting StressTesting-Stresstestingisalsoknownasendurancetesting.Stresstestingevaluates system performance when it is stressed for short periods of time. Stress tests areblack box tests which are designed to impose a range of abnormal and even illegal inputconditions so as to stress the capabilities of the software. Input data volume, input datarate, processing time, utilization of memory, etc. are tested beyond the designed capacity.For example, suppose an operating system is supposed to support 15 multi programmedjobs, the system is stressed by attempting to run 15 or more jobs simultaneously. A real-time system might be tested to determine the effect of simultaneous arrival of severalhighpriorityinterrupts. Stress testing is especially important for systems that usually operate below the maximumcapacity but are severely stressed at some peak demand hours. For example, if the non-functional requirement specification states that the response time should not be more than20 secs per transaction when 60 concurrent users are working, then during the stresstestingthe response timeischecked with 60 usersworkingsimultaneously. 106 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Volume Testing-It is especially important to check whether the data structures (arrays,queues,stacks,etc.)havebeendesignedtosuccessfullyextraordinarysituations.For Example, a compiler might be tested to check whether the symbol table overflows when averylargeprogram is compiled. ConfigurationTesting-Thisisusedtoanalyzesystembehaviorinvarioushardwareand software configurations specified in the requirements. Sometimes systems are built invariableconfigurationsfor different users. Forinstance, wemight define a minimalsystem to serve a single user, and other extension configurations to serve additional users.The system is configured in each of the required configurations and it is checked if thesystembehaves correctlyin all required configurations. Compatibility Testing -This type of testing is required when the system interfaces withother types of systems.Compatibility aims to check whether the interfacefunctionsperform as required. For instance, if the system needs to communicate with a largedatabase system to retrieve information, compatibility testing is required to test the speedandaccuracyof dataretrieval. Regression Testing -This type of testing is required when the system being tested is anupgradation of an already existing system to fix some bugs or enhance functionality,performance, etc. Regression testing is the practice of running an old test suite after eachchange to the system or after each bug fix to ensure that no new bug has been introduceddue to the change or the bug fix. However, if only a few statements are changed, then theentire testsuite need notbe run- only those testcasesthat testthe functionsthat arelikelyto be affected bythechangeneed to berun. Recovery Testing -Recovery testing tests the response of the system to the presence offaults, or loss of power, devices, services, data, etc. The system is subjected to the loss ofthe mentioned resources (as applicable and discussed in the SRS document) and it ischeckedifthesystemrecoverssatisfactorily.Forexample,theprintercanbedisconnected to check if the system hangs. Or, the power may be shut down to check theextentofdata loss and corruption. MaintenanceTesting-Thistestingaddressesthediagnosticprograms,andotherprocedures that are required to be developed to help maintenance of the system. It isverifiedthat theartifactsexist and theyperform properly. 107 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) DocumentationTesting-Itischeckedthattherequiredusermanual,maintenancemanuals, and technical manuals exist and are consistent. If the requirements specify thetypes of audience for which a specific manual should be designed, then the manual ischeckedfor compliance. Usability Testing- Usability testing concernschecking the user interface to see ifitmeets all user requirements concerning the user interface. During usability testing, thedisplayscreens,reportformats,andotheraspectsrelatingtotheuserinterfacerequirementsar etested. ErrorSeeding Sometimes the customer might specify the maximum number of allowable errors that may bepresent in the delivered system. These are often expressed in terms of maximum number ofallowable errors per line of source code. Errorseed can be used toestimate the number ofresidual errors in a system. Error seeding, as the name implies, seeds the code with some knownerrors. In other words, some artificial errors are introduced into the program artificially. Thenumberoftheseseedederrorsdetectedinthecourseofthestandardtestingprocedureisdetermined. These valuesinconjunctionwiththe number of unseedederrorsdetected can beusedto predict: • Thenumberof errors remainingin theproduct. • Theeffectivenessofthetestingstrategy. LetN bethe totalnumber ofdefects in thesystemand let n ofthesedefects be found bytesting.LetSbethe totalnumberof seededdefects, andlet sof thesedefectsbe foundduringtesting. n/N= s/S or N= S ×n/s Defectsstill remainingaftertesting = N–n= n×(S – s)/s Error seeding works satisfactorily only if the kind of seeded errors matches closely with the kindof defects that actually exist. However, it is difficult to predict the types of errors that exist in asoftware. To some extent, the different categories of errors that remain can be estimated to a firstapproximation by analyzing historical data of similar projects. Due to the shortcoming that thetypes of seeded errors should match closely with the types of errors actually existing in the code,errorseedingis useful onlyto a moderateextent. 108 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) RegressionTesting Regressiontestingdoesnotbelongtoeitherunittest,integrationtest,orsystemtesting.Instead,it is a separate dimension to these three forms of testing. The functionality of regression testinghasbeen discussedearlier. SOFTWAREMAINTENANCE NecessityofSoftwareMaintenance Softwaremaintenanceisbecominganimportantactivityofalargenumberofsoftwareorganizations. This is no surprise, given the rate of hardware obsolescence, the immortality of asoftware product per se, and the demand of the user community to see the existing softwareproducts run on newer platforms, run in newer environments, and/or with enhanced features.Whenthehardwareplatformischanged,andasoftwareproductperformssomelowlevelfunctions, maintenance is necessary. Also, whenever the support environment of a softwareproduct changes, the software product requires rework to cope up with the newer interface. Forinstance, a software product may need to be maintained when the operating system changes.Thus, every software product continues to evolve after its development through maintenanceefforts. Therefore it can be stated that software maintenance is needed to correct errors, enhancefeatures,port the softwareto newplatforms, etc. Typesofsoftwaremaintenance Therearebasicallythree types ofsoftwaremaintenance. Theseare:  Corrective: Corrective maintenance of a software product is necessary to rectify the bugsobservedwhile thesystem is in use.  Adaptive: A software product might need maintenance when the customers need theproduct to run on new platforms, on new operating systems, or when they need theproductto interfacewithnewhardwareor software.  Perfective: A software product needs maintenance to support the new features that userswant it to support, to change different functionalities of the system according to customerdemands,orto enhancetheperformanceof thesystem. Problemsassociatedwithsoftwaremaintenance Software maintenance work typically is much more expensive than what it should be and takesmore time than required.In software organizations, maintenance workismostly carried outusing ad hoc techniques. The primary reason being that software maintenance is one of the mostneglected areas of software engineering. Even though software maintenance is fast 109 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) becoming animportant area of work for many companies as the software products of yester years age, stillsoftware maintenance is mostly being carried out as fire-fighting operations, rather than throughsystematic and plannedactivities. Software maintenance has a very poor image in industry. Therefore, an organization often cannotemploy bright engineers to carry out maintenance work. Even though maintenance suffers from apoorimage,theworkinvolvedisoftenmorechallengingthandevelopmentwork.During maintenance it is necessary to thoroughly understand someone else’s work and then carry out therequiredmodifications and extensions. Another problem associated with maintenance work is that the majority of software productsneedingmaintenanceare legacyproducts. SoftwareReverseEngineering Softwarereverseengineeringistheprocessofrecoveringthedesignandtherequirementsspecification of a product from an analysis of its code. The purpose of reverse engineering is tofacilitate maintenance work by improving the understandability of a system and to produce thenecessary documents for a legacy system. Reverse engineering is becoming important, sincelegacy software products lack proper documentation, and are highly unstructured. Even welldesignedproductsbecomelegacysoftwareastheirstructuredegradesthroughaseriesofmaintenance efforts. The first stage of reverse engineering usually focuses on carrying out cosmetic changes to thecodetoimproveitsreadability,structure,andunderstandability,withoutchangingofitsfunctionalitie s. A process model for reverse engineering has been shown in fig. 24.1. A programcan be reformatted using any of the several available prettyprinter programs which layout theprogram neatly. Many legacy software products with complex control structure and unthoughtfulvariable names are difficult to comprehend. Assigning meaningful variable names is importantbecausemeaningfulvariablenamesarethemosthelpfulthingincodedocumentation.Allvaria bles, data structures, and functions should be assigned meaningful names wherever possible.Complexnestedconditionalsintheprogramcanbereplacedbysimplerconditionalstatementso rwhenever appropriatebycasestatements. 110 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.24.1:Aprocess modelforreverseengineering After the cosmetic changes have been carried out on a legacy software the process of extractingthe code, design, and the requirements specification can begin. These activities are schematicallyshown in fig. 24.2.Inorder toextract thedesign, afull understandingof thecodeis needed.Some automatic tools can be usedtoderive thedata flowand control flow diagramfrom thecode. The structure chart (module invocation sequence and data interchange among modules)shouldalsobeextracted.TheSRSdocumentcanbewrittenoncethefullcodehasbeenthoroughl yunderstood andthe designextracted. 111

ISBN : 978-81-963532-2-3 (E-Book) Fig.24.2:Cosmeticchangescarriedoutbeforereverseengineering Legacysoftwareproducts It isprudent todefine a legacy system asany software system that is hard to maintain.Thetypical problems associated with legacy systems are poor documentation, unstructured (spaghetticode with ugly control structure), and lack of personnel knowledgeable in the product. Many ofthe legacy systems were developed long time back. But, it is possible that a recently developedsystemhavingpoordesign and documentation canbeconsidered to be alegacysystem. The activities involved in a software maintenance project are not unique and depend on severalfactorssuchas: • theextentofmodificationto theproductrequired 112 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • theresourcesavailable tothemaintenanceteam • theconditionsof theexistingproduct(e.g., howstructuredit is,how well documenteditis, etc.) • theexpectedprojectrisks,etc. When the changes needed to a software product are minor and straightforward, the code can bedirectlymodifiedandthechangesappropriatelyreflectedinallthedocuments.Butmoreelaborateacti vitiesarerequiredwhentherequiredchangesarenotsotrivial.Usually,forcomplex maintenance projects for legacy systems, the software process can be represented by areverse engineering cycle followed by a forward engineering cycle with an emphasis on as muchreuseas possiblefrom the existingcodeand otherdocuments. RELIABILITYGROWTHMODELS A reliability growth modelisa mathematicalmodelof how software reliability improvesaserrors are detected and repaired. A reliability growth model can be used to predict when (or if atall) a particular level of reliability is likely to be attained. Thus, reliability growth modeling canbe used to determine when to stop testing to attain a given reliability level. Although severaldifferent reliability growth models have been proposed, in this text we will discuss only two verysimplereliabilitygrowthmodels. Jelinski and Moranda Model -The simplest reliability growth model is a step function modelwhere it is assumed that the reliability increases by a constant increment each time an error isdetected and repaired. Such a model is shown in fig. 27.1. However, this simple model ofreliability which implicitly assumes that all errors contribute equally to reliability growth, ishighly unrealistic since it is already known that correction of different types of errors contributedifferentlyto reliabilitygrowth. 113 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) . Fig.27.1:Stepfunction modelofreliabilitygrowth Littlewood and Verall’s Model -This model allows for negative reliability growth to reflect thefact that when a repair is carried out, it may introduce additional errors. It also models the factthat as errors are repaired, the average improvement in reliability per repair decreases (Fig. 27.2).It treat’s an error’s contribution to reliability improvement to be an independent random variablehaving Gamma distribution. This distribution models the fact that error corrections with largecontributions to reliability growth are removed first. This represents diminishing return as testcontinues. Fig.27.2:Random-stepfunctionmodelofreliabilitygrowth StatisticalTesting Statistical testing is a testing process whose objective is to determine the reliability of softwareproducts rather than discovering errors. Test cases are designed for statistical testing with anentirelydifferent objectivethan thoseof conventional testing. 114 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Operation profile Different categories of users may use a software for different purposes. For example, a Librarianmightusethelibraryautomationsoftwaretocreatememberrecords,addbookstothelibrary,etc. whereas a library member might use to software to query about the availability of the book,or to issue and return books. Formally, the operation profile of a software can be defined as theprobability distribution of the input of an average user. If the input to a number of classes {Ci} isdivided, the probability value of a class represent the probability of an average user selecting hisnext input from this class. Thus, the operation profile assigns a probability value Pi to each inputclass Ci. Stepsin statisticaltesting Statistical testing allows one to concentrate on testing those parts of the system that are mostlikely to be used. The first step of statistical testing is to determine the operation profile of thesoftware. The next step is to generate a set of test data corresponding to the determined operationprofile.Thethirdstepistoapplythetestcasestothesoftwareandrecordthetimebetweeneach failure. After a statistically significant number of failures have been observed, the reliability canbecomputed. Advantagesanddisadvantagesofstatisticaltesting Statistical testing allows one to concentrate on testing parts of the system that are most likely tobe used. Therefore, it results in a system that the users to be more reliable (than actually it is!).Reliabilityestimationusingstatisticaltestingismoreaccuratecomparedtothoseofothermethods such as ROCOF, POFOD etc. But it is not easy to perform statistical testing properly.There is no simple and repeatable way of defining operation profiles. Also it is very muchcumbersome to generate test cases for statistical testing because the number of test cases withwhichthe system is to betested should bestatisticallysignificant. SOFTWAREMAINTENANCEPROCESSMODELS Two broad categories of process models for software maintenance can be proposed. The firstmodel is preferred for projects involving small reworks where the code is changed directly andthe changes are reflected in the relevant documents later. This maintenance process is graphicallypresented in fig. 25.1. In this approach, the project starts by gathering the requirements forchanges. The requirements are next analyzed to formulate the strategies to be adopted for codechange. At this stage, the association of at least a few members of the original development teamgoes a long way in reducing the cycle team, especially for projects involving unstructured andinadequately documented code. The availability of a working old system to the maintenanceengineers at the maintenance site greatly facilitates the task of the maintenance team 115 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) as they get agood insight into the working of the old system and also can compare the working of theirmodified systemwiththe oldsystem.Also,debugging of thereengineeredsystembecomeseasier as the programtraces of boththe systems canbecompared tolocalizethe bugs. Fig.25.1:Maintenanceprocessmodel1 116 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Thesecondprocessmodelforsoftwaremaintenanceispreferredforprojectswheretheamountof rework required issignificant.Thisapproachcan be represented by a reverse engineeringcycle followed by a forward engineering cycle. Such an approach is also known as softwarereengineering. This process model is depicted in fig. 25.2. The reverse engineering cycle isrequiredforlegacyproducts.Duringthereverseengineering,theoldcodeisanalyzed(abstracted) to extract the module specifications. The module specifications are then analyzed toproduce the design. The design is analyzed (abstracted) to produce the original requirementsspecification. The change requests are then applied to this requirements specification to arrive atthe new requirements specification. At the design, module specification, and coding a substantialreuse is made from the reverse engineered products. An important advantage of this approach isthat it produces a more structured design compared to what the original product had, producesgood documentation, and very often results in increased efficiency. The efficiency improvementsare brought about by a more efficient design. However, this approach is more costly than the firstapproach. An empirical study indicates that process 1 is preferable when the amount of rework isno more than 15%. Besides the amount of rework, several other factors might affect the decisionregardingusingprocessmodel 1 over process model 2:  Reengineeringmightbe preferable forproductswhichexhibitahighfailurerate.  Reengineering might also be preferable for legacy products having poor designandcodestructure. 117 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.25.2:Maintenanceprocessmodel2 SoftwareReengineering Software reengineering isa combination of two consecutive processesi.e. software reverseengineeringand softwareforward engineeringasshown inthe fig.25.2. Estimationofapproximatemaintenancecost It is well known that maintenance efforts require about 60% of the total life cycle cost for atypical software product. However, maintenance costs vary widely from one application domainto another. For embedded systems, the maintenance cost can be as much as 2 to 4 times thedevelopmentcost. Boehm[1981]proposedaformulaforestimatingmaintenancecostsaspartofhisCOCOMOcost estimation model.Boehm’smaintenancecost estimation is made in termsofaquantitycalled the Annual Change Traffic (ACT). Boehm defined ACT as the fraction of a softwareproduct’s source instructions which undergo change during a typical year either through additionordeletion. ACT= KLOCadded+KLOC deleted KLOCtotal where,KLOCaddedisthetotalkilolines ofsourcecodeaddedduringmaintenance. KLOCdeletedisthe total kilolines ofsourcecodedeletedduringmaintenance. Thus, the code that is changed, should be counted in both the code added and the code deleted.The annual change traffic (ACT) is multiplied with the total development cost to arrive at themaintenance cost: maintenance cost=ACT ×developmentcost. Most maintenance cost estimation models, however, yield only approximate results because theydo not take into account several factors such as experience level of the engineers, and familiarityofthe engineerswith the product, hardwarerequirements, softwarecomplexity, etc. 118 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 26 SOFTWARERELIABILITYANDQUALITYMANAGEMENT Repeatablevs.non-repeatablesoftwaredevelopmentorganization A repeatable softwaredevelopmentorganizationisone inwhichthesoftware developmentprocessisperson-independent.Inanonrepeatablesoftwaredevelopmentorganization,asoftwaredevelopmentprojectbecomessuccessfulpri marilyduetotheinitiative,effort,brilliance, or enthusiasm displayed by certain individuals. Thus, in a non-repeatable softwaredevelopment organization, the chances of successful completion of a software projectis to agreatextent depends on theteam members. SoftwareReliability Reliabilityofasoftwareproductessentiallydenotesitstrustworthinessordependability.Alternatively, reliability of a software product can also be defined as the probability of theproductworking“correctly”over a given period of time. Itisobviousthatasoftwareproducthavingalargenumberofdefectsisunreliable.Itisalsoclear that the reliability of a system improves, if the number of defects in it is reduced. However,there is no simple relationship between the observed system reliability and the number of latentdefects in the system. For example, removing errors from parts of a software which are rarelyexecutedmakeslittledifferencetotheperceivedreliabilityoftheproduct.Ithasbeenexperimentall y observed by analyzing the behavior of a large number of programs that 90% ofthe execution time of a typical program is spent in executing only 10% of the instructions in theprogram. These most used 10% instructions are often called the core of the program. The rest90% of the program statements are called non-core and are executed only for 10% of the totalexecution time.It therefore may not be very surprising to note that removing 60% productdefects from the least used parts of a system would typically lead to only 3% improvement to theproduct reliability. It 119 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) is clear that the quantity by which the overall reliability of a programimproves due to the correction of a single error depends on how frequently the correspondinginstructionisexecuted. Thus,reliability of a productdependsnotonly on the number of latenterrorsbutalsoon theexact location of the errors. Apart from this, reliability also depends upon how the product isused, i.e. on its execution profile. If it is selected input data to the system such that only the“correctly” implemented functions are executed, none of the errors will be exposed and theperceived reliability of the product will be high. On the other hand, if the input data is selectedsuch that only those functions which contain errors are invoked, the perceived reliability of thesystemwill be verylow. Reasonsforsoftwarereliabilitybeingdifficulttomeasure Thereasonswhysoftwarereliabilityisdifficulttomeasurecanbesummarizedasfollows:  Thereliabilityimprovementduetofixingasinglebugdependsonwherethebugislocatedin the code.  Theperceived reliabilityof asoftwareproduct ishighlyobserver-dependent.  Thereliabilityofaproduct keepschanging as errors aredetected and fixed.  Hardwarereliabilityvs. softwarereliabilitydiffers. Reliability behavior for hardware and software are very different. For example, hardware failuresare inherently differentfromsoftware failures.Mosthardware failuresare due tocomponentwear and tear. A logic gate may be stuck at 1 or 0, or a resistor might short circuit. To fixhardware faults, one has to either replace or repair the failed part. On the other hand, a softwareproduct would continue to fail until the error is tracked down and either the design or the code ischanged. For this reason, when a hardware is repaired its reliability is maintained at the level thatexisted before the failure occurred; whereas when a software failure is repaired, the reliabilitymay either increase or decrease (reliability may decrease if a bug introduces new errors). To putthis fact in a different perspective, hardware reliability study is concerned with stability (forexample, inter-failure times remain constant). On the other hand, software reliability study aimsat reliability growth (i.e. inter-failure times increase). The change of failure rate over the productlifetime for a typical hardware and a software product are sketched in fig. 26.1. For hardwareproducts,itcanbeobservedthatfailurerateishighinitiallybutdecreasesasthefaultycomponent s are identified and removed. The system then enters its useful life. After some time(called product life time) the components wear out, and the failure rate increases. This gives theplot of hardware reliability over time its characteristics “bath tub” shape. On the other hand, forsoftwarethefailurerateisatit’shighestduringintegrationandtest.Asthesystemistested,more and more errors are identified and removed resulting in reduced failure rate. This errorremovalcontinuesataslowerpaceduringtheusefullifeoftheproduct.Asthesoftwarebecomesobso 120 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) letenoerrorcorrections occursand thefailurerate remains unchanged. 121 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) (a) Hardwareproduct (b) Softwareproduct Fig.26.1: Changeinfailurerateofaproduct ReliabilityMetrics The reliability requirements for different categories of software products may be different. Forthis reason, it is necessary that the level of reliability required for a software product should bespecified in the SRS (software requirements specification) document. In order to be able to dothis, some metrics are needed to quantitatively express the reliability of a software product. Agood reliability measure should be observer-dependent, so that different people can agree on thedegree of reliability a system has. For example, there are precise techniques for measuringperformance, which would result in obtaining the same performance value irrespective 122 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) of who iscarrying out the performance measurement. However, in practice, it is very difficult to formulateaprecisereliabilitymeasurement technique. Thenext basecaseis to have measures that correlate 123 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) with reliability. There are six reliability metrics which can be used to quantify the reliability ofsoftwareproducts.  Rateofoccurrenceoffailure(ROCOF)-ROCOFmeasuresthefrequencyofoccurrence of unexpected behavior (i.e. failures). ROCOF measure of a software productcan be obtained by observing the behavior of a software product in operation over aspecifiedtimeintervalandthenrecordingthetotalnumberoffailuresoccurringduringtheinterv al.  MeanTimeToFailure(MTTF)-MTTFistheaveragetimebetweentwosuccessive failures, observed over a large number of failures. To measure MTTF, we can record thefailuredatafornfailures.Letthefailuresoccuratthetimeinstantst,t,…,t.Then, 1 2 MTTFcan becalculatedas n It is important to note that only run time is considered in the time measurements, i.e. thetime for which the system is down to fix the error, the boot time, etc are not taken intoaccountin the timemeasurements and theclockis stopped at thesetimes.  Mean Time To Repair (MTTR) - Once failure occurs, sometime is required to fix theerror. MTTR measures the average time it takes to track the errors causing the failure andto fixthem.  Mean Time Between Failure (MTBR) - MTTF and MTTR can be combined to get theMTBR metric: MTBF = MTTF + MTTR. Thus, MTBF of 300 hours indicates that once afailureoccurs,thenextfailureisexpectedafter300hours.Inthiscase,timemeasurementsarereal time and nottheexecution time as inMTTF.  Probability of Failure on Demand (POFOD) - Unlike the other metrics discussed, thismetricdoesnotexplicitlyinvolvetimemeasurements.POFODmeasuresthelikelihoodof the system failing when a service request is made. For example, a POFOD of 0.001wouldmean that 1 outofevery1000 servicerequestswould result in afailure.  Availability- Availability of a system is a measure of how likely shall the system beavailableforuseoveragivenperiodoftime.Thismetricnotonlyconsidersthenumberof failures occurring during a time interval, but also takes into account the repair time(down time) of a system when a failure occurs. This metric is important for systems suchas telecommunication systems, and operating systems, which are supposed to be neverdown and where repair and restart time are significant and loss of service during that timeis important. 124 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Classificationofsoftwarefailures Apossibleclassificationoffailuresofsoftwareproductsintofivedifferenttypesisasfollows:  Transient-Transientfailuresoccuronlyforcertaininputvalueswhileinvokingafunctionofthe system.  Permanent-Permanentfailuresoccurforallinputvalueswhileinvokingafunctionofthesystem.  RecoverableWhenrecoverablefailuresoccur,thesystemrecoverswithorwithoutoperatorintervention.  Unrecoverable-Inunrecoverable failures,thesystemmayneedtobe restarted.  Cosmetic- These classes of failures cause only minor irritations, and do not lead toincorrect results. An example of a cosmetic failure is the case where the mouse button hasto be clicked twice instead of once to invoke a given function through the graphical userinterface. 125 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) MODULE4 SOFTWAREQUALITY Traditionally, a quality product is defined in terms of its fitness of purpose. That is, a qualityproduct does exactly what the users want it to do. For software products, fitness of purpose isusually interpreted in terms of satisfaction of the requirements laid down in the SRS document.Although “fitness of purpose” is a satisfactory definition of quality for many products such as acar, a table fan, a grinding machine, etc. – for software products, “fitness of purpose” is not awholly satisfactory definition of quality. To give an example, consider a software product that isfunctionally correct. That is, it performs all functions as specified in the SRS document. But, hasanalmostunusableuserinterface.Eventhoughitmaybefunctionallycorrect,wecannotconsider it to be a quality product. Another example may be that of a product which doeseverything that the users want but has an almost incomprehensible and unmaintainable code.Therefore, the traditional concept of quality as “fitness of purpose” for software products is notwhollysatisfactory. The modern view of a quality associates with a software product several quality factors such asthefollowing:  Portability: A software product is said to be portable, if it can be easily made to work indifferentoperatingsystemenvironments,indifferentmachines,withothersoftwareproducts, etc.  Usability: A software product has good usability, if different categories of users (i.e. bothexpertand noviceusers)can easilyinvoke thefunctions of theproduct.  Reusability: A software product has good reusability, if different modules of the productcan easilybereusedto develop newproducts. 126 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book)  Correctness: A software product is correct, if different requirements as specified in theSRSdocument havebeen correctlyimplemented.  Maintainability: A software product is maintainable, if errors can be easily corrected asand when they show up, new functions can be easily added to the product, and thefunctionalitiesof theproduct can beeasilymodified, etc. SoftwareQualityManagementSystem A quality management system (often referred to as quality system) is the principal methodologyusedbyorganizations to ensurethatthe products theydevelop havethedesired quality. Qualitysystemconsistsofthefollowing: ManagerialStructureandIndividualResponsibilities-Aqualitysystemisactuallytheresponsibility of the organization as a whole. However, every organization has a separate qualitydepartment to perform several quality system activities. The quality system of an organizationshould have support of the top management. Without support for the quality system at a highlevelin acompany, few members ofstaff willtakethe qualitysystem seriously. QualitySystemActivities-Thequalitysystem activitiesencompass thefollowing: - auditingofprojects - reviewofthequalitysystem - developmentofstandards,procedures,and guidelines,etc. - productionofreportsforthetopmanagementsummarizingtheeffectivenessofthequalitys ystem in the organization. EvolutionofQualityManagementSystem Quality systems have rapidly evolved over the last five decades. Prior to World War II, the usualmethod to produce quality products was to inspect the finished products to eliminate defectiveproducts.Sincethattime,qualitysystemsoforganizationshaveundergonethroughfourstages of evolution as shown in the fig. 28.1. The initial product inspection method gave way to qualitycontrol(QC).Qualitycontrolfocusesnotonlyondetectingthedefectiveproductsandeliminating them but also on determining the causes behind the defects. Thus, quality controlaims at 127 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) correcting the causes of errors and not just rejecting the products. The next breakthroughinqualitysystems was thedevelopment of qualityassuranceprinciples. Thebasicpremiseofmodernqualityassuranceisthatifanorganization’sprocessesaregoodand are followed rigorously, then the products are bound to be of good quality. The modernquality paradigm includes guidance for recognizing, defining, analyzing, and improving theproduction process. Total quality management (TQM) advocates that the process followed by anorganization must be continuously improved through process measurements. TQM goes a stepfurther than quality assurance and aims at continuous process improvement. TQM goes beyonddocumenting processes to optimizing them through redesign. A term related to TQM is BusinessProcess Reengineering (BPR). BPR aims at reengineering the way business is carried out in anorganization. From the above discussion it can be stated that over the years the quality paradigmhasshifted from product assuranceto processassurance(as shownin fig. 28.1). 128 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.28.1:Evolution ofqualitysystemand correspondingshift inthequalityparadigm ISO9000certification ISO(InternationalStandardsOrganization)isaconsortiumof63countriesestablishedtoformulate and foster standardization. ISO published its 9000 series of standards in 1987. ISOcertificationservesasareferenceforcontractbetweenindependentparties.TheISO9000standard specifies the guidelines for maintaining a quality system. We have already seen that thequalitysystemofanorganizationappliestoallactivitiesrelatedtoitsproductorservice.TheISOstanda rdmainlyaddressesoperationalaspectsandorganizationalaspectssuchasresponsibilities, reporting, etc. In a nutshell, ISO 9000 specifies a set of guidelines for repeatableand high quality product development. It is important to realize that ISO 9000 standard is a set ofguidelines for theproduction process and is not directlyconcerned about theproduct itself. TypesofISO9000qualitystandards ISO 9000 is a series of three standards: ISO 9001, ISO 9002, and ISO 9003. The ISO 9000 seriesofstandardsisbasedonthepremisethatifaproperprocessisfollowedforproduction,thengood quality products are bound to follow automatically. The types of industries to which thedifferentISO standardsapplyareas follows. ISO 9001 applies to the organizations engaged in design, development, production, and servicingofgoods.This isthestandardthat isapplicable tomost softwaredevelopment organizations. ISO 9002 applies to those organizations which do not design products but are only involved inproduction. Examples of these category industries include steel and car manufacturing industriesthatbuytheproductandplantdesignsfromexternalsourcesandareinvolvedinonlymanufactu ring those products. Therefore, ISO 9002 is not applicable to software developmentorganizations. ISO9003appliestoorganizationsthatareinvolvedonly ininstallationandtestingoftheproducts. Softwareproductsvs.otherproducts Therearemainlytwodifferences between softwareproducts andanyothertypeof products.  Software is intangible in nature and therefore difficult to control. It is very difficult tocontrol and manage anything that is not seen. In contrast, any other industries such as 129 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) carmanufacturing industries where one can see a product being developed through variousstagessuchasfittingengine,fittingdoors,etc.Therefore,itiseasytoaccuratelydetermine how much work has been completed and to estimate how much more time willittake.  During software development, the only raw material consumed is data. In contrast, largequantitiesof raw materials areconsumedduringthedevelopment ofanyotherproduct. NeedforobtainingISO9000certification ThereisamadscrambleamongsoftwaredevelopmentorganizationsforobtainingISOcertification due to the benefits it offers. Some benefits that can be acquired to organizations byobtainingISO certification areasfollows:  Confidence of customers in an organization increaseswhenorganization qualifiesforISOcertification.Thisisespeciallytrueintheinternationalmarket.Infact,manyorga nizationsawardinginternationalsoftwaredevelopmentcontractsinsistthatthedevelopment organization have ISO 9000 certification. For this reason, it is vital forsoftwareorganizationsinvolvedin softwareexportto obtainISO9000certification.  ISO 9000 requires a well-documented software production process to be in place. A welldocumented software production process contributes to repeatable and higher quality ofthedeveloped software.  ISO9000makesthedevelopmentprocessfocused,efficient, andcost-effective.  ISO 9000 certification points out the weak points of an organization and recommendsremedialaction.  ISO 9000 sets the basic framework for the development of an optimal process and TotalQualityManagement (TQM). summaryofISO9001certification AsummaryofthemainrequirementsofISO9001astheyrelateofsoftwaredevelopmentisasfollows.Section numbers inbrackets correspond to thosein thestandard itself: ManagementResponsibility(4.1)  Themanagementmust haveaneffectivequalitypolicy.  The responsibility and authority of all those whose work affects quality must be definedanddocumented.  Amanagementrepresentative,independentofthedevelopmentprocess,mustberesponsible for the quality system. This requirement probably has been put down so thattheperson 130 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) responsibleforthequalitysystem canwork in an unbiasedmanner.  Theeffectiveness of thequalitysystem must be periodicallyreviewed byaudits. QualitySystem(4.2) Aqualitysystemmust bemaintainedand documented. ContractReviews(4.3) Beforeenteringintoacontract,anorganizationmustreviewthecontracttoensurethatitisunderstood,and that the organization has thenecessarycapabilityfor carryingout its obligations. DesignControl(4.4)  Thedesignprocessmustbeproperlycontrolled,thisincludescontrollingcodingalso.Thisrequir ementmeansthat a goodconfiguration controlsystemmust beinplace.  Designinputsmustbeverifiedasadequate.  Designmustbeverified.  Designoutputmustbeof requiredquality.  Design changesmustbecontrolled. DocumentControl(4.5)  Theremustbeproper proceduresfordocument approval,issueandremoval.  Documentchangesmustbecontrolled.Thus,useofsomeconfigurationmanagementtoolsis necessary. Purchasing(4.6) Purchasingmaterial,includingbought-insoftwaremustbecheckedforconformingtorequirements. PurchaserSuppliedProduct(4.7) Materialsuppliedbyapurchaser,forexample,clientprovidedsoftwaremustbeproperlymanagedandchecked. 131 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) ProductIdentification (4.8) The product must be identifiable at all stages of the process. In software terms this meansconfigurationmanagement. ProcessControl(4.9)  Thedevelopment must beproperlymanaged.  Qualityrequirement must be identifiedin a qualityplan. InspectionandTesting(4.10) In software terms this requires effective testing i.e., unit testing, integration testing and systemtesting.Test records must be maintained. Inspection,MeasuringandTestEquipment(4.11) If integration, measuring, and test equipments are used, they must be properly maintained andcalibrated. InspectionandTestStatus(4.12) Thestatusofanitemmustbeidentified.Insoftwaretermsthisimpliesconfigurationmanagementandrele asecontrol. ControlofNonconformingProduct(4.13) In software terms, this means keeping untested or faulty software out of the released product, orotherplaceswhetherit might causedamage. CorrectiveAction (4.14) This requirement is both about correcting errors when found, and also investigating why theerrors occurred and improving the process to prevent occurrences. If an error occurs despite thequalitysystem, thesystem needs improvement. Handling,(4.15) This clause deals with thestorage, packing, and deliveryof thesoftwareproduct. Qualityrecords(4.16) Recording the steps taken to control the quality of the process is essential in order to be able toconfirm that theyhaveactuallytaken place. QualityAudits(4.17) Auditsof thequalitysystemmust be carried out toensurethat it is effective. 132 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Training(4.18) Trainingneedsmust beidentified andmet. SalientfeaturesofISO9001certification ThesalientfeaturesofISO9001areasfollows:  All documents concerned with the development of a software product should be properlymanaged,authorized,andcontrolled.Thisrequiresaconfigurationmanagementsyste mtobe in place.  Properplansshouldbepreparedandthenprogressagainsttheseplansshouldbemonitored.  Important documents should be independently checked and reviewed for effectivenessandcorrectness.  Theproductshouldbetestedagainst specification.  Several organizational aspects should be addressed e.g., management reporting of thequalityteam. ShortcomingsofISO9000 certification Even though ISO 9000 aims at setting up an effective quality system in an organization, it suffersfrom several shortcomings. Some of these shortcomings of the ISO 9000 certification process arethefollowing:  ISO 9000 requires a software production process to be adhered to but does not guaranteethe process to be of high quality. It also does not give any guideline for defining anappropriateprocess.  ISO 9000 certification process is not fool-proof and no international accreditation agencyexists. Therefore it is likely that variations in the norms of awarding certificates can existamongthe different accreditationagenciesand alsoamongtheregistrars.  Organizations getting ISO 9000 certification often tend to downplay domain expertise.These organizations start to believe that since a good process is in place, any engineer isas effective as any other engineer in doing any particular activity relating to softwaredevelopment.However,many areasofsoftwaredevelopmentare sospecializedthatspecialexpertiseandexperienceintheseareas(domainexpertise)isrequired.I nmanufacturing industry there is a clear link between process quality and product 133 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) quality.Once a process is calibrated, it can be run again and again producing quality goods. Incontrast, software development is a creative process and individual skills and experienceareimportant.  ISO 9000 does not automatically lead to continuous process improvement, i.e. does notautomaticallylead to TQM. SEICAPABILITYMATURITY MODEL SEI Capability Maturity Model (SEI CMM) helped organizations to improve the quality of thesoftware they developandthereforeadoptionof SEI CMMmodelhassignificantbusinessbenefits. SEICMMcanbeusedtwoways:capabilityevaluationandsoftwareprocessassessment.Capability evaluation and software process assessment differ in motivation, objective, and thefinal use of the result. Capability evaluation provides a way to assess the software processcapability of an organization. The results of capability evaluation indicates the likely contractorperformance if the contractor is awarded a work. Therefore, the results of software processcapability assessment can be used to select a contractor. On the other hand, software processassessment is used by an organization with the objective to improve its process capability. Thus,thistypeof assessment is forpurelyinternal use. SEI CMM classifies software development industries into the following five maturity levels. Thedifferent levels of SEI CMM have been designed so that it is easy for an organization to slowlybuildits qualitysystem starting from scratch. Level 1: Initial - A software development organization at this level is characterized by ad hocactivities.Veryfewornoprocessesaredefinedandfollowed.Sincesoftwareproductionprocessesare notdefined,differentengineersfollowtheirownprocessandasaresultdevelopment efforts become chaotic. Therefore, it is also called chaotic level. The success ofprojects depends on individual efforts and heroics. When engineers leave, the successors havegreat difficulty in understanding the process followed and the work completed. Since formalproject management practices are not followed, under time pressure short cuts are tried outleadingto low quality. 134 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Level 2: Repeatable - At this level, the basic project management practices such as tracking costand schedule are established. Size and cost estimation techniques like function point analysis,COCOMO, etc. are used. The necessary process discipline is in place to repeat earlier success onprojects with similar applications. Please remember that opportunity to repeat a process existsonlywhenacompanyproduces a familyof products. Level 3: Defined - At this level the processes for both management and development activitiesare defined and documented. There is a common organization-wide understanding of activities,roles, and responsibilities. The processes thoughdefined, the process and product qualities arenotmeasured.ISO 9000aims at achievingthis level. Level 4: Managed - At this level, the focus is on software metrics. Two types of metrics arecollected. Product metrics measure the characteristics of the product being developed, such as itssize, reliability, time complexity, understandability, etc. Process metrics reflect the effectivenessof the process being used, such as average defect correction time, productivity, average numberof defectsfound per hour inspection,averagenumber offailures detected during testing perLOC, etc. Quantitative quality goals are set for the products. The software process and productquality are measured and quantitative quality requirements for the product are met. Various toolslike Pareto charts, fishbone diagrams, etc. are used to measure the product and process quality.The process metrics are used to check if a project performed satisfactorily. Thus, the results ofprocessmeasurementsareusedto evaluateprojectperformanceratherthanimprovetheprocess. Level 5: Optimizing - At this stage, process and product metrics are collected. Process andproduct measurement data are analyzed for continuous process improvement. For example, iffrom an analysis of the process measurement results, it was found that the code reviews were notvery effective and a large number of errors were detected only during the unit testing, then theprocess may be fine-tuned to make the review more effective. Also, the lessons learned fromspecific projects are incorporated in to the process. Continuous process improvement is achievedboth by carefully analyzing the quantitative feedback from the process measurements and alsofrom application of innovative ideas and technologies. Such an organization identifies the bestsoftware engineering practicesand innovationswhich may be tools,methods, or processes.Thesebest practicesaretransferredthroughout theorganization. Keyprocessareas(KPA)of asoftwareorganization Except for SEI CMM level 1, each maturity level is characterized by several Key Process Areas(KPAs) that includes the areas an organization should focus to improve its software processtothe next level. The focus of each level and the corresponding key process areas are 135 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) shown in thefig.29.1. 136 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) CMMLevel 1.Initial 2.Repeatable 3.Defined Focus Competentpeople Projectmanagement Definitionofprocesses KeyProcessAres Softwareprojectplanning Softwareconfigurationmanagement Processdefinition Training programPeerrevi ews 4.Managed 5.Optimizing Product and process quality Continuousprocess improvement Quantitativeprocessmetrics Softwarequalitymanagement Defectprevention Process change managementTechnologychange management Fig.29.1: Thefocus of eachSEICMM levelandthe correspondingkeyprocess areas SEICMMprovidesalistofkeyareasonwhichtofocustotakeanorganizationfromonelevelof maturity to the next. Thus, it provides a way for gradual quality improvement over severalstages.Eachstage hasbeen carefully designedsuch that one stage enhances the capabilityalready built up. For example, it considers that trying to implement a defined process (SEI CMMlevel3)beforearepeatableprocess(SEI CMMlevel2)wouldbecounterproductiveasitbecomes difficult to follow the defined process due to schedule and budget pressures. ISO 9000certificationvs. SEI/CMM For quality appraisal of a software development organization, the characteristics of ISO 9000certificationand theSEICMM differin some respects.The differencesareas follows:  ISO9000isawardedbyaninternationalstandardsbody.Therefore,ISO9000certification can be quoted by an organization in official documents, communication withexternal parties, and the tender quotations. However, SEI CMM assessment is purely forinternaluse.  SEI CMM was developed specifically for software industry and therefore addresses manyissueswhich arespecificto softwareindustryalone.  SEI CMM goes beyond quality assurance and prepares an organization to ultimatelyachieve Total Quality Management (TQM). In fact, ISO 9001 aims at level 3 of SEICMM model.  SEI CMM model provides a list of key process areas (KPAs) on which an organization atany maturity level needs to concentrate to take it from one maturity level to the next.Thus, it provides awayforachievinggradual qualityimprovement. 137 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 138 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Applicabilityof SEICMMtoorganizations Highly systematic and measured approach to software development suits large organizationsdealing with negotiated software, safety-critical software, etc. For those large organizations, SEICMMmodelisperfectlyapplicable.ButsmallorganizationstypicallyhandleapplicationssuchasInt ernet,e-commerce,andarewithoutanestablishedproductrange,revenuebase,andexperience on past projects, etc. For such organizations, a CMM-based appraisal is probablyexcessive. These organizations need to operate more efficiently at the lower levels of maturity.Forexample,theyneedtopracticeeffectiveprojectmanagement,reviews,configurationmana gement,etc. PersonalSoftwareProcess Personal Software Process (PSP) is a scaled down version of the industrial software process. PSPis suitable for individual use. It is important to note that SEI CMM doesnot tell softwaredevelopers how to analyze, design, code, test, or document software products, but assumes thatengineers use effective personal practices. PSP recognizes that the process for individual use isdifferentfrom that necessaryforateam. Thequalityandproductivityofanengineeristoagreatextentdependentonhisprocess.PSPisaframework thathelpsengineerstomeasureandimprovetheway they work.Ithelpsindeveloping personal skills and methods by estimating and planning, by showing how to trackperformance againstplans, andprovides adefinedprocesswhichcanbetunedbyindividuals. TimemeasurementPSPadvocatesthatengineersshouldrackthewaytheyspendtime.Because,boringactivitiesseemlongert hanactualandinterestingactivitiesseemshort.Therefore, the actual time spent on a task should be measured with the help of a stop-clock to getan objective picture of the time spent. For example, he may stop the clock when attending atelephone call, taking a coffee break etc. An engineer should measure the time he spends fordesigning,writingcode, testing, etc. PSP Planning- Individuals must plan their project. They must estimate the maximum, minimum,andtheaverageLOCrequiredfortheproduct.Theyshouldusetheirproductivityinminutes/L OC to calculate the maximum, minimum, and the average development time. Theymustrecord the plan dataina project plan summary. The PSP is schematically shown in fig. 29.2. While carrying out the different phases, they mustrecord the log data using time measurement. During post-mortem, they can compare the log datawith their project plan to achieve better planning in the future projects, to improve their process,etc. 139 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.29.2:SchematicrepresentationofPSP ThePSPlevelsaresummarizedinfig.29.3. 140 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.29.3:LevelsofPSP PSP2 introduces defect management via the use of checklists for code and design reviews. Thechecklistsaredevelopedfrom gatheringandanalyzingdefect dataearlierprojects. SixSigma The purpose of Six Sigma is to improve processes to do things better, faster, and at lower cost. Itcan be used to improve every facet of business, from production, to human resources, to orderentry, to technical support. Six Sigma can be used for any activity that is concerned with cost,timeliness,and qualityofresults. Therefore,it is applicable to virtuallyeveryindustry. Six Sigma at many organizations simply means striving for near perfection. Six Sigma is adisciplined, data-driven approach to eliminate defects in any process – from manufacturing totransactionaland productto service. The statistical representation of Six Sigma describes quantitatively how a process is performing.ToachieveSixSigma,aprocessmustnotproducemorethan3.4defectspermillionopportuni ties. A Six Sigma defect is defined as any system behavior that is not as per customerspecifications. Total number of Six Sigma opportunities is then the total number of chances for adefect.Process sigma can easilybecalculated usingaSixSigmacalculator. ThefundamentalobjectiveoftheSixSigmamethodologyistheimplementationofameasurementbasedstrategythatfocusesonprocessimprovementandvariationreductionthroughtheapplicationofSix Sigmaimprovementprojects.ThisisaccomplishedthroughtheuseoftwoSix Sigmasubmethodologies:DMAICandDMADV.TheSixSigmaDMAICprocess (define, measure, analyze, improve, control) is an improvement system for existingprocesses failing below specification and looking for incremental improvement. The Six SigmaDMADV process (define, measure, analyze, design, verify) is an improvement system used todevelop new processes or products at Six Sigma quality levels. It can also be employed if acurrent process requires more than just incremental improvement. Both Six Sigma processes areexecuted by Six Sigma Green Belts and Six Sigma Black Belts, and are overseen by Six SigmaMasterBlackBelts. Many frameworks exist for implementing the Six Sigma methodology. Six Sigma Software Engineering Keerthana P, Manasa KN, Ganga D Bengal 141

ISBN : 978-81-963532-2-3 (E-Book) Consultantsall over the world have also developed proprietary methodologies for implementing Six Sigmaquality,basedon thesimilarchangemanagementphilosophies andapplicationsof tools. 142 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) SOFTWAREPROJECTPLANNING Project Planning and Project Estimation TechniquesResponsibilitiesofasoftwareproject manager Software project managers take the overall responsibility of steering a project to success. It isvery difficulttoobjectively describe the jobresponsibilitiesofa projectmanager. The jobresponsibility of a project manager ranges from invisible activities like building up team moraleto highly visible customer presentations. Most managers take responsibility for project proposalwriting, project cost estimation, scheduling, project staffing, software process tailoring, projectmonitoring and control, software configuration management, risk management, interfacing withclients, managerial report writing and presentations, etc. These activities are certainly numerous,varied and difficult to enumerate, but these activities can be broadly classified into projectplanning,andprojectmonitoringandcontrolactivities.Theprojectplanningactivityisundertake nbeforethedevelopmentstartstoplantheactivitiestobeundertakenduringdevelopment. The project monitoring and control activities are undertaken once the developmentactivities start with the aim of ensuring that the development proceeds as per plan and changingtheplan whenever required to copeup withthe situation. Skillsnecessaryforsoftwareprojectmanagement A theoretical knowledge of different project management techniques is certainly necessary tobecomeasuccessfulprojectmanager.However,effectivesoftwareprojectmanagementfrequently calls for good qualitative judgment and decision taking capabilities. In addition tohavingagoodgraspofthelatestsoftwareprojectmanagementtechniquessuchascostestimation,riskm anagement,configurationmanagement,projectmanagersneedgoodcommunication skills and the ability get work done. However, some skills such as tracking andcontrolling the progress of the project, customer interaction, managerial presentations, and teambuildingarelargelyacquiredthroughexperience.Nonetheless,theimportanceofsoundknowledge of theprevalent project managementtechniques cannot be overemphasized. ProjectPlanning Once a project is found to be feasible, software project managers undertake project planning.Projectplanningisundertakenandcompletedevenbeforeanydevelopmentactivitystarts.Proj 143 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) ectplanning consists of thefollowingessential activities:  Estimatingthefollowingattributesofthe project:  Project size: What will be problem complexity in terms of the effort and timerequiredto develop theproduct?  Cost:Howmuch isit goingtocost todevelop the project?  Duration:How longisit goingto taketo completedevelopment?  Effort:Howmucheffort wouldberequired? Theeffectivenessofthesubsequentplanningactivitiesisbasedontheaccuracyoftheseestimatio ns.  Schedulingmanpowerandotherresources.  Stafforganizationandstaffingplans.  Riskidentification,analysis,andabatementplanning  Miscellaneousplanssuch asqualityassuranceplan,configurationmanagementplan,etc. Precedenceorderingamongprojectplanningactivities Differentprojectrelatedestimatesdonebyaprojectmanagerhavealreadybeendiscussed.Fig. 30.1 shows the order inwhich important projectplanning activitiesmay be undertaken.Fromfig. 30.1 it can be easily observed that size estimation is the first activity. It is also the mostfundamentalparameterbasedonwhichallotherplanningactivitiesarecarriedout.Otherestimation ssuchasestimationofeffort,cost,resource,andprojectdurationarealsoveryimportantcomponents of project planning. 144 Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.30.1: Precedenceorderingamongplanningactivities SlidingWindowPlanning Project planning requires utmost care and attention since commitment to unrealistic time andresourceestimatesresultinscheduleslippage.Scheduledelayscancausecustomerdissatisfactionan dadverselyaffectteammorale.Itcanevencauseprojectfailure.However, project planning is a very challenging activity. Especially for large projects, it is very muchdifficult to make accurate plans. A part of this difficulty is due to the fact that the properparameters, scope of the project, project staff, etc. may change during the span of the project. Inorder to overcome this problem, sometimes projectmanagers undertake project planning instages.Planningaprojectoveranumberofstagesprotectsmanagersfrommakingbigcommitments too early. This technique of staggered planning is known as Sliding WindowPlanning. In the sliding window technique, starting with an initial plan, the project is plannedmore accurately in successive development stages. At the start of a project, project managershave incomplete knowledge about the details of the project. Their information base graduallyimproves as the project progresses through different phases. After the completion of every phase,the project managers can plan each subsequent phase more accurately and with increasing levelsofconfidence. SoftwareProjectManagementPlan(SPMP) Once project planning is complete, project managers document their plans in a Software ProjectManagement Plan (SPMP) document. The SPMP document should discuss a list of differentitems that have been discussed below. This list can be used as a possible organization of theSPMP document. OrganizationoftheSoftwareProjectManagementPlan(SPMP)Document 1. Introduction (a) Objectives (b) MajorFunctions (c) PerformanceIssues (d) ManagementandTechnicalConstraints 2. ProjectEstimates (a) HistoricalDataUsed (b) EstimationTechniquesUsed 145 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) (c) Effort,Resource,Cost,and ProjectDurationEstimates 3. Schedule (a) WorkBreakdownStructure (b) TaskNetworkRepresentation (c) GanttChartRepresentation (d) PERTChartRepresentation 4. ProjectResources (a) People (b) Hardwareand Software (c) SpecialResources 5. StaffOrganization (a) TeamStructure (b) ManagementReporting 6. RiskManagementPlan (a) RiskAnalysis (b) RiskIdentification (c) Risk Estimation (d) RiskAbatementProcedures 7. ProjectTrackingandControlPlan 8. MiscellaneousPlans (a) ProcessTailoring (b) QualityAssurance Plan (c) ConfigurationManagementPlan (d) ValidationandVerification 146 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) (e) SystemTestingPlan (f) Delivery, Installation, andMaintenancePlan METRICSFORSOFTWAREPROJECTSIZEESTIMATION Accurate estimation of the problem size is fundamental to satisfactory estimation of effort, timeduration and cost of a software project. In order to be able to accurately estimate the project size,some important metrics should be defined in terms of which the project size can be expressed.The size of a problem is obviously not the number of bytes that the source code occupies. It isneither the byte size of the executable code. The project size is a measure of the problemcomplexityin terms oftheeffort and time requiredto develop theproduct. Currently two metrics are popularly being used widely to estimate size: lines of code (LOC) andfunction point (FP). The usage of each of these metrics in project size estimation has its ownadvantagesand disadvantages. LinesofCode(LOC) 147 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) LOC is the simplest among all metrics available to estimate project size. This metric is verypopular because it is the simplest to use. Using this metric, the project size is estimated bycounting the number of source instructions in the developed program. Obviously, while countingthenumberofsourceinstructions,linesusedforcommentingthecodeandtheheaderlinesshould beignored. Determining the LOC count at the end of a project is a very simple job. However, accurateestimationoftheLOCcountatthebeginningofaprojectisverydifficult.Inordertoestimatethe LOC count at the beginning of a project, project managers usually divide the problem intomodules, and each module into submodules and so on, until the sizes of the different leaflevelmodules can be approximately predicted. To be able to do this, past experience in developingsimilarproductsishelpful.Byusingtheestimationofthelowestlevelmodules,projectmanag ers arriveat thetotal sizeestimation. Functionpoint(FP) Function point metric was proposed by Albrecht [1983]. This metric overcomes many of theshortcomings of the LOC metric. Since its inception in late 1970s, function point metric has beenslowly gaining popularity. One of the important advantages of using the function point metric isthat it can be used to easily estimate the size of a software product directly from the problemspecification. This is in contrast to the LOC metric, where the size can be accurately determinedonly after the product has fully been developed. The conceptual idea behind the function pointmetric is that the size of a software product is directly dependent on the number of differentfunctions or features it supports. A software product supporting many features would certainly beoflargersizethanaproductwithlessnumberoffeatures.Eachfunctionwheninvokedreads some input data and transforms it to the corresponding output data. For example, the issue bookfeature (as shown in fig. 31.1) of a Library Automation Software takes the name of the book asinput and displays its location and the number of copies available. Thus, a computation of thenumber of input and the output data values to a system gives some indication of the number offunctions supported by the system. Albrecht postulated that in addition to the number of basicfunctions that a software performs, the size is also dependent on the number of files and thenumberof interfaces. 148 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.31.1: Systemfunction asa mapof inputdatatooutput data Besides using the number ofinput and output data values,function point metric computesthesize of a software product (in units of functions points or FPs) using three other characteristics ofthe product as shown in the following expression. The size of a product in function points (FP)canbeexpressedastheweightedsumofthesefiveproblemcharacteristics.Theweightsassociatedwi ththefivecharacteristicswereproposedempiricallyandvalidatedbytheobservations over many projects. Function point is computed in two steps. The first step is tocomputethe unadjusted function point (UFP). UFP=(Numberofinputs)*4+(Numberofoutputs)*5+(Numberofinquiries)*4+(Numberoffi les)*10+ (Numberofinterfaces)*10 Numberofinputs:Eachdataiteminputbytheuseriscounted.Datainputsshouldbedistinguishedfromus erinquiries.Inquiriesareusercommandssuchasprint-account-balance. Inquiries are counted separately. It must be noted that individual data items input by the user arenot considered in the calculation of the number of inputs, but a group of related inputs 149 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) areconsidered as a single input. For example, while entering the data concerning an employee to anemployee pay roll software; the data items name, age, sex, address, phone number, etc. aretogether considered as a single input. All these data items can be considered to be related, sincetheypertain to asingle employee. Numberofoutputs:Theoutputsconsideredrefertoreportsprinted,screenoutputs,errormessages produced, etc. While outputting the number of outputs the individual data items withinareportarenot considered, but a set ofrelated dataitems is counted as oneinput. Number of inquiries: Number of inquiries is the number of distinct interactive queries whichcan be made by the users. These inquiries are the user commands which require specific actionbythe system. Number of files: Each logical file is counted. A logical file means groups of logically relateddata.Thus, logical files can bedata structures or physicalfiles. Numberofinterfaces:Heretheinterfacesconsideredaretheinterfacesusedtoexchangeinformationwit hother systems.Examplesof suchinterfacesare datafiles ontapes,disks,communicationlinks with othersystems etc. Once the unadjusted function point (UFP) is computed, the technical complexity factor (TCF) iscomputed next. TCF refines the UFP measure by considering fourteen other factors such as hightransaction rates, throughput, and response time requirements, etc. Each of these 14 factors isassigned from 0 (not present or no influence) to 6 (strong influence). The resulting numbers aresummed, yielding the total degree of influence (DI). Now, TCF is computed as (0.65+0.01*DI).AsDIcan varyfrom 0 to 70, TCFcan varyfrom 0.65 to1.35. Finally,FP=UFP*TCF. Shortcomingsoffunctionpoint(FP)metric LOCasameasureofproblemsizehasseveralshortcomings:  LOC gives a numerical value of problem size that can vary widely with individual codingstyle – different programmers lay out their code in different ways. For example, oneprogrammer might write several source instructions on a single line whereas anothermight split a single instruction across several lines. Of course, this problem can be easilyovercome by counting the language tokens in the program rather than the lines of code.However, a more intricate problem arises because the length of a program depends on thechoice of instructions used in writing the program. Therefore, even for the same problem,different programmers might come up with programs having different LOC 150 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) counts. Thissituationdoesnot improveevenif languagetokensarecountedinstead oflines ofcode.  A good problem size measure should consider the overall complexity of the problem andthe effort needed to solve it. That is, it should consider the local effort needed to specify,design, code, test, etc. and not just the coding effort. LOC, however, focuses on thecoding activity alone; it merely computes the number of source lines in the final program.Wehavealreadyseenthatcodingisonlyasmallpartoftheoverallsoftwaredevelopment activities. It is also wrong to argue that the overall product developmenteffort is proportional to the effort required in writing the program code. This is becauseeven though the design might be very complex, the code might be straightforward andviceversa.In suchcases,codesizeis a grosslyimproper indicator of theproblemsize.  LOC measure correlates poorly with the quality and efficiency of the code. Larger codesize does not necessarily imply better quality or higher efficiency. Some programmersproduce lengthy and complicated code as they do not make effective use of the availableinstruction set.In fact,itisvery likely that a poor and sloppily writtenpiece ofcodemighthavelarger numberofsourceinstructions thanapiecethat isneat andefficient.  LOC metric penalizes use of higher-level programming languages, code reuse, etc. Theparadox is that if a programmer consciously uses several library routines, then the LOCcount will be lower. This would show up as smaller program size. Thus, if managers usetheLOCcountasameasureoftheeffortputinthedifferentengineers(thatis,productivity),the ywould bediscouragingcodereuse byengineers.  LOC metric measures the lexical complexity of a program and does not address the moreimportant but subtle issues of logical or structural complexities. Between two programswith equal LOC count, a program having complex logic would require much more effortto develop than a program with very simple logic. To realize why this is so, consider theeffort required to develop a program having multiple nested loop and decision constructswithanother program havingonlysequential control flow.  It is very difficult to accurately estimate LOC in the final product from the problemspecification. The LOC count can be accurately computed only after the code has beenfully developed. Therefore, the LOC metric is little use to the project managers duringprojectplanning,sinceprojectplanning iscarried outevenbefore any developmentactivity has started. This possibly is the biggest shortcoming of the LOC metric from theprojectmanager’sperspective. FeaturePointMetric 151 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) A major shortcoming of the function point measure is that it does not take into account thealgorithmic complexity of a software. That is, the function point metric implicitly assumes thatthe effort required to design and develop any two functionalities of the system is the same. But,we know that this is normally not true, the effort required to develop any two functionalities mayvarywidely.Itonlytakesthenumberoffunctionsthatthesystemsupportsintoconsideration without distinguishing the difficulty level of developing the various functionalities. To overcomethisproblem,an extensionofthefunctionpointmetric calledfeaturepointmetricisproposed. Featurepointmetricincorporatesanextraparameteralgorithmcomplexity.Thisparameterensures that the computed size using the feature point metric reflects the fact that the more is thecomplexity of a function, the greater is the effort required to develop it and therefore its sizeshouldbelargercompared to simplerfunctions. ProjectEstimationTechniques Estimation of various project parameters is a basic project planning activity. The importantprojectparametersthatareestimatedinclude:projectsize,effortrequiredtodevelopthesoftwa re, project duration, and cost. These estimates not only help in quoting the project cost tothe customer, but are also useful in resource planning and scheduling. There are three broadcategoriesof estimation techniques: • Empiricalestimationtechniques • Heuristictechniques • Analyticalestimationtechniques EmpiricalEstimationTechniques Empirical estimation techniques are based on making an educated guess of the projectparameters. While using this technique, prior experience with development of similarproducts is helpful. Althoughempirical estimation techniques are based on commonsense, differentactivities involved inestimation have been formalizedover theyears.Twopopularempiricalestimationtechniquesare:ExpertjudgmenttechniqueandDel phicost estimation. 152 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) ExpertJudgmentTechnique Expert judgment is one of the most widely used estimation techniques. In this approach,an expert makes an educated guess of the problem size after analyzing the problemthoroughly.Usually,theexpertestimatesthecostofthedifferentcomponents(i.e.modu les or subsystems) of the system and then combines them to arrive at the overallestimate. However, this technique is subject to human errors and individual bias. Also, itis possible that the expert may overlook some factors inadvertently. Further, an expertmaking an estimate may not have experience and knowledge of all aspects of a project.For example, he may be conversant with the database and user interface parts but may notbeveryknowledgeableabout thecomputer communication part. A more refined form of expert judgment is the estimation made by group of experts.Estimation by a group of experts minimizes factors such as individual oversight, lack offamiliarity with a particular aspect of a project, personal bias, and the desire to wincontractthroughoverlyoptimisticestimates.However,theestimatemadebyagroupof experts may still exhibit bias on issues where the entire group of experts may be biaseddue to reasons such as political considerations. Also, the decision made by the group maybedominated byoverlyassertivemembers. DelphiCostEstimation Delphi cost estimation approach tries to overcome some of the shortcomings of the expertjudgment approach. Delphi estimation is carried out by a team comprising of a group ofexpertsandacoordinator.Inthisapproach,thecoordinatorprovideseachestimatorwithacopy ofthesoftwarerequirementsspecification(SRS)documentandaformforrecording his cost estimate. Estimators complete their individual estimates anonymouslyand submit to the coordinator. In their estimates, the estimators mention any unusualcharacteristicoftheproductwhichhasinfluencedhisestimation.Thecoordinatorprepar es and distributes the summary of the responses of all the estimators, and includesanyunusualrationalenotedbyanyoftheestimators.Basedonthissummary,theestimato rsre-estimate.Thisprocessisiteratedforseveralrounds.However,nodiscussion among the estimators is allowed during the entire estimation process. The ideabehindthisisthatifanydiscussionisallowedamongtheestimators,thenmanyestimators may easily get influenced by the rationale of an estimator who may be 153 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) moreexperiencedorsenior.Afterthecompletionofseveraliterationsofestimations,thecoordina tortakestheresponsibility ofcompilingtheresultsandpreparingthefinalestimate. HEURISTICTECHNIQUES Heuristic techniques assume that the relationships among the different project parameters can bemodeled using suitable mathematical expressions. Once the basic (independent) parameters areknown,theother(dependent)parameterscanbeeasilydeterminedbysubstitutingthevalueofthebasic parametersinthemathematicalexpression.Differentheuristicestimationmodelscanbedividedinto thefollowingtwoclasses:singlevariablemodel andthemulti variablemodel. Single variable estimation models provide a means to estimate the desired characteristics of aproblem, using some previously estimated basic (independent) characteristic of the softwareproductsuch asits size.A single variable estimation modeltakes the followingform: d EstimatedParameter =c *e 1 1 154 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) In the above expression, e is the characteristic of the software which has already been estimated(independent variable). Estimated Parameter is the dependent parameter to be estimated. Thedependentparametertobeestimatedcouldbeeffort, projectduration,staffsize,etc. canddare 1 constants.Thevaluesoftheconstantscanddareusuallydeterminedusingdatacollectedfrom 1 1 past projects (historical data). The basic COCOMO model is an example of single variable costestimationmodel. Amultivariablecostestimationmodel takesthefollowingform: d d EstimatedResource=c*e + c*e …… 1 155 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 1 11 1 2 2 22 Wheree, e,…arethebasic(independent) characteristicsofthe software alreadyestimated,and c,c,d,d,…areconstants.Multivariableestimationmodelsareexpectedtogivemore 1 2 1 2 accurate estimates compared to the single variable models, since a project parameter is typicallyinfluencedbyseveralindependentparameters.Theindependentparametersinfluencethedepe ndentparametertodifferentextents.Thisismodeledbytheconstantsc,c,d,d,…. 1 2 1 2 Valuesoftheseconstantsareusuallydeterminedfromhistoricaldata.TheintermediateCOCOMOmode l canbeconsideredto be an exampleof amultivariable estimationmodel. AnalyticalEstimationTechniques Analyticalestimationtechniquesderivetherequiredresultsstarting withbasicassumptionsregarding the project. Thus, unlike empirical and heuristic techniques, analytical techniques dohave scientific basis. Halstead’s software science is an example of an analytical technique.Halstead’ssoftwaresciencecanbeusedtoderivesomeinterestingresultsstartingwithafew simple assumptions. Halstead’s software science is especially useful for estimating softwaremaintenance efforts.Infact, it outperforms bothempirical and heuristic techniques when usedforpredictingsoftwaremaintenanceefforts. Halstead’sSoftwareScience–AnAnalyticalTechnique Halstead’s software science is an analytical technique to measure size, development effort, anddevelopment cost of software products. Halstead used a few primitive program parameters todevelop the expressions for overall program length, potential minimum value, actual volume,effort,and development time. Fora givenprogram,let:  ηbethe numberofuniqueoperators usedinthe program, 1  ηbethe numberofuniqueoperands usedin theprogram,  Nbethe totalnumberofoperators usedin theprogram,  Nbethe totalnumberofoperands usedin theprogram. 2 1 2 LengthandVocabulary ThelengthofaprogramasdefinedbyHalstead,quantifiestotalusageofalloperatorsandoperandsintheprogr am.Thus,lengthN=N+N.Halstead’sdefinitionofthelengthofthe 1 2 programasthetotalnumberofoperatorsandoperandsroughlyagreeswiththeintuitivenotationofthe program lengthasthe total numberoftokens used in theprogram. Theprogramvocabularyisthenumberofuniqueoperatorsandoperandsusedintheprogram. Thus,program vocabulary η=η+η. 156 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 1 2 ProgramVolume The length of a program (i.e. the total number of operators and operands used in the code)dependsonthechoiceoftheoperatorsandoperandsused.Inotherwords,forthesameprogramming problem,thelengthwoulddependontheprogrammingstyle.Thistypeofdependency would produce different measures of length for essentially the same problem whendifferentprogramminglanguagesareused.Thus,whileexpressingprogramsize,theprogramming languageused must be taken intoconsideration: V =Nlogη 2 Here the program volume V is the minimum number of bits needed to encode the program. Infact,torepresentηdifferentidentifiersuniquely,atleastlogηbits(whereηistheprogram 2 vocabulary)willbeneeded.Inthisscheme,Nlogηbitswillbeneededtostoreaprogramof 2 lengthN.Therefore,thevolumeVrepresentsthesizeoftheprogrambyapproximatelycompensatingfort heeffect of theprogramminglanguageused. PotentialMinimumVolume The potential minimum volume V* is defined as the volume of most succinct program in which aproblem can be coded. The minimum volume is obtained when the program can be expressedusing a single source code instruction. say a function call like foo( ) ;. In other words, the volumeis bound from below due to the fact that a program would have at least two operators and no lessthantherequisite numberof operands. Thus,ifanalgorithmoperatesoninputandoutputdatad,d,…d,themostsuccinctprogram wouldbef(d, d, … d);forwhich η=2, η=n. Therefore,V*=(2+η)log(2+η). 1 2 1 2 n 1 2 n 2 2 2 The program level L is given by L = V*/V. The concept of program level L is introduced in anattempt to measure the level of abstraction provided by the programming language. Using thisdefinition,languages canberanked into levels thatalso appear intuitivelycorrect. The above result implies that the higher the level of a language, the less effort it takes to 157 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) developaprogramusingthatlanguage.Thisresultagreeswiththeintuitivenotionthatittakesmoreeffort to develop a program in assembly language than to develop a program in a high-levellanguageto solve aproblem. EffortandTime The effort required to develop a program can be obtained by dividing the program volume withtheleveloftheprogramminglanguageusedtodevelopthecode.Thus,effortE=V/L,whereEis the number of mental discriminations required to implement the program and also the effortrequired to read and understand the program. Thus, the programming effort E = V²/V* (since L =V*/V) varies as the square of the volume. Experience shows that E is well correlated to the effortneededfor maintenanceofan existingprogram. The programmer’s time T = E/S, where Sthe speed of mentaldiscriminations.The value of Shas been empirically developed from psychological reasoning, and its recommended value forprogrammingapplications is 18. LengthEstimation Even though the length of a program can be found by calculating the total number of operatorsand operands in a program, Halstead suggests a way to determine the length of a program usingthe number of unique operators and operands used in the program. Using this method, theprogram parameters such as length, volume, cost, effort, etc. can be determined even before thestartofanyprogramming activity. His method issummarized below. Halstead assumed that it is quite unlikely that a program has several identical parts – in formallanguageterminology any program of length N consists identicalsubstrings– oflengthgreaterthanη(ηbeingtheprogramvocabulary). In fact, once a piece of code occurs identically at several places, it is made into aprocedure or a function. Thus, it can be assumed that ηuniquestringsoflengthη.Now,itisstandardcombinatorialresultthatforany givenalphabetof r 158 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal of N/

ISBN : 978-81-963532-2-3 (E-Book) sizeK, thereareexactlyKdifferentstrings of length r. Thus. η N/η≤η Or,N≤η Sinceoperatorsandoperandsusuallyalternateinaprogram,theupperboundcanbefurther η1 η2 refinedintoN≤ηη 1 η .Also,Nmustincludenotonlytheorderedsetofnelements,butit 2 shouldalsoincludeallpossiblesubsetsofthatorderedsets,i.e.thepowersetofNstrings(Thisparticularrea soningof Halstead is not veryconvincing!!!). Therefore, N Or,takinglogarithm onbothsides, η1 η2 N=logη+log 2 Soweget, η1 η2 N=log Or, N =logη η1 + logη η2 (η η ) 2 1 2 (approximately,byignoring logη) 2 (η η ) 2 1 2 η1 η2 2= η η η 1 2 η+1 159 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 2 1 1 2 1 22 = ηlogη+ ηlogη 2 22 Experimental evidence gathered from the analysis of larger number of programs suggests that thecomputed and actual lengths match very closely. However, the results may be inaccurate whensmallprograms when considered individually. In conclusion, Halstead’s theory tries to provide a formal definition and quantification of suchqualitative attributes as program complexity, ease of understanding, and the level of abstractionbasedonsomelowlevelparameterssuchasthenumberofoperands,andoperatorsappearingin theprogram.Halstead’ssoftwarescienceprovidesgrossestimationofpropertiesofalargecollectionofsoftw are, but extendsto individual cases ratherinaccurately. Example: LetusconsiderthefollowingCprogram: main() { inta, b, c, avg; scanf(“%d%d%d”,&a,&b,&c);av g= (a+b+c)/3; printf(“avg=%d”, avg); } Theunique operators are: main,(),{},int,scanf,&,“,”,“;”,=,+,/,printf Theuniqueoperandsare: a, b, c, &a, &b, &c, a+b+c, avg, 3,“%d%d%d”,“avg =%d” Therefore, η= 12, η= 11 1 2 Estimated Length =(12*log12+11*log11) =(12*3.58 + 11*3.45) =(43+38) = 81 160 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Volume=Length*log(23) = 81*4.52 = 366 COCOMOMODEL Organic,SemidetachedandEmbeddedsoftwareprojects Boehmpostulatedthatany softwaredevelopmentprojectcanbeclassifiedintooneofthefollowing three categories based on the development complexity: organic, semidetached, andembedded.Inordertoclassifyaproductintotheidentifiedcategories,Boehmnotonlyconsideredthec haracteristicsoftheproductbutalsothoseofthedevelopmentteamanddevelopmentenvironment.Roug hlyspeaking,thesethreeproductclassescorrespondtoapplication, utility and system programs, respectively. Normally, data processing programs areconsidered to be application programs. Compilers, linkers, etc., are utility programs. Operatingsystems and real-time system programs, etc. are system programs. System programs interactdirectly withthehardwareandtypically involvemeeting timing constraintsandconcurrentprocessing. Boehm’s[1981]definitionoforganic,semidetached,andembeddedsystemsare elaboratedbelow. Organic: A development project can be considered of organic type, if the project deals withdevelopingawellunderstoodapplicationprogram,thesizeofthedevelopmentteamisreasonablys mall,and the teammembers areexperiencedin developingsimilar typesofprojects. Semidetached:Adevelopmentprojectcanbeconsideredofsemidetachedtype,ifthedevelopment consists of a mixture of experienced and inexperienced staff. Team members mayhave limited experience on related systems but may be unfamiliar with some aspects of thesystembeingdeveloped. Embedded: A development project is considered to be of embedded type, if the software beingdevelopedisstronglycoupledtocomplexhardware,orifthestringentregulationsontheoperational procedures exist. COCOMO COCOMO (Constructive Cost Estimation Model) was proposed by Boehm [1981]. According 161 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) toBoehm,softwarecostestimationshouldbedonethroughthreestages:BasicCOCOMO,Intermediate COCOMO,and Complete COCOMO. BasicCOCOMOModel ThebasicCOCOMOmodelgivesanapproximateestimateoftheprojectparameters.ThebasicCOCOM Oestimation model is given bythefollowingexpressions: a Effort= a 1 1 х(KLOC) PM b 2 Tdev= b x(Effort) Months Where 2 • KLOCistheestimatedsizeofthesoftwareproductexpressedinKiloLinesofCode, • a, a,b, bareconstants foreachcategoryof softwareproducts, 1 2 1 2 • Tdevistheestimatedtimetodevelopthesoftware,expressedinmonths, • Effortisthetotaleffortrequiredtodevelopthesoftwareproduct,expressedinpersonmonth s (PMs). The effort estimation is expressed in units of person-months (PM). It is the area under thepersonmonth plot (as shown in fig. 33.1). It should be carefully noted that an effort of 100 PMdoes not imply that 100 persons should work for 1 month nor does it imply that 1 person shouldbe employed for 100 months, but it denotes the area under the person-month curve (as shown infig.33.1). 162 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.33.1:Person-monthcurve 163 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) AccordingtoBoehm,everylineofsourcetextshouldbecalculatedasoneLOCirrespectiveof the actual number of instructions on that line. Thus, if a single instruction spans several lines (saynlines),itisconsideredtobenLOC.Thevaluesofa,a,b,bfordifferentcategoriesof 1 2 1 2 products (i.e. organic, semidetached, and embedded) as given by Boehm [1981] are summarizedbelow. He derived the above expressions by examining historical data collected from a largenumberof actual projects. Estimationofdevelopmenteffort For the three classes of software products, the formulas for estimating the effort based on thecodesizeareshown below: 1.05 Organic:Effort=2.4(KLOC) PM 1.12 Semi-detached:Effort=3.0(KLOC) PM 1.20 Embedded:Effort=3.6(KLOC) PM Estimationofdevelopmenttime Forthethreeclassesofsoftwareproducts,theformulasforestimatingthedevelopmenttimebasedon the effort are given below: 0.38 Organic:Tdev=2.5(Effort) Months 0.35 164 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Semi-detached:Tdev=2.5(Effort) Months 0.32 Embedded:Tdev =2.5(Effort) Months SomeinsightintothebasicCOCOMOmodelcanbeobtainedbyplottingtheestimatedcharacteristics for different software sizes. Fig. 33.2 shows a plot of estimated effort versusproductsize.Fromfig.33.2,wecanobservethattheeffortissomewhatsuperlinearinthesizeof the software product.Thus, the effortrequired to develop a product increases very rapidlywithproject size. Fig.33.2:Effortversusproductsize The development time versus the product size in KLOC is plotted in fig. 33.3. From fig. 33.3, itcan be observed that the development time is a sub linear function of the size of the product, i.e.when the size of the product increases by two times, the time to develop the product does 165 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) notdouble but rises moderately. This can be explained by the fact that for larger products, a largernumberofactivitieswhichcanbecarriedoutconcurrentlycanbeidentified.Theparallelactivities can be carried out simultaneously by the engineers. This reduces the time to completethe project. Further, from fig. 33.3, it can be observed that the development time is roughly thesameforallthethreecategoriesofproducts.Forexample,a60KLOCprogramcanbedeveloped in approximately 18 months, regardless of whether it is of organic, semidetached, orembeddedtype. Fig.33.3:Development timeversus size From the effort estimation, the project cost can be obtained by multiplying the required effort bythemanpowercostpermonth.But,implicitinthisprojectcostcomputationistheassumptionthat the 166 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) entire project cost is incurred on account of the manpower cost alone. In addition tomanpower cost, a project would incur costs due to hardware and software required for the projectandthe companyoverheads foradministration, officespace, etc. It is important to note that the effort and the duration estimations obtained using the COCOMOmodel are called as nominal effort estimate and nominal duration estimate. The term nominalimplies that if anyone tries to complete the project in a time shorter than the estimated duration,thenthecostwillincreasedrastically.But,ifanyonecompletestheprojectoveralongerperiodof time than theestimated, then thereis almost nodecreasein the estimated cost value. Example: Assume that the size of an org organic type software product has been estimated to be 32,000lines of source code. Assume that the average salary of software engineers be Rs. 15,000/permonth.Determinetheeffortrequiredtodevelopthesoftwareproductandthenominaldevelopmentti me. FromthebasicCOCOMOestimationformulafor organicsoftware: 1.05 Effort=2.4х(32) =91PM 0.38 167 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Nominaldevelopmenttime=2.5 х(91) =14months Costrequiredto developthe product=14 х15,000 =Rs. 210,000/168 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) INTERMEDIATECOCOMOMODEL The basic COCOMO model assumes that effort and development time are functions of theproductsize alone. However, a hostof other projectparameters besides the productsize affectthe effort required to develop the product as well as the development time. Therefore, in order toobtainanaccurateestimationoftheeffortandprojectduration,theeffectofallrelevantparameters must be taken into account. The intermediate COCOMO model recognizes this factand refines the initial estimate obtained using the basic COCOMO expressions by using a set of15 cost drivers (multipliers) based on various attributes of software development. For example, ifmodernprogrammingpracticesareused,theinitialestimatesarescaleddownwardbymultiplication with a cost driver having a value less than 1. If there are stringent reliabilityrequirements on the software product, this initial estimate is scaled upward. Boehm requires theproject manager to rate these 15 different parameters for a particular project on a scale of one tothree. Then, depending on these ratings, he suggests appropriate cost driver values which shouldbe multiplied with the initial estimate obtained using the basic COCOMO. In general, the costdriverscan beclassifiedas beingattributes of the followingitems: Product: The characteristics of the product thatare considered include the inherentcomplexityofthe product, reliabilityrequirements of theproduct, etc. Computer: Characteristics of the computer that are considered include the execution speedrequired,storagespace required etc. Personnel: The attributes of development personnel that are considered include the experiencelevelof personnel, programmingcapability,analysis capability, etc. DevelopmentEnvironment:Developmentenvironmentattributescapturethedevelopmentfacilitiesa vailabletothedevelopers.Animportantparameterthatisconsideredisthesophisticationofthe automation (CASE) toolsusedforsoftwaredevelopment. 169 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) CompleteCOCOMO model AmajorshortcomingofboththebasicandintermediateCOCOMOmodelsisthattheyconsidera software product as a single homogeneous entity. However, most large systems are made upseveral smaller sub-systems. These sub-systems may have widely different characteristics. Forexample, some sub-systems may be considered as organic type, some semidetached, and someembedded.Notonlythattheinherentdevelopmentcomplexityofthesubsystemsmaybedifferent,b utalsoforsomesubsystemsthereliabilityrequirementsmaybehigh,forsomethe development team might have no previous experience of similar development, and so on. Thecomplete COCOMO model considers these differences in characteristics of the subsystems andestimatestheeffortanddevelopmenttimeasthesumoftheestimatesfortheindividualsubsystems. The cost of each subsystem is estimated separately. This approach reduces themarginof errorin thefinal estimate. The following development project can be considered as an example application of the completeCOCOMOmodel.AdistributedManagementInformationSystem(MIS)productforanorgani zation having offices at several places across the country can have the following subcomponents: • Databasepart • GraphicalUserInterface(GUI)part • Communicationpart Of these, the communication part can be considered as embedded software. The database partcould be semi-detached software, and the GUI part organic software. The costs for these threecomponentscanbeestimatedseparately,and summedupto givetheoverall costof thesystem. 170 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 35 STAFFINGLEVELESTIMATION Once the effort required to develop a software has been determined, it is necessary to determinethe staffing requirement for the project. Putnam first studied the problem of what should be aproper staffing pattern for software projects. He extended the work of Norden who had earlierinvestigated the staffing pattern of research and development (R&D) type of projects. In order toappreciate the staffing pattern of software projects, Norden’s and Putnam’s results must beunderstood. Norden’sWork Norden studied the staffing patterns of several R & D projects. He found that the staffing patterncanbeapproximatedbytheRayleighdistributioncurve(asshowninfig.35.1).Nordenrepresente dtheRayleighcurvebythefollowing equation: -t²/2t² E=K/t² * t *e d d WhereEistheeffortrequiredattimet.Eisanindicationofthenumberofengineers(orthe staffinglevel)atanyparticulartimeduringthedurationoftheproject,Kistheareaunderthecurve,andtisth etimeatwhichthecurveattainsitsmaximumvalue.Itmustberemembered d 171 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) thattheresultsofNordenareapplicabletogeneralR&Dprojectsandwerenotmeanttomodelthestaffingp attern of softwaredevelopment projects. 172 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.35.1:Rayleigh curve Putnam’sWork Putnamstudiedtheproblemofstaffingofsoftwareprojectsandfoundthatthesoftwaredevelopment has characteristics very similar to other R & D projects studied by Norden and thatthe RayleighNorden curve can be used to relate the number of delivered lines of code to theeffortandthetimerequiredtodeveloptheproject.By analyzingalargenumberofarmyprojects,Putnam derivedthe followingexpression: L= C 1/3 K t k d 4/3 173 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Thevarious termsof thisexpressionareas follows:  Kisthetotaleffortexpended(inPM)intheproductdevelopmentandListheproductsizein KLOC.  t correspondstothetimeofsystemandintegrationtesting.Therefore,t approximatelyconsideredas thetime requiredtodevelop thesoftware. k d  Cisthestateoftechnologyconstantandreflectsconstraintsthatimpedetheprogressof theprogrammer.TypicalvaluesofC=2forpoordevelopmentenvironment(no k methodology,poordocumentation,andreview,etc.),C k developmentenvironment(softwareengineeringprinciplesare adheredto), C=11foran k excellentenvironment(inadditiontofollowingsoftwareengineeringprinciples,automatedtool sandtechniquesareused).TheexactvalueofCforaspecificprojectcan k becomputedfrom thehistoricaldataofthe organizationdevelopingit. Putnamsuggestedthatoptimalstaffbuild-uponaprojectshouldfollowtheRayleighcurve.Only a small number of engineers are needed at the beginning of a project to carry out planningand specification tasks. As the project progresses and more detailed work is required, the numberof engineers reaches a peak. After implementation and unit testing, the number of project stafffalls. However, the staff build-up should not be carried out in large installments. The team size shouldeither be increased or decreased slowly whenever required to match the Rayleigh-Norden curve.Experienceshowsthataveryrapidbuildupofprojectstaffanytimeduringtheprojectdevelopment correlateswith schedule slippage. Itshouldbeclearthataconstantlevelofmanpowerthroughouttheprojectdurationwouldleadto wastage of effort and increase the time and effort required to develop the product. If a constantnumber of engineers are used over all the phases of a project, some phases would be overstaffedand the other phases would be understaffed causing inefficient use of manpower, leading toscheduleslippageand increasein cost. Effectofschedulechangeoncost Byanalyzing alargenumberof armyprojects, Putnam derived the followingexpression: L= C 1/3 K t k d 174 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal 4/3 =8forgoodsoftware canbe d

ISBN : 978-81-963532-2-3 (E-Book) Where,Kisthetotaleffortexpended(inPM)intheproductdevelopmentandListheproductsizeinKLOC, tcorrespondstothetimeofsystemandintegrationtestingandCisthestateof d technologyconstantand reflectsconstraintsthatimpedetheprogressoftheprogrammer Nowbyusingtheabove expression it is obtained that, 3 4 K= L3/C t k d Or, 4 K= C/t d For the sameproduct size,C = L3/ C3is a constant. or,K1/K2 = td2 k 4/td1 4 or,K1/t d or,cost1/t d (asprojectdevelopmenteffortisequallyproportionaltoprojectdevelopment cost) From the above expression, it can be easily observed that when the schedule of a project iscompressed, the required development effort as well as project development cost increases inproportion to the fourth power of the degree of compression. It means that a relatively smallcompression in delivery schedule can result in substantial penalty of human effort as well asdevelopment cost. For example, if the estimated development time is 1 year, then in order todevelop the product in 6 months, the total effort required to develop the product (and hence theprojectcost) increases 16times. 4 k 175 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) PROJECTSCHEDULING Project-task schedulingis an important projectplanning activity.It involves deciding whichtasks would be taken up when. In order to schedule the project activities, a software projectmanagerneeds to do thefollowing: 1. Identifyallthe tasksneeded tocompletetheproject. 2. Breakdownlargetasksintosmall activities. 3. Determinethe dependencyamongdifferentactivities. 4. Establishthemostlikelyestimatesforthetimedurationsnecessarytocompletetheactivities. 5. Allocateresourcesto activities. 6. Planthestartingandendingdatesforvarious activities. 7. Determinethecriticalpath.Acriticalpathisthechainofactivitiesthatdeterminesthedurationo fthe project. The first step in scheduling a software project involves identifying all the tasks necessary tocomplete the project. A good knowledge of the intricacies of the project and the developmentprocess helps the managers to effectively identify the important tasks of the project. Next, thelarge tasks are broken down into a logical set of small activities which would be assigned todifferent engineers. The work breakdown structure formalism helps the manager to breakdownthetaskssystematicallyaftertheprojectmanagerhasbrokendownthetasksandcreatedthewo rk breakdown structure, he has to find the dependency among the activities. Dependencyamong the different activities determines the order in which the different activities would becarried out. If an activity A requires the results of another activity B, then activity A must bescheduled after activity B. In general, the task dependencies define a partial ordering amongtasks, i.e. each tasks may precede a subset of other tasks, but some tasks might not have anyprecedence ordering defined between them (called concurrent task). The dependency among theactivitiesisrepresented in theform ofanactivitynetwork. Once the activity network representation has been worked out, resources are allocated to eachactivity. Resource allocation is typically done using a Gantt chart. After resource allocation isdone, a PERT chart representation is developed. The PERT chart representation is suitable forprogram monitoring and control. For task scheduling, the project manager needs to decomposetheprojecttasksintoasetofactivities.Thetimeframewheneachactivityistobeperformedisto be determined. The end of each activity is called milestone. The project manager tracks 176 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) theprogress of a project by monitoring the timely completion of the milestones. If he observes thatthe milestones start getting delayed, then he has to carefully control the activities, so that theoveralldeadlinecan still be met. WorkBreakdownStructure Work Breakdown Structure (WBS) is used to decompose a given task set recursively into smallactivities. WBS provides a notation for representing the major tasks need to be carried out inorder to solve a problem. The root of the tree is labeled by the problem name. Each node of thetree is broken down into smaller activities that are made the children of the node. Each activity isrecursively decomposed into smaller sub-activities until at the leaf level, the activities requiresapproximately two weeks to develop. Fig. 36.1 represents the WBS of a MIS (ManagementInformationSystem)software. Whilebreakingdownataskintosmallertasks,themanagerhastomakesomeharddecisions.Ifa task is broken down into large number of very small activities, these can be carried outindependently.Thus,itbecomespossibletodeveloptheproductfaster(withthehelpofadditional manpower). Therefore, to be able to complete a project in the least amount of time, themanagerneedstobreaklargetasksintosmallerones,expectingtofindmoreparallelism.However, it is not useful to subdivide tasks into units which take less than a week or two toexecute. Very fine subdivision means that a disproportionate amount of time must be spent onpreparingand revisingvarious charts. 177 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.36.1:Workbreakdownstructureof anMIS problem Activity networks and critical path method WBS representation of a project is transformed intoanactivitynetworkbyrepresentingactivitiesidentifiedinWBSalongwiththeirinterdependencies. An activity network shows the different activities making up a project, theirestimated durations, and interdependencies (as shown infig. 36.2). Each activity is representedbyarectangularnodeand the duration oftheactivityis shown alongside each task. Managers can estimate the time durations for the different tasks in several ways. One possibilityis that they can empirically assign durations to different tasks. This however is not a good idea,because software engineers often resent such unilateral decisions. A possible alternative is to letengineer himself estimate the time for an activity he can assigned to. However, some managersprefer to estimate the time for various activities themselves. Many managers believe that anaggressive schedule motivates the engineers to do a better and faster job. 178 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) However, carefulexperiments have shown that unrealistically aggressive schedules not only cause engineers tocompromiseonintangiblequalityaspects,butalsoareacauseforscheduledelays.Agoodwaytoachiev eaccuratelyinestimationofthetaskdurationswithoutcreatingundueschedulepressuresis havepeople set their own schedules. to Fig.36.2:Activitynetworkrepresentationofthe MISproblem CriticalPathMethod(CPM) From the activity network representation following analysis can be made. The minimum time(MT) to complete the project is the maximum of all paths from start to finish. The earliest start(ES)timeofataskisthemaximumofallpathsfromthestarttothetask.Thelateststarttimeis the difference between MT and the maximum of all paths from this task to the finish. The earliestfinish time (EF) of a task is the sum of the earliest start time of the task and the duration of thetask. The latest finish (LF) time of a task can be obtained by subtracting maximum of all pathsfrom this task to finish from MT. The slack time (ST) is LS – EF and equivalently can be writtenas LF – EF. The slack time (or float time) is the total time that a task may be delayed before itwill affect the end time of the project. The slack time indicates the “flexibility” in 179 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) starting andcompletionoftasks.Acriticaltaskisonewithazeroslacktime.Apathfromthestartnodetothe finish node containing only critical tasks is called a critical path. These parameters fordifferenttasksforthe MIS problem areshown in thefollowingtable. Task Specification Designdatabase DesignGUIpart Codedatabase CodeGUIpart Integrateandtest Writeusermanual ES 0 15 15 60 45 165 15 EF 15 60 45 165 90 285 75 LS 0 15 90 60 120 165 225 LF 15 60 120 165 165 285 285 ST 0 0 75 0 75 0 210 The critical paths are all the paths whose duration equals MT. The critical path in fig. 36.2 isshownwith ablue arrow. GanttChart Ganttchartsaremainlyusedtoallocateresourcestoactivities.Theresourcesallocatedtoactivities include staff, hardware, and software. Gantt charts (named after its developer HenryGantt) are useful for resource planning. A Gantt chart is a special type ofbar chart where eachbar represents an activity. The bars are drawn along a time line. The length of each bar isproportionalto theduration oftime planned forthecorrespondingactivity. Gantt charts are used in software project management are actually an enhanced version of thestandard Ganttcharts.In the Ganttchartsusedfor softwareprojectmanagement,eachbarconsists of a white part and a shaded part. The shaded part of the bar shows the length of timeeach task is estimated to take. The white part shows the slack time, that is, the latest time bywhich a task must be finished. A Gantt chart representation for the MIS problem of fig. 36.2 isshownin thefig. 36.3. 180 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.36.3:Ganttchart representationoftheMISproblem PERTChart PERT (Project Evaluation and Review Technique) charts consist of a network of boxes andarrows. The boxes represent activities and the arrows represent task dependencies. PERT chartrepresents the statistical variations in the project estimates assuming a normal distribution. Thus,in a PERT chart instead of making a single estimate for each task, pessimistic, likely, andoptimisticestimatesaremade.TheboxesofPERTchartsareusuallyannotatedwiththepessimistic, likely, and optimistic estimates for every task. Since all possible completion timesbetween the minimum and maximum duration for every task has to be considered, there are notone but many critical paths, depending on the permutations of the estimates for each task. Thismakes critical path analysis in PERT charts very complex. A critical path in a PERT chart isshown by using thicker arrows. The PERT chart representation of the MIS problem of fig. 36.2 isshown in fig. 36.4. PERT charts are a more sophisticated form of activity chart. In activitydiagrams only 181 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) theestimatedtask durations are represented. Since, the actual durations mightvaryfrom theestimateddurations, theutilityoftheactivitydiagrams arelimited. Gantt chart representation of a project schedule is helpful in planning the utilization of resources,while PERT chart is useful for monitoring the timely progress of activities. Also, it is easier toidentify parallel activities in a project using a PERT chart. Project managers need to identify theparallelactivities in aprojectforassignment to differentengineers. Fig.36.4:PERTchartrepresentationoftheMISproblem 182 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 183 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) ORGANIZATIONSTRUCTURE Usually every software development organization handles several projects at any time. Softwareorganizations assign different teams of engineers to handle different software projects. Each typeof organization structure has its own advantages and disadvantages so the issue “how is theorganization as a whole structured?” must be taken into consideration so that each softwareprojectcan befinishedbeforeits deadline. Functionalformatvs.projectformat There are essentially two broad ways in which a software development organization can bestructured: functional format and project format. In the project format, the project developmentstaffs are divided based on the project for which they work (as shown in fig. 37.1). In thefunctional format, the developmentstaffs are divided based on the functional group to whichthey belong. The different projects borrow engineers from the required functional groups forspecific phases to be undertaken in the project and return them to the functional group upon thecompletionofthe phase. 184 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) a) ProjectOrganization b) FunctionalOrganization Fig.37.1:Schematicrepresentationof thefunctionalandprojectorganization In the functional format, different teams of programmers perform different phases of a project.For example, one team might do the requirements specification, another do the design, and so on.Thepartiallycompletedproductpassesfromoneteamtoanotherastheprojectevolves.Therefore, the functional format requires considerable communication among the different teamsbecause the work of one team must be clearly understood by the subsequent teams working ontheproject. Thisrequiresgoodqualitydocumentationto be producedaftereveryactivity. In the project format, a set of engineers is assigned to the project at the start of the project andthey remain with the project till the completion of the project. Thus, the same team carries out allthe life cycle activities. Obviously, the functional format requires more communication amongteams than the project format, because one team must understand the work done by the previousteams. Advantagesoffunctionalorganization overprojectorganization 185 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Even though greater communication among the team members may appear as an avoidableoverhead, the functional format has many advantages. The main advantages of a functionalorganizationare: • Easeofstaffing 186 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) • Production ofgood qualitydocuments • Jobspecialization • Efficienthandlingoftheproblemsassociatedwithmanpowerturnover. The functional organization allows the engineers to become specialists in particular roles, e.g.requirements analysis, design, coding, testing, maintenance, etc. They perform these roles againand again for different projects and develop deep insights to their work. It also results in moreattentionbeingpaidtoproperdocumentationattheendofaphasebecauseofthegreaterneedfor clear communication as between teams doing different phases. The functional organizationalso provides an efficient solution to the staffing problem. We have already seen that the staffingpattern should approximately follow the Rayleigh distribution for efficient utilization of thepersonnel by minimizing their wait times. The project staffing problem is eased significantlybecause personnel can be brought onto a project as needed, and returned to the functional groupwhen they are no more needed. This possibly is the most important advantage of the functionalorganization. A project organization structure forces the manager to take in almost a constantnumber of engineers for the entire duration of his project. This results in engineers idling in theinitial phase of the software development and are under tremendous pressure in the later phase ofthe development. A further advantage of the functional organization is that it is more effective inhandling the problem of manpower turnover. This is because engineers can be brought in fromthe functional pool when needed. Also, this organization mandates production of good qualitydocuments,so newengineers can quicklyget usedto thework alreadydone. Unsuitabilityoffunctionalformatin smallorganizations In spite of several advantages of the functional organization, it is not very popular in the softwareindustry.The apparentparadoxisnotdifficulttoexplain.The projectformatprovidesjobrotationtotheteammembers.Thatis,eachteammembertakesontheroleofthe designer,coder, tester, etc during the course of the project. On the other hand, considering the present skillshortage, it would be very difficult for the functional organizations to fill in slots for some rolessuch as maintenance, testing, and coding groups. Also, another problem with the functionalorganizationisthatifanorganizationhandlesprojectsrequiringknowledgeofspecializeddo main areas, then these domain experts cannot be brought in and out of the project for thedifferent phases, unless the company handles a large number of such projects. Also, for obviousreasons the functional format is not suitable for small organizations handling just one or twoprojects. TeamStructures Team structure addresses the issue of organization of the individual project teams. There aresome possible ways in which the individual project teams can be organized. There are mainlythreeformalteamstructures:chiefprogrammer,democratic,andthemixedteamorganizations. 187 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) althoughseveralothervariationstothesestructuresarepossible.Problemsofdifferentcomplexitiesand sizesoften requiredifferentteamstructures forchiefsolution. ChiefProgrammerTeam In this team organization, a senior engineer provides the technical leadership and is designated asthe chief programmer. The chief programmer partitions the task into small activities and assignsthem to the team members. He also verifies and integrates the products developed by differentteam members. The structure of the chief programmer team is shown in fig. 37.2. The chiefprogrammerprovidesanauthority,andthisstructureisarguablymoreefficientthanthedemocratic team for well-understood problems. However, the chief programmer team leads tolowerteammorale,sinceteam-membersworkundertheconstantsupervisionofthechiefprogrammer. This also inhibits their original thinking. The chief programmer team is subject tosinglepointfailuresincetoomuchresponsibilityandauthorityisassignedtothechiefprogrammer. Fig.37.2:Chiefprogrammerteamstructure The chief programmer team is probably the most efficient way of completing simple and smallprojects since the chief programmer can work out a satisfactory design and ask the programmersto code different modules of his design solution. For example, suppose an 188 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) organization hassuccessfullycompletedmanysimpleMISprojects.Then,forasimilarMISproject,chiefprogrammer team structure can be adopted. The chief programmer team structure works wellwhenthetaskiswithintheintellectualgraspofasingleindividual.However,evenforsimple andwellunderstoodproblems,anorganizationmustbeselectiveinadoptingthechiefprogrammerstructure.Thec hiefprogrammerteamstructureshouldnotbeusedunlesstheimportance of early project completion outweighs other factors such as team morale, personaldevelopments,life-cyclecost etc. DemocraticTeam The democratic team structure, as the name implies, does not enforce any formal team hierarchy(asshowninfig.37.3).Typically,amanagerprovidestheadministrativeleadership.Atdiffere nttimes,different membersof thegroup providetechnical leadership. Fig.37.3:Democraticteamstructure The democratic organization leads to higher morale and job satisfaction. Consequently, it suffersfrom less man-power turnover. Also, democratic team structure is appropriate for less 189 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) understoodproblems, since a group of engineers can invent better solutions than a single individual as in achief programmer team. A democratic team structure is suitable for projects requiring less thanfiveorsixengineersandforresearchorientedprojects.Forlargesizedprojects,apuredemocratic organization tends to become chaotic. The democratic team organization encouragesegolessprogrammingasprogrammers can shareand reviewoneanother’s work. 190 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) RISKMANAGEMENT 191 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Asoftwareprojectcanbeaffectedbyalargevarietyofrisks.Inordertobeabletosystematicallyidentifythe importantriskswhichmightaffectasoftwareproject,itisnecessaryto categorize risks into different classes. The project manager can then examine which risks fromeachclass arerelevant to the project. Therearethreemaincategoriesofrisks whichcanaffectasoftwareproject: 1. Projectrisks Projectrisksconcernvariesformsofbudgetary,schedule,personnel,resource,andcustomerrelatedproblems.Animportantprojectriskisscheduleslippage.Since,software is intangible, it is very difficult to monitor and control a software project. It isvery difficult to control something which cannot be seen. For any manufacturing project,such as manufacturing of cars, the project manager can see the product taking shape. Hecan for instance, see that the engine is fitted, after that the doors are fitted, the car isgetting painted, etc. Thus he can easily assess the progress of the work and control it. Theinvisibility of the product being developed is an important reason why many softwareprojectssuffer from therisk of schedule slippage. 2. Technicalrisks Technicalrisksconcernpotentialdesign,implementation,interfacing,testing,andmaintenance problems. Technical risks also include ambiguous specification, incompletespecification, changing specification, technical uncertainty, and technical obsolescence.Most technical risks occur due to the development team’s insufficient knowledge abouttheproject. 3. Businessrisks This type of risks include risks of building an excellent product that no one wants, losingbudgetaryor personnel commitments, etc. RiskAssessment Theobjectiveofriskassessmentistoranktherisksintermsoftheirdamagecausingpotential.Forrisk assessment, first each riskshould beratedin two ways: • Thelikelihoodofariskcomingtrue (denoted asr). • Theconsequenceofthe problemsassociatedwiththatrisk(denotedass). Basedon thesetwo factors, thepriorityof each risk can becomputed: 192 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) p =r* s Where, p is the priority with which the risk must be handled, r is the probability of the riskbecoming true, and s is the severity of damage caused due to the risk becoming true. If allidentified risks are prioritized, then the most likely and damaging risks can be handled first andmorecomprehensive riskabatementprocedures can bedesignedfor theserisks. RiskContainment After all the identified risks of a project are assessed, plans must be made to contain the mostdamaging and the most likely risks. Different risks require different containment procedures. Infact,most risks requireingenuityon the part oftheproject manager in tacklingthe risk. Therearethreemain strategiestoplanforriskcontainment: Avoid the risk- This may take several forms such as discussing with the customer to change therequirements to reduce the scope of the work, giving incentives to the engineers to avoid the riskofmanpower turnover,etc. Transfer the risk- This strategy involves getting the risky component developed by athirdparty,buyinginsurancecover, etc. Riskreduction-Thisinvolvesplanningwaystocontainthedamageduetoarisk.Forexample,ifthereis risk that somekeypersonnel mightleave, new recruitment maybeplanned. RiskLeverage To choose between the different strategies of handling a risk, the project manager must considerthe cost of handling the risk and the corresponding reduction of risk. For this the risk leverage ofthedifferent risks can becomputed. Risk leverage is the difference in risk exposure divided by the cost of reducing the risk. Moreformally, riskleverage=(riskexposurebeforereduction– riskexposureafterreduction)/(costofreduction) Riskrelatedtoscheduleslippage Even though there are three broad ways to handle any risk, but still risk handling requires a lot ofingenuity on the part of a project manager. As an example, it can be considered the optionsavailable to contain an important type of risk that occurs in many software projects – that 193 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) ofscheduleslippage.Risksrelatingtoscheduleslippageariseprimarilyduetotheintangiblenature of software.Therefore,these canbe dealtwithby increasing the visibility of the softwareproduct. Visibility of a software product can be increased by producing relevant documentsduring the development process wherever meaningful and getting these documents reviewed byanappropriateteam.Milestonesshouldbeplacedatregularintervalsthroughasoftwareengineering process to provide a manager with regular indication of progress. Completion of aphase of the development process before followed need not be the only milestones. Every phasecan be broken down to reasonable-sized tasks and milestones can be scheduled for these taskstoo. A milestone is reached, once documentation produced as part of a software engineering taskis produced and gets successfully reviewed. Milestones need not be placed for every activity. Anapproximaterule ofthumb is to set amilestoneevery10 to 15 days. SoftwareConfigurationManagement The results (also called as the deliverables) of a large software development effort typicallyconsist of a large number of objects, e.g. source code, design document, SRS document, testdocument, user’s manual, etc. These objects are usually referred to and modified by a number ofsoftware engineers through out the life cycle of the software. The state of all these objects at anypoint of time is called the configuration of the software product. The state of each deliverableobjectchanges asdevelopment progressesandalso as bugsaredetectedandfixed. Releasevs.Versionvs.Revision A new version of a software is created when there is a significant change in functionality,technology, or the hardware it runs on, etc. On the other hand a new revision of a software refersto minor bug fix in that software. A new release is created if there is only a bug fix, minorenhancementsto the functionality, usability, etc. For example, one version of a mathematical computation package might run on Unixbasedmachines, another on Microsoft Windows and so on. As a software is released and used by thecustomer, errors are discovered that need correction. Enhancements to the functionalities of thesoftware may also be needed. A new release of software is an improved system intended toreplace an old one. Often systems are described as version m, release n; or simple m.n. Formally,a history relation is version of can be defined between objects. This relation can be split into twosubrelations is revision ofand is variant of. Necessityofsoftwareconfigurationmanagement There are several reasons for putting an object under configuration management. But, possiblythe most important reason for configuration management is to control the access to the differentdeliverableobjects.Unlessstrictdisciplineisenforcedregardingupdationandstorageofdiffere nt objects, severalproblems appear. Thefollowing are some of the important problemsthatappear 194 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) if configuration management is not used.  Inconsistency problem when the objects are replicated. A scenario can be consideredwhere every software engineer has a personal copy of an object (e.g. source code). Aseach engineer makes changes to his local copy, he is expected to intimate them to otherengineers, so that the changes in interfaces are uniformly changed across all modules.However, many times an engineer makes changes to the interfaces in his local copies andforgets to intimate other teammates about the changes. This makes the different copies oftheobjectinconsistent.Finally,whentheproductisintegrated,itdoesnotwork.Therefore, when several team members work on developing an object, it is necessary forthem to work onasinglecopyoftheobject, otherwiseinconsistencymayarise.  Problemsassociatedwithconcurrentaccess.Supposethereisasinglecopy ofaproblemmodule,andseveralengineersareworkingonit.Twoengineersmaysimultaneously carry out changes to different portions of the same module, and whilesaving overwrite each other. Though the problem associated with concurrent access toprogramcodehasbeenexplained,similarproblemsoccurforany otherdeliverableobject.  Providing a stable development environment. When a project is underway, the teammembers need a stable environment to make progress. Suppose somebody is trying tointegrate module A, with the modules B and C, he cannot make progress if developer ofmodule C keeps changing C; this can be especially frustrating if a change to module Cforces him to recompile A. When an effective configuration management is in place, themanager freezes the objects to form a base line. When anyone needs any of the objectsunderconfigurationcontrol,heisprovidedwithacopy ofthebaselineitem.Therequester makes changes to his private copy. Only after the requester is through with allmodifications to his private copy, the configuration is updated and a new base line getsformed instantly. This establishes a baseline for others to use and depend on. Also,configuration may be frozen periodically. Freezing a configuration may involve archivingeverything needed to rebuild it. (Archiving means copying to a safe place such as amagnetictape).  System accountingandmaintainingstatusinformation.Systemaccountingkeepstrackof who madeaparticular changeand whenthechangewas made.  Handling variants. Existence of variants of a software product causes some peculiarproblems. Suppose somebody has several variants of the same module, and finds a bug inone of them. Then, it has to be fixed in all versions and revisions. To do it 195 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) efficiently, heshouldnothaveto ofthesoftwareseparately. SoftwareConfigurationManagementActivities Normally,aprojectmanagerperformstheconfigurationmanagementactivitybyusinganautomatedcon figurationmanagementtool.Aconfigurationmanagementtoolprovidesautomatedsupportforovercom ingalltheproblemsmentionedabove.Inaddition,aconfiguration management tool helps to keep track of various deliverable objects, so that theproject manager can quickly and unambiguously determine the current state of the project. Theconfiguration management tool enables the engineers to change the various components in acontrolledmanner. Configurationmanagementiscarriedoutthroughtwoprincipalactivities: • Configurationidentificationinvolvesdecidingwhichpartsofthesystemshouldbekepttrackof . • Configurationcontrolensuresthatchangestoasystemhappensmoothly. ConfigurationIdentification The project manager normally classifies the objects associated with a software developmenteffort into three main categories: controlled, pre controlled, and uncontrolled. Controlled objectsare those which are already put under configuration control. One must follow some formalprocedures to change them. Pre controlled objects are not yet under configuration control, butwill eventually be under configuration control. Uncontrolled objects are not and will not besubjectedtoconfigurationcontrol.Controllableobjectsincludebothcontrolledandprecontrolledobj ects. Typical controllable objects include: • Requirementsspecificationdocument • Designdocuments Toolsusedtobuildthesystem,such ascompilers,linkers,lexicalanalyzers,parsers, etc. • Sourcecodeforeachmodule • Testcases • Problemreports The configuration management plan is written during the project planning phase and it lists allcontrolled objects. The managers who develop the plan must strike a balance between controllingtoo much, and controlling too little. If too much is controlled, overheads due to configurationmanagement increase to unreasonably high levels. On the other hand, controlling too little mightleadto confusion when somethingchanges. 196 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal fixitin eachandeveryversionandrevision

ISBN : 978-81-963532-2-3 (E-Book) Configuration Control Configuration control is the process of managing changes to controlled objects. Configurationcontrol is the part of a configuration management system that most directly affects the day-to-dayoperationsofdevelopers.Theconfigurationcontrolsystem preventsunauthorized changesto any controlled objects. In order to change a controlled object such as a module, a developer canget a private copy of the module by a reserve operation as shown in fig. 38.1. Configurationmanagement tools allow only one person to reserve a module at a time. Once an object isreserved, it does not allow anyone else to reserve this module until the reserved module isrestored as shown in fig. 38.1. Thus, by preventing more than one engineer to simultaneouslyreserveamodule, the problems associatedwith concurrentaccess aresolved. Fig.38.1:Reserveandrestoreoperationinconfigurationcontrol It can be shown how the changes to any object that is under configuration control can beachieved. The engineer needing to change a module first obtains a private copy of the 197 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) modulethrough a reserve operation. Then, he carries out all necessary changes on this private copy.However, restoring the changed module to the system configuration requires the permission of achange control board (CCB). The CCB is usually constituted from among the development teammembers. For every change that needs to be carried out, the CCB reviews the changes made tothecontrolled object andcertifiesseveral things about thechange: 1. Changeiswell-motivated. 2. Developerhasconsideredanddocumentedthe effectsofthechange. 3. Changesinteract wellwiththechangesmadebyotherdevelopers. 4. Appropriatepeople(CCB)havevalidatedthechange,e.g.someonehastestedthechangedcode,an d has verifiedthat thechangeis consistent with therequirement. The change control board (CCB) sounds like a group of people. However, except for verylarge projects, the functions of the change control board are normally discharged by theproject manager himself or some senior member of the development team. Once the CCBreviews the changes to the module, the project manager updates the old base line through arestore operation (as shown in fig. 38.1). A configuration control tool does not allow adevelopertoreplaceanobjecthehasreservedwithhislocalcopyunlesshegetsanauthorization from the CCB. By constraining the developers’ ability to replace reservedobjects, a stable environment is achieved. Since a configuration management tool allows onlyone engineer to work on one module at any one time, problem of accidental overwriting iseliminated. Also, since only the manager can update the baseline after the CCB approval,unintentionalchanges are eliminated. ConfigurationManagementTools SCCSandRCSaretwopopularconfigurationmanagementtoolsavailableonmostUNIXsystems. SCCS or RCS can be used for controlling and managing different versions of text files.SCCS and RCS do not handle binary files (i.e. executable files, documents, files containingdiagrams, etc.) SCCS and RCS provide an efficient way of storing versions that minimizes theamount of occupied disk space. Suppose, a module MOD is present in three versions MOD1.1,MOD1.2, 198 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) and MOD1.3. Then, SCCS and RCS stores the original module MOD1.1 together withchanges needed to transform MOD1.1 into MOD1.2 and MOD1.2 to MOD1.3. The changesneeded to transform each base lined file to the next version are stored and are called deltas. Themain reason behind storing the deltas rather than storing the full version files is to save diskspace.ThechangecontrolfacilitiesprovidedbySCCSandRCSincludetheabilitytoincorporate restrictions on the set of individuals who can create new versions, and facilities forchecking componentsinandout(i.e.reserveandrestoreoperations).Individualdeveloperscheck out components and modify them. After they have made all necessary changes to a moduleand after the changes have been reviewed, they check in the changed module into SCCS or RCS.Revisions are denoted by numbers in ascending order, e.g., 1.1, 1.2, 1.3 etc. It is also possible tocreatevariants or revisions of acomponentbycreatingafork in thedevelopmenthistory. 199 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) COMPUTERAIDEDSOFTWAREENGINEERING CASEtool andits scope A CASE (Computer Aided Software Engineering) tool is a generic term used to denote any formof automated support for software engineering. In a more restrictive sense, a CASE tool meansany toolused toautomatesomeactivity associatedwithsoftware development.Many CASEtools are available. Some of these CASE tools assist in phase related tasks such as specification,structured analysis, design, coding, testing, etc.; and others to non-phase activities such as projectmanagementandconfiguration management. ReasonsforusingCASE tools Theprimaryreasons forusingaCASE tool are: • Toincreaseproductivity • Tohelpproducebetter qualitysoftwareatlower cost CASEenvironment AlthoughindividualCASEtoolsareuseful,thetruepowerofatoolsetcanberealizedonlywhen these set of tools are integrated into a common framework or environment. CASE tools arecharacterized by the stage or stages of software development life cycle on which they focus.Since different tools covering different stages share common information, it is required that theyintegrate through somecentralrepository tohave a consistentview of informationassociatedwith the software development artifacts. This central repository is usually a data dictionarycontainingthe definition ofall compositeand elementary data items. Through the central repository all the CASE tools in a CASE environment sharecommon information among themselves. Thus a CASE environment facilities the automation ofthe step-by-step methodologies for software development. A schematic representation of a CASEenvironmentis shown in fig. 39.1. 200 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig.39.1:A CASEEnvironment CASEenvironmentvsprogrammingenvironment A CASE environment facilitates the automation of the step-by-step methodologies for softwaredevelopment. In contrast to a CASE environment, a programming environment is an integratedcollection oftools to support onlythe codingphaseof softwaredevelopment. Benefitsof CASE Several benefits accrue from the use of a CASE environment or even isolated CASE tools. Someofthose benefits are:  A key benefit arising out of the use of a CASE environment is cost saving through alldevelopment phases. Different studies carry out to measure the impact of CASE put theeffortreduction between30%to 40%. 201 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book)  Use of CASE tools leads to considerable improvements to quality. This is mainly due tothefactsthatonecaneffortlesslyiteratethroughthedifferentphasesofsoftwaredevelopmenta nd thechances of humanerror areconsiderablyreduced.  CASEtoolshelpproducehighqualityandconsistentdocuments.Sincetheimportantdata relating to a software product are maintained in a central repository, redundancy inthe stored data is reduced and therefore chances of inconsistent documentation is reducedtoa great extent.  CASE tools take out most of the drudgery in a software engineer’s work. For example,they need not check meticulously the balancing of the DFDs but can do it effortlesslythroughthe press ofabutton.  CASE tools have led to revolutionary cost saving in software maintenance efforts. Thisarises not only due to the tremendous value of a CASE environment in traceability andconsistency checks, but also due to the systematic information capture during the variousphasesof softwaredevelopment as a resultofadheringtoaCASE environment.  IntroductionofaCASEenvironmenthasanimpactonthestyleofworkingofacompany,and makes it oriented towards thestructured and orderlyapproach. RequirementsofaprototypingCASEtool Prototypingisusefultounderstandtherequirementsofcomplexsoftwareproducts,todemonstrate a concept, to market new ideas, and so on. The important features of a prototypingCASEtool areas follows: • Defineuserinteraction • Definethesystemcontrolflow • Storeandretrievedatarequiredbythesystem • Incorporatesomeprocessinglogic Featuresof agoodprototypingCASEtool There are several stand-alone prototyping tools. But a tool that integrates with the data dictionarycan make use of the entries in the data dictionary, help in populating the data dictionary andensure theconsistency betweenthedesigndataandtheprototype.Agoodprototyping toolshouldsupport the followingfeatures:  Sinceoneofthemainuses ofaprototypingCASE toolis graphicaluserinterface(GUI)development, prototyping CASE tool should support the 202 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) user to create a GUI using agraphics editor. The user should be allowed to define all data entry forms, menus andcontrols.  Itshould integratewith thedatadictionaryof aCASE environment.  If possible, it should be able to integrate with external user defined modules written in Corsomepopularhigh level programminglanguages.  Theusershouldbeabletodefinethesequenceofstatesthroughwhichacreatedprototypecanrun. Theusershouldalsobeallowedtocontroltherunningoftheprototype.  he run time system of prototype should support mock runs of the actual system andmanagementofthe inputand output data. Structuredanalysisanddesign withCASEtools Several diagramming techniques are used for structured analysis and structured design. Thefollowingsupports mightbeavailablefrom CASE tools.  ACASEtoolshouldsupportoneormoreofthestructuredanalysisanddesigntechniques.  Itshouldsupporteffortlesslydrawinganalysisanddesigndiagrams.  It should support drawing for fairly complex diagrams, preferably through a hierarchy oflevels.  The CASE tool should provide easy navigation through the different levels and throughthedesignand analysis.  The tool must support completeness and consistency checking across the design andanalysis and through all levels of analysis hierarchy. Whenever it is possible, the systemshould disallow any inconsistent operation, but it may be very difficult to implement sucha feature. Whenever there arises heavy computational load while consistency checking, itshouldbepossible to temporarilydisable consistencychecking. Codegeneration andCASEtools As far as code generation is concerned, the general expectation of a CASE tool is quite low. Areasonablerequirementistraceabilityfromsourcefiletodesigndata.More supportsexpectedfrom aCASE tool duringcodegeneration phasearethe following: pragmatic  The CASE tool should support generation of module skeletons or templates in one ormorepopularlanguages.Itshouldbepossibletoincludecopyrightmessage,briefdescription of the module, author name and thedate of creation in some selectableformat.  Thetoolshouldgeneraterecords,structures,classdefinitionautomaticallyfromthecontentsof thedata dictionaryin one ormorepopularlanguages.  Itshouldgeneratedatabasetablesforrelationaldatabasemanagementsystems. 203 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book)  The tool should generate code for user interface from prototype definition for X windowandMS window based applications. Testcasegeneration CASEtool TheCASEtool fortest case generationshould havethe followingfeatures:  Itshouldsupportbothdesignandrequirementtesting.  It should generate test set reports in ASCII format which can be directly imported into thetestplan document. 204 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Hardwareandenvironmentalrequirements In most cases, it is the existing hardware that would place constraints upon the CASE toolselection. Thus, instead of defining hardware requirements for a CASE tool, the task at handbecomes to fit in an optimal configuration of CASE tool in the existing hardware capabilities.Therefore, it can be emphasized on selecting the most optimal CASE tool configuration for agivenhardware configuration. The heterogeneous network is one instance of distributed environment and this can be chosen forillustrationasit ismorepopularduetoits machineindependent features.TheCASEtoolimplementation in heterogeneous network makes use of client-server paradigm. The multipleclients who run different modules access data dictionary through this server. The data dictionaryserver may support one or more projects. Though it is possible to run many servers for differentprojectsbut distributed implementation of data dictionaryis not common. The tool set is integrated through the data dictionary which supports multiple projects, multipleusers working simultaneously and allows sharing information between users and projects. Thedata dictionary provides consistent view of all project entities, e.g. a data record definition and itsentity-relationshipdiagrambeconsistent.Theservershoulddepicttheperprojectlogicalviewof the data dictionary. This means that it should allow back up/restore, copy, cleaning part of thedatadictionary, etc. Thetoolshouldworksatisfactorilyformaximumpossiblenumberofusersworkingsimultaneously. The tool should support multi-windowing environment for the users. This isimportant to enable the users to see more than one diagram at a time. It also facilitates navigationandswitching from one part to theother. DocumentationSupport The deliverable documents shouldbe organized graphically and shouldbe able to incorporatetext and diagrams from the central repository. This helps in producing up-to-date documentation.TheCASEtoolshouldintegratewithoneormoreofthecommerciallyavailabledesktopp ublishing packages. It should be possible to export text, graphics, tables, data dictionary reportstotheDTP packagein standard forms such as PostScript. ProjectManagementSupport The CASE tool should support collecting, storing, and analyzing information on the softwareproject’s progress such as the estimated task duration, scheduled and actual task start, completiondate,dates andresults ofthe reviews,etc. 205 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 206 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) ExternalInterface The CASE tool should allow exchange of information for reusability of design. The informationwhich istobeexported by the CASEtoolshouldbe preferably inASCII formatand supportopenarchitecture.Similarly,thedatadictionary shouldprovideaprogramminginterfacetoaccess information. It is required for integration of custom utilities, building new techniques, orpopulatingthe datadictionary. ReverseEngineering The CASE tool should support generation of structure charts and data dictionaries from theexisting source codes. It should populate the data dictionary from the source code. If the tool isused for re-engineering information systems, it should contain conversion tool from indexedsequentialfilestructure,hierarchicalandnetworkdatabasetorelational databasesystems. DataDictionaryInterface The data dictionary interface should provide view and update access to the entities and relationsstored in it. It should have print facility to obtain hard copy of the viewed screens. It shouldprovide analysis reports like cross-referencing, impact analysis, etc. Ideally, it should support aquerylanguageto view its contents. Second-generationCASEtool An important feature of the second-generation CASE tool is the direct support of any adaptedmethodology. This would necessitate the function of a CASE administrator organization who cantailor the CASE tool to a particular methodology. In addition, the second-generation CASE toolshavefollowingfeatures:  Intelligent diagramming support- The fact that diagramming techniques are useful forsystemanalysisanddesigniswellestablished.ThefutureCASEtoolswouldprovidehelpto aestheticallyandautomaticallylayout thediagrams.  IntegrationwithimplementationenvironmentTheCASEtoolsshouldprovideintegrationbetween design and implementation.  Data dictionary standards- The user should be allowed to integrate many developmenttools into one environment. It is highly unlikely that any one vendor will be able todeliveratotalsolution.Moreover,apreferredtoolwouldrequiretuningupforaparticular system. Thus the user would act as a system integrator. This is possibly only ifsomestandard ondata dictionaryemerges.  Customization support- The user should be allowed to define new types of objects andconnections. This facility may be used to build some special methodologies. Ideally itshould be possible to specify the rules of a methodology to a rule engine for carrying outthenecessaryconsistencychecks. 207 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) ArchitectureofaCASEenvironment The architecture of a typical modern CASE environment is shown diagrammatically in fig. 39.2.The important components of a modern CASE environment are user interface, tool set, objectmanagement system (OMS), and a repository. Characteristics of a tool set have been discussedearlier. Fig.39.2:Architectureof aModern CASEEnvironment UserInterface The user interface provides a consistent framework for accessing the different tools thus makingit easier for the users to interact with the different tools and reducing the overhead of learninghowthedifferent tools areused. ObjectManagementSystem(OMS)andRepository 208 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Different case tools represent the software product as a set of entities such as specification,design, text data, project plan, etc. The object management system maps these logical entitiessuch into the underlying storage management system (repository). The commercial relationaldatabasemanagementsystemsaregearedtowardssupportinglargevolumesofinformationstr uctured as simple relatively short records. There are a few types of entities but large number ofinstances.Bycontrast,CASEtoolscreatealargenumberofentityandrelationtypeswith 209 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) perhapsafewinstancesofeach.Thustheobjectmanagementsystemtakescareofappropriatelymappingi nto the underlyingstorage managementsystem. 210 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) 211 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) SOFTWARER EUSE 212 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Advantagesof softwarereuse Software products are expensive. Software project managers are worried about the high cost ofsoftware developmentand are desperately lookfor waystocutdevelopmentcost.A possibleway to reduce development cost is to reuse parts from previously developed software. In additionto reduced development cost and time, reuse also leads to higher quality of the developedproductssincethereusable components areensured to havehigh quality. Artifactsthatcanbereused It is important to know about the kinds of the artifacts associated with software development thatcan be reused. Almost all artifacts associated with software development, including project planandtest plancan bereused. However, theprominent itemsthat can beeffectivelyreusedare: • Requirementsspecification • Design • Code • Testcases • Knowledge Prosandconsofknowledgereuse Knowledge is the most abstract development artifact that can be reused. Out of all the reuseartifacts i.e. requirements specification, design, code, test cases, reuse of knowledge occursautomatically without any conscious effort in this direction. However, two major difficulties withunplanned reuse of knowledge are that a developer experienced in one type of software productmight be included in a team developing a different type of software. Also, it is difficult toremember the details of the potentially reusable development knowledge. A planned reuse ofknowledge can increase the effectiveness of reuse. For this, the reusable knowledge should besystematically extracted and documented. But, it is usually very difficult to extract and documentreusableknowledge. Easinessof reuseofmathematicalfunctions Theroutinesofmathematicallibrariesarebeingreusedverysuccessfullybyalmosteveryp rogrammer. No one inhis right mind would think of writing a routine to compute sine orcosine. Reuse of commonly used mathematical functions is easy. Several interesting aspectsemerge. Cosine means the same to all. Everyone has clear ideas about what kind argumentshouldcosinetake,thetypeofprocessingtobecarriedoutandtheresultsreturned. Secondly, 213 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal of

ISBN : 978-81-963532-2-3 (E-Book) mathematicallibrarieshaveasmallinterface.Forexample,cosinerequiresonlyoneparam eter.Also,thedata formats ofthe parameters arestandardized. Basicissuesinanyreuseprogram Thefollowingaresomeofthebasicissuesthatmustbeclearlyunderstoodforstartinganyreu seprogram. • Componentcreation • Componentindexingandstoring • Componentsearch • Componentunderstanding • Componentadaptation • Repositorymaintenance Component creation- For component creation, the reusable components have to be firstidentified. Selection of the right kind of components having potential for reuse is important.Domainanalysisisa promisingtechniquewhich can beusedtocreatereusablecomponents. ComponentindexingandstoringIndexingrequiresclassificationofthereusablecomponents so that they can be easily searched when looking for a component for reuse. Thecomponents need to be stored in a Relational Database Management System (RDBMS) or anObjectOrientedDatabaseSystem(ODBMS)forefficientaccesswhenthenumberofcompon entsbecomes large. Component searching- The programmers needto searchfor right components matchingtheir requirements in a database of components. To be able to search components efficiently,the programmers require a proper method to describe the components that they are lookingfor. Component understanding- The programmers need a precise and sufficiently completeunderstanding of what the component does to be able to decide whether they can reuse thecomponent. To facilitate understanding, the components should be well documented andshould dosomethingsimple. Component adaptation- Often, the components may need adaptation before they can bereused,sinceaselectedcomponentmay Software Engineering Keerthana P, Manasa KN, Ganga D Bengal notexactly 214

ISBN : 978-81-963532-2-3 (E-Book) fittheproblemathand.However,tinkering with the code is also not a satisfactory solution because this is very likely to be asourceof bugs. RepositorymaintenanceAcomponentrepositoryonceiscreatedrequirescontinuousmaintenance.Newcompo nents,asandwhencreatedhavetobeenteredintotherepository. The faulty components have to be tracked. Further, when new applications emerge, olderapplicationsbecomeobsolete.Inthiscase,theobsoletecomponentsmighthavet oberemovedfrom therepository. DomainAnalysis Theaim of domain analysis is to identifythereusable components foraproblem domain. Reuse domain- A reuse domain is a technically related set of application areas. A body ofinformationisconsideredtobe a problemdomainfor reuse, ifa deepandcomprehensiverelationship exists among the information items as categorized by patterns of similarity amongthe development components of the software product. A reuse domain is shared understanding ofsome community, characterized by concepts, techniques, and terminologies that show somecoherence. Examples of domains are accounting software domain, banking software domain,businesssoftwaredomain,manufacturingautomationsoftwaredomain,telecom municationsoftwaredomain, etc. Just to become familiar with the vocabulary of a domain requires months of interaction with theexperts. Often, one needs to be familiar with a network of related domains for successfullycarryingoutdomainanalysis.Domainanalysisidentifiestheobjects,operati ons,andtherelationships among them. For example, consider the airline reservation system, the reusableobjects can be seats, flights, airports, crew, meal orders, etc. The reusable operations beschedulingaflight,reservingaseat,assigningcrewtoflights,etc.Thedomainanalysisge neralizestheapplicationdomain.Adomainmodeltranscendsspecificapplications.Theco mmoncharacteristics orthesimilarities betweensystems are generalized. 215 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal the can

ISBN : 978-81-963532-2-3 (E-Book) During domain analysis, a specific community of software developers gets together to discusscommunity-widesolutions.Analysisoftheapplicationdomainisrequiredtoidentifythereusable components. The actual construction of reusable components for a domain is calleddomainengineering. EvolutionofareusedomainTheultimateresultofdomainanalysisisdevelopmentofproblemorientedlanguages.Theproblemorientedlanguagesarealsoknownasapplicationgenerators.Theseapplicationgenerators ,oncedevelopedformapplicationdevelopmentstandards. The domains slowly develop. As a domain develops, it is distinguishable the variousstagesit undergoes: Stage 1: There is no clear and consistent set of notations. Obviously, no reusable components areavailable.All softwareiswritten from scratch. Stage 2: Here, only experience from similar projects is used in a development effort. This meansthatthereis onlyknowledgereuse. Stage 3: At this stage, the domain is ripe for reuse. The set of concepts are stabilized and thenotations standardized. Standard solutions to standard problems are available. There is bothknowledgeandcomponent reuse. Stage 4: The domain has been fully explored. The software development for the domain can belargely automated. Programs are not written in the traditional sense any more. Programs arewrittenusingadomainspecific language,which isalso knownasan applicationgenerator. 216 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) REUSEAPPROACH ComponentsClassification Components need to be properly classified in order to develop an effective indexing and storagescheme. Hardware reuse has been very successful. Hardware components are classified using amultilevel hierarchy. At the lowest level, the components are described in several forms: naturallanguage description, logic schema, timing information, etc. The higher the level at which acomponentisdescribed,themoreistheambiguity.ThishasmotivatedthePrietoDiaz’sclassificationscheme. Prieto-Diaz’s classificationscheme:Eachcomponent isbestdescribed usinga number ofdifferentcharacteristicsorfacets.For beclassifiedusingthefollowing: 217 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal example,objectscan

ISBN : 978-81-963532-2-3 (E-Book) Searching- The domain repository may contain thousands of reuse items. A popular searchtechnique thathasprovedtobe very effectiveisone thatprovidesawebinterface totherepository.Usingsuchawebinterface,onewouldsearchanitemusinganapproximat eautomated search using key words, and then from these results do a browsing using the linksprovided to look up related items. The approximate automated searchlocates products thatappear to fulfill some of the specified requirements. The items located through the approximatesearch serve as a starting point for browsing the repository. These serve as the starting point forbrowsing the repository. The developer may follow links to other products until a sufficientlygood match is found. Browsing is done using the keyword-to-keyword, keyword-to-product, andproduct-toproductlinks.Theselinkshelptolocateadditionalproductsandcomparetheirdetailed attributes. Finding a satisfactorily item from the repository may require several locationsof approximate search followed by browsing. With each iteration, the developer would get abetterunderstandingoftheavailableproductsandtheirdifferences.However,wemustre member that the items to be searched may be components, designs, models, requirements, andevenknowledge. Repository maintenance - Repository maintenance involves entering new items, retiring thoseitems which are no more necessary, and modifying the search attributes of items to improve theeffectiveness of search. The software industry is always trying to implement something that hasnot been quite done before. As patterns requirements emerge, new reusable components areidentified, which may ultimately become more or less the standards. However, as technologyadvances,somecomponentswhicharestillreusable,donotfullyaddressthecu rrentrequirements. On the other hand, restricting reuse to highly mature components, sacrifices one ofthatcreatespotential reuseopportunity.Making a product availablebeforeit hasbeen thoroughly assessed can be counter productive. Negative experiences tend to dissolve the trust in the entirereuseframework. Application generator -The problem- oriented languages are known as application generators.Application generators translate specifications into application programs. The specification isusually written using 4GL. The specification might also in a visual form. Application generatorcanbeappliedsuccessfullytodataprocessingapplication,userinterface,andco mpilerdevelopment. 218 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Advantagesofapplicationgenerators Application generators have significant advantages over simple parameterized programs. Thebiggest of these is that the application generators can express the variant information in anappropriate language rather than being restricted to function parameters, andthefactthat named ortables.Theotheradvantagesincludefewererrors,easiertomaintain,substantially reduceddevelopmenteffort, theimplementationdetails. oneneednotbotherabout Shortcomingsofapplicationgenerators Application generators are handicapped when it is necessary to support some new concepts orfeatures. Application generators are less successful with the development of applications withcloseinteraction with hardwaresuch as real-time systems. Re-useatorganization level Achievingorganization-level reuserequires adoption ofthefollowingsteps: • Assessingaproduct’spotentialforreuse • Refiningproducts for greater reusability • Enteringtheproduct inthe reuse repository Assessing a product’s potential for reuse. Assessment of components reuse potentialcan be obtained from an analysis of a questionnaire circulated among the developers. Thequestionnaire canbe devisedtoaccessa component’sreusability.Theprogrammersworking in similar application domain can be used to answer the questionnaire about theproduct’s reusability. Depending on the answers given by the programmers, either thecomponentbetakenupforreuseasitis,itismodifiedandrefinedbeforeitisentere dinto the reuse repository, or it is ignored. A sample questionnaire to assess a component’sreusabilityis thefollowing. • Isthecomponent’sfunctionalityrequiredforimplementationofsystemsint hefuture? • Howcommonisthecomponent’sfunctionwithinitsdomain? • Wouldtherebeaduplicationoffunctionswithinthedomainifthecomponent istakenup? • Isthe componenthardwaredependent? • Isthedesignofthecomponentoptimizedenough? • Ifthecomponentisnonreusable,thencanitbedecomposedtoyieldsomereusablecomponents? constants, 219 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Canweparameterizeanon-reusablecomponent sothat itbecomesreusable? Refining products for greater reusability. For a product to be reusable, it must berelatively easy to adapt it to different contexts. Machine dependency must be abstractedout or localized using data encapsulation techniques. The following refinements may becarriedout: • Name generalization: The names should be general, rather than being directlyrelatedto a specificapplication. • Operation generalization: Operations should be added to make the componentmoregeneral.Also,operationsthataretoospecifictoanapplicatio ncan be removed. • Exception generalization: This involves checking each component to see whichexceptions it might generate. For a general component, several types of exceptionsmighthaveto be handled. • Handlingportabilityproblems:Programstypicallymakesomeassumpti onregardingtherepresentationofinformationintheunderlyingmachine.Thes eassumptions are in general not true for all machines. The programs also often need tocall some operating system functionality and these calls may not be same on allmachines. Also, programs use some function libraries, which may not be available onallhostmachines.Aportabilitysolutiontoovercometheseproblemsisshow ninfig. 41.1. The portability solution suggests that rather than call the operating system andI/O procedures directly, abstract versions of these should be called by the applicationprogram. Also, all platform-related calls should be routed through the portabilityinterface. One problem with this solution is the significant overhead incurred, whichmakes it inapplicable to many real-time systems and applications requiring very fastresponse. 220 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) Fig. 41.1:Improvingreusabilityofa component byusingaportabilityinterface Factorsthatinhibitaneffectivereuseprogram In spite of all the shortcomings of the state-of-the-art reuse techniques, it is the experience ofseveral organizations that most of the factors inhibiting an effective reuse program are non-technical.Some ofthesefactors arethefollowing.  Needforcommitmentfromthetopmanagement.  Adequatedocumentationtosupportreuse.  Adequate incentive to reward those who reuse. Both the people contributing new reusablecomponents and those reusing theexisting components should be rewarded to start areuseprogram and keep it going.  Providing access to and information about reusable components. Organizations are oftenhesitanttoprovideanopenaccesstothereuserepository for thefearofthereusecomponentsfinding awayto their competitors. 221 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

ISBN : 978-81-963532-2-3 (E-Book) REFERENCES BIBLIOGRAPHY 1. “FundamentalsofSoftwareEngineering”,RajibMall,Prentice-HallofIndia. WEBLIOGRAPGY 2. http://www.tutorialspoint.com/ 222 Software Engineering Keerthana P, Manasa KN, Ganga D Bengal

/Author details Prof. KEERTHANA P, is an Assistant Professor at Reva University, School of Computer Science and Engineering, Bengaluru, India. She has earned a Bachelor of Engineering in Computer Science and Engineering from Visvesvaraya Technology University. She earned her Master of Engineering in computer science and engineering from REVA University and Currently pursuing a Phd in computer science and engineering at REVA University. She is conducting research in the field of Machine Learning and Deep Learning and Artificial Intelligence. Prof. Manasa KN, is an Assistant Professor at Reva University, School of Computer Science and Engineering, Bengaluru, India. She earned a Bachelor of Engineering in Computer Science and Engineering from Nitte Meenakshi Institute of Technology, Bengaluru, Karnataka in 2012. She earned her Master of Engineering in Information Technology from University Visvesvaraya College of Engineering in 2015. She is conducting research in the field of Image Processing, Computer Vision, Machine Learning and Deep Learning. Prof. Ganga D Benal Technology , Bengaluru, , is an Assistant professor at Cambridge Institute Of India. She earned a Bachelor of Engineering in Information Science and Engineering from Atria Institute of Technology (VTU), Bengaluru, Karnataka in 2019. She earned her Master of Technology in computer science and engineering from REVA University in 2021. She is conducting research in the field of Machine Learning and Deep Learning. ISBN: 978-81-963532-2-3 (E-BOOK) Title: - SOFTWARE ENGINEERING Author: - KEERTHANA P MANASA KN GANGA D BENAL ISBN: - xxxxxxxxxxxxxx Price: 750/

1 Publizr

Index

1. 1
2. 2
3. 3
4. 4
5. 5
6. 6
7. 7
8. 8
9. 9
10. 10
11. 11
12. 12
13. 13
14. 14
15. 15
16. 16
17. 17
18. 18
19. 19
20. 20
21. 21
22. 22
23. 23
24. 24
25. 25
26. 26
27. 27
28. 28
29. 29
30. 30
31. 31
32. 32
33. 33
34. 34
35. 35
36. 36
37. 37
38. 38
39. 39
40. 40
41. 41
42. 42
43. 43
44. 44
45. 45
46. 46
47. 47
48. 48
49. 49
50. 50
51. 51
52. 52
53. 53
54. 54
55. 55
56. 56
57. 57
58. 58
59. 59
60. 60
61. 61
62. 62
63. 63
64. 64
65. 65
66. 66
67. 67
68. 68
69. 69
70. 70
71. 71
72. 72
73. 73
74. 74
75. 75
76. 76
77. 77
78. 78
79. 79
80. 80
81. 81
82. 82
83. 83
84. 84
85. 85
86. 86
87. 87
88. 88
89. 89
90. 90
91. 91
92. 92
93. 93
94. 94
95. 95
96. 96
97. 97
98. 98
99. 99
100. 100
101. 101
102. 102
103. 103
104. 104
105. 105
106. 106
107. 107
108. 108
109. 109
110. 110
111. 111
112. 112
113. 113
114. 114
115. 115
116. 116
117. 117
118. 118
119. 119
120. 120
121. 121
122. 122
123. 123
124. 124
125. 125
126. 126
127. 127
128. 128
129. 129
130. 130
131. 131
132. 132
133. 133
134. 134
135. 135
136. 136
137. 137
138. 138
139. 139
140. 140
141. 141
142. 142
143. 143
144. 144
145. 145
146. 146
147. 147
148. 148
149. 149
150. 150
151. 151
152. 152
153. 153
154. 154
155. 155
156. 156
157. 157
158. 158
159. 159
160. 160
161. 161
162. 162
163. 163
164. 164
165. 165
166. 166
167. 167
168. 168
169. 169
170. 170
171. 171
172. 172
173. 173
174. 174
175. 175
176. 176
177. 177
178. 178
179. 179
180. 180
181. 181
182. 182
183. 183
184. 184
185. 185
186. 186
187. 187
188. 188
189. 189
190. 190
191. 191
192. 192
193. 193
194. 194
195. 195
196. 196
197. 197
198. 198
199. 199
200. 200
201. 201
202. 202
203. 203
204. 204
205. 205
206. 206
207. 207
208. 208
209. 209
210. 210
211. 211
212. 212
213. 213
214. 214
215. 215
216. 216
217. 217
218. 218
219. 219
220. 220
221. 221
222. 222
223. 223
224. 224
225. 225
226. 226
227. 227
228. 228

Home