STRUCTURED A NALy AND TOOLS sis requirements. Thus, it is essential that the diagrai back to the user the essential aspects required of the software to be produced, Requireraent analysis is the activi ty during which the requirements gathered during elicitation are analysed for conflicts ambiguities, in consistencies, missing requirements or extra requirements, The requirements engineer must reconsile these conflicts through a process of negotiation, Customers users are asked to rank requirements and then discuss conflicts in priority. Risks associated with each requirement are identified and analyzed. Rough estimates of development effort are made and used to assess the impact of each requirements on project cost and delivery time, Using an interactive approach, requirements are eliminated, and/or | Modified so that each party achieves some measure of satisfaction. Even | &perienced analyst take considerable time to understand the ene nied of the customer. They know that without a clear understanding of the Pra aris is almost impossible to develop a satisfactory solution. a svadeu loped and collected all the required information regarding the system tot the structure and built, than the system part has to be specified. 5.1 STRUCTURED ANALYSIS scoarstesal desaiiiror® i alysis is to transform t y out the top- Problem inte ae act mode, Structa mals ed in thegiven problem iti f high level function is functional en Er net raphically. During structural analysis repre: a she system performs i. ch function that : decomposition ofthe system takes place. each Function et he i i decompos' identified during structural omalyzed and hierarchical design all functions eae ea ae called analysts during structure) fracture. This modu tdirectly implemented clea Se Happed ‘pritie given problem and it ¢ re architecture ; : uage- Using a conventional programming languae! a3 ms and specifications communicate4 Structural analysis have the following objectives = 1. To describe what the customer requires 2. Tocetabliah a basis for the creation of a software design, 3. To define a set of requirements that can be validated once the softy, wen ical tation of the sof i ical representation of the soft By structured analysis technique a grap! system is made which is under development. It Is part of SA/SD methodology SAID methodology consists of two activities i.e, structured analysis (5A) any structural design (SD). 5.2 TOOLS FOR STRUCTURAL ANALYSIS We know the aim of structural analysis is to transform the textual description, ofa problem into an graphical model. For representing a problem into an Staphicg model we need different tools. These tools are used for structural analysis tg represent graphically, By using tools, all functions identified during structurs analysis are mapped to a module structure. By structural analysis tools we Tepresent a software system graphically which is under development. These tool, are very important during the designing phase. The user reviews the diagram and ‘specification to determine if the software developers has understood the requirements. It is also essential that the diagram and specifications ar communicated back to the user which are essential for the software to be developed, These tools are the basis for the creation o fa software design. ‘There are different tools that are used for structural analysis : 1, Data flow diagram (DID). Data dictionary, }. Decision table. Decision trees. . Event list. . Context diagram (CD). Entity relationship diagram (ERD). Structured English, 9. State transition diagram (STD), 55 DATA FLOW DIAGRAM (OFD) Data Flow Diagrams (DED) are used widely for mod, ets They have been used for many Ke geer Modeling the requirem Years prior to the advent of computers. DFD sho the flow of data through a system. The system may be a company, an organization a set of procedures, a computer hardware system, a software system or #! combination of the preceding. The DFD is also known se a data flow graph ot? bubble chart. The following observations about DEDs are 1. Allnames should be unique. This maki DFD. way PNAnawn important [DAV 190} : es it easier to refer to items in!Bb Chapter 5: Structured Analysis and Tools 95 2, Remember that a DFD is not a flow chart. Arrows in a flow chart tepresent the order of events; arrows in DFD represent flowing data. A DED does not imply any order of events. 3. Suppress logical decisions. If we ever have the urge to draw a diamond shaped box ina DFD suppress that urge! A diamond shaped box is used in flow charts to represent decision points with multiple exit paths of which only oneis taken. This implies an ordering of events, which makes no sense inaDFD. 4. Do not become bogged down with details. Defer error condition and error handling until the end of the analysis. Standard symbols for DFDs are derived from the electric circuit diagram analysis and are shown in Fig.5.1. Function Data Flow Used to connect processes to each other, to sources or sinks; the arrow head indicates direction todata flow. Process Performs some transformation of input data toyield output data. Source or sink A source of system input or sink of system (External Entity) outputs. Data store ‘A repository of data; the arrow-heads \ (© indicate net inputs and net outputs o store. Fig, 5.1. Symbols for data flow diagrams. A circle (bubble) shows a process that transforms data inputs into data outputs. A curved line shows flows flow of data into or out of process or data store. A set of parallel lines shows a place for the collection of data items. A data store indicates that the data is stored which can be used at a later stage or by the other processes in a different order. The data store can have element or group of elements. Source or sink is an external entity and acts as a source of system inputs or sink of system outputs. Leveling : The DFD may be used to represent a system or software at any level of abstraction. In fact DFDs may be partitioned into levels that represent increasing information flow and functional detail. A level-0 DFD, also called a fundamental system model or context diagram represents the entire software elements as a single bubble with input and output data indicated by incoming: and outgoing arrows, respectively (PRES2K). Then the system is decomposed and tepresented as a DFD with multiple bubbles. Parts of the system represented by each of these bubbles are then decomposed and documented as more and more detailed DFDs. This process may be repeated at as many levels as necessary until the problem at hand is well understood. It is important to preserve the number of inputs and outputs between levels; this concept is called leveling by DeMacro. Thus, if bubble “A” has two inputs, x, and x, and one output y, then the expandedud Software Engincerng al inputs and one e; DFD, that represents "A” should have exactly two external inp *temay output as shown in Fig. 5.2. Fig, 5.2. Level-O DFD. i f result management system j The level-0 DFD, also called context diagram o b shown, inFig.53. As the bubbles are decomposed into less and less abstract bubbles, the corresponding data flow may also need to be decomposed. Data entry operator ‘Subject info Marks entry Lea unepering ‘Student Result, ‘Management, Student info entry Administrator User Account Maintenance Student info Mark sheets feports generated —_ generated Student performance report generated Fig: 5.3. Olevel DFD or result management system, Example : DFD for evaluation of arithmetic expression : (a+b)*(c+a"d) tir HAD_ Chapter 5: Structured Analysis and Tools ” DATA DICTIONARIES Families of DFDs can become quite com ma , plex. One way to manage this complexity is to augment DFDs with data dictionaries (DD), Data dictionaries are imply repositories to store information about all data items defined in DFDs. At ithe requirements stage, the data dictionary should at least define customer data fems, to ensure that the customer and developer use the same definitions and nologies. Typical information stored includes : vy Name of the data item y Aliases (other names for item) y Description/purpose v Related data items. v Range of values v Data structure definition/form. The name of the data item is self explanatory. Aliases include other names by ch this data item is called e.g., DEO for data entry operator and DR for deputy sgistrar, Description/purpose is a textual description of what the data item is d for or why it exist. Related data items capture relationships between data atems e.g, total marks must always equal to internal_marks plus external_marks. Range of values records all possible values, e.g,, total marks must be positive and between 0 to 100. Data flows capture the names of the processes that generate or receive the data item. If data items primitive, then data structure definition/form Captures the physical structure of the data item. If the data is itself data aggregate, en data structure definition/form captures the composition of the data items in rms of other data items. The mathematical operators used within the data dictionary are defined below in Table 5.1. TABLE 5.1: DATA DICTIONARY NOTATION AND. MATHEMATICAL OPERATORS Meanings z consists of data elements x and y z consists of either data element x or y Zaxty = [x/y] zx z consists of an optional data element x z= ylx} z. consists of y or more occurrences of data element x z= (xly z consists of y or fewer occurs of data element x z consists of some occurrences of data element x which are between y and m. z= ylxlm The data dictionary can be used to: ¥ Create an ordered listing of all data items. Y Create an ordered listing of a subset of data items. Find a data item name for a description. esign the software and test cases.vv Software Engineerin 98 hy 5S DECISION TABLES A decision table is a tabular representations of conditions and actions, ' used when the process logic is very complicated, involves, multiple conditi ; ht is not possible to represent the process logic efficiency with structural Engl, Decision tables provides a notation that translated actions and conditions into tabular form. The table is difficult to misinterpret and may even be used a5 machine readable input to a table driven algorithm. The main parts of decision tables are : 1, Conditional stubs : It lists all the conditions relevant to the decision, 2. Action stubs : It lists all the possible actions that will take place fora valid set of conditions. a a 3. Rules : It specifies which set of conditions will trigger which action, A decision table is divided into four quadrants. The upper left hand quadrarg contains a list of all conditions. The lower left hand quadrant contains a list of all actions that are possible based on combinations of conditions. The right hang quadrants form a matrix that indicates condition combinations and the corresponding actions that will occur for a specific combination. Therefore, each column of the matrix may be interpreted as a processing rule. The following steps are applied to develop a decision table : 1, List all actions that can be associated with a specific procedure (or module) 2. Listall conditions (or decisions made) during execution of the procedure 3. Associate specific sets of conditions with specific actions eliminating impossible combinations of conditions; alternatively, develop every Possible permutation of conditions, Rules Conditions t[els]ales Regularcustomer | 7 Silver customer TI Gold eee taal 7 Special discount Actions No discount Apply 8% discount Apply 15% discount Pere count | Apply additional x Percent discount ai Chapter 5: Structured Analysis and Tools 99 4, Define rul indi Pe ie enaeatng pias action(s) occurs for a set of conditions. from an informal use case that has just been Serene ait system (shown in Fig. 5) just been proposed for the print shop Three types of customers are defi ined a regular customer, a sil anda gold customer Ihese ype ve asgned by tee of Seon customer does with the print shop over a 12 month period}. A regular cust receives normal print rates and delivery. A silver customer gee an 8 sercent discount on all quotes and is placed ahead of all regular customers in thejob ia ‘A gold customer gets a 15 percent reduction in quoted prices and is placed shead of both regular and silver customers in the job queue. A special discount of x cent in addition to other discounts can be applied to any customer's quote at the discretion of management. an Fig. 5.4 illustrates a decision table representation of the preceding informal use-case. Each of the six rules indicates one of six viable conditions. As a general mule, the decision table can be used effectively to supplement other procedural design notation. 5.6 ENTITY RELATIONSHIP DIAGRAMS Another tool for requirement analysis is the entity relationship diagram, often called as “E-R diagram” [CHEN76]. It is a detailed logical representation of the data for an organization and uses three main constructs i.e., data entities, relationships and their associated attributes. Entities : An entity is a fundamental thing of an organization about which data may be maintained. An entity has its own identity, which distinguishes it from each other entity. An entity type is the description of all entities to which a common definition and common relationships and attributes apply. Consider a university that offers both regular and distance eduction programmes. These programmesare offered to national and international students. Programmes and student and both entity types in this example. Regular and distance education are entities of PROGRAMME whereas national and international are entities of STUDENT. We use capital letters in naming an entity type and in an ER diagram the name is placed inside a rectangle representing that entity as shown in Fig. 6.5. STUDENT PROGRAMME, Fig. 55. Two entity types in an E-R diagram. Relationship Arelationship is a a ; nships reason for associating two entity types. These relatior B ty typ ve two entity types. are sometimes called binary relationships because they invol ciated. Some forme of data model allow more than two entity types to be assoC by STUDENT is registered for PROGRAMME. Relationships are t¢PT* diamond notation in the E-R diagram as shown in Fig. 5.6.-d Analysis and Tools 105 Fig. 5.14. Context diagram. In other words it is a diagram in which working of the whole organization is nted by a single process and its interaction with external agents is shown ntext diagram for examination system are shown Faculty Examination Controt ‘System Establishment section Fig. 5.15, A sample context diagram. |58-DECISION TREES A decision tree is a classifier expressed as a recursive partition ee ena Space. The decision tree consists of nodes that from a rooted tree, a ae directed tree with a node called “root” that has no incoming edges. A eel have exactly one incoming edge. A node with outgoing edges is106 Software Engineering \ or test node. All other nodes are called leaves (also known as terminal or decig, odes). In a decision tree, each internal node splits the instance space into fet | more sub-spaces according to a certain discrete function of the input attrib | values. In the simplest and most frequent case, each test considers a single attrib such that the instance space is partitioned according to the attribute's value, }, Ute, case of numeric attributes, the condition refers to a range. *IN the Each leaf is assigned to one class representing the most appropriate ta value, Alternatively, the leaf may hold a probability vector indicating probability of the target attribute having a certain value. Instances are classi” by navigating them from the root of the tree down to a leaf, according tg 4 outcome of the tests along the path, Figure 5.16 describes a decision tree that req, th | whether or not a potential’ customer will respond to a direct mailing. Inter,, | odes are represented as circles, whereas leaves are denoted as triangles, Now that this decision tree incorporates both nominal and numeric attributes, Gigs’) this classifier, the analyst can predict the response of a potential customer (| sorting it down the tree), and understand the behavioural characteristics of ® entire potential customers population regarding direct mailing. Each node i labelled with the attribute it'tests, and its branches are labelled with ig corresponding values. te i Fig. 5.16. Decision tree presenting response to direct mailing. In case of numeric attributes, decision trees i interp" asa cocione iar i en rs cnt oma makers prefer less complex decision trees, since th¢y may be considered ™ comprehensible. Furthermore, according to Breiman, the tree complexity Ms) crucial effect on its accuracy. The tree complexity is explicitly controlled by stopping criteria used and. the pruning method employed, Usually the complexity is measured by one of the following metrics: the total number tno total number of leaves, tree depth and number. of attributes used. Decisi°, induction is closely related to rule induction, Each path from the root of 24° tree to one of its leaves can be transformed into a rule simply, by, conjol™chapter 5: Structured Analysis and Tools 5 107 iets 01078 the path to form the antecedent part, ar lethe cass value. For example, one of the paths rule: “yf customer age is less than or equal the tomer is “Male” —then the customer will get can then be simplified to improve its c rule sete tnd possibly its accuracy. There are three types of nodes in a decision tree : y Decision nodes ind taking the leaf’s class prediction in Fig. 5.16 can be transformed into to or equal to 30, and the gender of Tespond to the mail”. The resulting ‘omprehensibility to a human user, y Chance nodes y Terminal nodes. 5,10 STRUCTURED ENGLISH ‘ Itisa subset ‘of english language that support language construct to represent sequence, repetition and conditional statement in order to specify the process details. It is subset of english with restrictions on usage. Each sentence must be as follows: y Analgebraic equation, ¢.g., X= (Y *(Z+2)/Q+14, or ¥ Consist of a simple imperative sentence with a verb and an object * eg., Read next order eg., Display result to screen can use IF.... THEN....ELSE CONSTRUCTION. can use CASE construction can use loop construction object must be defined in the analysis or must be a local term defined for that process only. If define some acceptable verbs like : * GET/READ * FIND * ADD n * SUBTRACT * MULTIPLY * COMPUTE * MOVE *° DELETE * REPLACE * SORT We define other verbs or necessary, Meaning, but each must have a clear and specific For example : Consider an example of calculating (= rate108 Software Engineering Its specification in structured english are given as : If good are Texable DOCASE CASE good-type = “Food” Set tax-rate to 0 CASE good-type = “vehicle” Set tax-rate to 20 CASE good-type = “clothes” Set tax-rate to 40 Otherwise Set tax-rate to 15 ENDCASE ELSE . write tax not applicable to results data store ENDIF There are some restriction in structured english i.e., no more than three levels of nesting is used and use indentation to show level of nesting. 5.11 STATE TRANSITION DIAGRAM (STD) State transition diagram represent a process specification for a control bubble ina data flow diagram. It is used only for control processes It have four components: ¥ States ¥ Transitions ¥ Conditions ¥ Actions. It can be levelled like DFDs. It must have one initial state and may have multiple final states, For states and transitions consider the example of answering machine system. The transition diagram and states are shown below : Waiting for call Answering CALLSOFTWARE IMPLEMENTATION AND MAINTENANCE NN EEE Over three decades ago, software maintenance was characterized [CAN 77 as an “iceberg”. We hope that what is immediately visible is all there is to it, by we know that an enormous mass of potential problems and cost lies under the surface. In the early 1970s, the maintenance iceberg was big enough to sink an aircraft carries. Today, it could easily sink the entire navy! The maintenance of existing software can account for over 60 percent of all effort expended by a development organization and the percentage continues fo rise as more software is produced. Why so much maintenance is. required and why so much effort is expanded. Osborne and chik of sky [OSB 90] provide a Partial answer : Much of the software we depend on today is on average 10 to 15 years old. Even when these programs were created using the best design and coding techniques known at the time, they were created when Program size and storage space were principle concerned. They were then migrated to new platforms, adjusted for changes in machine and operating system technology and enhanced to meet new user needs-all without enough regard to overall architecture. The result is thé poorly designed structures, poor coding, poor logic and poor documentation of the software system. Another reason for the software maintenance problem is the mobility of software people. It is likely that the software team that did the original work is no longer around. Worse, subsequent generation of software people have modified the system and moved on. Today, there may be no one left who has any direct knowledge of the legacy system, Software maintenance is a task that every development group has to face when the software is delivered to the customer's site, installed and is operational. Therefore, delivery or release of software inaugurates the maintenance phase of software life cycle, Despite the itis routinely the poorly managed headache that nobody wants to do. — ss am %215 SOFTWare - “The term / MAINTENANCE roduct after; Software maintenance’ denotes any changes made to a software "Software ei been delivered to the customer. According, to (Benett 91), software syst enance can be defined as a set of activities. Undertaken on a ‘stem following its release for operational use", enhanstware Maintenance isa very broad activity that includes error corrections, ments of capabilities, deletion of obsolete capabilities, and optimization. Because change is inevitable, mechanisms must be developed for evaluating, controlling and making modification. Maintenance work Of a software is changes made in the software after i operation. The purpose is to preserve the value of software over time. The value can be enhanced by expanding the customer base, meeting additional requirements, becoming easier to use, mere efficient and employing newer technology. The maintenance phase of software life software product performs useful task. Typi software product spans our one or two years, for five to ten years. It should be observed that part of the software development cycle. Enhancement and adoption of software re-initiates development in the analysis phase, while correction of software problems may reinitiate the development cycle in the analysis phase, the design phase, or the implementation. : cycle is the time period in which a ically, the development cycle for a while the maintenance phase spans software maintenance is an integral Analysis activities during software maintenance involve understanding the scope and effect of a desired change, as well as the constraints on making the change. Design during maintenance involves redesigning the product to incorporate the desired changes. The changes must then be implemented, internal documentation of the code must be updated, and the new test cases must be designed toaccess the adequacy of the modification, Updated versions of the software (code and supporting documents) must then be distributed to various customer sites, and configuration control records for each site must be updated. All of these tasks must be accomplished using a systematic, orderly approach for tracking and analysis of change requests, and ‘careful redesign, teimplementation, revalidation and redocumeniation of the changes. Otherwise, the software product will quickly degrade as.a result of the maintenance process. 8.2 COST OF MAINTENANCE The cost of system maintenance represent a large proportion of the budget of Most organisations that use software system. Software maintenance cost are the Greatest cost incurred in developing and using a software system, In general, these fosts are under estimated when the system is designed and implemented. laintenance costs vary widely from one application to another but on average, they seen to be between two or four times of the development costs for large embedded software system. . | Itis usually cost effective to invest éffort when designing and implementing 4 system to reduce maintenance-costs. Its more expensive to add functionality after delivery because of the need to understand the existing system and analyzeSoftware Engineering a 216 therefore £004 software engineering techni stem changes: the use of object oriented development ang ecification ad to reduction in cost of maintenance. ; se as mi . werall life time costs may decrea Ore effort jg Figure 9.1 shows how 0% maintainable system. Becaysy nt to produce a B - expended during system develop inderstanding analysis and testing, there is of the potential red hen the system is developed for maintainability. fo, significant multipli f 25000 are invested in making the system system 1 extra kaa aeaiy is a saving of © 100000 in maintenance Costs over the more maintenance. mn ‘This proves that a percentage increase in development costs life tine of ne parable werall system costs. results i the impact of Sy such as precise SP configuration management, a percentage decrease in © system 1 System 2 050 100 150 200 250 300 350 400 450 500 550 600 BR development cost ZZ wainenance cs} ‘Fig, 9.1. Development and maintenance cost. One important reason why maintenance cost ate high is that it is more expensive to add functionality after a system is in operation than itis to implement the same functionality during development. 9.3. TYPE OF MAINTENANCE 1 -gTnt only thing that remain constant in lif is CHANGE". As the specification re computer system change, ‘reflecting chariges in the external world, so must aoe Bette More than two-fifths of maintenance activities 2° ions and modification requested b jor categones Or sofas rec acaton requested by the users, Thats PEAR Meee ai eereueative maintenance: Perfective' maintenance also known a5 es ecient of preventive maintenance, involves improving processing efficienY or performance, or restructuring the software to improve change ability perfect? : equi ree the enhancement in the following case : eens Processing efficiency or performance, Improving computational efficiency. nas i roving user displays and modes of interaction. pgrading external and internal documentation. y v Y v vU dit grading the’ performance characteristics of a system.i cospter? Software Implementation and Maintenance Hence, perfective maintenance refers to enhancements. | Making the product better, faster, smaller, better d gructured, with more function or reports. 217 locumented, cleaner ‘ 2. Adaptive maintenance : This type of mairitenance concerns external anges. Even if the software is errors free, itis possible tha hich the software system works will often change. t the environment in Adaptive maintenance includes modifying the software to match changes in theever changing environment. The term environment in this is context refers to the totality of all conditions and influences which act from outside upon the software, for example business rules, government policies, work patterns, software and hardware operating platforms. A change to the whole or part of this environment will require a corresponding modification of the software. The changes can be as follows : ¥ Introduction as new version of operating system, ¥. Modifying the product to be interfaced with new hardware or software. v. Moving tthe software to a different machine. Thus, this type of maintenance includes any work initiated as a consequence of moving the software to a different hardware and software platforms- compiler, operating system or new processor. 3, Corrective maintenance : Corrective maintenance refers to modifications initiated defects in the software. This type of maintenance is also called bug fixing. A defect can result from the following errors : y Designerrors. - / y Logic errors ¥ Coding errors. Design errors : It occurs when changes made to the software are incomplete, incorrect, wrongly communicated or the change request is misunderstood, Logic errors : It request from invalid test and conclusion, incorrect implementation of design specifications, faulty logic flow or incomplete test data. Coding errors : There’ are caused by incorrect implementation of detailed design and incorrect use of the source code logic. Therefore, corrective maintenance is required in the following cases : 4 ¥_ Rectification of the bugs observed while the system is in use. y Modification and revalidation of software for cot rection of errors. In the event of system failure due to an error, ‘actions are taken to restore operation of the software system. Some efrors require imm« can be corrected on a scheduled, periodic basic and other corrected, Due to pressure from management, maintena resort to emergency fixes known as ‘patching’. The nature Rives rise to a range of prob! unforeseen ripple effects. lems that include increased programs comp! ediate attention, some, are known but never ance personnel some time of this approach often lexity andSoftware Engineering ’ 218 + daptive and perfective - Corrective, adap! i chan, 4. other typeof mainenanee regs in the complenity of the sot causes Tongs term effects, Pr ire, The work is Fede vventive x to main which reflect deterionsibe. THiS work may benames “implies such thine , reduce it, re sys 3 Pine is often cee i hae eautomatic replacement of banks. of light lubrication of parts bet eendividually burn out. Since, So tware does not degray, bulbs before they oat a ‘and doesnot need maintenance toretain the Presently inthe ca etionallly That is why we have included this type of, activity lished level n Sader “other type of maintenance’ category: ae seatti from within the maintenance organiza wis activity I Ty ea trevor to understand and hence facilitate” bi see work. This include code restructuring code optimization anq Sosumentation updating. After a series of quick fixes to software, the complexity of its source code can increase to an unmanageable level, thus justifying complete the restructuring code. Code optimization can be performed to enable the programs o run faster or to make more efficient use of storage. Updating user and system documentation, though frequently ignored, is often necessary when any part of software is changed. The request come regularly to carry out maintenance activities. The request may before corrective, adaptive perfective and other type of maintenance. However, most of request are for perfective maintenance. It contains 50% efforts, ‘other type of maintenance’ is required to reduce the complexity of the code. This is not very high, itis only 4% efforts. The remaining efforts 25% of adaptive and 21% of corrective maintenance are there. This distribution of maintenance effort is shown in Fig. 92. Adaptive 25% Perfective Corrective : Fig. 9,2, Distribution of maintenance efforts, 9.4 MAINTENANCE PROCESS Once particular objecti nnel must first ha jective of maintenance is established, the maintenan 0 ve und at th satcgetaland what they are to modify. They must te that they does not affect others that they doesn erS portions of the programs i, oi sedinmoaiatonThally eye ea: Software Implementation and Maintenan chapter 9 P ce 219 isive, We correct program error add new capabilities, My optimation are done. The maintenance process consists Mig 93. delete obsolete features of four phases as shown, __-— Correct program error Add new capabilities Delete obsolete features { Phase — Optimization |}-—— Complexity Determine Maintenance Objective Program Understanding = [7 Swe Phase 2 Generate Particular Maintenance Proposal [——— Extensibity | ie |= Phase 3 Account for ripple 2 | effect “Stability Phase 4 ¥ Testing Testability Fig. 9.3. The software maintenance process. 1, Program understanding : The first phase consists of analyzing the program Forder to dealer it, Seversl attributes such as the complexity of the program, jhe documentation and the self descriptiveness of the program contribute to ibe ‘ase of understanding the program. The complexity of the program is a peeninee jhe effort required to understand the program and is usually based ea t! ah contr ; [ data flow of the program. The self descriptiveness of the Program ‘ ae °fhow clear the Program is i.e., how easy it is to read, understand an fH io 2. Generating particular maintenance proposal : The pet Fs temrentalion iSnerating a particular maintenance proposal to accomplish a ine ofboth the of the maintenance objective. This requires a Sear underseanaine as euesot /"aintenance objective and the program to be modified. Ho'Software Engine 220 ring y generating maintenance proposals for a program is primarily affected by attribute extensibility. The extensibility of the program He mesure Of the exten, to which the program can support extensions of critical function. nsists of accounting for all of the ripple a, 3. Ripple effect: The third phase con a nies of program modifications. In software, the effect of a modification may not be local to the modification, but may also affect other parts of the Program, Saeco ve offeet from the location of tite modification to the other parts of Terrains tral eet fected by the modification. One aspect of this ripple effects logical or functional is nature. ‘Another aspect of this ripple effects concerns the performance of the program. Since a large-scale programs usually has boy, functional and performance requirements, it is better to understand the potentia} effect of a program modification from both a logical and a performance point of bute affecting the ripple effect as a consequence ofa program view. The primary attril sequence of modification is the stability of the program. Program stability is defined as the resistance to the amplification of changes in the program. 4. Modified program testing: The fourth phase consists of testing the modified program to ensure that the modified program has at least the same reliability level as before. It is important that cost-effective testing techniques be applied during maintenance. The primary factor contributing to the development of these cost-effective techniques is the testability of the program. Program testability is defined as a measure of the effort required to adequately test the program according to some well-defined testing criterion. ; Maintainability : Each of these four phases and_-their associated software quality attributes are critical to the maintenance procures. All of these factors must be combined to form maintainability. How easy is it to maintain a program? To a large extent, that depends on how difficult the program is to understand. | Program maintainability and program understandability are parallel concept |, the more’ difficult it is to maintain, the highervits. maintainability risk ‘Maintainability may be defined qualitatively as: the ease with which software an be understood, corrected, adapted, and/or enhanced. ~ 9.5 MANAGEMENT OF MAINTENANCE Various issues regarding management of maintenance are : | 1. Defect reports : The first thin intainii duct is? I 6 g needed when maintaining a produ a mechanism for changing the product. With regard to corrective maintenance aN is, removing residual faults, if the product appears to be functioning incorrect’, then, 8 defect report should be filed by the users. This must include enou , information to enable the maintenance programmer to recreate the problem whit vey is ime sort of software failure. In addition the maintenance programm | b must indicate the severity of the defect; typical severity categor! de crit | major, normal, minor and trivial. ivplealseystiy Sates is | "Ideally, every defect reported by a’ user’should be fixed immediate practice, programming organization usually are under staffed with a backl%6/, | 4 wash, both development and maintenance. If the defect is critical, suc #" I ‘ in| Ca9: Software Implementation and Maintenance ‘ 221 ortet 4 ' iI ro! ip ees, imme # - . #emaintenance programmer should first consult the defect report fi ; port file. Thi ait all reported defects thathave not yet been fixed, together with. ‘afpestions Z working around them, that'is, ways for the user to by pass the portion of the ve, until such time as the defect can be fixed. If the defect has been reported se ysly, any information in the c.-fect file should be given to the uset. But if to be anew defect, then. the inaintenance programmer ‘atthe user report appears jeuld study the problem and attempt to find the cause and‘a way to fix it. ‘The maintenance programmer's conclusions should be added to the defect file, together with any supporting documentation. Such as listings, designs ‘pd manuals used tO arrive at those conclusions. The manager in charge of post- very maintenance should consult the file regularly, setting priorities for the carious fixes. The file also should contaii n the client's requests for perfective and saptive, maintenance. The next modifi ation made to the product then will be the rewith the highest priority. When copies of a product have been distributed toa atiety of sites, copies ‘of defect reports must be circulated to’all users of the product, gether with an estimate of when each defect can be fixed: Then; if thesame failure the user can consult the relevant defect 1 duct crashes the day before payday or ov i diate corrective action must be taken. Pee ee aan cee curs at another site, ‘eport to determine fit is possible to work-around 'the'defect arid:when it will be fixed. It would be preferable to fix every defect!immediately and distribute a new version of the product to all sites, of course. fm oa These is another reason why ‘defects iisually are not fixed immediately. It almost always is cheaper to make a number of changes, test them all, change the documentation, and ‘install the new version that it is to perform each change separately, test it, document it, install the new version, and then repeat the entire gycle for the riext change. ‘AS @ result, organizations prefer to accumulate non critical maintenance tasks and then implement the changes-as a group-""> 2. Authorizing changes to the product : Once a decision has been made'to mmer is assigned the task perform corrective maintenance, 4 maintenance progral of determining the fault thi iting it. After the code has been changed, the repair must be tested, as muc! uct as a whole (regression testing), Then, the document must be updated to reflect the changes In particular, a detailed description of what was changed, why it was changed. By whom and when must be added to the prologue co! Necessary, analysis design artifacts also are when performing perfective oF adaptive maintenance, the only real diffe that perfective and adaptive maintenance ar initiated by a change in require Tather than by a.defect repart. onl led would be to distril i ar ‘At this point all that would seem to be need mmer has no! Version to the users.‘ But, what if the maintenance progr oe os i st be subjected (057 ie distributed, it must be Ss! ibj ected Mo mpers.of mentsSoftware Engineer mm mn nt that the SQA. group remain managerially independen; programmer. Itis importa Iso is fault prone. Testing during For those same reasons, maintenance a maintenance is difficult and time consuming. ‘Another area in which management must ensure that procedures are followeg ily is when the technique of baselines and private copies is used. Suppose g ramer wishes to change Tax provision class. The programmer makes copie, of tax provision class andall the other code artifacts needed to perform the requireg maintenance task; often this includes all the other classes in the product. The programmer makes the necessary changes to Tax provision class and tests them, Now, the previous version of Tax provision class is frozen and the modified version of Tax provision class incorporating the changes is installed in the baseline. Buy, when the modified product is delivered to the user, it immediately crashes. What went wrong is that the maintenance programmer tested the modified version of Tax provision class using his or her private workspace copies, that is, the copies of the other code artifacts were updated by other maintenance programmer working on the same product. A third reason is that it has been estimated that the initial correction of a fault is itself incorrect some 70 percent of the time. 3. Ensuring maintainability : Maintenance is not a one-time effort. A well- written product goes through a series of versions over its lifetime. As a result, itis necessary to plan for maintenance during the entire software process. During the designs workflow, for example, information-hiding techniques should be employed; during implementation, variable names should be selected that will be meaningful fare maken programmers. Documentation should be complete, comec, A ent version of every component code artifact of the product. ii ae eae it is important not to compromise the maintainability product from the very beginning. In other word, justas software development personnel always should be conscious of the ine Roaralinery eainieetaatest ways ; ould be conscious of the inevitable ee cree ait So, software development personnel always should ly inevitable further future post-delivery maintenance. The principles established f paaeemarre u to post-delivery paca for maintainability, during development apply equally 4. Probl a lem of Repeated Maintenance: One of the more frustrating difficultié of software develo ii pment is the it constructs the product, the client cane eet Problem. As fast as the develope frustrating to the develonaest a asi the requirements, Not only ea constructed prod: oa , frequent changes cal It i ly The protien _ pair such changes add tothe cost ofthe indie completed product is td during post-delivery maintenance. They mo"! the more difficult further ‘ha the more it deviates from its original designs, documentation is likely t changes become. Under repeated maintenance the testing files may not beup aac less reliable than usual, and the regres fe. il + ¥ a whole may first have to be pease is done, the produt# en.wes s _ os Maintenance 23 The problem of the moving target; Clearly isa. management: management is sufficiently firm with the cli peginning of the project, then the requirem, ifications are signed off on until the pi est for perfective maintenance, the requirements can be frozen f. re year. In practice, it does not wastvake way. ovo months Trying to discourage additional “naintenance b changes are implemented slowly may mean that the relevant persons are repl by other prepared to do the job faster, In short, if the person who requests rey changes has sufficient clout, there is no solution to the Problem of the moving target. Y ensuring that the requested 9.6 CHARACTERISTICS OF SOFTWARE MAINTENANCE Software maintenance is becoming an important activity of a large number of organizations. This is no Surprise, given the rate of hardware obsolescence, the immortality of software product per se, and the demand of the user community to see the existing software product run on newer platform, run in newer environment, and /or with enhanced feature. When the hardware platform changes and a software product Perform some low-level functions, maintenance is necessary. Also, whenever the support environment of a software product changes, the software product requires rewash to cope up with the newer interface. For instance, a software product May need to be maintained when the Operating system. changes. Thus, every software product continues to evolve after ite development through maintenance efforts, Maintenance is look at from three different view point: ¥ The activities required to accomplish the maintenance! phase ‘and the impact of a software engineering approach on the usefulness of such activities. Y The cost associated with the maintenance phase. y.The problems that.are fre maintenance is undertaken, Measuring Maintenance chara characteristics: quently encountered when software ctéristics: There are two types of maintenance Necessary Measures : Necessary measures of maintenance are : Y Time at which problem is reported. ¥ Time lost due to administrative delay. ¥ Time required to analyze the problem. ¥ Time required for specifying which changes are to be made. ¥ Timeneeded to make the change, ¥ Time needed to test the change. Time needed to document the change. irable measures : Desirable measures are : : oe of table change implementation time to total of changes implemented.soe Software Engineering i ‘v Number of unsolved problems & time spent on these problems, ¥ Percentages of changes that introduce new faults. ¥ Number of components modified to implement a change. Software maintenance Characteristic’s can be either structed or instructeg maintenance: Structed maintenance characteristics may be conducted only if the Steps of the software engingering mythology, the waterfall cycle, one properly followed during the project development. Instructed maintenance happens when there is no good documentation, when, there is no information about the test performed etc. ‘The existence of a proper software configuration does not guarantee Problem free maintenance, but at least guarantees the reduction of wasted efforts ang increasing the quality of change. 9.7 NEED FOR SOFTWARE MAINTENANCE Maintenance is inevitable for almost any kind of product. However, most products need maintenance due to the wear and tear caused by use. On the other hand, software products do not need maintenance on this basis, but need maintenance for the following reasons : : I. Correct problem —errors undetected during software development may be found during use and require correction. ; IL, Enhance software product—over a period of time, original requirements of the software may change to reflect the customer's needs. IIL: Adaptation of-product to new Environment—with time new technologies are introduced such as new hardware, operating system etc. The software therefore must be modified to adopt to the new operating environment, 9.8 ENHANCING MAINTAINABILITY DURING DEVELOPMENT Maintenance effort can be reduced if sufficient care is taken during the development phase of the software. This can be done in the following manner: __ 2. Analysis activities: For the maintenance viewpoint, the most important activities that occur during analysis are as follows : L Develop standards and guidelines, IL Specify quality assurance products, IL Determine resources required for maintenance, IV. Identify likely product enhancements, V. Estimate cost of maintenance, : 2. Software Design: The design activities can be classified into two importatt part: ‘ L. Architectural design, IL. Detailed design. akModular systems are easier to document because each part can be a documented as an independent unit, programming individual modules in easier beca can focus on just one small, simple problem rather probiem. ee Testing and debugging individual modules be dealt, with in isolation from the rest of the Program, 5, Bugsare easier to isolate and understand, and they can be fixed without fear of introducing problems outside the module, . Well composed moclules are more reusable because they to comprise part of a solution of many problems. Als« should be easy to extract from any one of the progra another. 7:6 COUPLING Coupling between modules is the strength of interconnections between modules or a measure of interdependence among modules. Two modules with high coupling are strongly interconnected and thus, dependent on each other. Two modules with low coupling are not dependent on one another. “Loosely coupled” systems are made up of modules which are relatively independent. “Highly Coupied” system share a great deal of dependence between modules. For example if modules make use of shared global variables, ‘Uncoupled’ modules han interconnections at all; they are completely independent us shown in Fig. 7.4. A good design will have low coupling. Thus, interfaces should be carefully specified inorder to keep low value of cou pling. © O oO Oper use the programmer than a large complex - is easier because they can ry are more likely 0 a good module m and insert into ; ; (a) Uncoupled : (®) Loosely coupled : (©) Highly coupled : no dependencies some dependencies many dependencies Fig. 7.4. Module coupling. Coupling is measured by the number of interconnections between modules. For example, coupling increases as the number of calls between modules increases, orthe amount of shared data increases. The hypothesis is that design v:tth highly (Pling will have more errors. Loose coupling on the other hand, minimizes the 'terdependence amongst modules. This can be achieved in the following ways: Y Controlling the number of parameters passed amongst modules. ¥ Avoid Passing undesired data to calling module. Y Maintain parent/child relationship between calling and called modules. Y Pass data, not the control information.164 age a inimize the number of interfaces i i er module and the complexity cof each i An interes of 3s module a Used tg pass information toand from other mod fea Coupling would incre cn i is used by 01 . r increase ae Interface amo ule by oi irectand obscure interface, like direc, Dee clintere hared variables. Complexity of yy, ir i dule or using, S! using the internals of a mod ae ialek each interface is another factor affecting coupling. The m Pp interface jg the higher will be degree of coupling. The type Setar flow along the interfaces is the third major factor affecting coupling. i ere are two kinds of information that can flowalongan interface: data or comers Coupling is considereg highest if the data is hybrid, that is, some data items an some control items aa passed between modules. would like to™ interface: jules. Coup! To keep coupling low, we Classification of Coupling content, common, external, control, stam, lowest coupling (best) to highest coupling 7.6.1 Types of Coupling 0! Different types of coupling are and data. The strength of coupling from (worst) is given in Fig. 7.5. Data Coupling Stamp Coupling Control Coupling External Coupling ‘Common, Coupling Content Coupling Fig. 7.5. The types of module coupling. Give two procedures X and Y, identi in whi Gan we pro we can identify a number of ways in which (i Data coupling : The dependen is sai Data c :Thed cy between module X and Y is said tobe ditt coupled ah thls dependency is based on the fact they communicate by only passing fos ther .communicating through data, the two modules are independent data”. By eine #0 ensure that no module communication contains “tram? depen ng tt rat mca communicate only necessary data, module (ii) Sti jing: it ene amp coupling :Stamp coupling occurs between modules X and Y whe making up the sbi passed from one module to another. Since not all amides, stamp a are usually necessary in communication betwee” needs a part of a date etree cally Involves tramp data. If one procedure oY domplete'data stricture calling module should pass just that part, "ot iii) Conti ing: P eee pee Module X and Y are said to be control coupled ifthe commune by assing of contol information. This is usually accomplished module, y one module and reacted upon by the depe™ (iv) External coupling : A form of coupli em) : coupling in which a depend of other module, external to the software being aera eee :prs software Design _ ie 5 cur =, This is basically related to the communication to external tools and : n ‘ aver vai Common coupling : With common cow (o) d data. Global data areas are com I are faking a change to the common dat vs hi ‘ch access that data to evaluate th ey canbe dificult to determine which orl pling, module X and module Y monly found in Programmin, ta means tracking back to all the e effect of change. With common module is responsible for: Global: x Xe Common data area and Xy variable names Variable: My Yo Change y, to zero Increment y, Module X Module Y Module Z Fig. 7.6. Example of common coupling. 7 Having set a variable tova particular. value. Figure 7.6 shows how common coupling works. (vi) Content coupling : Content coupling occurs when module X change data ofmodule Y or when control is passed from one module to the middle of another. In Fig.77, module Y branches into Z, even though Z is supposed to be under the control of W. Module Y Goto temp Fig. 7.7. Example of content coupling.Software Engineerin 166 HESION : , 7.7 CO odule represents how tightly bound the internal elemen Cohesion oe aie another, Cohesion of a module gives the designer mie fa Serer different elements of module belong together in the same moy carats mand coupling are clearly related. Usually, the greater the cohesio, conestcin the system, the lower the coupling between modules is, “ Cohesion is a measure of the degree to while the elements of a mo functionally related. A strongly cohesive module implements functionalit related to one feature of the solution and requires little or no interaction modules. This is shown in Fig. 7.8. bd Db Fig. 7.8. Cohesion : strength of relation with in modules. Hence, an important design objective is to maximize the module cohesion and minimize the module coupling. ofeach lle ate ty that, With other 7.7.1 ‘Types of Cohesion or Classification of Cohesiveness There are seven types or levels of cohesion, These, are shown in Fig. 79. Functional Cohesion Sequential Cohesion Communicational Cohesion Procedural Cohesion “ ‘Temporal Cohesion Logical Cohesion Coincidental Cohesion Morten Best (High) Fig. 7.9. Type of module cohesion. that carries out operations X and Y, we can describe variows ween X and Y ; @ Functional cohesion : very good reason for them to Given a procedure forms of cohesion bet im into a single output datum. r culate current GPA” ot “cumulative GP are typical examples of functional cohesion,r software Design Vv coaster” “ a? sequential cohesion : X outputs some data which forms the input to Y. «a Seasons for them tobe contained in the same procedure, Fr example, nisi oe marks of individual subjects into a specific format is used to calculate ti a fe input (Or preparing the result of the students. A component is made of venience, FOF” myerecord” a8 Mpuls ‘ § (i) Communicational cohesion : X and Y both operate on the same input r contribute towards the same output data. This is okay, but we might o data « making them separate procedures. peGPAas Med to communicate/exchange data form one source for different por jonal purposes. They are together in a component for communicational neti ce. For example calculate current and cumulative GPA uses the “student (io) procedural cohesion : x and Y are both structured in the same way. This jgapoor reason for putting them in thesame procedure. Thus, procedural cohesion ovcurs in modules whose instructions although accomplish different tasks yet ree been combined because there is a specific order in which the tasks are to be completed. These types of modules are typically the result of first flow charting the olution to a program and then selecting a sequence of instruction to serve as a “ule. Since, these modules consist of instructions that accomplish several tasks that are virtually unrelated these types of modules tend to be less maintainable. (@) Temporal cohesion : X and Y both must perform around the same time. so, module exhibits temporal cohesion when it contains tasks that are related by the fact that all tasks must be executed in the same time-span. The set of functions responsible for initialization, start up activities. Such as setting program counters orcontrol flags associated with programs exhibit temporal cohesion. This is not a good reason to put them in same procedure. (ci) Logical cohesion :X and Y perform logically similar operations. Therefore, logical cohesion occurs in modules that contain instructions that appear to be related because they fall into the same logical class of functions. Considerable duplication can exist in the logical strength level. For example, more than one data item in an input transaction may be a date. Separate code would be written to check that each such date is a valid date. (vii) Coincidental cohesion : X and Y hcre no conceptual relationship other than shared code. Hence; coincidental cohesion exists in modules that contain instructions that have little or no relationship to one another, That is, instead of creating two components, each of one part, only one component is made with two unrelated parts. For example, check validity and print is a single component with two parts, Coincidental cohesion is to be avoided as far as possible. 7.8 RELATIONSHIP BETWEEN COHESION AND COUPLING ‘The essence of the design process is that the system is decomposed into parts to facilitate the capability of understanding and modifying a system. Projects Tarely gets into trouble because of massive requirement changes. These changes can be properly recognized and properly reviewed. If the software is not properly Modularized, a host of seemingly trivial enhancement or changes will result into death of the project. Therefore, a good software design professes clean decomposition ofaproblem into modules and the: arrangement of these modules in a neat hierarchy.Software Engineering a 168 Therefore, a software engineer must design the modules with goal of high cohesion \d low coupling. rh * a eat example of a system that has high cohesion and low coupling is the ‘ph a lay’ feature of the computer system. Various slots in the mothetboar, oftheaystem simply facilitate to add or remove the various services/functioy without affecting the entire system. This is because the add on components the services in highly cohesive manner. Figure 7.10 provide a graphical r cohesion and coupling. malities Provide review of High Coupling Low Coupling Fig. 7.10. View of cohesion and coupling. Module design with high cohesion and low coupling characterizes a module as black box when the entire structure of the system is described. Each inodule can be dealt separately when the module functionality is described. 7.9 SOFTWARE DESIGN STRATEGIES These are mainly two strategies used for software design : Y Top-down design, t Y Bottom-up design. I The above strategies are discussed as, Top-down Design Strategy : Top-down isa design'strategy.in which the Problem is divided into : small problems. The design activity must begin with the analysis of the requirements, definitions and should not consider implementation details at first, Top-down design has the following objectives: Y To systematize the design process, Y To producea modular Program design,’ *) Y To provide a frame effectively proceed, is A software project is decomposed into subprojects, and this procedure Tepeated until the subt, asks have become so simple that an algorithm can be vs es asolution. In top-down design, system components are derived from Pol ecifications, iHeviC MOrTAIaA 6S work in which the problem solving can mor