Your browser does not support JavaScript!
http://iet.metastore.ingenta.com
1887

35 years on: to what extent has software engineering design achieved its goals?

35 years on: to what extent has software engineering design achieved its goals?

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

Buy article PDF
$19.95
(plus tax if applicable)
Buy Knowledge Pack
10 articles for $120.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 Title Publication 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.

The term ‘software engineering’ was coined in 1968 to introduce the disciplines of established branches of engineering design to software manufacture. Some 35 years on, this paper attempts to gauge the success of software engineering against its original goals, with particular respect to the adoption of an industrial design process. The design issues raised in the 1968 NATO conference are examined and then modern examples of engineering design and software engineering are compared. While many aspects of design are found to be similar between the two, significant dissimilarities are also evident. Knowledge of such similarities and dissimilarities may offer opportunities for software engineering to learn lessons from engineering design, for example in the generation and evaluation of solution variants. Field studies are reviewed for empirical evidence of the success or failure of software engineering; results suggest a mixed picture over a diverse range of application domains. It is found that the issues surrounding software production identified 35 years ago remain unresolved today. Although considerable benefit was gained from adopting fundamental design practices from engineering design, the demands on software engineering continue to increase beyond the capabilities of current software engineering theory and practice.

References

    1. 1)
      • I. Sommerville . (2006) Software engineering.
    2. 2)
      • P. Clements , R. Kazman , M. Klein . (2002) Evaluating software architectures: methods and case studies.
    3. 3)
      • H.A. Simon . (1981) The sciences of the artificial.
    4. 4)
      • M.A. Jackson . (1975) Principles of program design.
    5. 5)
      • S. Pugh . (1991) Total design: integrated methods for successful product engineering.
    6. 6)
      • D. Perkins , D. Gabbay . (2001) Standard logic as a model of reasoning: the empirical critique, Handbook of the logic of argument and inference: the turn towards to the practical.
    7. 7)
      • J. Bosch . (2000) Design and use of software architectures: adopting and evolving a product-line approach.
    8. 8)
      • N. Suh . (1990) The principles of design.
    9. 9)
      • S. Flowers . (1996) Software failure, management failure.
    10. 10)
      • R. Glass . (1999) Computing calamities: lessons learned from products, projects and companies that failed.
    11. 11)
      • D. Navinchandra . (1991) Exploration and innovation in design.
    12. 12)
      • G. Pahl , W. Beitz . (1996) Engineering design.
    13. 13)
      • D. Rosenberg , M. Stephens . (2003) XP refactored.
    14. 14)
    15. 15)
      • D.A. Norman . (1988) The design of everyday things.
    16. 16)
      • G. BOOCH . (1994) Object-oriented analysis and design with applications.
    17. 17)
    18. 18)
      • C. Reimenschneider , B. Hardgrave , F. Davies . Explaining software developer acceptance of methodologies: a comparison of five theoretical models. IEEE Trans. Softw. Eng. , 1135 - 1145
    19. 19)
      • R. Pressman . (2000) Software engineering, a practitioner's approach - European adaptation.
    20. 20)
      • B. Lawson . (1997) How designers think – the design process demystified.
    21. 21)
      • R. Guindon . Knowledge exploited by experts during software system design. Int. J. Man-Mach. Stud. , 279 - 304
    22. 22)
      • Diaz-Herrera, J.: `Engineering design for software: on defining the software engineering profession', Proc. 31st IEEE Annual Frontiers in Education Conf. on Impact on Engineering Science and Education, vol. 1, Reno, NV, 10–13 October 2001, p. 685–688.
    23. 23)
    24. 24)
      • R. Glass , R.L. Glass . (2003) Facts and fallacies of software engineering.
    25. 25)
      • S. Amarel . On the mechanisation of creative design. IEEE Spectr. , 3 , 112 - 114
    26. 26)
      • C. Alexander . (1964) Notes on the synthesis of form.
    27. 27)
      • D. Parnas , P. Clements . A rational design process: how and why to fake it. IEEE Trans. Softw. Eng. , 251 - 257
    28. 28)
    29. 29)
      • R. Jefferies , A. Turner , P. Polson , M. Atwood , J. Anderson . (1981) The processes involved in designing software, Cognitive skills and their acquisition.
    30. 30)
      • J. de Almeida , J. Camargo , B.A. Basseto , S.M. Paz . Best practices in code inspection for safety-critical software. IEEE Softw. , 56 - 63
    31. 31)
      • K. Schwaber , M. Beedle . (2002) Agile software development with scrum.
    32. 32)
      • R. Reffat , J. Gero . (2000) Computational situated learning in design, Artificial intelligence in design 00.
    33. 33)
      • I. Jacobson , G. Booch , J. Rumbaugh . (1999) The unified software development process.
    34. 34)
      • Fenton, N.: `How effective are software engineering methods?', Proc. 2nd Int. Conf. on Achieving Quality in Software (AQUIS), Venice, Italy, 1993, p. 295–305.
    35. 35)
      • M. French . (1999) Conceptual design for engineers.
    36. 36)
    37. 37)
      • I. Parmee . (2001) Evolutionary and adaptive computing in engineering design.
    38. 38)
      • Naur, P, Randell, B: `Software engineering', Proc. Conf. sponsored by NATO Science Committee, 1968, NATOGarmisch, Germany.
    39. 39)
      • M. Eva . (1994) SSADM version 4: a user's guide.
    40. 40)
      • H. Apperley , C. Simons . (2003) Service- and component-based development.
    41. 41)
      • M. Fowler . Is design dead?. Softw. Dev. Mag. , 4
    42. 42)
      • A. Cockburn . (2002) Agile software development.
    43. 43)
    44. 44)
    45. 45)
      • K. Beck . (2000) Extreme programming explained: embrace change.
    46. 46)
      • D. Firesmith , B. Henderson-Sellers . (2001) The OPEN process framework: an introduction (OPEN series).
    47. 47)
      • L. Rips . (1994) The psychology of proof: deductive reasoning in human thinking.
    48. 48)
      • N. Roozenburg , J. Eekels . (1995) Product design: fundamentals and methods.
    49. 49)
      • N. Cross . (1989) Engineering design methods.
    50. 50)
      • P. Johnson-Laird , R. Byrne . (1991) Deduction.
    51. 51)
      • M. Fowler . (1999) Refactoring: improving the design of existing code.
    52. 52)
      • E. Yourdon , L.L. Constantine . (1979) Structured design: fundamentals of a disciplineof computer program and system design.
    53. 53)
      • I.C. Parmee . Improving problem definition through interactive evolutionary computing. Artif. Intell. Eng. Des. Anal. Manuf. , 185 - 202
    54. 54)
      • Brandstotter, M, Knoth, R, Kopacek, B, Kapacek, P: `Checklist for optimised design for re-use of printed wire boards and components', Presented at IEEE Int. Symp. on Electronics and the Environment, May 2003.
    55. 55)
      • Wimmer, W: `The ECODESIGN checklist method: a redesign tool for environmental product improvements', Presented at Int. Symp. on Environmentally Conscious Design (EcoDesign) and Inverse Manufacturing, 1–3 February 1999, Tokyo, Japan.
    56. 56)
      • T. DeMarco . (1978) Structured analysis and system specification.
    57. 57)
      • Belli, F, Crisan, R: `Towards automation of checklist-based code reviews', Presented at 7th Int. Symp. on Software Reliability Engineering, 30 October–2 November 1996, White Plains, NY.
    58. 58)
    59. 59)
      • E. Do . Drawing marks, acts and reacts: towards a computational sketching interface for architectural design. Artif. Intell. Eng. Des. Anal. Manuf. , 149 - 171
    60. 60)
      • M. Shaw , D. Garlan . (1996) Software architectures: perspectives on an emerging discipline.
    61. 61)
      • J. Nadhakumar , D. Avison . The fiction of methodological development: a field study of information systems development. Inf. Technol. People , 176 - 191
    62. 62)
      • R. Guindon . Designing the design process: exploiting opportunistic thoughts. Hum.-Comput. Interact. , 305 - 344
    63. 63)
    64. 64)
      • Hendershot, D.: `A checklist for inherently safer chemical reaction process design and operation', 17th Annual Int. Conf. of American Institute of Chemical Engineers, Jacksonville, FL, October 2002.
    65. 65)
      • A. Goel . Design, analogy, and creativity. IEEE Expert Intell. Syst. Appl. , 26 - 70
    66. 66)
      • J. Van Gurp , J. Bosch . Design erosion: problems and causes. J. Syst. Softw. , 105 - 119
    67. 67)
      • I.C. Parmee , D. Cvetkovic , A.H. Watson , C.R. Bonham , I. Packham . Introducing prototype interactive evolutionary systems for ill-defined design environments. J. Adv. Eng. Softw. , 429 - 441
    68. 68)
      • E. Yourdon . (1999) Death march.
    69. 69)
    70. 70)
      • D. Avison , G. Fitzgerald . Where now for development methodologies?. Commun. ACM , 79 - 82
http://iet.metastore.ingenta.com/content/journals/10.1049/ip-sen_20031198
Loading

Related content

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