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
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
|
Member Comments |
28 Comments |
21 member ratings |
|
✭ ✭ ✭ ✭ ✩
|
|
|
