LOGIN TO YOUR ACCOUNT

Username
Password
Remember Me
Or use your Academic/Social account:

CREATE AN ACCOUNT

Or use your Academic/Social account:

Congratulations!

You have just completed your registration at OpenAire.

Before you can login to the site, you will need to activate your account. An e-mail will be sent to you with the proper instructions.

Important!

Please note that this site is currently undergoing Beta testing.
Any new content you create is not guaranteed to be present to the final version of the site upon release.

Thank you for your patience,
OpenAire Dev Team.

Close This Message

CREATE AN ACCOUNT

Name:
Username:
Password:
Verify Password:
E-mail:
Verify E-mail:
*All Fields Are Required.
Please Verify You Are Human:
fbtwitterlinkedinvimeoflicker grey 14rssslideshare1
Languages: English
Types: Doctoral thesis
Subjects: QA76
Requirements change. The requirements of a legacy information system change, often\ud in unanticipated ways, and at a more rapid pace than the rate at which the information\ud system itself can be evolved to support them. The capabilities of a legacy system\ud progressively fall further and further behind their evolving requirements, in a degrading\ud process termed petrification. As systems petrify, they deliver diminishing business\ud value, hamper business effectiveness, and drain organisational resources.\ud To address legacy systems, the first challenge is to understand how to shed their\ud resistance to tracking requirements change. The second challenge is to ensure that a\ud newly adaptable system never again petrifies into a change resistant legacy system. This\ud thesis addresses both challenges.\ud The approach outlined herein is underpinned by an agile migration process - termed\ud Productive Migration - that homes in upon the specific causes of petrification within\ud each particular legacy system and provides guidance upon how to address them. That\ud guidance comes in part from a personalised catalogue of petrifying patterns, which\ud capture recurring themes underlying petrification. These steer us to the problems\ud actually present in a given legacy system, and lead us to suitable antidote productive\ud patterns via which we can deal with those problems one by one.\ud To prevent newly adaptable systems from again degrading into legacy systems, we\ud appeal to a follow-on process, termed Productive Evolution, which embraces and keeps\ud pace with change rather than resisting and falling behind it. Productive Evolution\ud teaches us to be vigilant against signs of system petrification and helps us to nip them in\ud the bud. The aim is to nurture systems that remain supportive of the business, that are\ud adaptable in step with ongoing requirements change, and that continue to retain their\ud value as significant business assets.
  • The results below are discovered through our pilot algorithms. Let us know how we are doing!

    • Developer Maturity....................................................................................................... 46 5.1. Preview ................................................................................................................ 46 5.2. Maturity Levels.................................................................................................... 46 5.3. Peaking................................................................................................................. 47 5.4. Dealing With Uncertainty and Instability............................................................ 48 5.5. Supporting Development ..................................................................................... 49 5.6. Relevance to Legacy Systems.............................................................................. 49 5.7. Review ................................................................................................................. 50
    • Predictive Methodologies ............................................................................................. 51 6.1. Preview ................................................................................................................ 51 6.2. Fear of the Unknown ........................................................................................... 51 6.3. Application-Oriented Predictive Methodologies ................................................. 54 6.4. Architecture-Oriented Predictive Methodologies................................................ 55 6.5. Architectural Pliability......................................................................................... 56 6.6. Unpredictable Change.......................................................................................... 56 6.7. Architectural Evolution........................................................................................ 57 6.8. Review ................................................................................................................. 57
    • Abrial, J.-R., Schuman, S. and Meyer, B. (1980) A Specification Language. In: McNaughten, R. and McKeag, R., (Eds.) On the Construction of Programs, Cambridge University Press.
    • Alexander, C. (1979) The Timeless Way of Building, Oxford University Press.
    • Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M. and Angel, S. (1975) The Oregon Experiment, Oxford University Press.
    • Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M. and Angel, S. (1977) A Pattern Language, Oxford University Press.
    • Burd, E. and Munro, M. (1998) Investgating Component-Based Maintenance and the Effect of Software Evolution: a reengineering approach using data clustering, Proceedings of International Conference on Software Maintenance, IEEE.
    • Burd, E., Munro, M. and Pakstiene, S. (2001) Initial Recommendations for Improving Maintenance Strategy. In: Henderson, P., (Ed.) Systems Engineering for Business Process Change, volume 2, Springer-Verlag.
    • Burr, R.J.A. and Casselman, R.S. (1994) Timethread-Role Maps for Object-Oriented Design of Real-time and Distributed Systems. In: Proceedings of OOPSLA 94, ACM.
    • Burr, R.J.A. and Casselman, R.S. (1996) Use CASE Maps for Object-Oriented Systems, Prentice Hall.
    • Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M. (1996) PatternOriented Software Architecture: A System of Patterns, Wiley.
    • Cagnin, M.I., Penteado, R., Braga, R.T.V. and Masiero, P.C. (2000) Reengineering using Design Patterns, Proceedings of the Working Conference on Reverse Engineering, IEEE.
    • CASE (2001) CASE tool index, http://www.cs.queensu.ca/SoftwareEngineering/tools.html.
    • Cockburn, A. (2001a) Crystal/Clear: A Human Powered Methodology for Small Teams, Addison-Wesley.
    • Cockburn, A. (2001b) Software Development as a Cooperative Game, AddisonWesley.
    • Coleman, J.S. (1987) Free Riders and Zealots. In: Cook, K., (Ed.) Social Exchange Theory, SAGE Publications.
    • Comella-Dorda, S., Wallnau, K., Seacord, R.C. and Robert, J. (2000) A Survey of Legacy System Modernization Approaches (CMU/SEI-2000-TN-003). Software Engineering Institute, Carnegie Mellon University.
    • DeLano, D.E. and Rising, L. (1997) Introducing Technology into the Workplace, http://st-www.cs.uiuc.edu/|plop/plop97/Proceedings/delano.pdf.
    • Fayad, M.E., Schmidt, D. and Johnson, R. (1999) Building Application Frameworks, Wiley.
    • Foote, B. and Opdyke, W.F. (1995) Lifecycle and Refactoring Patterns that Support Evolution and Reuse. In: Coplien, J.O. and Schmidt, D., (Eds.) Pattern Languages of Program Design, Addison-Wesley.
    • Foote, B. and Yoder, J. (1996) Evolution, Architecture, and Metamorphosis. In: Vlissides, J., Coplien, J.O. and Kerth, N., (Eds.) Pattern Languages of Program Design 2, Addison-Wesley.
    • Foote, B. and Yoder, J. (1998) The Selfish Class. In: Martin, R., Rohnert, H. and Buschmann, F., (Eds.) Pattern Languages of Program Design 3,
    • Foote, B. and Yoder, J. (2000) Big Ball of Mud. In: Harrison, N., Foote, B. and Rohnert, H., (Eds.) Pattern Languages of Program Design 4, Addison-Wesley.
    • Graham, I., Henderson-Sellers, B. and Younessi, H. (1997) The OPEN Process Specification, Addison-Wesley.
    • Green, T.F. (1979) Learning without Metaphor. In: Ortony, A., (Ed.) Metaphor and Thought, Cambridge University Press.
    • Griswold, W.G. (1991) Program Restructuring as an Aid to Software Maintenance (PhD thesis), University of Washington.
    • Highsmith, J.A. (1997) Messy, Exciting, and Anxiety-Ridden: Adaptive Software Development, American Programmer, 10, 4.
    • Highsmith, J.A. (1998) Order For Free, Software Development, 6, 3.
    • Highsmith, J.A. (1999a) Adaptive Management: Patterns for the E-Business era, Cutter IT Journal, September.
    • Highsmith, J.A. (1999b) Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House Publishing.
    • Highsmith, J.A. (1999c) Beyond Optimizing, Software Development, 10, 9.
    • Hong, Z., Xu, J. and Bennett, K. (2001) An Abstract Architecture for Dependable and Distributed Applications. In: Henderson, P., (Ed.) Systems Engineering for Business Process Change, volume 2, Springer-Verlag.
    • Jacobson, I., Booch, G. and Rumbaugh, J. (1999) The Unified Software Development Process, Addison-Wesley.
    • Jacobson, I., Jonsson, P. and Griss, M. (1997) Software Reuse: Architecture, process and organization for business success, Addison-Wesley.
    • Jeffries, R., Anderson, A. and Hendrickson, C. (2001) Extreme Programming Installed, Addison-Wesley.
    • Lauder, A. and Kent, S. (1998) Precise Visual Specification of Design Patterns. In: Jul, E., (Ed.) Proceedings of ECOOP '98, Springer-Verlag.
    • Lauder, A. and Kent, S. (1999a) EventPorts: Preventing Legacy Componentware. In: Atkinson, C., (Ed.) Proceedings of 3rd International Enterprise Distributed Object Computing Conference (EDOC 99), IEEE Press.
    • Lauder, A. and Kent, S. (1999b) Two-Level Modeling. In: Chen, J., Lu J. and Meyer, B., (Eds.) Proceedings of TOOLS Asia 99, IEEE Computer Society.
    • Lauder, A. and Kent, S. (2000a) A Pattern is a Metaphor in a World of Straight Lines, unpublished manuscript, email: .
    • Lauder, A. and Kent, S. (2000b) Legacy System Anti-Patterns and a Pattern-Oriented Migration Response. In: Henderson, P., (Ed.) Systems Engineering for Business Process Change, Springer-Verlag.
    • Lauder, A. and Kent, S. (2000c) Modeling Reusable Product-Line Designs, unpublished manuscript, email: .
    • Lopes, C., Mens.K., Tekinerdogan, B. and Kiczales, G. (1997) Proceedings of the Aspect-Oriented Programming Workshop at ECOOP 97, Springer-Verlag.
    • Lopes, C., Tekinerdogan, B., de Meuter, W. and Kiczales, G. (1998) Proceedings of the Aspect-Oriented Programming Workshop at ECOOP 98, Springer-Verlag.
    • Macaulay, S. (1992) Non-Contractual Relations in Business: A Preliminary Study. In: Granovetter, M. and Swedberg, R., (Eds.) Westview Press.
    • Marsden, P.V. (1987) Elements of Interactor Dependence . In: Cook, K., (Ed.) Social Exchange Theory, SAGE Publications.
    • Martin, R., Riehle, D. and Buschmann, F. (1998) Pattern Languages of Program Design 3, Addison-Wesley.
    • Riehle, D., Siberski, W., Baumer, D., Megert, D. and Zillinghoven, H. (1998) Serializer. In: Martin, R., Riehle, D. and Buschmann, F., (Eds.) Pattern Languages of Program Design 3, Addison-Wesley.
    • Rising, L. (2000) Customer Interaction Patterns. In: Harrison, N., Foote, B. and Rohnert, H., (Eds.) Pattern Languages of Program Design 4, Addison-Wesley.
    • Yacoub, S.M. and Ammar, H.H. (2000) Finite State Machine Patterns. In: Harrison, N., Foote, B. and Rohnert, H., (Eds.) Pattern Languages of Program Design 4, Addison-Wesley.
    • Yamagishi, T. (1987) An Exchange Theoretical Approach to Network Positions. In: Cook, K., (Ed.) Social Exchange Theory, SAGE Publications.
  • No related research data.
  • No similar publications.

Share - Bookmark

Download from

Cite this article