CMMI – Continuous as well as staged model CMMI capability levels – Incomplete, performed, managed, defined, quantitatively managed, optimized Example.

Slides:



Advertisements
Similar presentations
Systems Development Environment
Advertisements

Unified theory of software evolution Reengineering – Business process reengineering and software reengineering BPR model – Business definition, process.
Lecture 12 Reengineering Computer-aided Software Engineering Cleanroom Software Engineering.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Software Evolution Managing the processes of software system change
1 California State University, Fullerton Chapter 13 Developing and Managing Information Systems.
Software Reengineering
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Lecturer: Dr. AJ Bieszczad Chapter Lehman’s system types S-system: formally defined, derivable from a specification P-system: requirements based.
Software Engineering General Project Management Software Requirements
1 Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Software evolution.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Lead Black Slide. © 2001 Business & Information Systems 2/e2 Chapter 13 Developing and Managing Information Systems.
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Software Reengineering
Software Reengineering 2003 년 12 월 2 일 최창익, 고광 원.
Chapter 29 Maintenance and Reengineering
Chapter 9 – Software Evolution and Maintenance
1.Database plan 2.Information systems plan 3.Technology plan 4.Business strategy plan 5.Enterprise analysis Which of the following serves as a road map.
Chapter : Software Process
Process: A Generic View
Process: A Generic View n A software process  is a roadmap to building high quality software products.  provides a framework for managing activities.
UML - Development Process 1 Software Development Process Using UML (2)
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
CPSC 871 John D. McGregor MMS1 Maintenance & a new trend.
Software evolution. Objectives l To explain why change is inevitable if software systems are to remain useful l To discuss software maintenance and maintenance.
Karolina Muszyńska. Reverse engineering - looking at the solution to figure out how it works Reverse engineering - breaking something down in order to.
TOPIC R Software Maintenance, Evolution, Program Comprehension, and Reverse Engineering SEG4110 Advanced Software Design and Reengineering.
Chapter 1 Software and Software Engineering. A Quick Quiz 1. What percentage of large projects have excess schedule pressure? 25% 50% 75% 100% 2. What.
© 2001 Business & Information Systems 2/e1 Chapter 13 Developing and Managing Information Systems.
Chapter 2 Process: A Generic View
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis.
Software process improvement Framework for SPI SPI support groups, maturity and immaturity models Assessment and gap analysis Education and training Selection.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 2 The Software Process Discussion of the Software Process: Process Framework,
Software Engineering Spring (C) Vasudeva VarmaClass of 32 CS3600: Software Engineering: Process and Product* *Most of the Content drawn.
Enterprise Systems Architectures EGN 5621 Enterprise Systems Collaboration (Professional MSEM) Fall, 2012.
Information Systems Engineering. Lecture Outline Information Systems Architecture Information System Architecture components Information Engineering Phases.
Module 8: Software Evolution CSEB233 Fundamentals of Software Engineering Badariah Solemon 2010.
SWE311_Ch01 (071) Software & Software Engineering Slide 1 Chapter 1 Software and Software Engineering Chapter 1 Software and Software Engineering.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2.
Next week Tuesday Report on the project Demo of the working model. Today at the conclusion of lecture, class get together to figure out how you will present.
Module 8: Software Evolution CSEB233 Fundamentals of Software Engineering Badariah Solemon 2010.
1 Chapter 2 A Generic View of Process Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Architectural Design Introduction Design has been described as a multistep process in which representations of data and program structure,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Reengineering Work: Don’t Automate, Obliterate Jason C.H. Chen, Ph.D. Professor of MIS School of Business Administration Gonzaga University Spokane, WA.
Contents What is Reverse Engineering (RE)? Why do we need Reverse Engineering? Scope and Tasks of Reverse Engineering Reverse Engineering Tools Reverse.
Part 1 Introduction to Software Engineering 1 copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY.
CompSci 280 S Introduction to Software Development
Overview Software Maintenance and Evolution Definitions
Environment Assessment
Software Maintenance
Business Process Reengineering
For University Use Only
Software Engineering: A Practitioner’s Approach, 6/e Chapter 2 Process: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Chapter 8 Software Evolution.
Unit 5 15SE202 Software engineering Principles
System Reengineering Restructuring or rewriting part or all of a system without changing its functionality Applicable when some (but not all) subsystems.
Re- engineeniering.
Introduction Software maintenance:
For University Use Only
Presentation transcript:

