Skip to main content
Top

Hint

Swipe to navigate through the chapters of this book

Published in:
Cover of the book

2017 | OriginalPaper | Chapter

1. Background

Author : Gerard O’Regan

Published in: Concise Guide to Software Engineering

Publisher: Springer International Publishing

Abstract

This chapter presents a broad overview of software engineering and discusses various software lifecycles and the phases in software development. We discuss requirements gathering and specification, software design, implementation, testing and maintenance. The lightweight Agile methodology is introduced, and it has become very popular in industry. Mathematics may potentially assist software engineers in delivering high-quality software products that are safe to use and the extent to which mathematics should be employed remains a topic of active debate.

Dont have a licence yet? Then find out more about our products and how to get one now:

Springer Professional "Wirtschaft+Technik"

Online-Abonnement

Mit Springer Professional "Wirtschaft+Technik" erhalten Sie Zugriff auf:

  • über 102.000 Bücher
  • über 537 Zeitschriften

aus folgenden Fachgebieten:

  • Automobil + Motoren
  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Elektrotechnik + Elektronik
  • Energie + Nachhaltigkeit
  • Finance + Banking
  • Management + Führung
  • Marketing + Vertrieb
  • Maschinenbau + Werkstoffe
  • Versicherung + Risiko

Jetzt Wissensvorsprung sichern!

Springer Professional "Technik"

Online-Abonnement

Mit Springer Professional "Technik" erhalten Sie Zugriff auf:

  • über 67.000 Bücher
  • über 390 Zeitschriften

aus folgenden Fachgebieten:

  • Automobil + Motoren
  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Elektrotechnik + Elektronik
  • Energie + Nachhaltigkeit
  • Maschinenbau + Werkstoffe




 

Jetzt Wissensvorsprung sichern!

Springer Professional "Wirtschaft"

Online-Abonnement

Mit Springer Professional "Wirtschaft" erhalten Sie Zugriff auf:

  • über 67.000 Bücher
  • über 340 Zeitschriften

aus folgenden Fachgebieten:

  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Finance + Banking
  • Management + Führung
  • Marketing + Vertrieb
  • Versicherung + Risiko




Jetzt Wissensvorsprung sichern!

Footnotes
1
The “Mongolian Hordes” management myth is the belief that adding more programmers to a software project that is running late will allow catch-up. In fact, as Brooks says adding people to a late software project actually makes it later.
 
2
These are IT projects covering diverse sectors including banking and telecommunications, rather than pure software companies. Software companies following maturity frameworks such as the CMMI generally achieve more consistent results.
 
3
I recall projects at Motorola that regularly achieved 5.6σ-quality in a L4 CMM environment (i.e. approx. 20 defects per million lines of code. This represents very high quality).
 
4
Approaches such as the CMM or SPICE (ISO 15504) focus mainly on the management and organizational practices required in software engineering. The emphasis is on defining software processes that are fit for purpose and consistently following them. The process maturity models focus on what needs to be done rather how it should be done. This gives the organization the freedom to choose the appropriate implementation to meet its needs. The models provide useful information on practices to consider in the implementation.
 
5
Parnas has made important contributions to computer science. He advocates a solid engineering approach with the extensive use of classical mathematical techniques in software development. He also introduced information hiding in the 1970s, which is now a part of object-oriented design.
 
6
Software companies that are following approaches such as the CMM or ISO 9001 consider the education and qualification of staff prior to assigning staff to performing specific tasks. The appropriate qualifications and experience for the specific role are considered prior to appointing a person to carry out the role. Many companies are committed to the education and continuous development of their staff and on introducing best practice in software engineering into their organization.
 
7
The ancient Babylonians used the concept of accountability, and they employed a code of laws (known as the Hammurabi Code) c. 1750 B.C. It included a law that stated that if a house collapsed and killed the owner, then the builder of the house would be executed.
 
8
However, it is unlikely that an individual programmer would be subject to litigation in the case of a flaw in a program causing damage or loss of life. A comprehensive disclaimer of responsibility for problems rather than a guarantee of quality accompanies most software products. Software engineering is a team-based activity involving many engineers in various parts of the project, and it would be potentially difficult for an outside party to prove that the cause of a particular problem is due to the professional negligence of a particular software engineer, as there are many others involved in the process such as reviewers of documentation and code and the various test groups. Companies are more likely to be subject to litigation, as a company is legally responsible for the actions of their employees in the workplace, and a company is a wealthier entity than one of its employees. The legal aspects of licensing software may protect software companies from litigation. However, greater legal protection for the customer can be built into the contract between the supplier and the customer for bespoke software development.
 
9
Many software companies have a defined code of ethics that employees are expected to adhere. Larger companies will wish to project a good corporate image and to be respected worldwide.
 
10
The British Computer Society (BCS) has introduced a qualification system for computer science professionals that it used to show that professionals are properly qualified. The most important of these is the BCS Information System Examination Board (ISEB) which allows IT professionals to be qualified in service management, project management, software testing and so on.
 
