1 / 47

Software Change

Software Change. IS301 – Software Engineering Lecture # 25 – 2003-11-18 M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University mkabay@norwich.edu. Topics. Program Evolution Dynamics Software Maintenance Architectural Evolution. Software Change (1).

zachariah-jayson
Download Presentation

Software Change

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Change IS301 – Software Engineering Lecture # 25 – 2003-11-18 M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University mkabay@norwich.edu

  2. Topics • Program Evolution Dynamics • Software Maintenance • Architectural Evolution

  3. Software Change (1) • Managing processes of software system change

  4. Software Change (2) • Software change inevitable • New requirements emerge when software used • Business environment changes • Errors must be repaired • New equipment must be accommodated • Performance or reliability may have to be improved • Key problem for organizations: • Implementing and managing change to legacy systems

  5. Software Change Strategies • Software maintenance • Response to changed requirements • Fundamental software structure stable • Architectural transformation • Generally from centralized architecture to distributed architecture • Software re-engineering • No new functionality added • Restructured and reorganized • To facilitate future changes • Strategies may be applied separately or together

  6. Program Evolution Dynamics • Study of processes of system change • Lehman and Belady • Major empirical study • Proposed ‘laws’ applying to all systems as they evolved • Sensible observations rather than laws • Applicable to large systems developed by large organizations • Perhaps less applicable in other cases

  7. Lehman’s Laws • Continuing Change • Increasing Complexity • Large Program Evolution • Organizational Stability • Conservation of Familiarity

  8. Continuing Change • A program used in a real-world environment must necessarily change or it will progressively become less useful in that environment.

  9. Increasing Complexity • As an evolving program changes, its structure tends to become more complex. • Extra resources must be devoted to preserving and simplifying the structure.

  10. Large Program Evolution • Program evolution is a self-regulating process. • System attributes such as size, time between releases and the number of reported errors are approximately invariant for each system release.

  11. Organizational Stability • Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development.

  12. Conservation of Familiarity • Over the lifetime of a system, the incremental change in each release is approximately constant.

  13. Applicability of Lehman’s Laws • Not yet been established • Generally applicable to • Large, tailored systems • Developed by large organizations • Not clear how they should be modified for • Shrink-wrapped software products • Systems that incorporate significant number of COTS components • Small organizations • Medium sized systems

  14. Topics • Program Evolution Dynamics • Software Maintenance • Architectural Evolution

  15. Software Maintenance • Modifying program after it has been put into use • Does not normally involve major changes to system’s architecture • Changes are implemented by • Modifying existing components and • Adding new components to system

  16. Maintenance Inevitable • System requirements likely to change while system being developed • Because environment changing • Therefore delivered system won't meet its requirements (!) • Systems tightly coupled with their environment • When system installed in environment it changes that environment • Therefore changes system requirements • Systems MUST be maintained if they are to remain useful in their environment

  17. Tool/Problem Relation Availability of a tool changes the perception of what is possible

  18. Types of Maintenance • Repair software faults • Adapt software to different operating environment (e.g., new computer, OS) • Add to or modify system’s functionality

  19. Distribution of Maintenance Effort

  20. Spiral Maintenance Model

  21. Maintenance Costs • Usually greater than development costs (2* to 100* depending on application) • Affected by both technical and non-technical factors • Increases as software maintained • Maintenance corrupts software structure thus making further maintenance more difficult • Ageing software can have high support costs (e.g. old languages, compilers etc.)

  22. Development/Maintenance Costs

  23. Maintenance Cost Factors • Team stability • $$ reduced if same staff involved with them for some time • Contractual responsibility • Developers of system may have no contractual responsibility for maintenance • So no incentive to design for future change • Staff skills • Maintenance staff often inexperienced and may have limited domain knowledge • Program age and structure • As programs age, their structure degraded and they become harder to understand and change

  24. Evolutionary Software • Rather than think of separate development and maintenance phases, evolutionary software software designed to evolve continuously throughout its lifetime.

  25. Maintenance Process

  26. Change Requests • Change requests for system changes • From users, customers or management • In principle • All change requests should be carefully analyzed • Part of orderly maintenance process • In practice, some change requests must be implemented urgently • Fault repair • Changes to system’s environment • Urgently required business changes

  27. Change Implementation

  28. Emergency Repair

  29. Maintenance Prediction • Assessing which parts of system may cause problems and have high maintenance costs • Implementing changes degrades system and reduces its maintainability • Maintenance costs depend on number of changes and • Costs of change depend on maintainability

  30. Maintenance Prediction

  31. Change Prediction • Predicting number of changes requires and understanding of relationships between system and its environment • Tightly coupled systems require changes whenever environment changed • Factors influencing this relationship • Number and complexity of system interfaces • Number of inherently volatile system requirements • Business processes where system used

  32. Complexity Metrics • Predictions of maintainability can be made by assessing complexity of system components • Studies have shown that most maintenance effort spent on relatively small number of system components • Complexity depends on • Complexity of control structures • Complexity of data structures • Procedure and module size

  33. Process Metrics • Process measurements may be used to assess maintainability • Number of requests for corrective maintenance • Average time required for impact analysis • Average time taken to implement change request • Number of outstanding change requests • If any or all of these increasing, this may indicate decline in maintainability

  34. Topics • Program Evolution Dynamics • Software Maintenance • Architectural Evolution

  35. Architectural Evolution • Need to convert many legacy systems from centralized architecture to client-server architecture • Drivers for change: • Hardware costs: Servers cheaper than mainframes • User interface expectations: Users expect graphical user interfaces • Distributed access to systems: Users wish to access system from different, geographically separated, computers

  36. Distribution Factors

  37. Legacy System Structure • Ideally, for distribution, there should be clear separation between • user interface, • system services and • system data management • In practice, these are usually intermingled in older legacy systems

  38. Legacy System Structures

  39. Layered Distribution Model

  40. Legacy System Distribution

  41. Distribution Options • The greater the amount of processing shifted from server to client, the higher the costs of architectural evolution • Simplest distribution model • UI distribution • Only user interface implemented on client • “Thin client” • Most complex option • Server simply provides data management • Application services implemented on client • “Fat client”

  42. Distribution Option Spectrum

  43. User Interface Distribution • UI distribution • takes advantage of local processing power on PCs to • implement graphical user interface • Where there is clear separation between UI and application then • legacy system can be modified to distribute UI • Otherwise, screen management middleware can translate text interfaces to graphical interfaces

  44. User Interface Distribution

  45. UI Migration Strategies

  46. Homework • Read Chapter 27 thoroughly using the full SQ3R techniques. • Begin studying Chapter 28 on software re-engineering using the Survey-Question phases of SQ3R in preparation for Thursday’s class. • For Tuesday the 2nd of Dec, complete exercises 27.1 through 27.8 for a total of 24 points. Expect to answer these questions in about ¼ to ½ a page of text each.

  47. DISCUSSION

More Related