Software Engineering Notes
What is Software Engineering?
Software Engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software (IEEE Standard Glossary of Software Engineering Terminology). It encompasses everything needed to produce successful software, turning a raw idea into a powerful application that can be enhanced over time (Stephens, 2022).
Software product categories
Software systems can be categorized into two main types:
Generic Products: Stand-alone systems marketed to any customer (e.g., OS's, Office suites, games).
Product specification: Owned by the software developer, who makes decisions on software changes.
Customized Products: Software commissioned by a specific customer to meet their needs (e.g., software for specific markets, new products).
Product specification: Owned by the customer, who decides on required software changes.
Challenges in Software Engineering
Developing large software systems remains a challenging task. Typical problems include:
Meeting users’ needs
Low cost of production
On-time delivery
Low cost of maintenance
High reliability
Meeting Users’ Needs
This is the first step in every software project, involving requirements elicitation or analysis from users/customers, also known as requirements engineering.
Obstacles:
Problems of understanding: user <> technology
Problems of scope: defining boundaries
Problems of volatility: requirements changing over time
Mitigation: product owner and scrum master within SCRUM.
The set of requirements serves as checkpoints when the software will be delivered.
Validation: "Does the system conform to the requirements?" Are we building the right product?
Verification: Are we building the product right?
Cost of Software Production
The cost of software has evolved over time, with hardware costs decreasing and software costs increasing. Programmer productivity varies:
20-125 lines of code/day for small projects (10k lines)
1.5-25 LOC/day for large projects (1M lines)
Coding is only a small part of the Software Development Life Cycle (SDLC).
Software Cost Overruns
IT projects often face cost overruns and schedule overruns.
Software projects have an average cost overrun of 66%.
Value Delivery Capability Maturity leads to greater project performance. High maturity projects:
Complete 64% on time vs 36% for low maturity.
Complete 67% within budget vs 43% for low maturity.
Meet original goals/business intent 78% vs 56% for low maturity.
Experience scope creep 45% vs 63% for low maturity.
Are deemed failures 12% vs 21% for low maturity.
Lose 27% of budget when a project fails vs 37% for low maturity.
Influential Disasters
Examples of failed and over-budget custom software projects:
Healthcare.gov (US): Estimated: , Actual cost:
Dental health service system (Sweden): Estimated: , Cost: (CANCELLED)
Meeting Deadlines
Meeting deadlines is a typical challenge in software production. Brook’s Law states that "Adding manpower to a late software project makes it later.”
It takes time for people to become productive (training, getting to know the code base) + they take up time of the experienced team members.
More people doesn’t necessarily mean things get done faster:
Adding people to a highly divisible task decreases duration, until you get in each other's way….
Some specialized tasks are non-divisible, analogous to “It takes one woman 9 months to make one baby, 9 women can’t make a baby in one month”.
Communication overhead increases with team size → difficult to keep in sync:
Group communication increases by the the following formula:
Example:
Maintenance
Remedial Maintenance: Correcting faults in the software, as a consequence of inadequate testing.
Adaptive Maintenance: Due to users’ needs changing or OS/version changes, benefiting the “lifetime” of the software.
A well-known example of adaptive maintenance is addressing the “millennium bug” in legacy systems.
Reliability
Software is reliable if it works and continues to work without crashing or doing something undesirable. Key terms include:
Error: A wrong decision made during software development (e.g., Syntax error).
Fault: A problem that may cause software to depart from its intended behavior (caused by human mistakes, faulty business logic, functional/security faults).
Failure: An event when software departs from its intended behavior (e.g., execution of defect in code).
The job of removing bugs and ensuring reliability is called verification. Testing time accounts for 20-40% of development time.
Fail-safe Software?
A fundamental problem with testing is that you can never be sure that you have found every last bug, leading to the concept of “good enough software.” Software testing is crucial in “safety-critical systems.” The most expensive software fault was the Ariane 5 crash in 1996.
Phases of Software Engineering
Requirements
Software design
Implementation
Testing
Deployment
Maintenance
Note: Phases can be mixed or reordered!
SDLC (System Development Life Cycles)
SDLC is a term used in systems engineering, information systems, and software engineering to describe a process for planning, creating, testing, and deploying an information system.
SDLC Models
Waterfall
Spiral
(R)UP
Incremental Development
Agile & XP
Other:
Prototyping
Open source
Waterfall Model
The oldest model (1970), typical process model in engineering. In strict WF:
It is a series of steps (like a factory production line).
Each step is well-defined.
Each step creates a definite product.
Each product forms the basis for the next step.
Waterfall Model - Stages Frozen
In strict WF: stages are frozen. In practice: a problem in stage n+1 requires redo work in stage n, or worse: …n-1. WF + feedback undermines the model.
Waterfall Model - Advantages
Engineering approach (top-down, planning).
Each phase produces a well-defined deliverable.
Visible for management (in cost, in time).
Waterfall Model - Problems
Inflexibility when problems are detected; the later a problem is detected, the more effort is needed to fix it.
Large gap between requirements analysis at an early stage and acceptance testing (delivery) near the end.
Waterfall Model - Use Cases
Government or military: high structured and systematic approach needed, very strict requirements.
Safety-critical systems, embedded systems.
Software compliance (e.g., ISO standards).
Updates and maintenance of legacy systems (structured step-by-step approach).
Fixed-budget projects (limited budget and time).
Small, simple, and well-understood projects with fixed requirements:
Automating a specific business process.
V-Model
The V-model is an extension of the Waterfall model.
V-Model - Validation and Verification
the set of requirements serves as checkpoints when the software will be delivered.
“does the system conform to the req’s ?”
…this is known as validation
Difference between validation <> verification
validation: Are we building the right product?
verification: Are we building the product right?
V-Model - Static Analysis
Static analysis of documentation
Evaluation of products in the context of reviews
Traceability Analysis: "reason for being". The ability to establish a predecessor-successor relationship between one work product and another.
V-Model - Dynamic Analysis
Dynamic Testing
Validation
Does the system achieve the software requirements / business goals?
Does the system satisfy the end user's requirements?
Verification
Does the integrated system behave as per the overall design?
Do individual software modules behave as per the design?
V-Model - Use Cases
Government or military: high structured and systematic approach needed, very strict requirements.
Safety-critical systems, embedded systems.
Software compliance (e.g., ISO standards).
Updates and maintenance of legacy systems (structure approach to testing and verification
V-Model - Advantages
Structured approach: well-organized and easy to understand.
Each phase produces a well-defined deliverable.
Emphasis on testing and traceability of issues, so good for compliance with regulations or standards.
Visible for management (in cost, in time).
V-Model - Disadvantages
Linear and sequential: Changes to requirements or development are difficult to implement. → not suitable for projects where requirements are uncertain and subject to change.
Significant overhead (and cost): planning, documentation, and testing.
No initial prototypes, everything developed in the implementation phase.
Spiral Model
The main feature of the spiral model is the recognition that there is often enormous uncertainty at many stages during a software development project. The Spiral model makes the idea of ‘risk’ explicit. Each cycle consists of four steps:
analyze risks and plan
analyze requirements
construct
evaluate.
Spiral Model - Examples of Risks
The client changes some of the requirements.
Someone leaves the development team.
One of the component tasks of the development goes beyond its deadline.
The software performs too slowly.
The software occupies too much main memory.
A new software development tool or technology becomes available (or becomes obsolete?).
A user requirement was misunderstood
The target hardware configuration changes
A competitor launches a rival package onto the market.
Spiral Model - Advantages
Flexibility in the face of risks.
Cautious and robust approach to development.
Offers greater flexibility than the waterfall model
incremental, small WF’s, evolutionary prototype, …
Spiral Model - Disadvantages
Complex and costly.
Time-consuming due to multiple cycles of development, testing, and evaluation.
Absence of an early fixed plan.
Defining risks is not always straightforward → Risk-over-iteration.
Spiral Model - Use Cases
Diverse range of needs and requirements
Close collaboration with stakeholders
Iterative refinement
High risk or high complexity.
Complex, custom software for large corporations.
New, innovative application with cutting-edge technology
Examples:
Medical software: high degree of risk as it has to be safe and reliable.
Aerospace software: high risk, complex, harsh environments, …
Financial applications: high risk and complexity
Integration of multiple systems
(R)UP - Unified Process
UP “Unified Process”, from RUP:
Rational: company name
Unified: founders of Unified Modeling Language (UML): Booch, Rumbaugh, and Jacobson
P: process
UP Phases
The UP consists of four phases: inception, elaboration, construction, and transition.
Inception:
Project scope, business case, risk, key req’s
Elaboration:
Req's completed, general architecture devised, planning team, …
Architecture-Centric → “Executable Architecture Baseline”
Risk-Focused → most critical risks early in the project life cycle
Construction:
In timeboxed iterations!
Transition:
Deploy, validate & use it
UP - Techniques
Use of iterations in incremental development process:
The Elaboration, Construction, and Transition phases are divided into a series of time-boxed iterations
Focus on UML techniques (Analysis & Design)
Focus on providing executable code
Establishing a working architecture early
Using components
Establishing an effective team
Incorporating quality throughout V & V
UP - Advantages
Structured framework and process to manage complexity
Similar to the spiral model where largest risks are tackled early on
Early definition of architecture
Timeboxed iterations, some flexibility
Multi-disciplinary
Compatible with agile development (SCRUM, XP, see further)
UP - Disadvantages
A lot of overhead (e.g., UML, documentation, overly structured)
Risk assessment is essential (similar to the spiral model), requires specific expertise
As with all iterative approaches: risk for scope drift
UP - Use cases
Structured and disciplined approach towards a high-quality project that meets requirements
Flexible and adaptable to changes in requirements
Examples
Enterprise software: large-scale (Enterprise resource planning, customer relationship management, etc.)
Web applications (e.g., e-com, social networking)
Custom software for single client/organization
Agile
Agile methods:
A number of techniques that share common principles.
These principles are articulated in what is called the Agile Manifesto (2001)
These principles emerged from an analysis that older methods (referred to as heavyweight) were simply too big and unwieldy; that there was a need to use more lightweight approaches to development.
Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Agile principles
Customer satisfaction by early and continuous delivery of valuable software
Welcome changing requirements, even in late development
Working software is delivered frequently (weeks rather than months)
Close, daily cooperation between businesspeople and developers
Projects are built around motivated individuals, who should be trusted
Face-to-face conversation is the best form of communication (co-location)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicity—the art of maximizing the amount of work not done—is essential
Best architectures, requirements, and designs emerge from self-organizing cross-functional teams
Regularly, the team reflects on how to become more effective, and adjusts accordingly
Agile Methods - Range
Agile methods support a broad range of the software development life cycle:
some focus on the practices (e.g., XP),
some focus on managing the flow of work (e.g., Scrum, Kanban),
some support activities for requirements specification and development (e.g., FDD),
while some seek to cover the full development life cycle (e.g., DSDM, RUP)
Agile - Advantages
Flexible for changes in requirements
Increased collaboration between development teams, stakeholders, and customers
Continuous improvement
Faster time to market
Higher quality software due to continuous improvement
Agile - Disadvantages
Difficulty in defining requirements and architecture (no detail upfront)
Scope creep!
Difficult to predict when the project will be ready
Risk of lower quality documentation
Agile - Use Cases
Web applications: flexible for changes in requirements and design
Mobile applications: fast-evolving nature of tech and user expectations
Cloud-based solutions: due to focus on collaboration and continuous improvement
Emerging technologies: requirements might change quickly as technology evolves
Custom software: to handle complex and changing requirements
Agile - Extreme Programming (XP)
A very influential agile method, developed in the late 1990s, that introduced a range of agile development techniques. Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.
New versions may be built several times per day
Increments are delivered to customers every 2 weeks
All tests must be run for every build, and the build is only accepted if tests run successfully.
XP - Key practices
The user (client or a representative) is always present as a member of the development team
writes the ‘User stories for specification
prioritizes the User stories
specifies acceptance tests for each User story
Incremental development
is supported through small, frequent system releases.
Test-first development
Acceptance tests drive the project
Refactoring
Pair programming
XP - User stories for requirements
Customer/user part of the XP team
responsible for making deciding requirements
Requirements expressed as user stories or scenarios.
Broken down by the development team into implementation tasks = the basis of schedule and cost estimates.
The customer chooses stories for inclusion in the next release based on priorities and schedule estimates.
XP - Test-first development
Testing is central to XP, a program is tested after every change
XP testing features:
Test-first programming.
Incremental test development from scenarios.
User involvement in test development and validation.
Automated test harnesses are used to run all component tests each time that a new release is built.
XP - Customer involvement in Tests
Advantage:
The role of the customer in the testing process is to help develop acceptance tests for the stories that are to be implemented in the next release of the system.
Because the customer is involved in test phases, all new code is therefore validated, to ensure that it is what the customer needs.
Problem:
Not every customer will be full-time involved in the development team.
XP - Problems with test-first development
Programmers prefer programming to testing.
Some tests can be very difficult to write incrementally.
For example, in a complex user interface, it is often difficult to write unit tests for the code that implements the ‘display logic’ and workflow between screens.
It is difficult to judge the completeness of a set of tests.
Although you may have a lot of system tests,
…does your test set provide complete coverage?
XP - Pair programming
Pair programming involves programmers working in pairs, developing code together.
Advantage:
This helps develop common ownership of code and spreads knowledge across the team. + sharing of knowledge (if someone leaves)
It serves as an informal review process as each line of code is looked at by more than 1 person.
Problems:
Cost <> benefit?
XP - Refactoring
Conventional wisdom in software engineering is to “design for change”. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle.
XP, however, maintains that anticipating changes is not worthwhile as changes cannot be reliably anticipated.
Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.
XP - Refactoring Advantages
Advantage:
This improves the understandability of the software and so reduces the need for documentation.
Changes are easier to make because the code is well-structured and clear.
Problems:
Architecture refactoring will/could be an expensive process.
DevOps
Multiple parties are involved in software development
Client → defines the needs
Software developers → develop the app
Operational IT-team → deploy the app
Deployment/operations is not incorporated in agile. Often only limited interaction with operations during development. The application is unlikely to work from the start, e.g., specific configuration of IT infrastructure, security problems, network configuration, etc.
DevOps - Integration
DevOps is inspired by the agile approach of breaking down components and flexibility. It integrates operational IT and developers in 1 team.
Six C’s of Devops:
Continuous business planning
Collaborative development
Continuous integration → frequent commits to shared codebase, which are automatically and continuously tested
Continuous release and deployment (or continuous delivery):
Applications are split into small pieces of code that are continuously deployed
Immediate integration in IT environment: Daily updates to the apps (or even hourly…) instead of large updates every few weeks/months
Continuous monitoring
Collaborative customer feedback and optimization
DevOps Phases
Different versions of the cycle exist, but most map more or less to these steps:
Plan: define what functionality to build (i.e., create a backlog)
Code: develop the code
Build: commit code to shared repo (pull request), followed by code review and automated testing.
Test: further testing by deploying in test environment, security tests, manual tests (e.g., acceptance testing)
Release: build is ready for deployment in production (i.e., no breaking issues
Deploy: release in production
Operate: live and in use by customers, capture their feedback, keep operational (e.g., automated scaling of services)
Monitor: analyze feedback, performance, errors, etc.
DevOps - Advantages
Fast and continuous updates of software.
High reliability, high availability.
Quick rollout of new features.
Paradigms - Plan-driven & Agile
Agile methods have proven to be successful for small and medium-sized projects:
Small team, good communication, flexible working
So, appropriate for new software development. Possible problems are:
Lack of product documentation
Keeping customers involved in the development process
Maintaining the continuity of the development team
Agile in Large projects?
The informality of agile development is incompatible with the legal approach to contract definition that is commonly used in large companies.
Agile methods are appropriate for new software development. Yet most software costs in large companies come from maintaining their existing software systems.
Agile methods are designed for small co-located teams, yet much software development now involves worldwide distributed teams.
Are Agile methods “scalable”?
Is Agile suited for Critical Systems and Regulated Domains?
Conclusion
In practice, most practical processes will include elements of both plan-driven and agile approaches.