11
Software companies that are following the CMMI or ISO 9001 standards will employ audits to verify that the processes and procedures have been followed. Auditors report their findings to management, and the findings are addressed appropriately by the project team and affected individuals.
 
12
Agile teams are self-organizing and the project manager role is generally not employed for small projects (<20 staff).
 
13
This is essential for serious defects that have caused significant inconvenience to customers (e.g. a major telecoms outage). The software development organization will wish to learn lessons to determine what went wrong in its processes that prevented the defect from been identified during peer reviews and testing. Actions to prevent a reoccurrence will be identified and implemented.
 
14
These are the risk management activities in the Prince 2 methodology.
 
Literature
1.
go back to reference F. Brooks, The Mythical Man Month (Addison Wesley, Boston, 1975) F. Brooks, The Mythical Man Month (Addison Wesley, Boston, 1975)
2.
go back to reference Petrocelli, in Software Engineering, eds. by IN. Buxton, P. Naur, B. Randell. Report on two NATO Conferences held in Garmisch, Germany (October 1968) and Rome, Italy (October 1969) (1975) Petrocelli, in Software Engineering, eds. by IN. Buxton, P. Naur, B. Randell. Report on two NATO Conferences held in Garmisch, Germany (October 1968) and Rome, Italy (October 1969) (1975)
3.
go back to reference G. O’Regan, Mathematical Approaches to Software Quality (Springer, London, 2006) G. O’Regan, Mathematical Approaches to Software Quality (Springer, London, 2006)
4.
go back to reference F. Brooks, No Silver Bullet. Essence and Accidents of Software Engineering. Information Processing (Elsevier, Amsterdam, 1986) F. Brooks, No Silver Bullet. Essence and Accidents of Software Engineering. Information Processing (Elsevier, Amsterdam, 1986)
5.
go back to reference G. O’Regan, Introduction to Software Process Improvement (Springer, London, 2010) G. O’Regan, Introduction to Software Process Improvement (Springer, London, 2010)
6.
go back to reference G. O’Regan, Introduction to Software Quality (Springer, Switzerland, 2014) G. O’Regan, Introduction to Software Quality (Springer, Switzerland, 2014)
7.
go back to reference M. Fagan, design and code inspections to reduce errors in software development. IBM Syst. J. 15(3) (1976) M. Fagan, design and code inspections to reduce errors in software development. IBM Syst. J. 15(3) (1976)
8.
go back to reference T. Gilb, D. Graham, Software Inspections. (Addison Wesley, Boston, 1994) T. Gilb, D. Graham, Software Inspections. (Addison Wesley, Boston, 1994)
9.
go back to reference Office of Government Commerce, Managing Successful Projects with PRINCE2 (2004) Office of Government Commerce, Managing Successful Projects with PRINCE2 (2004)
10.
go back to reference W. Royce, in The Software Lifecycle Model (Waterfall Model). Proceedings of WESTCON, August, 1970 W. Royce, in The Software Lifecycle Model (Waterfall Model). Proceedings of WESTCON, August, 1970
11.
go back to reference B. Boehm, A spiral model for software development and enhancement. Computer 21(5), 61–72 (1988) B. Boehm, A spiral model for software development and enhancement. Computer 21(5), 61–72 (1988)
12.
go back to reference J. Rumbaugh et al., The Unified Software Development Process (Addison Wesley, Boston, 1999) J. Rumbaugh et al., The Unified Software Development Process (Addison Wesley, Boston, 1999)
13.
go back to reference K. Beck, Extreme Programming Explained. Embrace Change (Addison Wesley, Boston, 2000) K. Beck, Extreme Programming Explained. Embrace Change (Addison Wesley, Boston, 2000)
14.
go back to reference I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Modelling Language User Guide (Addison-Wesley, Boston, 1999) I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Modelling Language User Guide (Addison-Wesley, Boston, 1999)
15.
go back to reference D. Parnas, On the criteria to be used in decomposing systems into modules. Commun. ACM 15(12), 1053–1058 (1972) D. Parnas, On the criteria to be used in decomposing systems into modules. Commun. ACM 15(12), 1053–1058 (1972)
16.
go back to reference E.W. Dijkstra, Structured Programming (Academic Press, Cambridge, 1972) E.W. Dijkstra, Structured Programming (Academic Press, Cambridge, 1972)
17.
go back to reference M. Fagan, Design and code inspections to reduce errors in software development. IBM Syst. J. 15(3) (1976) M. Fagan, Design and code inspections to reduce errors in software development. IBM Syst. J. 15(3) (1976)
18.
go back to reference J.M. Spivey, The Z Notation. A Reference Manual. Prentice Hall International Series in Computer Science, 1992 J.M. Spivey, The Z Notation. A Reference Manual. Prentice Hall International Series in Computer Science, 1992
Metadata
Title
Background
Author
Gerard O’Regan
Copyright Year
2017
DOI
https://doi.org/10.1007/978-3-319-57750-0_1

Premium Partner