Definition

Email this page to a friend   

Email to a friend

Software Engineering

(Alias: SE, systems engineering)

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

Login/register to access our free white paper

Click to login and access our white paper

Summary

We explore the engineering approach to software intensive systems development, how it differs from that of non-engineers, and why this is important to your company and your career.

  • Success story: The Soul of a Chemical Reactor
  • Why software must be engineered
  • How software projects fail
  • The business case for software engineering
  • What a software engineer needs to know
  • The opposing belief systems of engineering and craft work
  • Why formal methods work
  • Differentiating engineering from computer science
  • The way out of the software crisis

Prologue: The Soul of a Chemical Reactor

The Meaning of Total Control
Under Pressure
The Exotherm
Good Design Looks Easy
The Back Story
Building a Complex Thing
Why the Engineering Approach Works

1. Software Must Be Engineered

1.1. Why this Applies to You
1.2. How you Can Apply this Information

2. The Origin of Software

3. The Problem With Modern Software

3.1. Growth in Size and Complexity
3.2. IT Report Card
3.3. How Software Projects Fail

4. The Business Case for Software Engineering

5. What is Software Engineering?

6. Codifying and Licensing Software Engineering

6.1. ISO/IEC 12207
6.2. SWEBOK
6.3. IEEE/ACM SE Curriculum Guidelines
6.4. Licensing and Certification

6.4.1. IEEE Certification
6.4.2. Software Engineering Licensing Consortium (SELC)

7. Codifying Computer Science

8. Is Software Engineering For You?

9. The Craftsmen and the Engineer

9.1. Story: Loving the Solution
9.2. Choosing Your Path
9.3. Belief Systems - Point and Counter Point

9.3.1. Discovering Requirements
9.3.2. Solving Wicked Problems
9.3.3. Making Design Decisions
9.3.4. Innovating in Design
9.3.5. Formalising the Design Process
9.3.6. Building Better Systems
9.3.7. Documenting
9.3.8. Reusing Software
9.3.9. Collaborating
9.3.10. Specialisation or Generalisation
9.3.11. Managing Risk
9.3.12. Making it Safe
9.3.13. Making it Secure
9.3.14. Planning and Management
9.3.15. Managing Scope
9.3.16. Estimating Cost
9.3.17. Estimating Time
9.3.18. Being Efficient
9.3.19. Being Productive
9.3.20. Delivering Quality
9.3.21. Learning
9.3.22. Validating Software
9.3.23. Maintaining Software
9.3.24. Behaving Ethically

10. Why Formal Methods Work

10.1. A Formal Methods Case Study: Océ
10.2. What are Formal Methods?
10.3. Formal Software Development
10.4. Applying Formal Languages
10.5. A Non-Constructive Formal Language Example
10.6. The Benefits of Formalism

11. The Computer Scientist and the Software Engineer

11.1. Complimentary Skill Sets
11.2. Contrasting Ways of Working
11.3. How Computer Science Supports Software Engineering
11.4. Story: A Software Project Lost in Computer Science

12. Software Communities

12.1. Software Engineers
12.2. Computer Scientists
12.3. Software Craftsmen

13. Summary

Appendix A - Modelling with Finite State Machines

A.1 - State Transition Diagrams
A.2 - An English Language Requirements Specification
A.3 - Modelling with State Transition Diagrams
A.4 - State Transition Tables
A.5 - Dealing with Exception Conditions
A.6 - Harel's State Charts
A.7 - State Machines Simplify
A.8 - Code Generation with State Machines
A.9 - The Role of State Machines in Software Development

Appendix B - Seriously Bad Ideas

B.1 - Tell customers what they want
B.2 - I know it's bad but together we can make it better
B.3 - Working code is more valuable than documentation
B.4 - Risk can't be managed – expect to fail now and then
B.5 - Reuse strategies are too expensive and don't work

Appendix C - References

White Paper Excerpts ...

The Origin

When did engineering get involved with software? According to the Institute of Electrical and Electronics Engineers (IEEE) it was first used in the title of a 1968 NATO conference [NATO 68]. Looking at the literature, the IEEE Computer Society first published its Transactions on Software Engineering in 1972.

The Essence

The essence of the engineering approach to software as follows:

Creating cost-effective solutions

  • Providing software intensive solutions with predictable performance, scope, cost, time and quality,
  • While making economic use of all resources.

To real-world problems

  • To problems that are important to end users even though they may not fully understand their needs at the outset.
  • For large user communities, systematic commercial manufacture and large-scale production for resale.

