Presentation is loading. Please wait.

Presentation is loading. Please wait.

Unified theory of software evolution Reengineering – Business process reengineering and software reengineering BPR model – Business definition, process.

Similar presentations

Presentation on theme: "Unified theory of software evolution Reengineering – Business process reengineering and software reengineering BPR model – Business definition, process."— Presentation transcript:


2 Unified theory of software evolution Reengineering – Business process reengineering and software reengineering BPR model – Business definition, process identification, Process evaluation, process specification and design, prototyping, refinement and instantiation Software reengineering process model – Inventory analysis, document restructuring, reverse engineering, code restructuring, data restructuring, forward engineering Reverse engineering 2

3 Modification of source code and/or data In general, no modification of all program architecture Focus on design details of individual modules and local data structure If it involves program architecture, it becomes forward engineering Restructuring occurs when the basic architecture is solid 3

4 Better design to perform the same function Different techniques – Warnier’s logical simplification techniques Boolean algebra Conversion of “spaghetti-bowl” code into structured program – Reengineering tools Resource exchange diagram maps program module and resources Program architecture is restructured to minimize coupling 4

5 Analysis of source code prior to data restructuring Data definitions, file descriptions, I/O, and interface descriptions are evaluated Objective is to extract data related information It is also called data analysis Data redesign – Data record standardization – Data name rationalization – Physical modifications to existing data structures 5

6 Consider an example – “spaghetti bowl” code – Modules are 2000 statements long – Few meaningful comment lines – 290,000 statements – No other documentation Modification options – Continue the ad hoc design – Try to understand inner workings of the program – Redesign, recode, and test the relevant portions – Complete redesign, recode, and test No single “correct” choice 6

7 Do not wait for maintenance request Select a program that – Will remain in use for preselected number of years – Is currently being used successfully – Is likely to undergo major modifications – Option 2, 3, and 4 should be applied Why we redevelop – The cost to maintain one line of source code may be 20 to 40 times the cost of initial development of that line 7

8 – Redesign of the software architecture (program and/or data structure), using modern design concepts, can greatly facilitate future maintenance – Because a prototype of the software already exists, development productivity should be much higher than average – The user now has experience with the software. Therefore, new requirements and the direction of change can be ascertained with greater ease – Automated tools for reengineering will facilitate some parts of the job – A complete software configuration (documents, programs, and data) will exist upon completion of preventive maintenance 8

9 Consider a large organization – 500-2000 production programs – Ranked based on the importance – Reviewed for the possible candidates Forward engineering process applies SE principles, concepts, and methods It does not simply re-create a modern equivalent program of an older version If focuses on the use of new user and technology requirements 9

10 Many mainframe applications are reengineered to accommodate client-server architectures – Application functionality migrates to each client computer – New GUI interfaces are implemented at the client sites – Database functions are allocated to the server – Specialized functionality (e.g. compute-intensive analysis) may remain at the server site – New communications, security, archiving, and control requirements must be established at both the client and server sites It requires business reengineering, software reengineering, and enterprise network infrastructure 10

11 It starts with thorough analysis of the business environment Three layers of abstraction can be identified Database layer Business rules layer Client applications layer 11

12 Choice of many organizations Some applications remain “as is” but some reengineered Appropriate data, functional, and behavioral models are created by reverse engineering If extended functionality/behavior is required, use cases are also created Class hierarchies, object-relationship models, object- behavior models, and subsystems are defined Component library can be used if exists for that domain Otherwise algorithms and data structures may be reused 12

13 Reengineering needs resources Resources are limited that may be used for other business purposes Cost-benefit analysis Nine parameters are proposed P 1 = current annual maintenance cost for an application P 2 = current annual operations cost for an application P 3 = current annual business value of an application P 4 = predicted annual maintenance cost after reengineering P 5 = predicted annual operations cost after reengineering 13

14 P 6 = predicted annual business value after reengineering P 7 = estimated reengineering costs P 8 = estimated reengineering calendar time P 9 = reengineering risk factor L = expected life of the system Cost associated with continuing maintenance C maint = [P 3 – (P 1 + P 2 )] * L 14

15 Cost associated with reengineering C reeng = P 6 + (P 4 + P 5 ) * (L – P 8 ) – (P 7 * P 9 ) Overall benefit of reengineering Cost benefit = C reeng – C maint It should be for high-priority applications Highest cost-benefit applications can be targeted Others can be postponed until resources are available 15

16 Reuse-based software engineering is a strategy Originally, it was started as development strategy Factors – Lower software production and maintenance costs – Faster delivery of systems – Improved software quality Software is a valuable asset for an organization Reuse to increase return on investment Availability of reuse software is also dramatically increased – Open source movement – Organizations provide reusable components – Standards help to develop reusable general services 16

17 Application system reuse – The whole application may be reused – Application families with a common architecture Component reuse – Subsystems to single objects – Example: pattern matching system (text-process system) may be used in a database management system Object and function reuse – Component for a single function / an object class – Standard libraries Concept reuse 17

18 Software development processes should be adapted for reuse strategy Requirements refinement stage Design and implementation stages may include explicit activities Software reuse is more effective when planned as an organization-wide reuse program – Creation of reusable assets – Adaptation of development processes Japanese industry is quite mature in reuse 18

19 Increased dependability – Tested software – More reliable Reduced process risk – Cost of existing software is already known – Margin of error is reduced in cost estimation Effective use of specialists – No reinvent the wheel – Domain specialist can encapsulate their knowledge 19

20 Standard compliance – User interface standards – Fewer mistakes Accelerated development – Time to market – Speed up system production 20

21 Restructuring – Code restructuring, data restructuring Forward engineering – Client-server architectures, object-oriented architectures Economics of reengineering – Cost benefit analysis Software reuse – Benefits of reuse 21

Download ppt "Unified theory of software evolution Reengineering – Business process reengineering and software reengineering BPR model – Business definition, process."

Similar presentations

Ads by Google