Software Processes

# Software Processes

Think about the last time you built something by hand — a piece of furniture, a garden shed, a batch of cookies. You did not simply start hammering; you followed a set of steps in a sensible order, and when a step went wrong you went back and adjusted. Building software works the same way, except the "steps" are far more elaborate, the teams are bigger, and the customers change their minds. A software process is the coherent set of activities that produces a software system — the ordered, repeatable way a team turns an idea into working, maintained software.

This material covers:

• What a software process is and the four fundamental activities every process contains — specification, development, validation, and evolution
• How processes are described (work products, roles, preconditions and postconditions)
• The three general software process models — waterfall, incremental, and reuse-oriented development — and when each one fits
• The main activities inside specification (requirements engineering), development (design and implementation), validation (testing), and evolution (maintenance)

The thread running through the whole lecture is this: there is no single process that fits every project. Choosing and shaping the process — or a blend of processes — to match the software, the people, and the constraints is itself a core engineering skill.

2.1 What Is a Software Process?

2.1.1 Definition and the Four Fundamental Activities

A software process (the set of related activities that leads to the production of a software system) is the backbone of every software project. In any engineering activity you perform a sequence of activities, and building software is no different. There is, however, no universal one-size-fits-all software engineering method that works for every kind of software product or system, and so no universally applicable software process exists. The process a company uses on a given project depends on the type of software being developed, the requirements of the customer, the skills of the people writing the software, and the operational constraints — the platform the software must run on, the time available, the budget, and so on.

Even though processes vary widely, all of them must include, in some form, the four fundamental software engineering activities:

These four look simple, but each is a very complex process in its own right. They contain many sub-activities, such as requirements elicitation, requirements specification, requirements validation, architectural design, high-level design, low-level design, unit testing, and integration testing. The processes also include supporting activities — software configuration management, software project management, and software quality management — that support development throughout the lifecycle and through the later maintenance and evolution of the system.

• Requirements elicitation (how you gather what users need) and requirements validation (how you check those needs are right) are sub-activities of specification.
• Architectural design (the overall skeleton), high-level design (subsystems), and low-level design (individual modules) are sub-activities of development.
• Unit testing (checking one component) and integration testing (checking components working together) are sub-activities of validation.
• Configuration management (tracking versions of code and documents), project management (planning, staffing, budgets, progress), and quality management (setting and checking quality standards) run alongside the whole lifecycle rather than belonging to any single phase.

2.1.2 Describing a Process: Work Products, Roles, Preconditions, and Postconditions

When we talk about software processes we usually describe the activities themselves — defining a database, designing a database, designing user interfaces, or the ordering of these activities — because everyone can relate to what people actually do to develop software. But a full process description must say more than what is being done. It must also say who is involved, what the input is, what the output is, and what conditions influence the sequence of activities.

A process description may also include:

• Work products (also called deliverables) — the outcomes of a process activity. For example, the outcome of a high-level architectural design activity may be a model of the software architecture. Work products are the visible, reviewable results that let managers and customers track progress.
• Roles — the responsibilities of the people involved in the process. Examples are software developers, software testing engineers, software project manager, configuration manager, and quality manager. A person may fill several roles, and a role may be shared by several people; what matters is that the responsibilities are clear.
• Preconditions and postconditions — for every activity there is a precondition that must hold before the activity is enacted (or before a work product is produced) and a postcondition that must hold after. For example, before architectural design begins, a precondition may be that the customer has approved all the requirements; after architectural design, a postcondition is that an architectural model of the system exists.

Software processes are complex, highly intellectual, and creative. They rely on people making decisions and judgments throughout, which is one more reason no single process suits every organization. Most software companies have developed their own software development processes, and these processes have evolved to take advantage of the capabilities of the developers in the organization and the characteristics of the systems being developed. For very safety-critical systems a very structured development process is required, with detailed records maintained and the design completely verified even before development can start. For interactive business systems, where requirements are likely to change frequently, a more flexible, agile process is likely to work better.

Professional software development is a properly managed activity, and planning is an inherent part of all processes — even the most agile project plans its next steps; only the planning horizon differs.

2.1.3 Plan-Driven versus Agile Processes

A plan-driven development process is one where all the activities of the entire software development lifecycle are planned in advance, and progress is measured against that plan. Resources are allocated, budgeted, and tracked and monitored continuously. This is the characteristic of plan-driven processes: the set of activities for the whole project is fixed up front.

An agile process is incremental and iterative. Here the planning itself is incremental and continual, carried on while the software is being developed, because not all requirements are captured upfront. The initial core requirements might be specified in the first iterations or increments. Because planning is continual, it is easier to change the process to reflect changing customer or product requirements. Agile methods are discussed in detail in a later session.

The lecture contrasts the two approaches directly — this is one of the most repeated distinctions in the whole session:

When to pick which: choose plan-driven where the cost of getting something wrong is huge and the requirements can be pinned down; choose agile where requirements will keep moving and feedback is cheap. For large software systems — systems of systems — you generally need to find a balance between plan-driven and agile approaches for the various parts of the system: the well-understood core can be planned, while the uncertain edges evolve.

2.1.4 Process Improvement

There is always scope for process improvement in any organization. Processes may include outdated techniques, or they may not take advantage of the best practices of industrial software engineering — many organizations still do not apply best practices in their regular development activity. Organizations can improve their processes by adopting techniques and tools such as UML-based processes and test-driven development. These aspects come up again when process improvement is discussed.

Real-world connection: Every piece of software you use today ran through all four activities, arranged by some process. A car's engine-control unit was developed with a heavy, heavily documented plan-driven process, because a silent failure in the steering software could cost lives. The social media app on your phone was built incrementally — features shipped in weekly increments, feedback gathered from real users, and evolution continues daily. When you later design operating-system algorithms or lead a team, the concurrency, quality, and configuration-management concerns that processes coordinate will be your daily environment.

2.2 Software Process Models

2.2.1 What a Process Model Is

A software process model, sometimes called a software development lifecycle (SDLC) model, is an abstract or simplified representation of a software process. A model, by definition, is a representation of a real-world entity or process. Each software process model represents the process from a particular perspective, and so provides only partial information about that process. For example, a process activity model shows the activities and their sequence, but may not show the roles of the people involved in those activities. A roles-and-responsibilities model may show who does what but say nothing about ordering. Neither is "wrong" — each is incomplete by design, and that incompleteness is what makes the model readable.