By applying a formal scientific approach

  • By applying computer science, mathematics, logic and other scientific disciplines (for example control theory, fluid dynamics).
  • Using modelling and analysis techniques together with constructive knowledge unique to the engineering discipline.
  • Designing from combinations of off-the-shelf technologies that are then tested, adjusted and refined until they work satisfactorily.
  • Making decisions based on formal methods, scientific evidence and defensible metrics.

To building software

  • To building complex systems with many components and complex interactions, in problem domains with predictable inputs and repeatable, decision-making processes.
  • Using large multidisciplinary teams - featuring an ever-increasing number of specialties (safety, security, logistic support, reliability, availability).

In the best interests of mankind

  • As a trusted agent acting, not only to serve employers and customers but also to advance the well-being of mankind by applying an engineering code of ethics to protecting public health, safety and welfare.

The Business Case for Software Engineering

Software engineering is attractive to investors because it ...

Solves your problem
(pays attention to your needs and will get you a result)

  • Uses your problem statement as a starting point
  • Adds value with theoretical knowledge: science, mathematics, physics, logic and computing technology
  • Formally models your problem (defines your need precisely)
  • Uses progressive validation (doesn't wait until delivery to ask your opinion)
  • Formally manages fitness for purpose (quality)

Is predictable
(provides trustworthy cost, scope and time estimates)

  • Has a plan (with a reliable end date)
  • Provides reliable estimates of scope, cost and time
  • Is honest about risk (quantifies it in the precision of the estimates)
  • Has a proven process (doesn't make it up as it goes along)
  • Uses proven, codified knowledge, frameworks, models, proofs, historical metrics
  • Inspires confidence that commitments will be delivered

Is observable
(you can see where your money's going)

  • Has performance milestones for you to evaluate progress
  • Can quantify progress
  • Can predict future performance from past performance
  • Can demonstrate best practice (is auditable)
  • Manages change with a formal process

Is efficient
(does not waste resources)

  • Spends more time on analysis (less on reworking code)
  • Uses proven design patterns
  • Has fewer false starts
  • Incorporates known working solutions (seldom starts from scratch)

Is automated
(does not waste your money with error-prone manual procedures)

  • A focus on repeatable process lends itself to automation in development which leads to:
    • No lost requirements
    • More thorough validation (formal methods in testing)
    • No mistakes in the release process
    • Significantly higher quality

Is risk aware
(won't take silly risks with your money)

  • Can recognise risk (is aware of the risk raisers in software projects)
  • Tells you about risk
  • Quantifies risk (puts a precision on cost estimates)
  • Shuts down unacceptable high-risk activities early
  • Won't engage in destructive risky behaviour (no matter how much pressure you apply)
  • Takes action to reduce risk

Is safe
(designs products that will not destroy life and property)

  • Recognises and minimises safety risks
  • Has a framework for developing safe systems
  • Can comply with international software safety standards
  • Can make a case that your system is safe

Is secure
(designs products that can't be hacked)

  • Recognises security threats
  • Has a framework for developing secure systems
  • Can comply with international standards for security

Can build big
(can be trusted to deliver large and complex systems)

  • Has methods to deal with largeness and complexity (has partitioning strategies; is good at simplifying things)
  • Is expert in systems integration
  • Works well in multidisciplinary teams
  • Communicates well
  • Formally manages interfaces
  • Thinks in terms of whole systems

Has ethics
(cares about you and humanity in general)

  • Is practiced by professionals who ...
    • Have a published code of ethics
    • May require a licence to practice
    • Are morally bound to deliver systems that are fit for purpose
    • Won't do unprofessional things (no matter how much pressure you apply)
    • Will provide fearless advice on scope, cost and schedule
    • Will admit it if they screw up
    • Are less likely to lie to you
Collaboration

Member Comments

28 Comments 

21 member ratings

✭ ✭ ✭ ✭ ✩

RE Definition: Software Engineering

Understanding POC in Software Development

By anonymous » Tue 20-Feb-2024, 18:56, My rating: ✭ ✭ ✭ ✭ ✭

Diving into software engineering intricacies is fascinating! If you're keen on how a concept evolves before full development, check out this insightful piece on the role of Understanding POC in Software Development in the process. It's a game-changer for efficient project planning and risk management!💻🚀 #SoftwareEngineering

28 Comments  • Page 2 of 28 •        Previous «  1   2   3   4   5  …28 » Next

- Rate this definition.
- Did it help?
- Suggest improvements.
- Request more information.
- Exchange ideas with our member community.

Email to a friend