http://iet.metastore.ingenta.com
1887

Measuring software flexibility

Measuring software flexibility

For access to this article, please select a purchase option:

Buy article PDF
£12.50
(plus tax if applicable)
Buy Knowledge Pack
10 articles for £75.00
(plus taxes if applicable)

IET members benefit from discounts to all IET publications and free access to E&T Magazine. If you are an IET member, log in to your account and the discounts will automatically be applied.

Learn more about IET membership 

Recommend to library

You must fill out fields marked with: *

Librarian details
Name:*
Email:*
Your details
Name:*
Email:*
Department:*
Why are you recommending this title?
Select reason:
 
 
 
 
 
IEE Proceedings - Software — Recommend this title to your library

Thank you

Your recommendation has been sent to your librarian.

Flexibility has been recognised as a desirable quality of software since the earliest days of software engineering. Classic and contemporary software design literature suggests that particular implementations are more flexible than others, but stops short of suggesting objective criteria for quantifying such claims. To measure software flexibility in precise terms, we introduce the notion of evolution complexity and demonstrate how it can be used to measure and compare the flexibility of (1) programming paradigms (Object-Oriented against Procedural programs), (2) architectural styles (Shared Data, Pipes and Filters, and Abstract Data Type) and (3) design patterns (Visitor and the Abstract Factory). We also demonstrate how evolution complexity can be used to choose the most flexible design policy. We conclude with experimental results corroborating our claims.

References

    1. 1)
      • M. Lehman . Laws of software evolution revisited. Lect. Notes Comput. Sci. , 108 - 124
    2. 2)
      • P. Naur , B. Randell . (1969) Software engineering: report of a conference sponsored by the NATO science committee.
    3. 3)
      • W.W. Gibbs . Software's chronic crisis. Sci. Am. , 3 , 86 - 95
    4. 4)
      • B.W. Boehm . (1981) Software engineering economics.
    5. 5)
      • (1999) Standard glossary of software engineering terminology 610.12-1990.
    6. 6)
    7. 7)
      • D. Garlan , G.E. Kaiser , D. Notkin . Using tool abstraction to compose systems. Computer , 6 , 30 - 38
    8. 8)
      • Parnas, D.L.: `Software Aging', Proc. Int. Conf. on Software Engineering – ICSE, May 1994, IEEE Computer Society Press, Los Alamitos, p. 279–287.
    9. 9)
      • E. Gamma , R. Helm , R. Johnson , J.M. Vlissides . (1994) Design patterns: elements of reusable object-oriented software.
    10. 10)
      • A. Urquhart , L. Floridi . (2004) Complexity, The Blackwell guide to philosophy of computing information.
    11. 11)
      • M. Shaw , D. Garlan . (1996) Software architecture—perspectives on an emerging discipline.
    12. 12)
      • Lehman, M.M., Ramil, J.F., Wernick, P., Perry, D.E., Turski, W.M.: `Metrics and laws of software evolution – the nineties view', Proc. Int. Symp. on Software Metrics, 5–7 November 1997, Albuquerque, NM, IEEE Computer Society Press, Los Alamitos, p. 20–32.
    13. 13)
      • Osterweil, L.: `Software processes are software too', Proc. 9th Int. Conf. on Software Engineering – ICSE, IEEE Computer Society, Los Alamitos, p. 2–13.
    14. 14)
      • Osterweil, L.: `Software processes are software too revisited', Proc. 19th Int. Conf. on Software Engineering – ICSE, May 1997, IEEE Computer Society, Los Alamitos, p. 540–548.
    15. 15)
    16. 16)
      • T. McCabe . A software complexity measure. IEEE Trans. Soft. Eng. , 308 - 320
    17. 17)
      • T. Mens , A.H. Eden . On the evolution complexity of design patterns. Electron. Lecture Notes Comput. Sci. , 3 , 147 - 163
    18. 18)
      • I. Craig . (2000) The interpretation of object-oriented programming languages.
    19. 19)
      • Eden, A.H.: `An experiment in evolution complexity: instructions to subjects', Technical Report CSM-431, 2005, ISSN 1744-8050.
    20. 20)
      • Mens, T., Eden, A.H.: `Revised experiment in evolution complexity: instructions to subjects', Technical Report CSM-439, 2005, ISSN 1744-8050.
    21. 21)
      • J. Kerievsky . (2004) Refactoring to patterns.
    22. 22)
      • Curtis, B.: `In search of software complexity', Proc. Workshop on Qualitative Software Models for Reliability, Complexity and Cost, October 1979, p. 95–106.
    23. 23)
      • H. Zuse . (1998) Software complexity.
    24. 24)
      • M.H. Halstead . (1977) Elements of software science.
    25. 25)
      • M. Jørgensen . Experience with the accuracy of software maintenance task effort prediction models. IEEE Trans. Softw. Eng. , 8 , 674 - 681
    26. 26)
      • Sneed, H.: `Estimating the costs of software maintenance tasks', Proc. Int. Conf. on Software Maintenance, 1995, Los Alamitos, IEEE Computer Society Press, p. 168–181.
    27. 27)
      • Ramil, J.F., Lehman, M.M.: `Metrics of software evolution as effort predictors – a case study', Proc. Int. Conf. on Software Maintenance, October 2000, Los Alamitos, IEEE Computer Society Press, p. 163–172.
    28. 28)
      • Li, L., Offutt, A.: `Algorithmic analysis of the impact of changes to object-oriented software', Proc. Int. Conf. on Software Maintenance – ICSM, 1996, Los Alamitos, IEEE Computer Society Press, p. 171–184.
    29. 29)
    30. 30)
      • N. Chapin , J. Hale , K. Khan , J. Ramil , W.G. Than . Types of software evolution and software maintenance. J. Softw. Maint. Evol. , 3 - 30
    31. 31)
      • M. Fowler . (1999) Refactoring: improving the design of existing code.
http://iet.metastore.ingenta.com/content/journals/10.1049/ip-sen_20050045
Loading

Related content

content/journals/10.1049/ip-sen_20050045
pub_keyword,iet_inspecKeyword,pub_concept
6
6
Loading
This is a required field
Please enter a valid email address