The general process models, sometimes called process paradigms, are high-level abstract descriptions of software processes that can be used to explain different approaches to software development. Think of them as process frameworks that can be extended and adapted to create more specific software engineering processes suited to your organization, your project, the resources you have, your people, and the organizational, technical, and social constraints you face. You choose the approaches that are applicable to your organization.

In short: a process model is a template. Your organization takes the template, extends it, and instantiates it into a concrete process with named stages, named roles, and real documents. Two companies can both claim "we use the waterfall model" and run visibly different processes, because both customized the same template differently.

2.2.2 The Three General Process Models

Three general process models are examined here, at a high level: the framework of each process rather than the details of its internal activities. Each of the next several sections digs into one of them.

1. The waterfall model — assumes the fundamental process activities (requirements specification, software development, software validation, and software evolution) and represents them as separate process phases: requirements specification, software design and implementation, and testing. The phases run one after another, like water falling over ledges.
2. Incremental development — the system is developed as a series of versions or increments, with each version or increment adding functionality to the previous one. Incremental and iterative development of this kind is the basis for agile development — the sentence that defines the model's place in the process landscape.
3. Reuse-oriented development — based on the availability of reusable components or systems that can be integrated into an existing or a new system: you configure these components for use and integrate them into the system you want to develop.

Reuse-oriented development is quite common nowadays, because rarely does any professional software development start from scratch — unless you are doing a programming assignment as part of a course. In professional development you usually start with an existing base of code, with libraries and components available within a framework such as .NET or any other application development framework, and you draw on them, integrate them, and configure them to suit your requirements.

The three models differ in how they arrange the same fundamental activities:

2.2.3 No Universal Model: Matching the Model to the System

There is no single process model that is right for all kinds of software. The right model depends on the customer, the requirements, the regulatory requirements, the environment where the software will be used, and the type of software being developed. To take the recurring examples:

The majority of practical software processes are based on a general model — the waterfall, the incremental model, or the reuse-oriented model. This is especially true for large systems engineering. For large systems, which are systems of systems, it makes sense to combine the best features of all three general models. You need information about the essential system requirements to design a software architecture that supports them, so you cannot develop a large system purely incrementally: you need an architectural base, then you develop each module or component one by one, incrementally. Different subsystems inside a large system may have to be designed and developed using different approaches. Parts of the system that are well understood, with fully specified requirements, can be developed using a waterfall model, or bought as commercially available off-the-shelf systems, or taken as reusable components and configured directly into your system. Parts that cannot be specified in advance, because the evolution of the requirements is not clear, should be developed using an incremental approach. In both the waterfall and the incremental model you may also reuse a number of software components, depending on their availability and suitability.

2.2.4 The Rational Unified Process

Many attempts have been made to develop universal process models that draw on all the general models. One of them is the Rational Unified Process (RUP), also called the unified process, developed by Rational, a US software engineering company. The Rational Unified Process is a framework that can be instantiated in different ways to create processes and process models that resemble any of the general process models, or a combination of them. It has been adapted by some large companies, notably IBM, but it has not been widely adopted. The unified process is looked at briefly in a later session.

The lesson of RUP's history is worth keeping: even the best-engineered universal framework did not achieve universal adoption. Organizations do not adopt a process because it is elegant on paper; they adopt one that matches their people, their contracts, their regulations, and their habits — which is why the "no universal model" claim keeps coming back.

Real-world connection: Process models are not academic decoration — they shape real engineering budgets and careers. Aviation and medical-device suppliers certify their processes precisely because regulators must audit the waterfall-style record trail before a chip or a drug pump ships. Product companies like web-app vendors run continuous incremental delivery: weekly releases, each a new increment. Enterprise IT departments spend most of their time configuring and integrating existing systems — the reuse-oriented model — because rebuilding a payroll system from scratch would be commercial suicide. When you interview for a software role, "what process does your team use?" is a genuine, meaningful question about how the team's work will be planned and controlled.

2.3 The Waterfall Model

2.3.1 Origins and Overview

The classic waterfall model draws on classic engineering approaches, specifically traditional hardware engineering, where you specify the requirements, design, create a high-level design, then do the implementation, then the testing and integration, and then operation and maintenance. It was the first published model of the software development process, derived from the engineering process models used in large systems engineering. It presents software development as a number of stages, and because of the cascade-like appearance flowing from requirements downward, it became known as the waterfall model of the software development lifecycle.

The waterfall model is an example of a plan-driven process: every activity is planned well in advance, resources are allocated, and progress is tracked and monitored periodically by the managers concerned. In principle, you plan and schedule all process activities before starting software development.

Different sources show many variants of this classic model — searching images for "waterfall model" turns up countless adapted versions, and organizations adapt the model to their needs. The simplified version used here is just one example.

The waterfall diagram (visualize it): picture five rounded rectangles stacked vertically, one per stage, from top to bottom: requirements definition, system and software design, implementation and unit testing, integration and system testing, operation and maintenance. A solid arrow runs downward from each box to the next — the forward flow. There is also a backward feedback flow: from each stage, a dashed arrow loops back up to the previous stages. The layout reads like water cascading down a series of ledges — that is where the name comes from. The one-sentence takeaway: the diagram shows both the ideal downward sequence and the practical reality that information flows backward whenever a later stage discovers a problem in an earlier one.

2.3.2 The Five Stages in Detail

The five stages directly reflect the four fundamental activities — specification appears as the first stage, development as stages 2–3, validation as stage 4, and evolution as stage 5.

Stage 1 — Requirements analysis and definition. You specify the system services, the constraints on its development and operation, and the goals for the product, in consultation with the system users. These are then refined and defined in detail, and a detailed system specification, or software requirements specification, is prepared at the end of this phase. The output is the contract the rest of the process will be judged against.

Stage 2 — System and software design. Once the requirements are agreed and signed off between the client and the developers, you do the system design and software design, which includes the high-level architectural design as well as the detailed design of the modules. In systems engineering, requirements are allocated to either hardware or software, and an overall system architecture is established. Software design identifies the fundamental software system abstractions, the architectural components and their relationships, and then elaborates the architectural design into a more detailed design with sub-modules and components that interact with each other, as you do in object-oriented analysis and design.