CMMI – Continuous as well as staged model CMMI capability levels – Incomplete, performed, managed, defined, quantitatively managed, optimized Example – process area – Specific goals and practices, general goals and practices Other SPI frameworks – SPICE, Bootstrap, TickIT, PSP, TSP SPI return on investment SPI trends 2

The law of continuing change – Real world computing context The law of increasing complexity – Complexity increases if software evolves The law of self regulation – Distribution of process and product measures close to normal The law of conservation of organizational stability – Average effective global activity rate is invariant 3

The law of conservation of familiarity – Maintain mastery of its content and behavior The law of continuing growth – Functional content must be continually increased The law of declining quality – Quality will be declined unless rigorously maintained The feedback system law – Good feedback system 4

Radical redesign of business processes and computing Positive and negative changes Efforts to improve competitiveness, downsizing, and outsourcing System view – business reengineering and software engineering 5

“The search for, and the implementation of, radical change in business process to achieve breakthrough results.” How is the search conducted? How is the implementation achieved? How to ensure that the “radical change” lead to breakthrough results (rather than organizational chaos)? 6

Set of logically related tasks People, equipment, material resources, and business procedures Examples: designing a new product, purchasing services and supplies, hiring a new employee Every business process has a defined customer Across the organizational boundaries The business → business subsystems → business processes → business sub-processes 7

BPR is iterative and evolutionary process Changing business environment Business definition – Business goals are defined – Cost reduction, time reduction, quality improvement, personal development and empowerment – Business level or specific business component Process identification – Critical processes are defined – Processes ranking 8

Process evaluation – Existing processes analysis – Costs are noted – Quality/performance problems are isolated Process specification and design – Use cases are prepared – New set of tasks are designed Prototyping – Prototyping of the redesigned business process Refinement and instantiation – Feedback from the prototype 9

10 Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7 th ed., p. 766

Reengineering absorbs a lot of resources It is a rebuilding activity Inventory analysis – Inventory of all applications – Business criticality, longevity, current maintainability – Candidates for reengineering – Resource allocation to candidate applications – Inventory analysis on a regular basis 11

Document restructuring – Weak documentation for legacy system – Creating documentation is too time consuming – Documentation must be updated, but your organization has limited resources – The system is business critical and must be fully re- documented Reverse engineering – Origin is hardware world – One or more design and manufacturing specifications – In SE, it is design recovery 12

Code restructuring – The most common type of reengineering – Code is restructure/rewritten – Reviews and testing Data restructuring – Full-scale reengineering activity – Existing data architecture is analyzed – Causes program architecture and code-level changes Forward engineering – Automated generation of new application – Recover the design information from existing software and use it to alter the existing system 13

14 Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7 th ed., p. 769

There is no “magic slot” Abstraction level, documentation completeness, tools, human analysts, process direction are highly variable Abstraction level should be high Completeness is the level of detail provided at an abstraction level Completeness is directly proportional to the amount of analysis performed Interactivity refers to integration of automated tools and analysts One-way directionality 15

16 Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7 th ed., p. 773

First reengineering task Different levels of abstraction At the program level, internal program data structures At system level, global data structures Internal data structures – Definition of classes – Grouping related program variables 17

Database structure – Definition of data objects and their relationships – Build an initial object model – Determine candidate keys – Refine the tentative classes – Define generalizations – Discover associations 18

Understand and extract procedural abstractions Different level of abstractions – System, program, component, pattern, and statement Overall functionality must be understood Block diagram of system interaction Component specifications (if available) are reviewed for conformance to existing code For large systems, automated tools may be used Output of this process is passed to restructuring and forward engineering tools 19

Most common reengineering activity What are the basic actions (e.g., keystrokes and mouse clicks) that the interface must process? What is a compact description of the behavioral response of the system to these actions? What is meant by a "replacement," or more precisely, what concept of equivalence of interfaces is relevant here? New interface may not mirror the old one It is good to develop new metaphor 20

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 21