Stage 3 — Implementation and unit testing. Once the design is agreed and verified as correct and complete with respect to the requirements, the software design is realized as a set of programs, modules, or program units. Unit testing is done by the programmers themselves, verifying that each unit or program meets its specification. "Unit" here means one independently buildable piece — a module, a class, a function package — and its test is the programmer's personal quality gate.

Stage 4 — Integration and system testing. The individual program units or modules are integrated and tested as a complete system, to ensure that the software requirements are met as a whole, as stated in the requirements specification. This stage involves various types of testing — integration testing, system testing, and acceptance testing — and after it, including acceptance testing, the software system is delivered to the customer.

Stage 5 — Operation and maintenance. Once the system is delivered it is put into operation, and it then undergoes continuous maintenance: changing requirements, fixing bugs, and so on. This is the longest lifecycle phase. Maintenance involves correcting various errors that were not discovered in earlier stages of the lifecycle, improving the system units, enhancing the system services whenever new requirements are discovered, and enabling the system to remain strong and serve a long, productive, and useful life.

2.3.3 Sign-Off and Feedback between Stages

In principle, the result of each phase of the waterfall model is one or more documents that are approved and signed off between the client and the developer, and the next phase cannot start until the previous phase has finished. This comes from the earlier hardware development process, where manufacturing costs are high, so it makes sense to sign off the requirements and the design once they are verified, and to sign off testing, and so on.

For software, however, these stages overlap and feed information to each other, through forward-feeding information and feedback arrows. During design, problems with requirements are identified; during coding, certain design problems are found; and so on. In practice the software process is never the simple linear sequence the waterfall diagram suggests, with arrows moving only from requirements to design to implementation to testing to operation and maintenance. Instead there is feedback from one phase to another — from operations back to implementation, testing, design, or even to requirements. As new information emerges during the process, the documents produced at previous stages should be modified to reflect the required system changes. For example, if it is discovered that a requirement is too expensive to implement, the requirements document should be changed to modify or remove that requirement. That requires customer approval and causes delays in the overall development process.

2.3.4 Renegotiating Requirements and Premature Freezing

The exchange above captures a real tension: every requirement change costs delay and paperwork in a plan-driven project, so both sides feel pressure to declare "this is it" and stop changing. But that freeze does not make the problems disappear — it pushes them into the future, where they surface as user disappointment, hacked-together workarounds, or systems that quietly fail to do what people actually needed.

During the final lifecycle phase of operation and maintenance, the software is put into use. Various errors and omissions in the original software requirements are discovered, programming errors, bugs, and design errors emerge, and while the system is in operation the users realize that this is not exactly what they wanted, and new requirements emerge. So the system must evolve to remain useful. Good systems survive for long; it is bad software that does not serve its purpose that is discarded soon. You may have to repeat all the previous process stages, starting from requirements, but in reality the software has to be flexible and accommodate change while it is being developed.

2.3.5 When the Waterfall Model Fits (and When It Does Not)

The need for early commitment to a fixed requirement, and the rework involved when changes are made, mean the waterfall model is appropriate only for certain types of systems: safety-critical systems and embedded systems.

For safety-critical systems there is a need for extensive safety and security analysis and verification of the specification as well as the design, sometimes including formal verification, that is, verification against a mathematical model. In these systems the specification and design documents must be thorough and complete so that this analysis is possible. Safety-related problems in the specification and design are usually very expensive to correct at the implementation stage or even after implementation.

The waterfall model also suits large software systems that are part of broad systems engineering projects including both hardware and software, with many partnering companies involved in the development. The hardware in such systems may be developed using a model similar to the waterfall model, and companies find it easier to apply one common model, like the waterfall, for both hardware and software. When several companies are involved, complete specifications may be needed even to distribute the work: independent development of different subsystems by different contractors needs a complete specification.

The waterfall model is not the right choice where informal team communication is required and possible, and where the software requirements keep changing quickly. For systems with a lot of user interaction, iterative or incremental development and agile methods are much better.

In short, the waterfall model is mostly applicable when the requirements are well understood and changes during the design process are likely to be fairly limited, and for large systems engineering projects that need coordination of work among different developers.

2.3.6 Formal System Development

One variation of the waterfall model — or one component of it — is formal system development. You develop a mathematical model of the system specification, refine it using mathematical transformations that preserve its consistency, and then translate it into executable code using automated code converters from the mathematical specification to code, which preserves correctness. Because of the high cost of developing a formal specification, this development model is very rarely used, except for highly safety-critical systems engineering.

The logic of the approach: if the specification is a mathematical model, and every refinement step provably preserves consistency, and the code is generated automatically from the final model, then correctness is preserved by construction from specification to code. The price is that building the mathematical specification is slow, needs highly specialized people, and demands complete requirements up front — which is exactly why formal development only appears where the cost of a defect is catastrophic. A refinement step counts as safe only if it provably keeps the model consistent; skipping that proof, or letting the model drift from the real requirements, silently destroys the guarantee.

Real-world connection: The waterfall's discipline lives on wherever failure is unforgiving — avionics, medical devices, railway signaling, nuclear-plant control. Regulatory bodies audit the sign-off documents themselves; the process record is part of the deliverable. And the human-lifecycle point is worth remembering when you choose a career path: roughly two-thirds of a professional software developer's effort typically goes into evolving existing systems, not building new ones — the iceberg is real, and most of your working life will be spent below the waterline.

2.4 Incremental Development

2.4.1 Core Idea: Concurrent Specification, Development, and Validation

A process model is an abstract diagram representing the sequence of activities, or the arrangement and flow of activities, within the process. The waterfall model is a linear sequential model with feedback from each stage to the previous stages. In the incremental model, the three main activities — requirements specification, software development, and software validation — are concurrent activities. There is feedback from each to the others and feed-forward from each to the others, moving back and forth in an iterative, incremental manner, producing many intermediate versions before the final version of a particular module or increment is released.

Incremental development starts with an outline description, not a detailed specification, and it is intended for interactive systems where the requirements are frequently going to change. The idea is simple: develop an initial implementation, get feedback from the users and other stakeholders, and the software evolves through several intermediate versions until the requirements for that particular module are met, so that a final version is developed as the first increment. This first increment may undergo further changes as the software gets developed. The key point is that specification, development, and validation are concurrent: a module may be specified partly, implementation of that part can begin, and it can even be validated and tested, while the next part of the module is specified, developed, and incremented.

The incremental development diagram (visualize it): three horizontal streams — specification at the top, development in the middle, validation at the bottom — flow left to right, with arrows crossing between them in both directions, so information moves from any stream to any other. The process starts on the left with an outline description (not a specification). Working across the three interleaved streams, the system passes through intermediate versions (each a partially complete system) until it reaches the final version on the right. The one-sentence takeaway: while the waterfall draws one pipeline, this diagram draws three parallel pipes with constant cross-traffic — the activities genuinely overlap in time.

2.4.2 Concurrent versus Parallel

So specification, development, and validation are interleaved in time rather than run in parallel, with rapid feedback across all the activities.

The correction sticks because the two words sound interchangeable, but they describe different machines. Parallel execution means several things literally happen at the same instant — two threads on two cores, two assembly lines side by side. Concurrent execution means several things are in progress during the same time window, taking turns — one thread waiting for input while another computes, a chef who starts the rice, then chops vegetables, then returns to the rice. In the incremental model, specification, development, and validation do not all run simultaneously; they take turns, interleaved, and each feeds the others.

2.4.3 How Increments Are Chosen and Evaluated

In some form, incremental development is the most common process model. It is the same as the agile approach to development, and it is the most common approach for developing application systems and software products. It can be plan-driven, agile, or usually a mixture of both: in a plan-driven approach the system increments are identified in advance; in an agile approach the early increments are identified, but the development of later increments depends on the progress of the project and the customer's priorities.

Incremental software development, which is a fundamental part of agile development methods, is better than the waterfall approach for systems whose requirements are likely to change during the development process — which is the case for most business systems and software products. It also reflects the way we actually solve problems. We rarely get the complete set of requirements at the outset, and we rarely work out a complete problem solution for a complex system well in advance. Instead we move towards a solution in a series of steps, tackling one component at a time and backtracking when we realize we have made a mistake or hit a dead end. Developing software incrementally is also more manageable, cheaper, and makes changes easier than trying to develop a complete system as a whole — although, as we will see later, the waterfall model also allows a lot of flexibility.

Each increment or version of the system incorporates some of the functionality the customer needs. Generally, the early increments include the most important, most critical, or most urgently required functionality.

2.4.4 Advantages over the Waterfall Model

Incremental development has several advantages over the waterfall model:

• The cost of accommodating requirements changes is much reduced, because you are working in smaller chunks, and even if a change is not found to meet the requirements you can modify it in the next increment.
• The amount of analysis and documentation that has to be redone is significantly less than with the waterfall model, where you try to capture the complete specification up front and then design the complete system architecturally and in detailed design.
• With smaller increments it is easier to get customer feedback on the development work done. The customer can comment on demonstrations of the software and see how much has been implemented and what the progress is. With only a design document or a requirements specification, the customer cannot appreciate the progress — unless they see something working, even a prototype, they cannot appreciate work in progress from design documents alone.
• You get early delivery and deployment of useful software to the customer. If a module's requirements are well understood and the module is critical or urgent for business needs, the customer can start using it and gain some value — and some experience with the software — much earlier than with the waterfall model, where you specify all requirements, design the complete system, implement it, test it, and deliver it after a long time.

2.4.5 Management Problems and Structural Degradation

From a management perspective, there are problems too — and software engineering is not only about design, development, and testing; it also involves software project management, quality management, and configuration management. A manager needs regular visible work products to measure progress. When systems are developed quickly without documentation, it is hard to produce documentation for each version on a daily basis, so documentation is rarely updated, especially when incremental, iterative (agile) models are followed. You end up with an incomplete product — some modules delivered, developed, and tested — but you cannot sign off on a prototype, you need some documentation, and the process is not as visible as it is in the waterfall model.

The second problem comes from rapid changes in the implementation, the requirements, and the design, without a stable architectural design as the basis for constructing the whole software system. Because the design and the requirements keep changing, the system structure — the core architectural structure — tends to degrade as new increments are added. Regular change leads to messy code, as new functionality is added in whatever way is possible, sometimes in a jury-rigged way, just so that it works and meets the requirements. Over time it becomes increasingly difficult and quite expensive to add new features, because the code becomes too difficult to manage, it is not refactored, and it is not quite understandable; add a new requirement and the code tends to collapse.

So the incremental model trades one cost for another: it lowers the cost of change but raises the cost of chaos. The waterfall spends heavily up front to keep the structure clean; the incremental model must spend continuously to keep the structure from rotting.

2.4.6 Refactoring and the Woodpecker Warning

To reduce structural degradation and general code messiness, agile methods suggest that you regularly refactor: improve and restructure the software periodically so that it stays understandable, reliable, and clear, and easier to code and develop. Refactoring (restructuring existing code without changing what it does) is the maintenance discipline that pays the structural debt the increments accumulate.

The need for this was captured by one of the earliest software engineers, back in the 1970s, who observed that system structure tends to degrade with constant tinkering of code, and put it succinctly:

"As if builders built buildings the way programmers tend to write programs, then the very first woodpecker that comes along would destroy the entire civilization."

Think about the programs you wrote years ago — can you still understand them? And if many people work on the code together and the structure degrades, can you still make changes and keep the code strong and reliable? The system structure tends to degrade as you try to add new increments without refactoring and redesigning the system.

These problems are particularly acute for large, complex, long-lifetime systems where different teams develop different parts of the system. Large systems need a stable framework or architecture, and the responsibilities of different teams working on different parts of the system need to be defined precisely with respect to that architecture, planned well in advance rather than developed incrementally.

2.4.7 Incremental Development versus Incremental Delivery

Incremental development does not mean you have to deliver each increment to the customer. You can develop the software system incrementally and expose it to customers and stakeholders for feedback and comments, without necessarily delivering or deploying the software in the customer's environment. There is also incremental delivery: the software is actually deployed into the real operational environment, so that user feedback is likely to be more realistic. Providing feedback through real deployment is not always possible, though, because experimenting with the new software can disrupt all the normal business processes.

The practical distinction: development is about how you build (in slices, with feedback); delivery is about where the slices end up (in the customer's real working environment). A team can develop incrementally and demo each increment in a test environment — the customer reacts, but their daily business is untouched. Incremental delivery puts each increment into production, where feedback is more realistic — users genuinely try the software in real workflows — but the risk is disruption: a half-built system sharing the stage with the legacy system can disturb normal business processes, so not every customer will accept that mode.

Real-world connection: Incremental development is the default engine of the modern software industry — mobile apps ship every few weeks, web products deploy continuously, and each release is an increment built on user feedback. The concurrency vocabulary also lives at the heart of computing: operating systems juggle concurrent processes (interleaved) and exploit parallel processes (simultaneous on multiple cores), and the same interleaving discipline governs modern system design from cloud schedulers to database transactions.

2.5 Reuse-Oriented Development

2.5.1 The Idea of Building from Existing Components

Reuse-oriented development is based on the availability of reusable components or systems. You configure these components for use in a new system, and you integrate them into the system that you want to develop. As noted earlier, it is quite common nowadays: rarely does professional software development start from scratch — that happens mainly in programming assignments as part of a course. In professional development you start with an existing base of code, and you have several libraries and other components available within a framework, such as .NET or any other framework for application development. You draw on them, and the developer integrates and configures these components to suit the requirements.

Real-world: business systems are increasingly being developed by reusing or configuring existing systems and integrating them to create a new system with the functionality that is required. Commercially available off-the-shelf products are a related idea: instead of building everything yourself, you buy a system that already exists and configure it to your needs. Component selection also shows up inside design: when a team designs a system, one activity is looking for reusable components — if suitable components exist, they are integrated; if not, new components are designed (see the design activities in Section 2.7).

How the reuse process runs (an outline): the team starts from an outline of the essential requirements (not a full specification), then discovers and evaluates candidate components and systems — do they provide the required functionality? The requirements are then refined to reflect what the available components actually offer. If a suitable off-the-shelf application exists, it is configured for the new setting; otherwise reusable components are adapted and any gaps filled by developing new components, and everything is integrated into the new system. Notice the direction of the flow: requirements bend toward what exists. That is the honest price of reuse — and its biggest difference from the other two models.

2.5.2 Reuse inside Large Systems

In large systems engineering, reuse is one of the levers for combining the best features of the three general models. Parts of the system that are well understood, with fully specified requirements, can be developed with a waterfall model, or they may also be bought as commercially available off-the-shelf systems, or taken as a reusable component and directly configured into the system. Parts that cannot be specified in advance are developed incrementally. In both cases — the waterfall model as well as incremental development — you could have a number of software components that are reused, based on their availability and suitability. The choice of how to build each part is an organizational, technical, and commercial decision as much as an engineering one.

Real-world connection: Look at any large enterprise IT department and you are looking at reuse-oriented development: enterprise resource planning suites configured for a company's accounting rules, customer-relationship systems wired to existing databases, payment gateways and identity services invoked as web services. Even the mobile app on your phone is mostly a thin layer of new code over a stack of reused components — SDKs, cloud services, and open-source libraries. Understanding reuse is also a career skill: "design for reuse" and "evaluate before you build" are everyday professional decisions, not course abstractions.

2.6 Requirements Engineering Activities

2.6.1 Elicitation and Analysis

The first requirements activity is requirements elicitation and analysis: collecting information about what the system must do. This may involve developing one or more system models and prototypes that help you understand the system to be specified. Requirements engineering is discussed in detail in a later session; here the activities are surveyed in brief.

Elicitation is detective work, not dictation. The information comes from observing existing systems in operation, from discussions with potential users and procurers, and from task analysis — breaking down the actual work people do so the system can support it. Often the team also builds one or more system models and prototypes: a model (a diagram of the domain or the data) makes assumptions visible, and a prototype lets users react to something concrete instead of describing what they want in the abstract. Many organizations also run a short, cheap feasibility study before requirements engineering starts, asking whether the system is needed, whether it is technically possible, and whether it is financially realistic.

2.6.2 Specification: User Requirements and System Requirements

Requirements specification is the activity of translating the information collected during requirements elicitation into a document that defines a set of requirements. That set typically has two levels:

The same capability appears twice at two levels of detail: abstract enough for the people paying, precise enough for the people building. Requirements analysis continues during definition and specification, and new requirements come to light during the entire process, so all these activities are interleaved with each other — the three activities of elicitation, specification, and validation are not a one-pass sequence but an ongoing conversation.

2.6.3 Validation of Requirements

Requirements validation checks the requirements for correctness, completeness, consistency, and realism. During this process the various errors in the requirements are discovered, and the requirements are modified to correct these problems.

The four checks have distinct meanings:

• Correctness — the requirements describe what the users really need, not what someone assumed they need.
• Completeness — nothing essential is missing; every important behavior, input, and constraint is captured.
• Consistency — the requirements do not contradict each other (one requirement must not say "every order is shipped immediately" while another says "orders from the warehouse are held for review").
• Realism — the requirements can actually be delivered with the available technology, people, budget, and time.

Each error found here is cheap to fix — a sentence in a document. The same error discovered after implementation means reworking design, code, and tests.

2.6.4 Requirements in Agile versus Plan-Driven Projects

In agile methods, requirements specification is not a separate activity of drawing up a requirements specification document; it is seen as part of the system development. Requirements are informally specified for each increment, like a story, just before that increment is developed, and the stories are prioritized. The requirements are elicited from users who are part of the system or who work closely with the development team — most agile teams have an end-user representative.

The answer points at a real distinction between the two worlds: a user story ("As a warehouse manager, I want to see stock levels below reorder point so that I can reorder in time") is a compact, priority-ranked requirement written just before the increment is developed; a plan-driven requirements document is a formal, agreed, signed-off contract that development cannot start without. Both describe the same system's needs; they differ completely in form, timing, and legal weight.

Real-world connection: Requirements failures are the most-cited cause of software project trouble — projects built for the wrong users, features nobody asked for, and budgets blown fixing misunderstandings. Every serious engineering domain has institutionalized the checks: regulated industries audit requirements documents, agile teams put a product owner in the room, and safety-critical work formally traces every requirement to a test. When you take on any software task, the elicitation questions ("who uses this, when, and what do they truly need?") are the most valuable questions you can ask.

2.7 Software Design and Implementation

2.7.1 The Design Process: Inputs, Activities, Outputs

Once the requirements are captured, analyzed, and specified, they have to be converted into an executable system. That is the development activity, and it involves the separate activities of software design and implementation. In most agile methods, design and implementation are interleaved, with no formal design documents produced; the software is still designed, but the design is recorded informally — on wikis, whiteboards, and notebooks.

Software design is a description of the structure of the software to be implemented: the data models and structures to be used by the system, the interfaces between the system components, and sometimes the algorithms to be used. Design is covered in detail in the course modules on software engineering.

Designers do not arrive at a finished design immediately; they develop the design in stages, adding detail as they go, with constant backtracking to modify earlier designs. The design process can be shown as an abstract model with inputs, process activities, and outputs. The design process activities are both interleaved and independent: even though they are shown as input, process, and output, they are interleaved as well as independent. New information about the design is constantly being generated, and this affects the various previous design decisions, so rework in design is inevitable. Design is an iterative process and a creative process.

The design process diagram (visualize it): three columns — on the left, the design inputs (platform information, software requirements, data descriptions); in the middle, the design activities (the four activities detailed below); on the right, the design outputs (the artifacts those activities produce). Arrows flow left-to-right, but the middle column's activities are drawn as interleaved and interdependent, not as a strict sequence. The one-sentence takeaway: the diagram looks like a pipeline but behaves like a web — a discovery in one activity routinely sends the team back to earlier decisions.

2.7.2 Platform and Data Inputs to Design

Most software interfaces with other software systems and other hardware systems: operating systems, databases, middleware, and other application systems. These make up the software platform — the environment in which the software will execute. Information about this platform is an essential input to the design process: what technology, what platform, what will the product run on? Designers must decide how to best integrate the system with its environment. If the system's data description is an essential input to the design process, it may be included in the platform specification, and the system data organization can be defined during design.

Think of the platform as the "ecosystem" the software will live in: the operating system it runs on, the database it stores its records in, the middleware that connects it to other services, and the neighboring application systems it must talk to. Ignoring the platform is designing in a vacuum — a system architected without knowing its database and OS will fight its environment from day one.

2.7.3 The Four Design Activities for Information Systems

The activities in the design process vary depending on the type of system being developed. Real-time systems, for example, require a further stage of timing design, but may not involve a database at all, so there is no database design. For an information system, the typical design process has four activities:

The four activities are not a checklist to be finished one after another — they feed each other. The architecture constrains the database, the interfaces constrain the components, and what the component search finds (or fails to find) feeds back into the architecture.

2.7.4 Design Outputs

These activities lead from the design inputs — platform information, the requirements specification, and the data description — to the design outputs: the system architecture, the database design, the interface specification, and the component descriptions, which can then be used to implement the components.

The form of the outputs depends on the approach. For safety-critical systems, the outputs are detailed design documents setting out precise and accurate descriptions of the system. If a model-driven approach is used — converting UML models into code — the design outputs are the design diagrams. In agile methods, the outputs of the design process may not be a separate specification document like a design specification; they may be represented through the code of the program itself, which implements the required features and structure, with constant refactoring.

The same design work can produce very different artifacts: a 200-page design document for a safety-critical subsystem, a set of UML diagrams that generate code, or simply a well-structured codebase that has been continuously refactored. What matters is that the design exists — as a document, as diagrams, or as the code's own structure — and that it is accurate enough to build on.

2.7.5 Implementation and Programming Strategies

Developing the programs that implement the system naturally follows from the system design. Some classes of programs, like safety-critical systems, are designed in thorough detail and verified before any implementation begins. But typically in agile development methods, design and programming are interleaved. Software development tools can generate high-level skeleton code from a design, including code that defines and implements interfaces; in many cases the developer only needs to add the details of the algorithm of each program component.

Programming is an individual activity, and there is no general process for programming. Different programmers proceed differently. Some start with the components they understand well, develop and test them first, then move on to the components that are less understood or less fully specified. Others take the opposite approach: they postpone the small familiar components (because they know how to develop and integrate them later), define the data early, understand the complex components, do some prototyping, and develop the less understood components first, using that to drive program development. Some like to define the data structures early; others defer the data to a later stage of the design process and look at the functionality first.

There is no single "right" programming strategy, only strategies that fit the individual and the problem. What the strategies share is that they are personal working styles — which is exactly why the process level (design, interfaces, architecture) exists: it coordinates individuals whose inner working methods cannot and should not be standardized.

2.7.6 Unit Testing and Debugging

Programmers normally carry out some testing of their code as they develop it. This is unit testing, and it often reveals program defects or bugs that must be removed from the program. Finding and removing bugs from the program is called debugging.

Testing and debugging are different activities. Testing establishes the presence of defects, while debugging locates and corrects them. When you debug, you generate hypotheses about the observable behavior of the program, and then test those hypotheses, hoping to find the fault that caused the output anomaly. Testing is covered in detail under the testing chapters. Testing a hypothesis may involve tracing the program code manually — walking through the code — and may require new test cases to identify and localize the problem. Interactive debugging tools, which show the intermediate values of the program variables and trace the execution of statements, are usually used to support the debugging process.

The distinction is easy to blur: testing is a yes/no verdict — "there is a defect somewhere"; debugging is an investigation — "here is exactly the fault, and here is the corrected code." Testing tells you the patient is sick; debugging is the diagnosis and the surgery. Real-world: most practitioners use a variety of debugging tools for their testing and debugging work.

Real-world connection: Every serious codebase you will meet is a design artifact first: the architecture decides which team owns which module, the interfaces let teams develop in parallel, and the database design shapes everything from performance to migrations. The IDE habit you already have — letting the tool generate skeletons and filling in the algorithms — is the same division of labor used at industrial scale with UML model-driven development. And debugging with breakpoints and variable inspection, the daily craft of every practitioner, is the process this section describes: form hypotheses, test them, trace, localize, fix.

2.8 Verification and Validation: Software Testing

2.8.1 What Validation Means

Of the four broad software development activities — specification, development, validation, and evolution — validation, or more generally verification and validation (V&V), is intended to show that the system both conforms to its requirements specification and meets the expectations of the system customer.

Program testing — executing the system using simulated test data — is the principal validation technique. Validation may also involve checking processes like inspections and reviews at each stage of the software process, from user requirements definition through design to program development. But most of the verification and validation time is spent on execution-based program testing.

The two halves of V&V answer two different questions. Verification asks "did we build the system right?" — does it conform to the requirements specification? Validation asks "did we build the right system?" — does it meet the customer's expectations? A system can pass verification perfectly and still fail validation, if the specification itself was wrong. Inspections and reviews (human reading of documents and code) catch problems the way a proofreader catches typos; program testing catches them the way a field trial catches flaws — by running the thing.

Except for small programs, systems should not be tested as a single monolithic unit after all components are assembled. Instead you use a three-stage testing process: system components are individually tested first, then the integrated system is tested, and then — for custom software — the customer tests the system with real customer data, which is acceptance testing. For products that are sold as applications, customer testing is sometimes called beta testing, where selected users try out and comment on the software.

2.8.2 Three-Stage Testing: Component, System, Customer

Stage 1 — Component testing. The components that make up the system are tested by the people who are developing the system. Each component is tested independently, without other components. The components may be simple entities, like functions or object classes, or coherent groupings of these entities, like packages.

Stage 2 — System testing. The components are integrated to create subsystems or systems, and the complete system is tested. This stage is concerned with finding errors that result from unanticipated interactions between components and from component interface problems. It is also concerned with showing that the system meets its functional and non-functional requirements. Non-functional requirements are emergent properties — like performance, reliability, usability, and maintainability — that only appear when the components work together. For large systems, system testing may be a multi-stage process: components are integrated to form subsystems, the subsystems are individually tested, and then the subsystems are integrated to form the final system.

Stage 3 — Acceptance (customer) testing. This is the final stage in the testing process, before the system is accepted for operational use. The system is tested by the system customer — or by a potential customer, in the case of a product — using real data rather than simulated test data. For custom-built software, acceptance testing may reveal various errors and omissions in the system requirements definition, because real data exercises the system in different ways from simulated test data. Customer testing may also reveal requirements problems — system facilities that do not really meet the real needs of the users, or unacceptable system performance. For products, customer testing (beta testing) shows how well the product meets customer needs.

Ideally, component defects are discovered early in the testing process and interface problems are found when the system is integrated. But as defects are discovered, the program must be debugged, and this may require the other stages of the testing process to be repeated — errors in program components may only come to light during system testing. So the process is iterative, with information fed back from later stages to earlier stages.

2.8.3 Testing in Incremental, Agile, and Plan-Driven Projects

Component testing is simply part of the normal development process, like unit testing. Programmers make up their own test data and incrementally test the code as it is being developed. Since the programmer knows the component well — its data structures and algorithms — he or she is best placed to generate test cases and test the components.

If you use an incremental approach, each increment should be tested as it is being developed, with the tests based on the requirements for that particular increment. If you use test-driven development (TDD), which is a normal part of the agile process, the tests are developed along with the requirements, before the development itself starts. This helps the testers and developers understand the requirements, and ensures there are no delays creating test cases — because when you specify a test case, you understand the functionality better.

In a plan-driven development process for embedded or critical systems, testing is driven by a set of plans: an independent team of testers works from test plans that have been developed from the system specification.

The contrast is worth keeping straight: in agile projects the same person who writes the code writes and runs the tests, increment by increment — TDD goes one step further and writes the test first, as a precise statement of the requirement. In plan-driven projects, testing is an independent discipline: a separate team of testers, working from formal test plans derived from the specification, with no stake in the code being tested. Both strategies test the same system; they differ in who tests, when, and against what.

2.8.4 The V Model

The link between testing and development activities can be drawn as the V model. Test plans are developed concurrently with the corresponding requirements and design specifications: you create the acceptance test plan as the requirements specification is done; as the system specification is developed, you have the system integration test plan; as the subsystems are designed, you have the subsystem integration plan; module coding and unit testing are done by the component developers. On the testing side you then run the subsystem integration test, the system integration test, and the user acceptance test, and finally the product is delivered and put into service. If you rotate the diagram of this model, you get a V shape — that is where the name comes from. Many colorful variants of the V model exist (searching images for "V model" shows them), and it is widely used in organizations.

The V model diagram (visualize it): draw a "V". Down the left arm, the development stages descend from requirements gathering through systems analysis and software design to module design, ending at the point of the V with coding. Up the right arm, the testing stages ascend: unit testing, integration testing, system testing, acceptance testing. Now draw horizontal dashed lines connecting each level — each development stage on the left has a matching testing stage on the right: requirements gathering pairs with acceptance testing, systems analysis pairs with system testing, software design pairs with integration testing, module design pairs with unit testing, and coding sits at the core. One student shared a V-shaped diagram of the plan-driven process showing exactly these correspondences — with the validation phase on one side and the verification phase on the other. The one-sentence takeaway: in a plan-driven process, every testing activity is planned at the same time as its corresponding development activity, so that the right test exists the moment the code is ready.

2.8.5 Beta Testing for Software Products

When a system is to be marketed as a software product, a testing process called beta testing is often used. Beta testing involves delivering the system to a number of potential customers who agree to use that system and report problems to the system developers. This exposes the product to real use and detects errors that the program developers may not have anticipated. After this feedback, the software product may be modified and released for further beta testing, or even released as a commercially available product.

Beta testing is acceptance testing with strangers: no customer contract, no hand-picked friendly users — just real users in real environments hammering the product with usage patterns the developers never imagined. The software may loop through several beta rounds (fix, release, collect more feedback) before the commercial release.

Real-world connection: The three-stage discipline is everywhere in professional practice: developers run unit tests continuously (JUnit and its cousins in every language), CI/CD pipelines run integration suites on every commit, and release candidates face staged validation that mirrors the V model's pairings. Regulated industries make the correspondence literal — a requirements traceability matrix ties every requirement to a test, exactly as the V model's dashed lines suggest. And every app you have ever used went through beta rounds before you saw it.

2.9 Software Evolution

2.9.1 Evolution as a Continuum

Software undergoes change throughout its life, much like a human baby that, after delivery, grows and evolves through its whole life cycle. Software should continue to change, and so it should be maintainable.

Many people prefer development projects over maintenance projects: would you like to go on site for a maintenance project, where you have a huge code base developed decades ago that you cannot understand, and you have to support a system by going through the code, making modifications, and making it work in real time while it is in production? Evolution is a challenge, especially when there is no documentation and the code base is difficult to understand.

The point of the show-of-hands question is not to mock the maintenance-preferring minority — it is to dissolve the distinction. If almost no project starts from scratch, then "development" and "maintenance" are not two different careers; they are two phases of the same continuous activity. The evolutionary view of software engineering — the software is continuously changed even during development, over its lifetime, in response to changing requirements and customer needs — is the realistic description of the profession. The baby grows through its whole life cycle: delivery is birth, and the growing never stops.

2.9.2 The Evolution Process Model

The evolution process can itself be modeled as a cycle: you assess the existing system, propose system changes, modify the system, then check whether the modified system meets the requirements; the new system is assessed again, and the changes continue. This continuous cycle — assess, propose, modify, check, assess again — is why software evolution is never finished, and why the software must evolve to remain useful. Techniques like prototyping and incremental delivery help cope with this constant change.

The evolution cycle (visualize it): draw a circle with four boxes on it — assess existing system, propose system changes, modify system, check modified system — with arrows chasing each other around the loop. The cycle does not end: the checked system is assessed again, and the loop continues for the life of the software. The one-sentence takeaway: evolution is a closed loop, not a line — the same system is assessed, changed, and re-checked many times, and every round starts from the previous round's result.

Because the loop never stops, the process needs tools that tolerate change: prototyping (quick versions used to check requirements and design decisions before committing to them) and incremental delivery (delivering changes in slices so the system keeps working while it evolves) — both discussed in more depth in the agile session.

Real-world connection: Look at the software that runs your university, your bank, or a hospital: most of it is between five and forty years old, and most IT budgets go to evolving it — new regulations, new interfaces, new business models — not to building replacements. The next time you read about a "legacy system," you are reading about the evolution phase at work. And the code you write for your coursework today is already a small experiment in evolution: the version you submit next week will not be the same file you wrote this week.

Exam Guidance Summary

No mark distribution or exam-format details were given in this session, but the teaching repeatedly emphasized a set of core points worth mastering:

• The definition of a software process as a coherent set of activities for software production, and the four fundamental activities every process includes in some form: software specification, software development, software validation, and software evolution. Know what each one contains (Exam note: the four fundamental activities are core knowledge this session kept returning to).
• Why there is no universal software process or process model, and what the choice depends on (customer, requirements, regulatory requirements, environment, type of software, skills, constraints). This theme was repeated throughout the session.
• Plan-driven versus agile processes: plan-driven means planning all activities in advance and measuring progress against the plan; agile means incremental, iterative planning that continues as the software is developed.
• The three general process models (waterfall, incremental development, reuse-oriented development), the situations each fits, and how large systems combine them.
• The waterfall stages in order (requirements analysis and definition, system and software design, implementation and unit testing, integration and system testing, operation and maintenance), the sign-off principle, and feedback between stages in practice.
• The consequences of prematurely freezing requirements, and of bypassing design problems with implementation tricks.
• Incremental development: concurrent specification, development, and validation; how increments are chosen (most critical functionality first); its advantages and its management problems.
• Concurrency versus parallelism: the correction that concurrency means activities interleaved in time while parallel means simultaneous. This is flagged as important knowledge in computing systems, especially for operating-system algorithms (Exam note: expect this distinction to matter — it was explicitly called important).
• Requirements engineering activities: elicitation, specification (user versus system requirements), and validation (correctness, completeness, consistency, realism); how requirements work in agile (stories) versus plan-driven projects (formal document, IEEE standard exists but is customizable).
• The design process: inputs (platform information, requirements specification, data description), activities (architectural, database, interface, component selection and design), and outputs (system architecture, database design, interface specification, component descriptions).
• Testing versus debugging: testing establishes the presence of defects; debugging locates and corrects them.
• The three-stage testing process (component, system, acceptance/customer testing), test-driven development, plan-driven test plans, and the V model correspondences (requirements gathering ↔ acceptance testing, systems analysis ↔ system testing, software design ↔ integration testing, module design ↔ unit testing).
• Software evolution as a continuum of development and maintenance, and the assess–propose–modify–check cycle.

Study advice given during the session: review the difference between parallelism and concurrency on your own; note that there are many variants of the waterfall and V models, and search for examples; requirements engineering and design get detailed treatment in later sessions, and agile processes are covered in more detail in the next session.

The most reliable way to use this list: for each bullet, close your notes and explain the point aloud in two or three sentences — if you cannot, that is the gap to revise. The three ideas the session weighted most heavily are the four fundamental activities, the waterfall stages plus their feedback reality, and the concurrency-versus-parallelism distinction.

Key Industry Applications

• Safety-critical systems — waterfall development with extensive analysis, verification, and documentation; formal verification for the most critical cases. Real-world: vehicle recalls of leading car brands after defective chips or software show how expensive safety problems become after implementation.
• Embedded systems — software verified and then programmed into the ROM of the hardware, with no later changes possible.
• Large systems engineering — systems of systems with many partnering companies and contractors; a common waterfall-style model plus complete specifications to distribute subsystem work.
• Off-the-shelf products — always developed incrementally, and bought or configured rather than built from scratch.
• Business systems — increasingly built by reusing and configuring existing systems; .NET and other application frameworks provide the reusable libraries and components.
• The Rational Unified Process — a framework model adapted by large companies, notably IBM, though not widely adopted.
• Requirements documentation — the IEEE standard for requirements documents, customized to project need and scale; agile teams write stories instead.
• Testing practice — test automation tools such as JUnit for Java; test-driven development in agile teams; independent test teams working from test plans in plan-driven (embedded/critical) projects; beta testing for marketed software products; the V model widely used in organizations.
• Design practice — UML (Unified Modeling Language) for detailed design models, model-driven generation of implementation from models, and IDEs generating skeleton code that developers fill in.
• Maintenance and evolution — most professional work evolves existing, often decades-old code bases in production, which is why maintainability and refactoring matter.

The pattern behind the list: each application domain picks the process model that matches its risk profile. Where failure is catastrophic or hardware is inflexible, the waterfall's ceremony is the price of survival; where markets and requirements move fast, incremental development and reuse keep pace; and in the mature systems that dominate real IT estates, evolution and refactoring are the daily reality. When you meet a system in your career, ask which model built it — and which one should evolve it next.