Introduction to Software Engineering
# Introduction to Software Engineering
1.1 Software Is Everywhere
1.1.1 Software Runs Society
Hook: Stop for a moment and count how many things around you would simply stop working if every piece of software vanished. The money in your bank, the lights in the street, the plane in the sky — this lecture opens with a single claim: the world today runs on software.
Software is essential for the functioning of any organization, government, or society — national and international businesses and institutions alike. The world today runs on software. National systems are controlled by computer-based systems. Most electrical products include computers and controlling software. Industrial manufacturing and distribution are completely automated, and so are the financial systems and stock markets.
Software is everywhere in layers. Consider a single routine day: your alarm clock is a small computer running a program; your phone connects to the internet through software-controlled switches; your commute may use traffic lights governed by embedded controllers; your bank transaction is executed by a financial system that cannot run without software; and the shop you buy from processes your payment through a point-of-sale system. None of these layers is optional — if the software layer fails, the whole layer above it fails.
Real-world: digital entertainment is entirely software-intensive — the music industry, computer games, films, and television all run on software. Most of the world's population owns a mobile phone and has access to the internet and to applications on the internet.
- The music industry moved from vinyl and CDs to streaming platforms, where the product is software itself.
- Computer games are among the most demanding software systems built, often combining graphics engines, physics simulation, and online services.
- Films and television use software not only for streaming but also for editing, special effects, and broadcasting.
- Manufacturing and distribution are completely automated — robots, warehouse management, and supply-chain tracking all run on software.
- Financial systems and stock markets execute millions of transactions per second purely in software.
A small thought experiment to make "software runs society" concrete: think about what it takes for you to buy a cup of coffee with a card. The payment terminal runs embedded software. The terminal talks to a bank's payment network over software-defined routers. The bank's core banking system checks your balance, deducts the amount, and records the transaction in a database. The merchant's accounting system later reconciles the day's sales. That one purchase touches at least four separate software systems built by different organizations — each of which needed software engineering to be reliable enough to trust with money.
1.1.2 Software Is Economically Significant
Software represents a significant fraction of the gross national product (GNP) of all countries. Software costs often dominate the cost of any automation or computer system. It also costs much more to maintain software over a long lifetime than it takes to develop it: software serves a useful life for many decades, and during that time it undergoes a lot of change, which involves a lot of cost. This is why the whole idea of software engineering is to develop good software that is cost-effective and delivered within time constraints.
Pitfall — thinking software is a "small" part of a system. When a company automates a factory or a hospital, people tend to budget for the machines and underestimate the software. In practice, software costs often dominate the cost of the whole automation project, and the maintenance of that software over its lifetime exceeds its original development cost. The economic weight of software is exactly why this course exists: software engineering exists to make software development cost-effective and timely.
Recap + bridge: Software runs society, and software is a major part of the economy — a product with a long, expensive lifetime. Because software is so important and so costly, we need an engineering approach to build it well. That raises the next question: what kind of "material" is software, and why is building it so different from building physical things? The next section takes up the single most important property of software — that it is abstract and intangible.
Real-world & domain connection: Software engineering sits at the center of every industry that has digitized — banking, logistics, healthcare, entertainment, and government. When a national system such as a stock exchange or a tax collection system goes down, the impact is measured in millions and the blame falls on software. This is why the discipline of software engineering — producing dependable software economically — is not a niche skill but a fundamental infrastructure of modern society.
1.2 Software Is Abstract and Intangible
1.2.1 No Physical Laws Bind It
Hook: A bridge obeys gravity; a car obeys friction; a building obeys the strength of its materials. What laws does software obey? The surprising answer: none of the physical ones. Software is the only engineered product with no weight, no material, and no manufacturing process — and that freedom is both a blessing and a curse.
You can see software in action while it performs tasks according to the end user's requirements, but the software itself is abstract and intangible. Unlike physical products, it is not constrained by the physical properties of materials, by physical laws, or by the constraints of manufacturing processes. That may make software engineering seem simpler — software is not bound by physical laws and there are no natural limits to its potential.
Software has no physical "body." A program is a collection of instructions and data that exist as patterns — in text files, in memory, or in the electromagnetic state of a disk. You can never hold a piece of software in your hand. When you buy a video game, the physical disc is not the software; the software is the instructions that the disc stores. Because there is no material, there is no wear-and-tear from use, no manufacturing tolerance, and no gravity to fight. In principle, software could be infinitely complex without ever getting heavier — a single program could in theory grow without any physical limit pushing back.
Intuition — software is like a recipe, not like a cake. A cake is physical: bake it once, and you get one cake, and the recipe's quality is locked in by the ingredients and the oven. Software is the recipe — the instructions themselves. You can copy the recipe a million times at almost no cost, and you can revise the recipe even after the cake is baked (deployed). But here is the catch: a recipe has no weight, which means nothing physically forces you to keep it simple. A cake batter that is too thick simply will not rise — nature imposes the limit. Software has no such natural limit, so the only thing that keeps software from collapsing into unmanageable complexity is the discipline of the people who build it. That discipline is what software engineering provides.
1.2.2 The Cost of Intangibility
The lack of physical constraints works against us in a different way. Because software is intangible and abstract, software systems can quickly become very complex, very difficult to understand, and very expensive to change. Touch some module and it will have an impact on the rest of the system. This intangibility is a large part of why software development is difficult to manage — an idea the course returns to as it proceeds.
The hidden cost of freedom. Because nothing physical limits software's complexity, complexity grows without warning. Every part of a system is connected to every other part in invisible ways — a change in one module can silently break a module far away. In a physical product, changing one component means re-cutting metal or re-molding plastic, so you are forced to think before you change. In software, changing a module is as easy as editing a text file — so easy that teams change things without fully tracing the ripple effects, and the system becomes difficult to understand and expensive to maintain.
A concrete illustration of the ripple effect. Imagine a banking application with a module that computes interest. A developer "improves" the interest formula to fix a rounding error. The change is one line. But the same formula was also used by the monthly statement generator, the tax report, and the loan calculator. The one-line change silently alters statements, tax filings, and loan quotes. No physical constraint warned the developer; the change compiled and ran. Only careful design — separating the formula so all consumers use one version — could have contained the impact. This is exactly the kind of "touch one module, affect the whole system" risk the lecture warns about.
Recap + bridge: Software is abstract and intangible: it is bound by no physical laws, so its potential is unlimited — but that same freedom lets complexity grow until the system becomes hard to understand and expensive to change. Keep this property in mind, because it explains many difficulties later in the course. Next, the lecture shows why one more consequence of intangibility matters: because software comes in so many shapes and sizes, no single approach to building it works for everything.
Real-world & domain connection: Intangibility explains real industry phenomena — why software projects are chronically underestimated, why "legacy" systems with decades of undocumented changes become costly to touch, and why companies like banks run teams whose whole job is managing the complexity of systems no single person fully understands. In contrast, a bridge can be inspected, measured, and certified; software's invisible structure must be deliberately managed through design, documentation, and process — the core concerns of software engineering.
1.3 Different Software Systems Need Different Approaches
1.3.1 No Universal Techniques Exist
Hook: If there were one perfect way to build software, every project would use it. But think of the range: a thermostat chip, a banking website, a flight simulator, a video game, a stock exchange. Could one method possibly suit all of them? This section answers with a firm "no."
Software systems range from simple embedded systems and mobile devices to complex worldwide information systems running on huge cloud-based infrastructures — and beyond that, to the entire internet itself. There are no universal notations, methods, or techniques for software engineering, because different types of software systems require different types of approaches to development.
Why no single method can work. The properties that matter differ completely from one system type to another:
- An embedded system (a chip in a car or a microwave) must be tiny, fast, and proven correct before it is shipped — you cannot easily update it in the field.
- A worldwide information system must handle huge numbers of users, huge amounts of data, and continuous availability — but a software update can be rolled out gradually.
- A video game must be visually rich and responsive to the player — a game that is correct but boring is a failure.
Because the goals differ, the ways of working differ: the notations used to describe the system, the methods used to design it, and the tools used to build and test it. A method that works well for one type may be useless — even harmful — for another.
1.3.2 Three Contrasting Examples
Developing an organizational information system is completely different from developing a controller for a scientific instrument. Neither of those has much in common with a computer game or a mobile video game, which is graphics-intensive. All of these applications need software engineering, but they may each use different software engineering methods, techniques, and tools.
Compare three systems and what each demands:
| System | Primary demand | Typical techniques |
|---|---|---|
| Organizational information system (e.g., a hospital records system) | Data integrity, usability, security | Requirements analysis, database design, user interface design, careful testing of transactions |
| Scientific instrument controller (e.g., a telescope positioning controller) | Precision, real-time response, reliability | Formal specification, rigorous verification, embedded programming |
| Computer game / mobile video game | Graphics performance, interaction quality, responsiveness | Graphics engines, prototyping, iterative play-testing, performance tuning |
All three need software engineering — planned, systematic development — but a hospital system and a game will share almost no methods, techniques, or tools. The lesson is that the discipline of software engineering is universal; the specific techniques are not.
Pitfall — assuming one methodology fits all projects. A classic mistake is to take the process that worked on one project and apply it mechanically to the next, regardless of system type. A rigid, documentation-heavy process that suits a safety-critical embedded controller would slow down a video game studio to a crawl, while an agile, prototype-driven approach that suits a game would be dangerously loose for a medical device. The skill of a software engineer includes choosing the right approach for the type of system — a theme the course returns to when it examines software processes and methods.
Recap + bridge: There are no universal software engineering methods: different types of systems — from embedded chips to cloud information systems to graphics-intensive games — need different approaches, even though all of them need software engineering. Remember this "no one-size-fits-all" idea; the lecture returns to it repeatedly, most directly when it examines application types and the software process. Next, the course introduces the idea that ties all software engineering together: the triple constraint of good, fast, and cheap.
Real-world & domain connection: In industry, this diversity shows up as specialized engineering communities — embedded engineers verify code to aviation or automotive safety standards, web teams ship features continuously, and game studios prototype relentlessly. Large companies such as Microsoft and Google run all of these kinds of projects simultaneously and maintain different methods and tools for each, which is why "software engineering" is best understood as a family of disciplines rather than a single fixed recipe.
1.4 The Triple Constraint: Good, Fast, Cheap
1.4.1 The Three Constraints
Hook: Would you rather have your software delivered right, delivered now, or delivered cheaply? Every customer answers "all three" — and every project finds out how hard that is. This good–fast–cheap problem is described by the professor as the pivot of the whole course.
You have probably seen the Venn diagram with three circles labelled good, fast, and cheap, intersecting in the middle. The challenge is that it is very hard to have all three at once: if something is fast and cheap, it may not be good; if it is good and cheap, it may not be fast; if it is good and fast, it may not be cheap. This good–fast–cheap triangle is the pivot of the whole course, because software engineering is exactly about developing good quality software that meets real-world requirements economically — cost-effectively, within the constraints of budget and time.
The three corners, defined.
- Good — the software meets the required quality: it does what the customer needs, is dependable, maintainable, and usable (the full list of attributes comes in section 1.9).
- Fast — the software is delivered within the required schedule. The professor's recurring phrase: customers want deadlines of "one month ago", never in the future.
- Cheap — the software is developed within the available budget.
The three constraints pull against each other: a good product takes time to build, time to test, time to deliver, and the more time it takes, the more it costs. You cannot simply add resources and make it both faster and cheaper — quality, schedule, and cost form a triangle of trade-offs.
Customers today want software as quickly as possible. Deadlines feel like "one month ago", never in the future — the product is wanted immediately. But a good product takes time to build, time to test, time to deliver, and the more time it takes, the more it costs. So the focus of software engineering is delivering good quality software on time and within budget.
1.4.2 The Venn Diagram in the Chat
Q: A student pasted the good-fast-cheap Venn diagram into the chat, as the class had been asked to do for the benefit of everyone. Was this the right diagram, and where is the sweet spot?
A: That is exactly the right diagram. The sweet spot is at the center, where the three circles overlap — achieving good, fast, and cheap all at once. In practice that center is usually a challenge; the diagram's center is a dream for most projects. The same is true in your own work: how often do you deliver software at high quality, earlier than the expected deadline, and at lower cost than budgeted?
Pitfall — believing the center of the diagram is the normal case. The Venn diagram's center — simultaneously good, fast, and cheap — is the exception, not the rule. Treat it as a target to aim for, not an entitlement. Projects that assume all three will be delivered are usually the ones that quietly slip on quality, schedule, or budget. The realistic job of the software engineer is to make deliberate trade-offs and to communicate them honestly.
1.4.3 Why the Triple Constraint Is Central
Good, fast, cheap will keep coming back throughout the course. Every engineering decision in software development is ultimately a trade-off among these three. Exam note: treat the good-fast-cheap triple constraint as a central organizing idea — expect it to recur when the course discusses processes, requirements, design, and project management.
Exam note: The good–fast–cheap triple constraint is "the pivot of our discussions" — expect it to recur when the course discusses processes, requirements, design, and project management. Be able to state the three constraints, explain why the center of the Venn diagram is a dream for most projects, and connect each major topic back to this trade-off.
Recap + bridge: Every engineering decision in software development is a trade-off among good, fast, and cheap, and the sweet spot at the center of the Venn diagram is the ideal most projects cannot reach. This triple constraint will organize much of the course. Next, the lecture turns to the failures of real software projects and asks: when software projects go wrong, what actually causes it?
Real-world & domain connection: The triple constraint is the language of every software contract and every project review. Executives ask for "fast and cheap," regulators and users demand "good," and the project manager reconciles the three. In industry, frameworks such as agile processes and incremental delivery exist largely to manage this trade-off — for example, delivering a good subset of features fast (an increment) rather than waiting for everything to be perfect and cheap. Whenever this course studies project management, requirements, or design, notice how each activity is ultimately negotiating the same three corners.
1.5 Software Project Failures and Their Two Causes
1.5.1 Critics of Software Engineering
Hook: Software failures make headlines — delayed projects, systems that do not do what customers wanted, abandoned products. Critics use these stories to argue that software engineering itself is inadequate. This section answers the critics: the failures are real, but their true causes are two, and neither is "software engineering does not work."
There are many reports of software projects going wrong — getting delayed, not delivering what they should, not meeting the exact requirements of the customer. Projects are sometimes not accepted by the customers and get abandoned midway. Critics of software engineering say that current techniques are inadequate for modern software development. The correction is that these often-quoted failures are mainly a consequence of two factors.
The two causes of software project failures:
- Increasing system complexity — systems keep growing in size and ambition, faster than our techniques for handling them.
- Methods not applied rigorously — even the methods we already have are often used carelessly or not at all.
Neither cause says "engineering techniques are worthless." Cause one says the bar keeps rising; cause two says practitioners often do not use what exists. This is the lecture's correction to the critics: fix these two causes, and most failures lose their cause.
1.5.2 Cause One: Increasing System Complexity
Newer and newer software engineering techniques help us develop larger, much more complex systems, but the demands keep changing and expectations are much higher. Systems have to be built and delivered even more quickly, and they are much larger. More complex systems are required, and they should dynamically adapt to changing requirements while delivering solutions effectively and efficiently. Systems must have new capabilities that were previously thought to be impossible. So new software engineering techniques have to be developed to meet the new challenges of delivering more complex, more flexible, more dynamic software that meets all requirements within budget and time.
The treadmill of rising expectations. Each generation of software engineering techniques makes bigger systems possible — and immediately, customers expect even bigger ones. What was impossible yesterday (a voice assistant in a watch, a self-driving car feature, a global payments network) becomes a requirement today. Complexity is not a sign of failure; it is the cost of ambition. The failure risk arises when a project takes on complexity that its techniques and skills cannot yet carry — which is why technique development must keep pace with demand.
1.5.3 Cause Two: Methods Not Applied Rigorously
The second reason for failure is that we do not use software engineering methods as rigorously as we should. It is fairly easy to write programs without using systematic and quantifiable software engineering methods and techniques. Many companies — even product manufacturing companies and other verticals — have drifted into software development as their products and services evolved, because they are packaging software as a service along with their products. Their primary businesses are in manufacturing or pharmaceuticals, so they may not use very rigorous software engineering methods in their day-to-day work. The result is that their software is often more expensive and less reliable than it should be. Better software engineering education and training is part of the answer to this problem.
Pitfall — "we are a car company, not a software company." Modern cars, appliances, and medical devices are full of software, so many traditional manufacturers have drifted into software development without adopting software engineering discipline. Writing programs is easy; building reliable software systematically is not. These companies discover the cost only later: software that is more expensive to maintain and less reliable than it should be. The same trap applies to students — skipping the process because the code "works on my machine."
At the same time, there is genuine pride in what software engineering has achieved: without software engineering methods and techniques we could not have achieved the internet, modern telecommunications, or modern forms of travel and communication systems. And looking ahead, the challenges of the 21st century — climate change, reducing natural resources, changing demographics, an expanding world population — will be met with software engineering, developing software that helps society cope with these demands.
Recap + bridge: Software failures come mainly from two causes — increasing system complexity and methods not applied rigorously — not from software engineering being a failed discipline. The field is also genuinely proud: the internet, modern telecommunications, and safe modern travel would be impossible without it, and the great challenges of the 21st century will be tackled with software. Next, the lecture draws the line between professional software development and the personal programming you may have done until now.
Real-world & domain connection: The two causes are visible everywhere in industry. Complexity: modern aircraft, banks, and cloud platforms push the frontier of what software can do, and their engineering organizations invest continuously in new techniques. Lack of rigor: the "software is a small side product" mindset of traditional manufacturers and even government bodies is a recurring source of costly, unreliable systems. Education and training — exactly what this course provides — are part of the answer to cause two, while research and new methods are the answer to cause one.
1.6 Professional vs Personal Software Development
1.6.1 Three Kinds of Software Writing
Hook: You have almost certainly written programs — for an assignment, for fun, or to process some data. Is that software engineering? This section draws the key boundary: most programming you have done is personal software development; the course is about the professional kind.
People in business write programs with Excel and other tools to help them in their jobs. Scientists and engineers write programs to process their experimental data. People writing software as a hobby write it for their own enjoyment and for an interest in developing creative new applications. The key distinction in this course is between all of that and professional software development.
Three ways people write software.
| Who | Why | Audience |
|---|---|---|
| Business people (spreadsheets, macros) | To simplify their own jobs | Themselves or a small group |
| Scientists and engineers | To process experimental data | Themselves and colleagues |
| Hobbyists | Enjoyment, creative applications | Themselves |
All three are legitimate uses of programming. None of them is professional software development in the sense this course uses the term. The boundary is not about skill or code quality — it is about who the software is for and how it is produced and maintained.
1.6.2 What Professional Development Adds
In professional software development, teams develop the software, and it is constantly maintained and changed throughout its useful lifetime. Software engineering as a discipline is intended to support professional software development rather than individual programming exercises. It includes techniques that support program specification, design, and evolution — as the software is put into operation it changes over a period of time. None of that is normally relevant for personal software development.
What professional development adds on top of programming.
- Teams — the software is developed by a group, not an individual, so coordination, communication, and shared understanding become essential.
- A long useful lifetime — the software is used by people other than its developers and keeps running for years or decades.
- Constant change — once in operation, the software is modified again and again: new features, bug fixes, changed business rules, new platforms. This is what "evolution" means.
- Specification, design, and evolution techniques — professional software needs upfront clarity about what it should do (specification), a thought-out structure (design), and managed change over time (evolution). For personal programs, none of this is normally needed.
Software engineering exists precisely to support this professional setting: teams, long life, and continuous change.
The same app, two very different lives. Suppose you write a small billing script for yourself: it runs on your laptop, you are the only user, and if the tax rules change you simply edit the script and rerun it. That is personal software development.
Now suppose the same billing logic becomes a payroll module used by 2,000 employees: dozens of people must agree on what it should do (specification); its structure must be clear enough for other engineers to modify (design); every change must be tested so it does not break other parts of the system (validation); and it must be updated for years as laws and company policies change (evolution). The code in both cases may be similar — but the second case is professional software development and demands software engineering techniques that the first case never needed.
Pitfall — treating a professional project like a personal program. When students (or new developers) build professional software the way they build personal scripts — no specification, no design, no thought for other people who will use or change the code — the result is software that is hard to maintain, breaks when touched, and costs far more over its lifetime. The techniques this course teaches exist because professional software is a team product with a long life, not a personal exercise.
Recap + bridge: People write software for many reasons — business, science, hobby — but the course focuses on professional software development: software developed by teams, for other people, and maintained and changed throughout a long useful lifetime. Software engineering is the discipline that supports this professional setting. Next, the lecture clarifies what "software" itself really includes — a correction most people find surprising.
Real-world & domain connection: Almost all software used in industry is professional software: banking platforms, enterprise systems, embedded vehicle software, cloud services. These are built by teams, live for decades, and are changed constantly. When you join such a team, the personal-programming habits — skipping documentation, ignoring design, editing without testing — are the habits that create exactly the expensive, unreliable software described in the previous section. This professional/personal distinction is the foundation on which every later course topic (process, requirements, design, testing, evolution) is built.
1.7 What Software Really Is
1.7.1 More Than Programs
Hook: If we asked you to "hand over the software" for a project, what would you give us? Most people answer: the code. This section delivers the key correction: in software engineering, software is much more than the programs themselves.
People who are not software engineers tend to think software is just another word for computer programs. The key correction: in software engineering, software is not just the programs themselves, but also all the associated documentation, the libraries you use, the supporting websites, and the configuration data that make these programs useful.
Software = programs + everything that makes them useful. The full definition of software includes:
- The programs — the instructions that execute.
- Documentation — the documents that describe and explain the software (system documentation and user documentation).
- Libraries — reusable code collections that the programs call on.
- Supporting websites — places where users get product information and updates.
- Configuration data — the files and settings that set the programs up for a particular environment or customer.
A textbook description expresses the same idea: software is (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to manipulate information; and (3) descriptive information, in hard copy and virtual forms, that describes the operation and use of the programs.
1.7.2 The Parts of a Software System
A professionally developed software system is often more than a single program. A system may consist of several separate programs plus configuration files used to set up those programs. It may include system documentation that describes the structure of the system, user documentation that explains how to use the system, and websites where users can download recent product information.
The typical parts of a professional software system.
- Several separate programs — a system is often a collection of cooperating programs, not one monolith (for example, a server program, a client program, and a maintenance utility).
- Configuration files — data files that set up the programs for a particular installation (server addresses, feature toggles, database names).
- System documentation — describes the structure of the system: how the programs fit together, what each module does, how they communicate.
- User documentation — explains how to use the system: manuals, online help, tutorials.
- Supporting websites — where users download the latest product information, updates, and fixes.
Notice the pattern: a professional system is a product plus its support materials. All of these parts must be produced, versioned, and maintained together.
1.7.3 Why the Distinction Matters
This is one of the differences between professional software and amateur individual software development. If you write a program for yourself, no one else may use it, and you may not need user manuals or program guides documenting the program design. But if you write software that other people will use, or that other engineers will change, you normally have to provide extra information apart from the code that explains the code and the system.
A worked contrast: personal script vs delivered product.
- Personal case: a student writes a script that converts their experimental data into charts. They are the only user. No manual is needed — they remember how it works — and no documentation exists. If the script breaks next semester, they debug it by reading the code they wrote.
- Professional case: the same idea becomes a charting utility sold to 500 researchers. Users need a manual (user documentation). New engineers who join the team need system documentation to understand the structure. The installer needs configuration files to set it up on different computers. A website hosts the manual and updates. Without these parts, the product is unusable and unmaintainable — the code alone is not the software.
The lesson: the moment other people use or change your software, you must provide the extra information apart from the code — this is exactly what separates professional software from amateur individual development.
Pitfall — "the code is the software." Beginners often believe that if the program runs, the deliverable is complete. In professional practice, undelivered documentation, missing configuration, and absent user guidance are treated as defects: the system cannot be operated, changed, or supported without them. When you deliver professional software, you deliver the whole package — programs, documentation, libraries, configuration, and web support.
Recap + bridge: Software is not just programs: it also includes documentation, libraries, supporting websites, and configuration data that make the programs useful, and a professional system is typically several programs plus these supporting parts. This is one of the key differences between professional and amateur development. Next, the lecture classifies software products into two types — generic and customized — and asks who controls the specification in each.
Real-world & domain connection: In industry, this distinction governs contracts and team structure. Enterprise software vendors (for example, ERP vendors like SAP and Oracle) deliver their systems with configuration tools, documentation, training material, and support portals — the "software" a customer buys is the whole package. Similarly, open-source projects like Linux succeed only because they include documentation and configuration standards alongside the code. Whenever this course discusses design, implementation, or evolution, remember that these activities produce all parts of the software, not just code.
1.8 Software Products: Generic vs Customized
1.8.1 Generic Products
Hook: A software vendor has two completely different business models: build one product and sell it to everyone, or build a system specifically for one customer. The two models even decide who owns the requirements — and that single difference changes everything about how the project runs.
Software engineers are concerned with developing software products — software that can be sold to a customer or a client. There are two types. Generic products are standalone systems produced by a development organization, such as Microsoft or Google, and sold in the open market to any customer who is able to buy them. Examples include mobile device apps and computer applications, various kinds of software tools, and tools for several verticals — banking, library information systems, hospital accounting systems — as well as products like Tally accounting systems for various industries.
Generic products — also called generic products or market software. They are developed by an organization (Microsoft, Google, and so on) and sold on the open market to any customer who can buy them.
- Examples: mobile apps, desktop applications (word processors, databases), software tools, and "vertical" products aimed at a specific industry — banking software, library information systems, hospital accounting systems, and accounting suites like Tally.
- The defining feature: the development organization controls the specification. If development runs into trouble, the vendor can rethink what is to be built — change the feature list, delay a release, or drop a requirement.
1.8.2 Customized (Bespoke) Products
Customized software, also called bespoke software, is commissioned and developed for a particular customer. A software contractor designs and implements a software especially for that customer. Examples include control systems for various electronic devices, ERP applications, and air traffic applications.
Customized (bespoke) products — commissioned by and developed for a particular customer. A software contractor designs and implements the software especially for that customer.
- Examples: control systems for electronic devices, enterprise resource planning (ERP) applications built for one organization, and air traffic control systems.
- The defining feature: the customer controls the specification. The developer must work to the specification as stated by the buying organization.
1.8.3 Who Controls the Specification
The distinction between the two types comes down to control of the specification. In generic products, the organization that develops the software controls the software specification — if they run into development problems, they can rethink what is to be developed. For custom products, the specification is developed and controlled by the organization that is buying the software, so the software developers must work to that specification as stated by the customer.
Pitfall — confusing "who builds it" with "who decides what it does." The type of a product is not decided by its size or its technology but by control of the specification: who has the power to change the requirements when problems arise. In a generic product, the vendor decides (and can renegotiate the feature list internally). In a bespoke system, the customer decides, and the developer must meet the stated specification — deviating from it without approval is a contract violation, not a design choice. Exam questions on this topic almost always turn on this single point.
1.8.4 The Blurring Boundary
The distinction between product types is becoming increasingly blurred. More and more systems are being built with a generic product as a base — Tally as an accounting system, for example, or an ERP product — and then adapted to suit the requirements of the customer.
Real-world: typical enterprise resource planning (ERP) systems such as SAP and Oracle are the best examples of this approach. A large and complex system is adapted for a company by incorporating information about its business rules and processes, the reports required, and so on, and is then implemented to suit the company's requirements.
Worked example — adapting an ERP system (SAP/Oracle model). Suppose a retail chain adopts an ERP product as its base system. The steps of adaptation:
- The vendor's generic ERP already provides standard modules: accounting, inventory, procurement, payroll, and reporting.
- The customer's business rules are fed in as configuration: tax rates for each region, approval workflows for purchases above a threshold, the inventory reorder policy.
- The required reports are specified: daily sales by store, monthly profit by product line, annual tax summaries.
- The resulting system is then implemented to suit the company's requirements — a unique system, but built on a generic base.
Notice the blurred boundary: the base product is generic (developed for the open market), but the final system behaves like a bespoke one because its business rules, processes, and reports are the customer's. This "generic base, customer-adapted" pattern — best exemplified by SAP and Oracle ERP systems — is becoming the norm in industry.
Recap + bridge: There are two types of software products — generic (sold on the open market, specification controlled by the developer) and customized or bespoke (commissioned for one customer, specification controlled by the customer) — and the boundary is blurring as systems are increasingly built on a generic base and adapted to customer requirements, with ERP systems like SAP and Oracle as the best examples. Next, the lecture answers the obvious follow-up: what exactly makes software good?
Real-world & domain connection: The generic/customized distinction shapes whole industries. Microsoft, Google, and vendors like Tally live by the generic model: sell to many, control the roadmap. Systems integrators and government contractors live by the bespoke model: one customer, one specification, acceptance tests written by the buyer. Understanding which model you are in matters professionally because it decides who can change requirements, how contracts are written, and how conflicts get resolved.
1.9 Attributes of Good Software
1.9.1 The Essential Attributes
Hook: What does "good software" mean exactly? If a program runs but nobody can understand it, is it good? If it is fast but crashes weekly, is it good? This section pins down the four essential attributes every good software product must have.
When we say good software — whether an individual programming assignment or a large team project — it should provide the required functionality and performance to the user, and it should be maintainable, dependable, and usable. Maintainable means it should be adaptable to changing requirements. Dependable means reliable, safe, and secure. And it should be usable by its users. These four attributes — delivering the required functionality, maintainability, dependability, and usability — are the essential characteristics of any good software, whether small or large scale. You may have other characteristics, but these are the essential ones.
The essential attributes of good software.
| Attribute | Meaning | In one sentence |
|---|---|---|
| Required functionality and performance | The software does what the user needs, with acceptable speed and resource use | "It works as needed." |
| Maintainability | The software can be adapted to changing requirements | "It can be changed." |
| Dependability | The software is reliable, safe, and secure | "It can be trusted." |
| Usability | The software can be used by its intended users | "It can be used." |
The course's closing recap names the same idea in slightly different words: the essential attributes of all good software products are maintainability (the software should be amenable to change during its evolution), dependability and security, efficiency, and acceptability. Compare the two lists: functionality and performance appear as "efficiency" and "acceptability" (software must be acceptable — understandable and usable — to its users); maintainability and dependability appear in both. They are the same message in two vocabularies: good software delivers the function, performs well, and can be changed, trusted, and used.
1.9.2 Attributes Depend on the Application
The specific set of attributes you might expect from a software system depends on its application. An air traffic control system must be quite safe, whereas an interactive video game must be quite responsive, and a telephone network system must be quite reliable.
Which attribute dominates depends on the application.
| System | Attribute that dominates | Why |
|---|---|---|
| Air traffic control | Safety | A wrong decision endangers aircraft and lives |
| Interactive video game | Responsiveness | A laggy game is unplayable, no matter how correct it is |
| Telephone network | Reliability | A phone network that drops calls is worthless, even if mostly correct |
| Bank transaction system | Dependability and security | A lost or exposed transaction has immediate financial consequences |
| Hospital patient records | Confidentiality and usability | Clinicians must find records fast, and patients' privacy must be protected |
All good software needs all four attributes in the background, but the priority ordering — which attribute you design, test, and budget for first — is set by the application. This is why the lecture insists the specific set of attributes depends on the application.
Pitfall — one-size-fits-all quality. A common beginner mistake is to rank every attribute equally in every project. In practice, safety-critical systems trade raw speed for exhaustive verification; games accept risky corner cases in exchange for responsiveness; embedded devices sacrifice flexibility for reliability. "Good software" means the right balance for the application, not the maximum of every attribute. When an attribute is essential for the application, it must be engineered in from the start — you cannot bolt safety or usability onto a finished system.
Recap + bridge: Good software delivers the required functionality and performance and is maintainable (adaptable to change), dependable (reliable, safe, secure), and usable — with the recap naming maintainability, dependability and security, efficiency, and acceptability; the specific priority of attributes depends on the application, as air traffic control (safe), video games (responsive), and telephone networks (reliable) show. Next, the lecture formally defines the discipline that produces such software: software engineering.
Real-world & domain connection: These attributes are the vocabulary of quality in industry. Contractors write acceptance criteria around functionality, performance, and usability; regulators certify safety and security for medical and aviation software; and maintenance budgets exist because maintainability was (or was not) designed in. In modern practice, the same attributes appear as non-functional requirements and quality attributes that architects trade off explicitly, and standards such as ISO 25010 organize them into a quality model that engineering teams use to define and measure "good."
1.10 What Is Software Engineering?
1.10.1 A Definition
Hook: An architect designs a building; a civil engineer makes sure it stands. What does the software engineer do? The one-sentence answer in this lecture defines the whole course — and two words inside it carry most of the meaning.
Software engineering is an engineering discipline that is concerned with all aspects of software production — technical, economical, managerial, organizational, and business aspects — because you need to build good software that is within budget and delivered on time. In full: software engineering is an engineering discipline concerned with all aspects of software production, from the early stages of system specification through to maintaining the system long after it has gone into use.
The definition, unpacked. "Software engineering is an engineering discipline concerned with all aspects of software production, from the early stages of system specification through to maintaining the system long after it has gone into use."
Three things to notice:
- It is an engineering discipline — engineers make things work; they apply theories, methods, and tools selectively and deliver solutions even when no theory exists (the full picture comes in topic 1.16, "Engineers Make Things Work").
- All aspects of software production — not just writing code. The technical aspects (specification, development, validation) are only part of it; the economical, managerial, organizational, and business aspects are equally part of the discipline.
- From early specification to long-term maintenance — the discipline's responsibility starts before the first line of code and ends long after the system goes into use.
1.10.2 Two Important Terms
There are two important terms in this definition. First, it is an engineering discipline — how software engineering is an engineering discipline, and how it differs from other disciplines, is examined in the topic "Engineers Make Things Work". Second, it is concerned with all aspects of software production — not just the technical processes of software development, but also activities like software project management and the development of the various tools, methods, and theories that support software development and production.
The two key terms of the definition.
- Engineering discipline — Software engineering applies engineering principles to software: using theories, methods, and tools where they are appropriate, using them selectively, and getting results of the required quality within schedule and budget, even when that requires compromise. This is examined in depth in topic 1.16, "Engineers Make Things Work."
- All aspects of software production — software engineering is not just the technical processes of development. It also includes activities such as software project management, and the development of the tools, methods, and theories that support software development and production. A software engineer's job is broader than programming.
1.10.3 Systematic and Quantitative
Software engineering is a systematic and quantitative approach to the development of good quality software, on time, within budget, and within all the constraints of the organization. The main activities in any software engineering project are: specification — specify the requirements; development — design and implementation; validation — testing; and software evolution.
Systematic and quantitative. Software engineering is a systematic and quantitative approach: systematic, because the work follows an organized, repeatable method rather than inspiration; quantitative, because progress, quality, and cost are measured, not guessed. The goal: good quality software, on time, within budget, and within all the constraints of the organization.
The four main activities of any software engineering project (examined in detail when the course studies the software process):
| Activity | What it does |
|---|---|
| Specification | Specify the requirements — define what the software should do |
| Development | Design and implementation — design the structure and write the programs |
| Validation | Testing — check that the software does what the customer wants |
| Software evolution | Modify the software to reflect changing requirements after it is in use |
Exam note: The exam syllabus covers the topics discussed in class, the topics covered in the courseware, and the relevant chapters of the textbook (Pressman, Software Engineering). Be ready to reproduce the definition of software engineering, name its two key terms (engineering discipline; all aspects of software production), and list the four main activities: specification, development, validation, and evolution.
Recap + bridge: Software engineering is an engineering discipline concerned with all aspects of software production, from early specification to long-term maintenance; the two key terms are "engineering discipline" and "all aspects of software production," and it is a systematic, quantitative approach built around four activities: specification, development, validation, and evolution. Next, the lecture places software engineering among its neighboring disciplines: computer science and systems engineering.
Real-world & domain connection: The breadth of this definition explains real organizations: software companies do not just employ programmers — they employ project managers, requirements analysts, testers, process engineers, and tool builders, because "all aspects of software production" demands all of them. The systematic, quantitative emphasis shows up in industry as measurable practices: estimation, metrics, quality gates, and earned-value tracking, all of which this course examines in later topics.
1.11 Software Engineering vs Computer Science vs Systems Engineering
1.11.1 Software Engineering vs Computer Science
Hook: Is software engineering "applied computer science"? Partly — but only partly. This section places software engineering on the map between two neighbors: computer science below it, systems engineering above it.
Computer science provides the necessary theory and fundamentals for developing algorithms, data structures, and software. Software engineering is a larger discipline, concerned with the practicalities of developing and delivering useful software within real-world constraints — budget, time, quality — and meeting organizational and social requirements. Software engineering is not just computer science; it builds on it.
Computer science vs software engineering.
- Computer science provides the theory and fundamentals: algorithms, data structures, and the principles underlying software. It asks "what is possible and how can it be computed efficiently?"
- Software engineering is a larger discipline: it uses computer science as a foundation, then adds the practicalities of developing and delivering useful software within real-world constraints — budget, time, and quality — and meeting organizational and social requirements.
The relationship is like physics to civil engineering: a civil engineer needs physics, but physics alone does not tell you how to build a bridge within budget, on schedule, and to code. Software engineering is not just computer science — it builds on it.
1.11.2 Software Engineering vs Systems Engineering
Systems engineering is concerned with all aspects of computer-based systems, including hardware, software, networking, and organizational process engineering. Software engineering is a part of the larger systems engineering process, in which the focus is on software specification, development, validation, and evolution.
Software engineering vs systems engineering.
- Systems engineering is concerned with all aspects of computer-based systems: hardware, software, networking, and organizational process engineering. Systems engineers specify the whole system, define its overall architecture, and integrate the parts into the finished system.
- Software engineering is a part of the larger systems engineering process, focusing on the software component: specification, development, validation, and evolution.
The nesting is clear: systems engineering ⊃ software engineering ⊃ computer science theory.
Pitfall — drawing the boundaries too sharply. The three disciplines are not rival boxes with a fence between them; they are nested layers of responsibility. A software engineer who ignores hardware constraints (battery, memory, real-time deadlines) fails on embedded projects. A systems engineer who ignores software engineering methods still has to deliver software. And a computer scientist who ignores budgets and deadlines cannot ship. Knowing where each discipline sits — and that software engineering builds on computer science while being part of systems engineering — is exactly what the exam expects.
| Dimension | Computer science | Software engineering | Systems engineering |
|---|---|---|---|
| Core concern | Theory and fundamentals (algorithms, data structures) | Practical development and delivery of useful software | All aspects of computer-based systems (hardware, software, networking, process) |
| Typical question | What can be computed, and how? | How do we deliver good software within budget and time? | How does the whole computer-based system work together? |
| Position | Foundation | Builds on computer science; part of systems engineering | Encompasses software engineering |
When to think in which discipline: use computer science to choose an algorithm, software engineering to organize a project and deliver the product, and systems engineering when software must be integrated with hardware and organizational processes — for example, designing a new aircraft's flight system, which is a systems engineering problem containing a software engineering problem.
Recap + bridge: Computer science supplies the theory and fundamentals; software engineering is the larger discipline that builds on it to deliver useful software within real-world constraints; and systems engineering covers all aspects of computer-based systems, with software engineering as one part of it. Next, the lecture looks at the concrete difficulties these disciplines face today: the key challenges of software engineering.
Real-world & domain connection: In industry the three disciplines map to real roles and departments: research groups and algorithm teams (computer science), product and engineering teams (software engineering), and integration and platform teams that own the whole computer-based system, including hardware (systems engineering). Companies building physical products — cars, medical devices, industrial robots — feel the nesting directly, because their software engineering must be coordinated with hardware and process engineering under a systems engineering umbrella.
1.12 Key Challenges Facing Software Engineering
1.12.1 Diversity and New Demands
Hook: What keeps software engineers awake at night? Three challenges recur across the industry — and the professor names all three in this section: diversity, impossible deadlines, and trust.
The key challenges include coping with increasing diversity in technology and diversity in platforms, and various demands for new challenging software all the time.
Challenge one: diversity and new demands. Software must run on an ever-widening range of technologies and platforms — desktop computers, phones, tablets, embedded devices, clouds — and new kinds of software are demanded constantly. Coping with this diversity means techniques must be flexible enough to span very different environments. (The course examines this challenge in detail in topic 1.19 under "heterogeneity of environments.")
1.12.2 Reduced Delivery Times
Delivery times are always "one month ago" and not in the future — you have to race against time to deliver. Customers want the product immediately, so a central challenge is delivering good quality software within the time and budget.
Challenge two: reduced delivery times. Delivery deadlines feel like "one month ago" — customers want the product immediately. The central challenge is delivering good quality software within the available time and budget: exactly the "fast" corner of the good–fast–cheap triangle from section 1.4. This is why the lecture says you have to race against time to deliver.
1.12.3 Trustworthy Software
You do not want software that is unreliable and crashes frequently. Developing trustworthy software — software that is dependable — is a key challenge, along with focusing on good quality software within time and budget.
Challenge three: trustworthy software. Nobody wants software that is unreliable and crashes frequently. Developing trustworthy software — software that is dependable — is a key challenge, alongside producing good quality software within time and budget. Trustworthiness here means the software can be relied on: it behaves as expected, does not fail, and is secure. (Dependability, safety, and security are the subjects of later topics on dependable systems.)
Pitfall — treating the three challenges as separate to-do items. The three challenges interact and compound. Reducing delivery time while ignoring trust produces software that crashes — which is more expensive to fix later (section 1.13). Racing to new platforms without managing diversity produces systems that fail in the field. The realistic engineering response is a balance: deliver good quality software within time and budget — the same trade-off as the triple constraint, applied to the whole industry.
Recap + bridge: The key challenges facing software engineering are coping with increasing diversity in technology and platforms, meeting reduced delivery times (the "one month ago" deadline), and developing trustworthy, dependable software — all while keeping quality, time, and budget in balance. Next, the lecture puts numbers on one of the reasons these challenges are hard: the costs of software.
Real-world & domain connection: These three challenges describe today's industry headlines. Diversity: a mobile app must run on thousands of device models and be integrated with legacy systems. Reduced delivery times: continuous delivery and agile methods exist largely to compress delivery cycles. Trustworthiness: security breaches and crashes of critical systems (airlines, hospitals, banks) cost companies reputation and money. Any modern software engineering team's roadmap is, in essence, a response to these three challenges.
1.13 The Costs of Software
1.13.1 The Numbers
Hook: Where does the money in a software project actually go? The answer surprises most people: not into writing code. Development is less than half the story, testing is a huge slice, and the biggest cost of all comes after delivery.
Look at where the money goes: while 50% of the costs are development, 40% are testing during the development phase. Then there is evolution — the cost of maintaining the software during its useful lifetime — and that often exceeds the development costs.
The cost split. During the development phase of a typical software project:
- 50% of costs go to development — specification, design, and implementation.
- 40% of costs go to testing during the development phase.
So nearly half of the upfront spend is verification, not coding — a strong hint that "programming" is a minority activity in real software projects. On top of both sits evolution: the cost of maintaining and changing the software during its useful lifetime, which often exceeds the development costs. The lecture's central lesson: most of the money in software is spent after the first version works.
Standard figures in the reference material: reference texts give comparable numbers — roughly 60% of software costs are development costs and 40% are testing costs, with evolution costs for custom software often exceeding development costs. Whichever edition you use, the two conclusions are identical: testing is a major share of development cost, and maintenance/evolution dominates the total cost of software over its lifetime.
1.13.2 The Iceberg Analogy
Picture an iceberg. The tip that is visible above the surface of the ocean is the cost of software development, from specification to delivery. Once the software is delivered, it is put into operation and it undergoes change as it evolves. This evolution cost is like the entire iceberg that is submerged and invisible below the ocean surface — and it costs much more than the visible tip. Most costs of software are in maintenance, especially if the software is used for a long time.
The iceberg analogy (the professor's picture). Imagine a software project as an iceberg floating in the ocean. The tip above the water — the part everyone sees and budgets for — is the cost of development, from specification to delivery. Below the waterline, invisible and far larger, sits the cost of evolution: all the changes made once the software is in operation — new features, bug fixes, platform updates, changed business rules. The submerged mass costs far more than the visible tip, and the longer the software lives, the larger it grows. Most costs of software are in maintenance — especially for software that serves for many decades.
Worked example — a decade of cost. Suppose a company builds a billing system for \$1,000,000 of development cost (the visible tip). Using the lecture's split, roughly \$500,000 of that was development and \$400,000 testing. The system runs for 10 years and is changed every year: new tax rules, new reports, new integrations. Industry experience — and the iceberg analogy — says the accumulated evolution cost over those 10 years exceeds the \$1,000,000 development cost, and grows with every extra year the system stays in service. The project's true total cost is well above the number in the original budget — which is exactly why cost estimation and maintainability matter so much in software engineering. Sense-check: if evolution cost simply equaled development cost, the iceberg would be only twice as large as the tip; real systems routinely spend several times the development cost on change — the submerged part dominates.
1.13.3 Bugs Cost Far More Later
If there are bugs in the software, fixing them will cost much more once the system is in production or in operation. What could be just a typographical correction during requirements would cost a thousand times more if it is a bug detected during production or operations and you have to fix it. The lesson: the same defect is enormously more expensive the later it is found.
Worked example — the same defect, a thousand times more expensive. Take a single defect: a wrong field name in a requirement, say "customer_address" typed as "custome_address".
- Found during requirements (a typo caught while reviewing the specification): fixing it means correcting one line in a document — practically free, perhaps \$1 of effort.
- Found during production/operations (after the system has been built, tested, deployed, and is in daily use): the "typo" has propagated everywhere. The database schema, the data-entry forms, the reports, and the interfaces all use the wrong name. Fixing it requires design changes, code changes, data migration, retesting, redeployment, and customer communication — roughly \$1,000 — about a thousand times more than the requirements-time fix.
The lesson: the same defect costs enormously more the later it is found. Sense-check: the numbers scale — a defect that costs \$10 to fix at requirements time costs on the order of \$10,000 in production; the multiplier is what matters, not the currency.
Pitfall — celebrating "we delivered on time" while ignoring the iceberg. A common beginner view is that a project's cost ends at delivery. In reality delivery is the beginning of the expensive part: evolution costs often exceed development costs, and a bug found in production can cost a thousand times more than the same bug caught early. This is why the lecture insists on doing things right the first time (topic 1.17) and why testing gets 40% of development-phase cost.
Recap + bridge: Costs of software: roughly 50% development and 40% testing during development (reference texts give ~60/40), with evolution often exceeding development costs — the iceberg analogy (visible development tip, large invisible maintenance mass) captures this, and a defect found in production can cost a thousand times more than the same defect fixed at requirements time. Next, the lecture asks whether there is one method that fits every software project — the answer is a menu, not a one-size-fits-all.
Real-world & domain connection: These cost facts drive real industry decisions. Because maintenance dominates total cost, companies invest in maintainable design, documentation, and automated tests; because late defects are so expensive, organizations use reviews, continuous testing, and staged releases to catch problems early. The "defect cost curve" is a standard argument used to justify quality assurance budgets and modern DevOps practices that shorten the time between a change and its verification.
1.14 Software Engineering Methods: No One-Size-Fits-All
1.14.1 A Menu of Methods
Hook: If there is no universal method (section 1.3), what is there? The answer: a menu. Software engineering offers several families of methods, and the skill is choosing the right one for the kind of software you are building.
Since there is a wide variety of software, a wide variety of methods and techniques are used. There is no single method that is good for all software and no one-size-fits-all solution. Each kind of software has its methods: agile methods, plan-driven methods, incremental methods, reuse-oriented methods. All of these are examined as the course proceeds.
The menu of software engineering methods. Each kind of software has methods suited to it:
- Agile methods — flexible, iterative, built around rapid change and close customer involvement; suited to interactive web systems and apps whose requirements evolve.
- Plan-driven methods — everything is specified and planned in advance, then executed; suited to systems where requirements must be fully understood before building (for example, safety-critical embedded systems).
- Incremental methods — the system is developed and delivered in increments, each adding functionality; suited to large systems where partial delivery is valuable.
- Reuse-oriented methods — the system is assembled largely from existing components; suited to web and business systems built on frameworks and services.
There is no single method that is good for all software and no one-size-fits-all solution. The course examines each of these families in detail as it proceeds — remember this menu, because later topics (processes, agile development, reuse-oriented software engineering) each explore one entry of it.
1.14.2 Cloud and Web Changed Deployment
Cloud-based development has changed the deployment of software — software as a service and so on — and web-based development has brought in a lot of new changes to software engineering as a discipline and as a function.
How cloud and web changed deployment. Two transformations have reshaped the discipline:
- Cloud-based development changed how software is deployed: instead of installing copies on every user's computer, software runs on shared remote servers and is accessed over the internet — the model of software as a service (examined in topic 1.23).
- Web-based development changed software engineering as a discipline and as a function: new methods (incremental and agile delivery), new ways of assembling systems (reuse of components and frameworks), and new teams and skills (front-end, back-end, DevOps) have become mainstream.
Pitfall — choosing a method by fashion rather than by system type. "We must be agile" or "we must be plan-driven" is a decision about fitness, not fashion. Web apps whose requirements change weekly are best served by agile and incremental methods; a chip in a braking system that must be proven safe before manufacturing is best served by plan-driven rigor with extensive verification. Using the wrong family from the menu — however modern it sounds — produces the failures described in section 1.5.
Recap + bridge: There is a menu of methods — agile, plan-driven, incremental, and reuse-oriented — because each kind of software suits a different approach; cloud-based development changed deployment (software as a service) and web-based development changed the discipline itself. Next, the lecture sharpens the idea of software quality: what quality means for professional software used and changed by others.
Real-world & domain connection: The menu of methods maps directly to today's industry: startups and product companies run agile teams; banks and avionics suppliers run plan-driven processes with rigorous validation; platform vendors (for example, cloud providers) deliver incrementally and continuously; and most modern web systems are assembled reuse-first from frameworks like J2EE and .NET, plus open-source libraries. Choosing and blending these families — often called a "methodology" — is one of the most visible decisions a software organization makes.
1.15 Quality of Professional Software
1.15.1 Quality Includes Behavior and Structure
Hook: A program can produce correct outputs yet still be bad software — because professional software is used and changed by people other than its developers. That single fact expands the meaning of quality beyond "does it work?"
When we talk about the quality of professional software, we have to consider that the software is used and changed by people apart from its developers. Quality is not just concerned with what the software does. It also has to include the software's behavior while it is executing, and the structure and organization of the system programs and the associated documentation.
Quality has three faces. For professional software, quality is not just what the software does:
- Function — what the software does (the required features).
- Behavior while executing — how it behaves at runtime: response times, stability, resource use, concurrency behavior.
- Structure and organization — the internal structure of the system programs and the associated documentation: is the code understandable? Is the design coherent? Can a new engineer find their way around?
Why include structure? Because professional software is changed by people apart from its developers. A system whose behavior is perfect but whose structure is a tangle will be expensive and risky to change — and change is guaranteed (section 1.13). Quality of structure is a quality of the software itself, not a nicety.
1.15.2 Quality Properties
This quality is reflected in the software's properties: reliability, safety, usability, maintainability, and also performance — response time to user queries — and the understandability of the code.
The quality properties of professional software.
| Property | Plain meaning |
|---|---|
| Reliability | The software behaves as expected without failures |
| Safety | The software does not cause harm, even when it fails |
| Usability | Users can operate the software effectively |
| Maintainability | The software can be changed without undue cost or risk |
| Performance | For example, response time to user queries |
| Understandability of code | People other than the author can read and modify the code |
These properties are called non-functional or quality attributes in the reference literature: they are not about a single feature but about how the whole system behaves and how easy it is to live with. Notice the two groups: the runtime properties (reliability, safety, performance) describe behavior while executing; the change-oriented properties (maintainability, understandability) describe structure and organization.
1.15.3 Quality Depends on Application
The specific set of attributes you expect from a software system depends on its application: an air traffic control system must be quite safe, an interactive video game must be quite responsive, a telephone network system must be quite reliable. On top of that, maintainability, dependability, efficiency, and acceptability are the essential characteristics of any professional software system.
Which quality property dominates, application by application.
| System | Dominant quality property | What it means in practice |
|---|---|---|
| Air traffic control | Safety | A failure must never endanger aircraft |
| Interactive video game | Responsiveness | Input-to-frame latency must stay tiny |
| Telephone network | Reliability | Calls must connect and survive — continuously |
| E-commerce site | Availability and performance | Users must reach it 24/7 without long waits |
| Hospital records system | Usability and security | Clinicians find records fast; patient data stays protected |
The pattern: the priority ordering of quality properties is set by the application, while the base set — maintainability, dependability, efficiency, acceptability — applies to any professional system. Dependability wraps reliability, safety, and security together; acceptability means the software must be understandable, usable, and compatible with the other systems its users work with.
Pitfall — measuring quality only by "does it run?" A system that passes its feature tests can still be low quality: slow responses, an interface users cannot operate, a structure nobody can change safely. Professional quality must be designed and verified — for structure (reviews, design standards, documentation) and for behavior (performance testing, reliability monitoring, usability testing) — not inferred from a working demo.
Recap + bridge: Quality of professional software includes not only what the software does but its behavior while executing and the structure of the programs and documentation, reflected in properties such as reliability, safety, usability, maintainability, performance, and understandability of code — with the dominant property set by the application (safe: air traffic control; responsive: games; reliable: telephone networks) and maintainability, dependability, efficiency, and acceptability as the essential characteristics of any professional system. Next, the lecture steps back and explains what it means for software engineering to be an engineering discipline: engineers make things work.
Real-world & domain connection: These properties are what real engineering organizations measure and manage. Reliability and availability are tracked with service-level agreements and uptime dashboards; safety is enforced by regulatory standards in aviation, medical devices, and vehicles; usability is tested with real users; maintainability and understandability are protected through code reviews, coding standards, and documentation requirements. The lecture's two quality groups — runtime behavior and internal structure — correspond to the two sides of modern engineering: operations and development.
1.16 Engineers Make Things Work
1.16.1 What Engineers Do
Hook: What is the difference between a scientist and an engineer? A scientist asks "what is true?" An engineer asks "how do I make this work?" — and is willing to get it working even when the theory does not yet exist. That is the definition of engineering this section builds.
As engineers, you make things work. You apply various theories, methods, and tools that are appropriate to create things that work, efficiently and effectively. But you use them selectively — you use the methods, techniques, and tools selectively, and you deliver or discover solutions to problems even when there are no applicable theories and methods. If the problem is new, you try to create a new solution, even when there are no standard methods and tools available.
The engineer's job description. Engineers make things work. Three parts stand out:
- Apply theories, methods, and tools — where they are appropriate. Theory is a tool, not a straitjacket.
- Use them selectively — the engineer chooses what to apply, rather than applying everything mechanically. This is the theme of section 1.14's menu of methods: the discipline is the same, the selection varies.
- Deliver solutions even when no theory exists — if the problem is new and no standard methods and tools are available, the engineer creates a new solution anyway. Engineers do not get to say "sorry, no theory covers this problem."
1.16.2 Working Within Constraints
As engineers you also recognize that you must work within organizational and financial constraints, and you must look for solutions within these constraints. You do not have a ready-made manual of theories and methods to apply; you have to use your judgment, combining experience and creativity to come up with solutions. The goal of any engineer is the same good-fast-cheap goal: achieve good quality products as quickly as possible within budget constraints. Engineering is about getting results of the required quality within the schedule and budget. This often involves making compromises — as engineers, you may not be perfectionists.
Constraints are part of the problem. Every engineering problem comes wrapped in organizational and financial constraints, and the solution must live inside them. There is no ready-made manual: the engineer uses judgment, combining experience and creativity.
The engineer's goal is exactly the good–fast–cheap goal of section 1.4: good quality products as quickly as possible within budget. Engineering means getting results of the required quality within schedule and budget — which often requires compromises. The striking consequence, stated directly in the lecture: as engineers, you may not be perfectionists. A solution that meets the required quality within budget beats a perfect solution that never ships.
1.16.3 The Systematic Approach
People writing programs for themselves can spend as much time as they wish on program development, if it is just for a hobby or research. But in general, software engineers adopt a systematic and organized approach to their work. This is the hallmark of engineering — a systematic and organized approach to work, and the most effective way to produce high quality software.
The systematic approach is the hallmark of engineering. A hobbyist can spend unlimited time on a program; professional engineers cannot — so they adopt a systematic and organized approach to their work. This is the hallmark of engineering: not inspiration, not heroics, but an organized method. It is also the most effective way to produce high quality software — the same conclusion as the definition of software engineering as a systematic and quantitative approach (section 1.10).
1.16.4 Choosing the Method for the Situation
Engineering is all about selecting the most appropriate method for a set of circumstances. A more creative, less formal approach to development may be the right one for some kinds of software and some situations. A more flexible software process that accommodates rapid change is particularly appropriate for the development of interactive web-based systems and mobile apps, which require a blend of graphical design skills and software design skills.
Choosing the method for the situation — two worked contrasts.
- Interactive web-based system / mobile app: requirements change fast, the look and feel is part of the product, and time to market is short. The right choice is a flexible process that accommodates rapid change — the agile and incremental family from section 1.14 — because it lets the team respond as users react. Such systems require a blend of graphical design skills and software design skills.
- Safety-critical embedded system (for example, a car braking controller): requirements must be completely specified and verified before development (section 1.18), and change after manufacturing is extremely expensive (section 1.20). The right choice is a plan-driven process with rigorous verification, even though it is slower.
The same engineer, the same discipline, two different selections from the method menu — because engineering is all about selecting the most appropriate method for a set of circumstances.
Pitfall — perfectionism disguised as engineering. The lecture is explicit: engineers may not be perfectionists. Holding a release for one more round of polish, ignoring budget and schedule, is not engineering — it is the good-fast-cheap triangle collapsing under "good" alone. The engineering skill is delivering the required quality within schedule and budget, making compromises deliberately and openly, not silently slipping quality.
Recap + bridge: Engineers make things work: they apply theories, methods, and tools selectively; they deliver solutions even when no theory exists; they work within organizational and financial constraints toward the good-fast-cheap goal, often compromising (engineers may not be perfectionists); and they adopt a systematic, organized approach — selecting the most appropriate method for each situation. Next, the lecture gives the two reasons software engineering itself is important.
Real-world & domain connection: This is the most career-relevant section of the lecture. In industry, the "engineer's mindset" shows up in how teams handle trade-offs: product managers, architects, and engineers negotiate scope, schedule, and quality continuously; new problems (new platforms, new regulations) are solved with creative combinations of existing techniques; and judgment — "which method here?" — is precisely what distinguishes an experienced engineer from a technician. The good-fast-cheap goal is also the core of project management, studied later in this course.
1.17 Why Software Engineering Is Important
1.17.1 Reason One: Society Depends on Software
Hook: Why does this course exist? The lecture gives two reasons, and the first is the simplest and the strongest: we cannot afford for society's software to be unreliable, because we now depend on it for almost everything.
More and more individuals and society rely on software systems, so we need to be able to produce reliable and trustworthy systems economically. Reliable and trustworthy is good; economically is fast — cheap and quickly is fast.
Reason one: society depends on software. More and more individuals and society rely on software systems, so we need to produce reliable and trustworthy systems — and to do so economically. The lecture links this back to the triple constraint: "reliable and trustworthy is good; economically is fast — cheap and quickly is fast." Dependability (good) and cost/speed (fast, cheap) must both be achieved — which is exactly what software engineering makes possible. Without the discipline, society's dependence on software would be dependence on fragile systems.
1.17.2 Reason Two: Cheaper in the Long Run
It is usually cheaper in the long run to use systematic and organized software engineering methods and techniques for professional software systems than to write them as a personal programming project. If you fail to use systematic software engineering methods, it leads to higher costs for testing, quality assurance, and long-term maintenance after the software has gone into use.
Reason two: cheaper in the long run. It is usually cheaper in the long run to use systematic, organized software engineering methods for professional software systems than to write them as a personal programming project. Skipping the method looks cheaper at first — but the costs surface later: higher costs for testing, quality assurance, and long-term maintenance after the software has gone into use. This is the iceberg from section 1.13 viewed from the budget side: the disciplined investment up front buys a far smaller submerged cost later.
1.17.3 Do Things Right the First Time
It is better to do things right the first time than to keep on fixing bugs later. Capture the requirements right, design right, code and implement right, test it properly — rather than fixing bugs much later, which becomes quite expensive.
Pitfall — "we will fix it in testing." The lecture warns against the assumption that bugs can simply be caught and fixed later. Doing things right the first time is cheaper: capture the requirements right, design right, code and implement right, and test properly — rather than fixing bugs much later, when the same defect costs a thousand times more (section 1.13). "We will fix it later" is the most expensive phrase in software development; it quietly converts a cheap early fix into an expensive production fix.
Recap + bridge: Software engineering matters for two reasons: society depends on software, so we must produce reliable and trustworthy systems economically; and using systematic methods is cheaper in the long run, because failing to do so raises testing, quality-assurance, and long-term maintenance costs. The practical consequence: do things right the first time — requirements, design, code, and tests — rather than fixing bugs much later. Next, the lecture introduces the vehicle of this systematic approach: the software process.
Real-world & domain connection: Reason two is the economic foundation of the entire software industry. Organizations that invest in process — reviews, testing infrastructure, quality assurance — consistently spend less on long-term maintenance than those that do not. Government reports and industry studies repeatedly show that the "fix it later" culture produces systems that consume their own budgets in maintenance. This is why modern engineering organizations institutionalize quality early: continuous testing, design reviews, and requirements validation are direct applications of "do things right the first time."
1.18 The Software Process
1.18.1 Definition
Hook: "Software process" sounds like bureaucracy — but it is simply the answer to a practical question: in what order do we do the work of building software, and what activities does every project need, no matter what?
The systematic approach used in software engineering is sometimes called the software process: a sequence of activities that leads to the production of a software product. Software processes are examined in detail in the next class.
The software process, defined. The systematic approach used in software engineering is sometimes called the software process: a sequence of activities that leads to the production of a software product. It is the organized way the work gets done — the systematic and organized approach of section 1.16, made concrete as a sequence of steps. Software processes are examined in detail in the next class, so this section only establishes the core: the process exists, and four fundamental activities appear in every process.
1.18.2 The Four Fundamental Activities
There are four fundamental activities common to all software processes:
- Software specification — the customers and engineers define the software that is to be produced and also specify the constraints on its development and operation.
- Software development — the software engineers design and program the software.
- Software validation — sometimes called verification and validation; the software is checked to ensure that it does what the customer wants.
- Software evolution — once the software is tested and delivered, it is put into operation or use, and it is modified to reflect changing customer and market requirements as the system evolves.
The four fundamental activities of every software process.
- Software specification — customers and engineers define the software to be produced and the constraints on its development and operation.
- Software development — the software engineers design and program the software.
- Software validation — also called verification and validation; the software is checked to ensure it does what the customer wants.
- Software evolution — once tested and delivered, the software is put into operation and modified to reflect changing customer and market requirements.
A helpful picture: the four activities form a cycle. Specify what to build → develop it → validate that it matches → deliver it and let it evolve → changes feed back into a new round of specification, development, and validation. Every software process — whatever its style — is an organization of these four activities.
Exam note: Be ready to name the four fundamental activities of the software process: specification, development, validation, and evolution — and to state what each does. This is a standard exam item for this lecture.
Recap + bridge: The software process is the sequence of activities that produces a software product; the four fundamental activities common to all processes are specification (define what to build), development (design and program), validation (check it does what the customer wants), and evolution (modify it after delivery as requirements change). Next, the lecture shows that even these four generic activities are organized differently for different types of systems.
1.18.3 Different Systems Need Different Processes
Different types of systems need different types of development processes. Real-time systems — embedded systems, for example — have to be completely specified and validated and verified even before development begins. In contrast, in some interactive applications and web-based systems, specification and development are usually done concurrently because the requirements keep changing. The generic activities — specification, development, validation, evolution — may be organized in different ways and described at different levels of detail depending on the type of software system being developed.
Two systems, two process organizations.
| Safety-critical real-time (embedded) system | Interactive web-based system | |
|---|---|---|
| Requirements | Stable, must be captured completely | Change continuously |
| Specification timing | Complete specification before development begins | Specification and development done concurrently |
| Validation timing | Fully validated and verified even before development | Validated incrementally, release by release |
| Process style | Plan-driven, rigorous | Agile, incremental |
The same four generic activities appear in both — but they are organized differently and described at different levels of detail. The activities are the skeleton; the ordering and rigor are chosen to fit the system type. This is the "no one-size-fits-all" idea (sections 1.3 and 1.14) applied to the process itself.
Pitfall — assuming one process order for everything. Beginners often picture one universal sequence: requirements, then design, then code, then test, once. Real processes vary by system type: embedded real-time systems must be completely specified, validated, and verified before development begins, while interactive web systems run specification and development concurrently because requirements keep changing. The four activities are constant; their organization is not.
Recap + bridge: The software process is a sequence of activities leading to a software product, built from four fundamental activities — specification, development, validation, and evolution — organized differently per system type: real-time embedded systems are completely specified and verified before development, while interactive web systems specify and develop concurrently. Next, the lecture looks ahead at the challenges that will test software engineering in the years to come.
Real-world & domain connection: The software process is the backbone of real engineering organizations: avionics and automotive teams use process frameworks with complete upfront specification and verification (for example, DO-178C and ISO 26262 compliance processes), while web companies run continuous delivery pipelines where specification, development, and validation overlap in weekly cycles. When this course studies process models, agile methods, and plan-driven methods in the coming classes, you will see each as a different organization of these same four activities.
1.19 Software Engineering Challenges Ahead
1.19.1 Heterogeneity of Environments
Hook: The future software landscape is not one computer but a tangle: phones, tablets, embedded devices, old systems nobody dares touch, all speaking different languages. The challenges ahead all come from this growing diversity — and from the trust we place in the result.
Increasingly, systems are required to operate in distributed systems across networks that include different types of computer and mobile devices, as well as running on general purpose computer software. Software may also have to execute on embedded devices, mobile phones, and tablets. You may have to integrate new software with older legacy systems written in a variety of programming languages that are no longer supported. The challenge here is to develop techniques for building dependable, trustworthy systems that are flexible enough to cope with this heterogeneity in the environment.
Challenge: heterogeneity of environments. Systems increasingly operate as distributed systems across networks that mix many device types: general-purpose computers, mobile phones, tablets, and embedded devices. And new software often has to integrate with older legacy systems written in programming languages that are no longer supported. The challenge: develop techniques for building dependable, trustworthy systems flexible enough to cope with this heterogeneity. (This is the "diversity in technology and platforms" challenge of section 1.12, now in its technical form.)
1.19.2 Business and Social Change
Businesses and society are changing very rapidly as emerging economies develop and new technologies become available quickly, and they need to be able to change their existing software. Many traditional software engineering techniques are time consuming, and delivery of new systems often takes longer than planned. Software engineering needs to evolve so that the time required for delivering software of value to its customers is reduced — you need to rapidly develop good software that delivers value to customers as quickly as possible.
Challenge: business and social change. Businesses and society change very rapidly as emerging economies develop and new technologies appear quickly — and they need to change their existing software to keep up. Many traditional software engineering techniques are time consuming, and delivery of new systems often takes longer than planned. Software engineering must evolve so the time from idea to software of value to customers shrinks: rapidly develop good software that delivers value as quickly as possible — the "fast" corner of the triple constraint, applied to the whole industry.
1.19.3 Security and Trust
As software governs all aspects of our lives and is intertwined with all devices and all things that we use, it is essential that we can trust software. This is especially true for remote software systems that are accessed through a web service or a cloud-based application. We have to make sure that malicious users and others cannot successfully attack our software, that information security is maintained, and that software does not turn hazardous to the people who use it. With pervasive computing, the internet of things, and wearable devices, security and trust are an important concern for all software systems.
Challenge: security and trust. As software governs all aspects of our lives and is intertwined with all the devices and things we use, we must be able to trust it. This is especially true for remote systems accessed through web services or cloud applications. The requirements: malicious users cannot successfully attack the software, information security is maintained, and the software never turns hazardous to the people who use it. With pervasive computing, the internet of things, and wearable devices, security and trust are now a concern for all software systems — not just banks and governments.
1.19.4 Scalability
Software has to be developed across a wide range of scales — from micro and nano embedded systems, to portable wearable devices, to internet-scale cloud-based systems that serve a global community.
Challenge: scalability. Software spans an enormous range of scales: micro and nano embedded systems, portable wearable devices, and internet-scale cloud-based systems serving a global community. Techniques that work at one scale often fail at another — a memory-efficient trick for a wristwatch chip is irrelevant to a cloud platform, and a cloud architecture cannot fit in a wearable. Scalability is both a technical and a methodological challenge.
1.19.5 New Tools and Creative Combinations
To address all of these challenges we will need new tools and techniques, as well as innovative ways of combining and using existing software engineering methods, tools, and techniques — in the right way, in an innovative, creative way — to generate good quality solutions that are dependable, trustworthy, secure, safe, and scalable, and that take care of the diversity or heterogeneity in the environment. A professional software engineer needs a broad perspective of how things are changing in the software engineering landscape across a variety of domains and applications.
Challenge: new tools and creative combinations. No single new technique will answer all four challenges. What is needed: new tools and techniques, plus innovative ways of combining and using existing methods, tools, and techniques — in the right way, in an innovative, creative way — to produce solutions that are dependable, trustworthy, secure, safe, and scalable, and that handle the diversity of the environment. This is the "engineer creates new solutions even without standard methods" idea of section 1.16, applied at the scale of the whole discipline.
Pitfall — waiting for a silver bullet. A recurring illusion in software engineering is that some single new technique will solve everything (in the reference literature this is known as the "no silver bullet" argument). The lecture's answer is more realistic: the challenges are addressed by combinations — new tools plus creative use of existing ones — and by engineers who keep a broad perspective across domains. A professional software engineer needs to keep watching how the landscape changes, across a variety of domains and applications.
Recap + bridge: The challenges ahead are heterogeneity of environments (distributed, mixed devices, legacy integration), business and social change (rapid delivery of value), security and trust (attacks, information security, hazard), scalability (from nano embedded to internet-scale clouds), and the need for new tools and creative combinations of existing ones — requiring a broad professional perspective. Next, the lecture gives the concrete map of the terrain: the different types of software systems and what each demands.
Real-world & domain connection: These challenges define the modern engineering agenda: containerization and microservices exist to tame heterogeneity; DevOps and continuous delivery exist to shorten time-to-value; threat modeling and secure development lifecycles exist for security and trust; and cloud computing itself is the industrial answer to scale. The internet of things and wearable devices have made security a consumer-safety issue, not just a corporate one — each of these challenges will return in later course topics on dependable systems, distributed systems, and evolution.
1.20 Application Types
1.20.1 Standalone Applications
Hook: Software is not one thing — it is at least eight different things. A game on your phone, a bank's overnight payroll run, a weather satellite's sensor stream, and a city's e-commerce site are all "software," but they demand completely different engineering. This section maps the territory.
Standalone applications run on personal computers or mobile devices and may not need to be connected to a network. This includes games, travel apps, and productivity apps on the desktop or mobile.
Type 1 — Standalone applications. These run on a personal computer or mobile device and may not need a network connection. Examples: office applications, CAD programs, photo manipulation software, travel apps, and productivity apps on desktop or mobile. They include all necessary functionality themselves.
1.20.2 Interactive Transaction-Based Applications
Interactive transaction-based applications are applications like e-commerce applications, where you interact with a remote system to avail a service — buying a ticket or buying things online. Interactive applications often incorporate a large data store that is accessed and updated in each transaction.
Type 2 — Interactive transaction-based applications. You interact with a remote system to get a service: e-commerce sites where you buy tickets or goods online, business systems accessed through a web browser or a client program, and cloud-based services like mail and photo sharing. These applications often incorporate a large data store that is accessed and updated in each transaction — every click is a small transaction against a shared database.
1.20.3 Embedded Control Systems
Embedded control systems are embedded in small devices, sometimes wearable computers, and there are probably much more embedded systems than any other type of system. They include software in a mobile phone, software that controls braking systems in a car, and software that controls equipment like microwave ovens.
Type 3 — Embedded control systems. Software embedded inside devices that controls and manages hardware: the software in a mobile phone, the software controlling anti-lock braking in a car, and the software that runs a microwave oven. Numerically, there are probably more embedded systems than any other type of system — every car, phone, appliance, and industrial machine carries several.
1.20.4 Batch Processing Systems
Organization-wide batch processing systems are processed on a periodic basis. A payroll system is the classic example — the data is processed in large batches. Periodic billing systems, like electricity billing, phone billing, and payroll systems, work the same way.
Type 4 — Batch processing systems. Business systems that process data in large batches on a periodic basis: they take large numbers of individual inputs and produce corresponding outputs in one run. The classic example is a payroll system; periodic electricity billing, phone billing, and salary payment systems work the same way.
1.20.5 Digital Entertainment Systems
There is a wide variety of digital entertainment systems, for personal use as well as mass use. The quality of user interaction is the most important distinguishing characteristic of entertainment systems, along with the response time and the speed at which they interact.
Type 5 — Digital entertainment systems. A wide variety of systems for personal and mass use — most of them games of one kind or another, possibly on special-purpose consoles. The quality of user interaction is the most important distinguishing characteristic, along with response time and interaction speed. An entertaining but slow game fails; a fast but dull one fails too.
1.20.6 Scientific Modeling and Simulation
Scientific applications for modeling and simulation simulate various physical processes and situations, and may include many separate interacting objects, hardware, and lab equipment. These are computationally intensive and usually require high performance parallel computers or systems for execution because of the complex computational requirements.
Type 6 — Scientific modeling and simulation. Scientists and engineers use these systems to model physical processes or situations that include many separate, interacting objects — weather models, aircraft aerodynamics, molecular dynamics. They are computationally intensive and usually require high-performance parallel computers or systems to execute.
1.20.7 Data Collection and Big Data
Data collection systems — the big data systems of the current environment — collect data from various sources through remote sensors, like a weather information system. Big data analysis may also involve cloud-based systems carrying out statistical analysis, looking for relationships among the collected data.
Type 7 — Data collection and big data systems. These collect data from the environment — often through remote sensors, as in a weather information system — and send it elsewhere for processing. "Big data" analysis involves cloud-based systems carrying out statistical analysis and looking for relationships in the collected data. Sensor systems often run in hostile environments (inside an engine, in a remote location), so reliability is critical.
1.20.8 Enterprise Systems of Systems
The data from all these systems is used in large organizations. Systems used in enterprises and large organizations are often composed of a number of other software systems. Some of these may be generic software products like ERP systems; others can be specifically written for the environment. There may be systems of systems.
Type 8 — Systems of systems. Systems used in enterprises and large organizations are often composed of a number of other software systems: some may be generic products such as ERP systems; others may be specially written for the environment. The whole may be a system of systems — an enterprise that connects its ERP, its billing, its supply chain, and its customer systems into one ecosystem.
1.20.9 Blurred Boundaries
The boundaries between these system types are getting blurred. If you develop a game for a phone, you have to take into account the same constraints — power, hardware interaction — as the developers of the phone software. Batch processing systems are often used in conjunction with web-based transaction systems: in a company, all travel expense claims may be submitted through a web application but processed in a batch for monthly payment.
Worked example — the blurred boundary in one company. A company runs a web application where every employee submits travel expense claims online. That web system is an interactive transaction-based application: each submission is a transaction against a data store. But the money is not paid per claim — every month, a batch processing run collects all submitted claims and produces the payments in one pass. One business process uses two system types glued together. Similarly, a phone game is an entertainment system, yet its developers must respect the same power and hardware-interaction constraints as the developers of the phone's own embedded software. The boundaries between the types are getting blurred — real systems increasingly combine several types.
1.20.10 Specialized Engineering per Type
Each type of system requires specialized software engineering techniques, because the software has different characteristics. An embedded control system in an automobile is a safety-critical system, installed in the vehicle and very expensive to change: if there is a problem with the chip in a car, the entire set of cars that have been sold have to be recalled — it has happened in many cases. Such a system needs extensive verification and validation, so that the chances of having to recall cars after sale to fix embedded system problems are minimized. There is no user interaction with such embedded systems, which are in the chip, so there is no need for a development process that relies on user interface prototyping or frequent user interaction — it should be verified thoroughly before it is built.
For an interactive web-based system or an app, by contrast, iterative development and delivery is the best approach, with the system being composed of reusable components. But such an approach may be impractical for a system of systems, where detailed specification of the system interactions has to be specified in advance so that each system can be separately developed.
Worked example — the car recall. Consider an embedded control system in an automobile: the braking controller. It is a safety-critical system, installed in the vehicle, and extremely expensive to change after manufacturing. If a problem is found in the chip, the entire set of cars already sold may have to be recalled to fix it — and this has happened in many real cases, costing manufacturers billions. Consequences for engineering:
- The system needs extensive verification and validation, so that the chance of a post-sale recall to fix embedded problems is minimized.
- There is no user interaction with such systems (they live in the chip), so the development process does not rely on user interface prototyping or frequent user interaction.
- The correct approach is to: verify it thoroughly before it is built.
Compare an interactive web system or app: iterative development and delivery is the best approach, with the system composed of reusable components. But even that approach is impractical for a system of systems, where the interactions between the separate systems must be specified in detail in advance so that each system can be developed independently. One lecture, three different engineering approaches — because the software's characteristics differ.
Pitfall — applying one development approach to every application type. The type of system dictates the engineering: safety-critical embedded systems need exhaustive verification before build (no user-interface prototyping needed); interactive web systems need iterative delivery with reusable components; systems of systems need detailed upfront specification of interactions so each system can be developed separately. Using the web-style approach on an embedded braking controller, or the embedded-style rigor on a game, is a recipe for either danger or wasted effort.
Recap + bridge: Application types: standalone applications, interactive transaction-based applications, embedded control systems, batch processing systems, digital entertainment systems, scientific modeling and simulation, data collection/big data systems, and enterprise systems of systems — with blurred boundaries (a phone game shares constraints with phone software; expense claims are submitted by web transaction but paid by batch) and specialized engineering per type (embedded safety-critical: verify before build; web: iterative delivery; systems of systems: detailed upfront interaction specification). Next, the lecture asks what fundamentals apply to all of these types.
Real-world & domain connection: Application types shape real industries and even regulations: automotive and aviation embedded software must satisfy safety standards before the first car or aircraft ships; e-commerce and banking platforms are engineered for transaction correctness and availability; payroll and billing run on batch infrastructure; weather agencies operate data collection networks feeding big-data analytics; and modern enterprises run systems of systems, integrating ERP products with custom components. When you meet these systems in later course topics (design, testing, evolution), remember that each type carries its own engineering approach.
1.21 Fundamentals That Apply to All Systems
1.21.1 A Managed, Understood Process
Hook: After all those different application types, is there anything that applies to every system? Yes — four fundamentals. Whatever you build and however you build it, these four hold: a managed process, dependability and performance, managed requirements, and reuse.
The software engineering fundamentals that apply to all types of software systems: the software should be developed using a managed and understood development process. The company developing the software should plan the development process and have clear ideas of what will be produced and when it will be completed. The first thing a customer wants to know before even giving the contract is: how much will it cost and by when will you deliver? The first question is the time of delivery. Of course, the specific process you choose depends on the type of software you are developing.
Fundamental 1 — a managed, understood development process. Whatever the system type, the software should be developed using a managed and understood process: the company plans the development process and has clear ideas of what will be produced and when it will be completed. The customer asks two questions before even giving the contract: how much will it cost, and by when will you deliver? — with the first question being the time of delivery. Of course, the specific process still depends on the type of software being developed (section 1.18) — the fundamental is that there is a managed process, not that there is only one.
1.21.2 Dependability and Performance
Dependability and performance are very important for all types of software systems. The software should behave as expected, without failures, and should be available for use when it is required. It should be safe in its operation and, as far as possible, secure against external attacks. The system should perform efficiently and should not waste system resources like memory and storage. Every device you use is software-intensive and should be absolutely dependable and trustworthy. Secure software engineering is the branch that deals with the security aspects.
Fundamental 2 — dependability and performance. Software should behave as expected, without failures, and be available when required; it should be safe in operation and, as far as possible, secure against external attacks; and it should perform efficiently without wasting resources like memory and storage. Every device you use is software-intensive and should be absolutely dependable and trustworthy. A whole branch of the discipline — secure software engineering — deals with the security aspects of this fundamental.
1.21.3 Understanding and Managing Requirements
Understanding and managing the specification — what the software should do — is very important, because the specifications form the basis for the design and development and ultimately the testing, validation, and acceptance of the product. You have to know what different customers and users of the system expect, and you have to manage their expectations so that a useful system can be delivered within budget and to schedule. Requirements engineering — an important aspect of software engineering, discussed in detail later in the course — is where you collect, classify, organize, specify, and manage the software specification as it evolves throughout development and later during the evolution of the software product.
Fundamental 3 — understanding and managing requirements. Understanding and managing the specification — what the software should do — matters because the specification forms the basis for design and development and ultimately for testing, validation, and acceptance of the product. You must know what different customers and users expect, and manage their expectations so a useful system is delivered within budget and to schedule. The professional name for this activity is requirements engineering: collecting, classifying, organizing, specifying, and managing the software specification as it evolves through development and later during the product's evolution. It is discussed in detail later in the course.
1.21.4 Reuse Wherever Appropriate
Wherever appropriate, you should reuse software that has been developed rather than develop new software from scratch. It is not good to reinvent the wheel when you can reuse existing software that is already found to be successful elsewhere. Often the tendency is to develop new software from scratch rather than reuse other software, because you are not sure of the quality of the reused software and you are not sure what consequences it will have on your system — there are trust issues with reusing software. But building from scratch is a waste of resources and time.
Fundamental 4 — reuse wherever appropriate. Wherever appropriate, reuse software that already exists rather than develop new software from scratch: it is not good to reinvent the wheel when successful software is already available elsewhere. The human obstacle is real — teams hesitate because they are unsure of the reused software's quality and unsure what consequences it will have on their system; there are trust issues with reuse. But building from scratch is a waste of resources and time. (The next section, 1.22, examines reuse-oriented development in detail.)
Recap + bridge: Four fundamentals apply to all types of software systems: a managed, understood development process (customers ask cost and delivery date first); dependability and performance (available, safe, secure, efficient — with secure software engineering as the security branch); understanding and managing requirements (the specification drives design, testing, validation, and acceptance — requirements engineering manages it); and reuse wherever appropriate (building from scratch wastes resources and time, though trust issues make teams hesitate). Next, the lecture focuses on that fourth fundamental: reuse-oriented development.
Real-world & domain connection: These four fundamentals are the common core of every engineering organization's practice: project planning and estimation answer the customer's cost-and-date questions; reliability engineering, security engineering, and performance teams deliver dependability; requirements engineering teams manage expectations and specifications; and platform teams maintain shared libraries and services so teams reuse instead of rebuilding. Later course topics on processes, requirements, design, and project management each deepen one of these four fundamentals.
1.22 Reuse-Oriented Development
1.22.1 Reuse Is Standard in Other Engineering Fields
Hook: No engineer redesigns a wheel. The electronics industry assembles computers from off-the-shelf chips; civil and mechanical engineers build on decades of standardized components. Only in software does "build it from scratch" remain the default — and this section asks why, and what we lose by it.
Look at the electronics industry: to assemble a new computer, you have integrated circuit (IC) chips for every functionality, and you just plug them into the circuit. Reuse is extensive in all engineering disciplines. In mechanical or civil engineering, building a new automobile does not mean redesigning it from first principles — you do not redevelop the wheel or the forces of motion and acceleration. All the components are in place and all the design is in place; you improvise upon it and build a new thing rather than building from scratch.
Reuse is the norm in other engineering fields. The electronics industry assembles a new computer from integrated circuit (IC) chips — one chip for each function — and simply plugs them into the circuit. Building a new automobile does not mean redesigning from first principles: you do not redevelop the wheel or the physics of motion and acceleration. All the components and designs are already in place; engineers improvise on top of them and build something new rather than starting from scratch. In every mature engineering discipline, reuse is extensive — it is what makes progress possible.
1.22.2 Software Developers Hesitate to Reuse
In software, a new one-off project tends to be built from scratch, and developers are hesitant to reuse components. Reuse-oriented software engineering and its challenges are examined in depth as the course works through the various types of software processes, with a specific focus on reuse-oriented software engineering.
In software, reuse is the exception, not the rule. A new one-off software project tends to be built from scratch, and developers hesitate to reuse components — the exact opposite of electronics and mechanical engineering. Reuse-oriented software engineering, and its challenges, are examined in depth later in the course, when the various types of software processes are studied — with a specific focus on reuse-oriented software engineering.
1.22.3 Students vs Industry Practice
Q: Do you reuse existing software components in your development projects, or do you prefer writing your own code from scratch? What is the common approach?
A: Typically as college students, most would prefer writing their own code, because they won't understand somebody else's code — that is the risk with reuse. But in industry, especially when you have to deliver software faster, you assemble things from existing pieces of code so that you can deliver good things faster and cheaper.
Pitfall — "I do not understand somebody else's code, so I will write my own." The student answer to the reuse question is honest and typical: most college students prefer writing their own code because they do not understand somebody else's code — that is the real risk of reuse. But the correction is that this preference, carried into industry, costs money: industry teams assemble existing pieces of code precisely because they must deliver faster and cheaper. Learning to read, evaluate, and integrate other people's code is a professional skill, not an optional one.
Worked example — how reuse wins in industry. Two teams build the same reporting feature for a corporate system, with a one-month deadline:
- Team A (from-scratch): writes its own authentication, its own date-handling library, its own PDF generator, and its own dashboard widgets — four components to build, debug, and test from zero. Realistically, they finish late, and every component carries fresh, untested bugs.
- Team B (reuse-oriented): pulls an existing authentication service, a well-known date-handling library, a standard PDF library, and a tested dashboard component from the company's component shelf — four components to integrate instead of build. They finish on time, with less code to test, because the reused components are already proven elsewhere.
Team B delivers good things faster and cheaper — the lecture's exact phrase. The catch is the trust issue: Team B must be confident about the quality of what they reuse, which is precisely the challenge reuse-oriented software engineering must solve.
1.22.4 The Four Course Themes
These four fundamental notions — a managed, understood, dependable process; dependability and performance; requirements management; and reuse-oriented software development — are the important themes of this course. Different methods reflect them in different ways, but they all underlie professional software development.
These fundamentals are independent of the programming language used. The course does not focus on any programming language or on programming or coding in general, except for some examples as part of design, implementation, and testing. Exam note: there are no programming assignments in this course, and no focus on specific programming languages like Python.
The four course themes. The four fundamentals of section 1.21 — a managed, understood process; dependability and performance; requirements management; and reuse-oriented software development — are the important themes of this course. Different methods reflect them in different ways, but they all underlie professional software development. These fundamentals are independent of the programming language used.
Exam note: There are no programming assignments in this course and no focus on any specific programming language (like Python); code appears only as examples within design, implementation, and testing. Also be ready to name the four fundamental notions that underlie all professional software development: a managed process, dependability and performance, requirements management, and reuse-oriented development.
Recap + bridge: Reuse is standard in other engineering fields (IC chips in electronics, wheels and physics in automotive design), yet software developers hesitate to reuse components — students prefer writing their own code because they do not understand somebody else's, while industry assembles existing pieces to deliver faster and cheaper; reuse-oriented development is one of the four course themes, and these fundamentals are independent of programming language. Next, the lecture shows how the internet and the cloud made reuse the dominant way of building: web-based and cloud-based systems.
Real-world & domain connection: Reuse is the economic engine of the modern software industry: operating systems, databases, web frameworks (J2EE, .NET), cloud services, and open-source libraries are all reused billions of times. The trust problem is solved in practice by standards, testing, and reputation — certified components, widely adopted libraries, and service-level agreements — which is exactly why reuse-oriented software engineering focuses on trust and quality assurance as much as on assembling components.
1.23 Web-Based and Cloud-Based Systems
1.23.1 Software as a Service
Hook: Once, buying software meant installing disks on every machine. Today most products run in a browser and you never install anything — the software lives on someone else's servers. The internet changed not just where software runs, but how the whole industry works.
The development of the internet has had a profound effect on our lives, and many products now run on web browsers — you do not have to write and install software on every computer. Every application has moved to a web-based application, and the notion of software as a service has become the standard approach to delivery of web-based systems.
Real-world: Google Apps, Office 365, and Adobe products are all delivered this way. More and more software runs on remote cloud servers instead of local servers and is accessed over the internet.
Software as a service. The internet moved software from local installation to the browser: instead of writing and installing software on every computer, users access applications served from remote machines. The notion of software as a service (SaaS) has become the standard approach to delivering web-based systems. Real-world examples: Google Apps, Office 365, and Adobe products are all delivered this way — the software runs on remote cloud servers and is accessed over the internet.
1.23.2 The Computing Cloud
A computing cloud is a huge number of linked computer systems that is shared by many users. Users do not buy software; they pay according to how much the software is used, or they are given free access in return for watching advertisements displayed on the screen.
Real-world: YouTube is the classic example of the ad-supported model.
The computing cloud. A computing cloud is a huge number of linked computer systems shared by many users. Users do not buy software — they pay according to how much they use it, or they get free access in return for watching advertisements on the screen. Real-world example: YouTube is the classic ad-supported model: free access for users, revenue from ads. Web-based mail, storage, and video are all cloud-based systems in this sense.
1.23.3 How the Web Changed Development
The fundamental ideas of software engineering apply to web-based systems just as they apply to other software systems, but the web has had significant impacts on software development:
- Software reuse has become the most dominant approach for constructing web-based or cloud-based apps. When building these systems, you think about how to assemble them from pre-existing software components and systems, which are often bundled together in a framework like J2EE or .NET.
- It is now recognized that it is impractical to specify all the requirements of e-commerce and business web interactive applications in advance. So web-based interactive systems are always developed and delivered incrementally, using incremental and agile approaches.
- Typically all these software systems are implemented as services — service-oriented computing or service-oriented components, where software components are standalone web services.
- A lot of rich interfaces have emerged — React, Angular, and many other tools enable support to create rich interfaces in web-based applications.
The fundamental ideas of software engineering are equally applicable to web-based software. And since web-based and cloud-based systems are getting larger, the software engineering techniques that deal with scale and complexity are also relevant for these systems.
Four ways the web changed software development.
- Reuse became dominant. Web and cloud applications are assembled from pre-existing components and systems, often bundled in a framework like J2EE or .NET. The reuse-first mindset of section 1.22 is now the default, not the exception.
- Requirements cannot be fully specified in advance. It is recognized as impractical to specify all requirements of e-commerce and business web applications up front, so web-based interactive systems are always developed and delivered incrementally, using incremental and agile approaches.
- Systems are implemented as services. Service-oriented computing (service-oriented components): software components are standalone web services that communicate over the network.
- Rich interfaces emerged. Tools like React and Angular support the creation of rich interfaces in web-based applications.
Intuition — why web systems cannot be fully specified in advance. In a traditional system, the users and requirements are known before work begins. On the web, the users are unknown until launch, the market moves weekly, and every deployed feature changes what users expect next. A complete upfront specification would be wrong before it was finished. This is why incremental and agile approaches — deliver a small usable slice, learn, then deliver the next slice — are the always rule for web-based interactive systems, and why the professor stresses they are developed and delivered incrementally, never all at once.
Worked example — one product, four web-era techniques. A company builds a new e-commerce site:
- Reuse: the team assembles the site from pre-existing components — a payment service, a product catalog system, an authentication framework — rather than writing them; frameworks like J2EE or .NET bundle many such components together.
- Incremental delivery: it is impractical to specify all requirements in advance, so the team ships increment one (browse products), learns from users, then increment two (checkout), increment three (order tracking) — using incremental and agile approaches.
- Services: the components are implemented as standalone web services — the payment service, catalog service, and auth service each expose their own API (service-oriented computing).
- Rich interfaces: the storefront is built with React or Angular to give users a rich, responsive interface.
The fundamental software engineering ideas — specification, development, validation, evolution — apply to this system exactly as they do to any other; the four web-era changes determine how those activities are organized. And because such systems keep growing, the software engineering techniques that deal with scale and complexity are increasingly relevant.
Pitfall — treating the web as a lawless exception. The web changed how software is developed, not whether software engineering applies: the fundamental ideas of software engineering are equally applicable to web-based software. A team that skips specification, validation, or architecture because "it is just a web app" builds the same expensive, unreliable software described in section 1.5 — only faster. Web systems are engineered systems; they are just engineered differently (reuse-first, incremental, service-based).
Recap + bridge: The internet made software as a service the standard delivery model (Google Apps, Office 365, Adobe; the cloud is shared linked computers — YouTube shows the ad-supported model); the web changed development in four ways — reuse became dominant (frameworks like J2EE and .NET), requirements are never fully specified in advance so delivery is always incremental and agile, systems are implemented as services (service-oriented computing), and rich interfaces are built with tools like React and Angular — while the fundamental ideas of software engineering apply equally. Next, the lecture closes the first class with the professional and ethical responsibilities of the software engineer.
Real-world & domain connection: Web and cloud systems are the largest part of today's software economy: enterprises run on cloud platforms, and companies like Google, Microsoft, and Adobe deliver their products as services. The four web-era techniques are visible daily — microservices and REST APIs (service-oriented computing), CI/CD pipelines (incremental and agile delivery), framework ecosystems like J2EE/.NET/React/Angular (reuse), and freemium and ad-supported products (the SaaS/cloud business model). The scale and complexity techniques mentioned here become central in later course topics on distributed and cloud-based software engineering.
1.24 Professional Ethics in Software Engineering
1.24.1 The Wider Responsibility
Hook: Can a skilled programmer be a bad engineer? Yes — if they ignore the wider responsibility of the profession. Software engineering is carried out inside a social and legal framework, and this final section of the lecture is about the ethical and professional duties that come with the skills.
Like other engineering disciplines, software engineering is carried out within a social and legal framework that limits the freedom of the people working in that area. As a software engineer, you must accept that your job involves wider responsibility than simply the application of technical skills like coding and testing. You must exhibit ethical and morally responsible conduct if you are to be respected as a professional engineer. You should uphold normal standards of honesty and integrity in all your professional activities, and you should not use your skills and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession or the organization.
The wider responsibility. Software engineering is carried out within a social and legal framework that limits the freedom of the people working in that area. The job involves wider responsibility than applying technical skills like coding and testing: engineers must exhibit ethical and morally responsible conduct to be respected as professionals — upholding normal standards of honesty and integrity, and never using their skills dishonestly or in ways that bring disrepute to the profession or the organization.
1.24.2 Professional Responsibility
There are areas where the standards of acceptable behavior are not bound by laws, but by the notion of professional responsibility:
- Confidentiality — you should respect the confidentiality of your employers or clients, whether or not a formal confidentiality agreement has been signed.
- Competence — you should not misrepresent your level of competence, and you should not knowingly accept work that is outside your competence.
- Intellectual property rights — you should be aware of the local laws governing the use of intellectual property, such as copyright and patents, and you should be careful to ensure that the intellectual property of employers and clients is protected at all times.
- Misuse of computer resources — you should not misuse your technical skills, from typical minor things like playing games on an employer's machine to the dissemination of malicious software.
Four areas of professional responsibility. There are areas where acceptable behavior is not bound by law but by the notion of professional responsibility:
- Confidentiality — respect the confidentiality of employers and clients, whether or not a formal confidentiality agreement has been signed.
- Competence — do not misrepresent your level of competence; do not knowingly accept work outside your competence.
- Intellectual property rights — be aware of local laws on intellectual property (copyright, patents) and protect the intellectual property of employers and clients at all times.
- Misuse of computer resources — do not misuse your technical skills, from minor things (playing games on an employer's machine) to serious ones (disseminating malicious software).
1.24.3 Professional Codes of Ethics
Professional societies and institutions have an important role to play: the ACM (Association for Computing Machinery), the IEEE (Electrical and Electronics Engineers), and the British Computer Society. They publish codes of professional conduct, or codes of ethics, and members of these organizations undertake to follow that code when they sign up for membership. These codes of conduct are generally concerned with fundamental ethical behavior. In particular, the ACM and IEEE professional associations have cooperated to produce a joint code of ethics and professional practice. The code exists both in a short form and in a longer form; the longer form adds detail and substance to the shorter version.
Professional codes of ethics. Professional societies set ethical standards: the ACM (Association for Computing Machinery), the IEEE (the professional association of electrical and electronics engineers), and the British Computer Society publish codes of professional conduct (codes of ethics), and members undertake to follow the code when they sign up for membership. These codes concern fundamental ethical behavior. Notably, the ACM and IEEE cooperated to produce a joint code of ethics and professional practice, which exists in a short form and a longer form — the longer form adds detail and substance to the shorter version. (The full code is organized around eight principles — public, client and employer, product, judgment, management, profession, colleagues, and self.)
1.24.4 Why the Code Exists
The rationale behind the code is summarized by the observation that computers have a central and growing role in commerce, industry, government, medicine, education, society, and law. Because of their roles in developing software systems, software engineers have significant opportunities to do good or harm — and to influence others to do good or harm. So engineers should adhere to the code of ethics and professional practice.
The code has a preamble, and covers several areas: the principles governing your public responsibility; your responsibility towards your clients and employers; and responsibility for the product — software engineers shall ensure that the products and related modifications meet the highest professional standards possible. It also covers professional judgment — using integrity and independence in professional judgment — and management: software engineering managers shall subscribe to and provide an ethical approach to the management of software development and maintenance.
Why the code exists, and what it covers. The rationale: computers have a central and growing role in commerce, industry, government, medicine, education, society, and law. Because of their role in developing software, engineers have significant opportunities to do good or harm — and to influence others to do good or harm — so the code of ethics and professional practice exists.
The code has a preamble and covers several areas:
- Public responsibility — principles governing your conduct toward the public;
- Clients and employers — your responsibility toward them;
- Product — software engineers shall ensure that products and related modifications meet the highest professional standards possible;
- Professional judgment — using integrity and independence in professional judgment;
- Management — software engineering managers shall subscribe to and provide an ethical approach to the management of software development and maintenance.
1.24.5 Ethics Is Concrete, Not Abstract
Ethics and professional responsibility are an increasingly important topic because software-intensive systems pervade every aspect of life. Ethics can be considered from a philosophical standpoint, where the basic principles of ethics are considered and software engineering ethics are discussed with reference to those principles. But the philosophical approach is too abstract and difficult to relate to everyday experience. A more concrete approach — the one embedded in professional codes of conduct like the ACM and IEEE codes — is best discussed in the software engineering context, and not as a separate subject in its own right. The course will look at certain ethical aspects wherever appropriate when it takes up the design and implementation of software systems.
Ethics is concrete, not abstract. Ethics can be studied philosophically — basic ethical principles, then software engineering ethics derived from them — but the philosophical approach is too abstract and hard to relate to everyday experience. The more concrete approach — the one embedded in professional codes of conduct like the ACM and IEEE codes — is best discussed within the software engineering context, not as a separate subject. The course will touch ethical aspects wherever appropriate when it takes up the design and implementation of software systems.
1.24.6 Ethical Dilemmas
There are various dilemmas one can face while adhering to the principles of ethics and codes of conduct. There could be disagreement with your employer — for example, disagreement about releasing a safety-critical system without adequate testing, or about participating in the development of military weapons or nuclear systems. You must make up your mind on these matters. The appropriate ethical questions depend on the views of the people involved; the potential for damage, the extent of the damage, and the people affected by the damage should influence the decision.
If the situation is very dangerous, it may be justified to publicize it using social media or other means. However, you should always try to resolve the situation while respecting the rights of your employer. There are many situations where both employers and employees should make their views known to each other in advance. Employees must be willing to accept any worker assignment; and if an employee is taken on and makes clear that he does not wish to work on certain systems, employers must not exert pressure to do so at a later date.
Ethical dilemmas are real. Dilemmas arise while adhering to ethics and codes of conduct — for example, disagreement with your employer about releasing a safety-critical system without adequate testing, or about participating in the development of military weapons or nuclear systems. You must make up your own mind. There are no absolutes: the appropriate ethical questions depend on the people involved, and the potential for damage, the extent of the damage, and the people affected by the damage should influence the decision. If the situation is very dangerous, publicizing it (via social media or other means) may be justified — but you should always try to resolve the situation while respecting your employer's rights. Employers and employees should make their views known to each other in advance: employers may require willingness to accept any assignment, but an employee who stated they will not work on certain systems must not be pressured to do so later.
Recap + bridge: Software engineering carries a wider responsibility than technical skill: honesty and integrity; professional responsibility in confidentiality, competence, intellectual property rights, and computer misuse; professional codes of ethics from the ACM, IEEE, and British Computer Society (joint ACM/IEEE code, short and long forms); and ethical dilemmas — releasing safety-critical systems without testing, military or nuclear work — where potential damage should guide the decision, always respecting the employer while protecting the public. This closes the lecture; the next class moves to the software process in detail.
Real-world & domain connection: Ethics is a daily professional reality: engineers routinely face pressure to ship unsafe code, to keep silent about quality problems, or to work on systems they personally oppose. Whistle-blowing cases in the software industry, security researchers deciding how to disclose vulnerabilities, and engineers choosing employers partly by the ethics of their products are all modern versions of the dilemmas described here. Codes such as the ACM/IEEE joint code give professionals a reference point — and are part of the professional framework the lecture says surrounds all engineering work.
Exam Guidance Summary
- The primary textbook is Pressman, Software Engineering — the 8th edition or the 7th edition, whichever is available.
- There is a pre-recorded courseware available on the course page ("courseware software engineering"); follow the course handout to go through the relevant courseware at leisure. It covers the entire content of the course. The class sessions complement the courseware with examples and discussions.
- The syllabus for the exams includes both the topics covered in the class and the topics covered in the courseware, along with whatever relevant chapters from the textbook are concerned.
- Announcements will be made about the chapters to be studied for the mid-semester test and various components as the course progresses.
- The course has no programming assignments and no focus on any specific programming language (like Python); some code examples appear as part of design, implementation, and testing.
- Exam note: expect the good-fast-cheap triple constraint to keep recurring — it is "the pivot of our discussions" throughout the course. Be ready to explain the three constraints and the Venn diagram's center.
- Exam note: be ready to name the four fundamental activities of the software process — specification, development, validation, and evolution — and the four fundamental notions that underlie all professional software development: a managed process, dependability and performance, requirements management, and reuse-oriented development.
- Exam note: know the essential attributes of good software (functionality, maintainability, dependability, usability; also named in the recap as maintainability, dependability and security, efficiency, acceptability), the generic vs customized (bespoke) product distinction, and who controls the specification in each case.
- Exam note: the exam syllabus covers the topics discussed in class plus the courseware and the relevant Pressman textbook chapters; ethics topics from the class are part of the syllabus along with the courseware.
- The course roadmap going forward: software processes, then requirements engineering, architectural design, detailed design, implementation, testing and validation, evolution, and some aspects of software project management toward the end.
Key Industry Applications
- Real-world: society runs on software — national systems, manufacturing automation, financial systems and stock markets, and digital entertainment (music, computer games, films, television).
- Real-world: generic software products are produced by organizations like Microsoft and Google and sold in the open market — mobile apps, desktop applications, software tools, and vertical products like Tally accounting systems for banking, library information systems, and hospital accounting.
- Real-world: customized (bespoke) systems — control systems for electronic devices, ERP applications, and air traffic applications — are commissioned by a specific customer who controls the specification.
- Real-world: enterprise resource planning (ERP) products such as SAP and Oracle are the best example of a generic product base adapted to a company's business rules, processes, and reports.
- Real-world: software as a service is the standard delivery model — Google Apps, Office 365, Adobe products; YouTube shows the ad-supported free-access model; a computing cloud is a huge number of linked computer systems shared by many users.
- Real-world: web development assembles systems from pre-existing components bundled in frameworks like J2EE and .NET; rich web interfaces are built with tools like React and Angular; systems are implemented as standalone web services (service-oriented computing).
- Real-world: embedded control systems are everywhere — mobile phones, car braking systems, microwave ovens — and safety-critical embedded failures can force recalls of sold vehicles.
- Real-world: batch processing runs payroll, electricity billing, and phone billing on a periodic basis; travel expense claims submitted through a web application are processed in a batch for monthly payment.
- Real-world: big data systems collect data from remote sensors (e.g., weather information systems) and run cloud-based statistical analysis to find relationships in collected data.
- Real-world: professional societies — the ACM, the IEEE, and the British Computer Society — publish codes of professional conduct and ethics that members undertake to follow.
SE Lecture 1 notes · Introduction to Software Engineering
Sections Breakdown
Software runs society — national systems, manufacturing, finance, and digital entertainment all depend on it — and software represents a significant, growing fraction of every country's GNP, which is why software engineering matters.
Software is abstract and intangible — bound by no physical laws, materials, or manufacturing processes — so its potential is unlimited, but the same lack of constraints lets complexity grow until systems become hard to understand and expensive to change.
Software systems range from simple embedded systems to worldwide cloud information systems, so there are no universal notations, methods, or techniques — different types of systems require different development approaches, though all need software engineering.
The good–fast–cheap triple constraint is the pivot of the course: it is very hard to achieve all three at once, the sweet spot at the center of the Venn diagram is a dream for most projects, and every software engineering decision is ultimately a trade-off among the three.
Software project failures are mainly a consequence of two factors: increasing system complexity (expectations and scale keep rising) and software engineering methods not applied rigorously (companies drift into development without discipline), not of software engineering being inadequate.
Personal software development (business spreadsheets, scientific data processing, hobby programs) differs from professional software development, where teams develop software for other people and maintain and change it throughout a long useful lifetime; software engineering supports the professional setting.
Software is not just programs: it also includes associated documentation, libraries, supporting websites, and configuration data that make the programs useful; a professional system is often several programs plus these parts, which is a key difference from amateur development.
Software products come in two types: generic products sold on the open market with the developer controlling the specification, and customized (bespoke) products commissioned for one customer who controls the specification; the boundary is blurring as systems are built on a generic base (like ERP systems) and adapted to customers.
Good software delivers the required functionality and performance and is maintainable (adaptable to change), dependable (reliable, safe, secure), and usable; the recap names maintainability, dependability and security, efficiency, and acceptability — and the specific attribute priorities depend on the application.
Software engineering is an engineering discipline concerned with all aspects of software production, from early system specification through to maintaining the system long after it has gone into use; it is a systematic and quantitative approach built on four activities: specification, development, validation, and evolution.
Computer science provides the theory and fundamentals; software engineering is the larger discipline that builds on it to deliver useful software within real-world constraints; systems engineering covers all aspects of computer-based systems, with software engineering as a part of it.
The key challenges are coping with increasing diversity in technology and platforms, meeting reduced delivery times (customers want products 'one month ago'), and developing trustworthy, dependable software within time and budget.
Roughly 50% of software costs are development and 40% are testing during development (references: ~60/40); evolution (maintenance) costs often exceed development costs — the iceberg analogy — and a defect found in production can cost a thousand times more than the same defect fixed during requirements.
Because software varies widely, there is a menu of methods — agile, plan-driven, incremental, reuse-oriented — and no single one-size-fits-all solution; cloud-based development changed deployment (software as a service) and web-based development changed the discipline.
Quality of professional software includes what the software does, its behavior while executing, and the structure and organization of programs and documentation — reflected in reliability, safety, usability, maintainability, performance, and code understandability; the dominant property depends on the application.
Engineers make things work: they apply theories, methods, and tools selectively, deliver solutions even without applicable theory, work within organizational and financial constraints toward the good-fast-cheap goal (sometimes compromising — engineers may not be perfectionists), and adopt a systematic, organized approach, choosing the method for the situation.
Software engineering is important because society depends on software (so we must produce reliable and trustworthy systems economically) and because using systematic methods is cheaper in the long run — failing to do so raises testing, quality-assurance, and long-term maintenance costs; do things right the first time.
The software process is a sequence of activities leading to the production of a software product; the four fundamental activities common to all processes are software specification, development, validation, and evolution, organized differently depending on the type of system.
The challenges ahead are heterogeneity of environments (mixed devices, legacy integration), business and social change (faster delivery of value), security and trust, scalability from nano embedded to internet-scale clouds, and the need for new tools and creative combinations of existing methods.
Application types include standalone, interactive transaction-based, embedded control, batch processing, digital entertainment, scientific modeling and simulation, data collection/big data, and systems of systems; boundaries blur and each type requires specialized engineering techniques.
Four fundamentals apply to all software systems: a managed, understood development process; dependability and performance; understanding and managing requirements; and reuse wherever appropriate — these are the themes of the course and are independent of programming language.
Reuse is standard in other engineering fields (IC chips, wheels), but software developers hesitate to reuse components; students prefer their own code because they do not understand others', while industry assembles existing components to deliver faster and cheaper; reuse-oriented development is one of the four course themes.
Software as a service is the standard delivery model (Google Apps, Office 365, Adobe); a computing cloud is linked computer systems shared by users (YouTube: ad-supported); the web changed development via dominant reuse (J2EE, .NET), incremental/agile delivery, service-oriented components, and rich interfaces (React, Angular).
Software engineering carries wider responsibility than technical skill: honesty and integrity, professional responsibility (confidentiality, competence, intellectual property rights, computer misuse), codes of ethics from ACM/IEEE/BCS, and ethical dilemmas such as releasing safety-critical systems without adequate testing.
Exam guidance: Pressman textbook (7th/8th edition), courseware covering the whole course, syllabus covering class topics plus courseware plus textbook chapters, no programming assignments or language focus, recurring good-fast-cheap constraint, four process activities, four fundamental notions, and the essential attributes of good software.
Named industry applications: society runs on software; generic products from Microsoft, Google, Tally; bespoke systems; ERP adaptation by SAP and Oracle; software as a service (Google Apps, Office 365, Adobe) and ad-supported clouds (YouTube); web frameworks J2EE/.NET and interfaces React/Angular; embedded systems; batch payroll and billing; big data from sensors; codes of ethics from ACM, IEEE, and BCS.
Exam Revision Notes
Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.
Software Is Everywhere
Must-know: Software is essential to the functioning of society: national systems, electrical products, manufacturing, finance, and entertainment all run on software; software is a significant fraction of GNP and maintenance over a long lifetime costs more than development.
⚠️ Top pitfall: Underestimating software as a minor component of an automation project; in reality software costs often dominate and its long-life maintenance exceeds development cost.
Self-check: Name three systems in everyday life that depend on software, and state why maintenance dominates software cost.
Connects to: Software Is Abstract and Intangible, The Costs of Software
Software Is Abstract and Intangible
Must-know: Software is not constrained by physical laws or manufacturing processes; the lack of physical constraints lets software become extremely complex, difficult to understand, and expensive to change — changing one module affects the rest of the system.
⚠️ Top pitfall: Assuming that because software is free of physical limits it is easy to build; in reality the same freedom produces unmanageable complexity and costly ripple effects.
Self-check: Why can software become complex without any physical warning, and what is the consequence of changing one module?
Connects to: Software Is Everywhere, The Costs of Software, Quality of Professional Software
Different Software Systems Need Different Approaches
Must-know: There are no universal software engineering methods: different types of software (embedded, information systems, games) need different approaches, methods, techniques, and tools.
⚠️ Top pitfall: Applying one methodology to every project regardless of system type; rigid processes hurt agile projects and loose processes endanger safety-critical ones.
Self-check: Why can there be no universal software engineering technique, and what do all systems still need?
Connects to: The Triple Constraint: Good, Fast, Cheap, Application Types
The Triple Constraint: Good, Fast, Cheap
Must-know: Good, fast, cheap form a triple constraint; the sweet spot at the center of the Venn diagram where all three overlap is usually a dream for projects; every engineering decision is a trade-off among the three, and the constraint recurs throughout the course.
⚠️ Top pitfall: Assuming the center of the Venn diagram — good, fast, and cheap simultaneously — is the normal case rather than the exception.
Self-check: Why is it very hard to be good, fast, and cheap at the same time, and what does the professor call the pivot of the whole course?
Connects to: Attributes of Good Software, The Costs of Software, Engineers Make Things Work
Software Project Failures and Their Two Causes
Must-know: Failures of software projects have two main causes: increasing system complexity and failure to use software engineering methods rigorously; better education and training are part of the answer.
⚠️ Top pitfall: Companies (even manufacturers) drifting into software development without rigorous methods, producing software that is more expensive and less reliable than it should be.
Self-check: What are the two causes of software project failures given in this section?
Connects to: Software Is Everywhere, Software Engineering Challenges Ahead
Professional vs Personal Software Development
Must-know: Professional software development is characterized by teams, use by people other than the developer, and constant maintenance and change over the software's lifetime; software engineering supports professional rather than personal programming.
⚠️ Top pitfall: Building professional software the way one writes personal scripts — without specification, design, or regard for other users and changers of the code.
Self-check: What distinguishes professional software development from personal programming?
Connects to: What Software Really Is, What Is Software Engineering?
What Software Really Is
Must-know: Software includes programs plus documentation (system and user), libraries, supporting websites, and configuration data; professional systems are more than a single program.
⚠️ Top pitfall: Believing 'the code is the software'; professional delivery requires documentation, configuration, and user guidance alongside the programs.
Self-check: What parts make up a software system besides the programs themselves?
Connects to: Professional vs Personal Software Development, Software Products: Generic vs Customized
Software Products: Generic vs Customized
Must-know: Generic products: developed by an organization, sold on the open market, developer controls the specification. Customized (bespoke): commissioned for a particular customer, customer controls the specification. The boundary blurs when a generic base (e.g., SAP, Oracle ERP) is adapted to a customer.
⚠️ Top pitfall: Confusing who builds the software with who controls the specification; the deciding distinction is control of the specification.
Self-check: What is the critical distinction between generic and customized software products?
Connects to: What Software Really Is, Attributes of Good Software, Web-Based and Cloud-Based Systems
Attributes of Good Software
Must-know: Essential attributes of good software: required functionality and performance, maintainability (adaptable to changing requirements), dependability (reliable, safe, secure), and usability; the recap adds efficiency and acceptability; the specific set of attributes depends on the application (air traffic control: safe; video game: responsive; telephone network: reliable).
⚠️ Top pitfall: Ranking all quality attributes equally in every project instead of letting the application set the priority.
Self-check: What are the essential attributes of good software, and which attribute dominates for an air traffic control system?
Connects to: The Triple Constraint: Good, Fast, Cheap, Quality of Professional Software
What Is Software Engineering?
Must-know: Software engineering = an engineering discipline concerned with all aspects of software production, from early specification through long-term maintenance; two key terms: engineering discipline, all aspects of production (including project management and tool development); systematic and quantitative approach; four main activities: specification, development, validation, evolution.
⚠️ Top pitfall: Reducing software engineering to programming; it includes managerial, organizational, economical, and business aspects as well as tools, methods, and theories.
Self-check: What are the two important terms in the definition of software engineering, and what are the four main activities?
Connects to: Software Engineering vs Computer Science vs Systems Engineering, Engineers Make Things Work, The Software Process
Software Engineering vs Computer Science vs Systems Engineering
Must-know: CS provides theory and fundamentals (algorithms, data structures); SE builds on CS and covers the practicalities of delivering useful software within budget, time, and quality constraints plus organizational/social requirements; Systems engineering covers all aspects of computer-based systems (hardware, software, networking, process) and SE is part of it.
⚠️ Top pitfall: Drawing sharp fences between the disciplines; they are nested — SE builds on CS and is part of systems engineering.
Self-check: How does software engineering relate to computer science and to systems engineering?
Connects to: What Is Software Engineering?, Engineers Make Things Work
Key Challenges Facing Software Engineering
Must-know: Key challenges: (1) coping with increasing diversity in technology and platforms and new demands; (2) reduced delivery times — deadlines feel like 'one month ago'; (3) developing trustworthy software that is dependable — alongside good quality within time and budget.
⚠️ Top pitfall: Treating the three challenges in isolation; they compound (fast delivery without trust produces crashing software that is costlier later).
Self-check: What are the key challenges facing software engineering?
Connects to: The Triple Constraint: Good, Fast, Cheap, The Costs of Software, Software Engineering Challenges Ahead
The Costs of Software
Must-know: Cost split: 50% development, 40% testing during the development phase (references: ~60/40); evolution cost often exceeds development costs; iceberg analogy (visible tip = development, submerged mass = maintenance); the same defect costs about a thousand times more when found in production than at requirements time.
⚠️ Top pitfall: Assuming project cost ends at delivery; maintenance/evolution dominates total cost, and late-found bugs multiply cost enormously.
Self-check: What are the approximate proportions of development and testing cost, and what does the iceberg analogy represent?
Connects to: Software Is Everywhere, Why Software Engineering Is Important, The Triple Constraint: Good, Fast, Cheap
Software Engineering Methods: No One-Size-Fits-All
Must-know: There is no one-size-fits-all method: agile, plan-driven, incremental, and reuse-oriented methods each suit different kinds of software; cloud and web changed deployment to software as a service.
⚠️ Top pitfall: Choosing a method by fashion rather than fitness for the system type.
Self-check: Name the families of software engineering methods and which change cloud/web brought to deployment.
Connects to: Different Software Systems Need Different Approaches, The Software Process, Web-Based and Cloud-Based Systems
Quality of Professional Software
Must-know: Quality includes function, behavior while executing, and structure/organization of programs and documentation; properties: reliability, safety, usability, maintainability, performance (response time), understandability of code; the specific set depends on application (air traffic: safe; game: responsive; phone network: reliable); essentials: maintainability, dependability, efficiency, acceptability.
⚠️ Top pitfall: Judging quality only by whether the software runs; structure and runtime behavior are part of professional quality.
Self-check: What does quality include beyond what the software does, and which property dominates for a telephone network?
Connects to: Attributes of Good Software, What Software Really Is, The Costs of Software
Engineers Make Things Work
Must-know: Engineers make things work: use theories/methods/tools selectively; solve problems even with no applicable theory; work within organizational and financial constraints; goal is good quality within schedule and budget (good-fast-cheap), often requiring compromise — engineers may not be perfectionists; hallmark of engineering is a systematic, organized approach; engineering selects the most appropriate method for the circumstances.
⚠️ Top pitfall: Perfectionism — refusing to compromise on 'good' while ignoring schedule and budget; engineering requires delivering required quality within constraints.
Self-check: Why may engineers not be perfectionists, and what is the hallmark of engineering?
Connects to: The Triple Constraint: Good, Fast, Cheap, What Is Software Engineering?, Software Engineering Methods: No One-Size-Fits-All
Why Software Engineering Is Important
Must-know: Two reasons software engineering matters: (1) society relies on software, so we need reliable and trustworthy systems produced economically; (2) it is cheaper in the long run to use systematic software engineering methods — skipping them raises testing, QA, and long-term maintenance costs; better to do things right the first time than fix bugs later.
⚠️ Top pitfall: Assuming bugs can simply be fixed later; fixing a defect much later is enormously more expensive.
Self-check: What are the two reasons software engineering is important?
Connects to: Software Is Everywhere, The Costs of Software, The Software Process
The Software Process
Must-know: Software process = sequence of activities leading to production of a software product; four fundamental activities: specification, development, validation, evolution; different systems organize them differently (real-time/embedded: complete specification and verification before development; interactive/web: concurrent specification and development).
⚠️ Top pitfall: Assuming one universal process order; the four activities are constant but their organization depends on system type.
Self-check: What are the four fundamental activities of every software process?
Connects to: What Is Software Engineering?, Software Engineering Methods: No One-Size-Fits-All, Engineers Make Things Work
Software Engineering Challenges Ahead
Must-know: Challenges: (1) heterogeneity — distributed systems across different devices, legacy systems; (2) business and social change — rapidly deliver software of value; (3) security and trust — protect from malicious attacks, maintain information security, avoid hazard; (4) scalability — from micro/nano embedded to internet-scale cloud systems; (5) new tools and creative combinations of existing techniques.
⚠️ Top pitfall: Waiting for a single 'silver bullet' technique; the challenges require new tools plus creative combinations and a broad professional perspective.
Self-check: Name the key challenges software engineering faces ahead.
Connects to: Key Challenges Facing Software Engineering, Web-Based and Cloud-Based Systems
Application Types
Must-know: Eight application types: standalone; interactive transaction-based (e-commerce, large data store per transaction); embedded control (most numerous; phone, car braking, microwave); batch processing (payroll, billing); digital entertainment (interaction quality, response time); scientific modeling and simulation (computationally intensive, parallel); data collection/big data (sensors, cloud analytics); systems of systems (enterprise, composed of other systems). Boundaries blur; each type needs specialized engineering.
⚠️ Top pitfall: Applying one development approach to every type: embedded safety-critical systems must be verified thoroughly before build (recall risk), web systems use iterative delivery with reusable components, systems of systems need detailed upfront specification of interactions.
Self-check: What are the main application types, and why does an embedded car system need verification before it is built?
Connects to: Different Software Systems Need Different Approaches, The Software Process, Fundamentals That Apply to All Systems
Fundamentals That Apply to All Systems
Must-know: Four fundamentals for all systems: (1) managed and understood development process (customer first asks cost and delivery time); (2) dependability and performance (behave as expected, available, safe, secure, efficient); (3) understanding and managing requirements/specification (basis of design, testing, validation, acceptance; requirements engineering); (4) reuse wherever appropriate.
⚠️ Top pitfall: Building from scratch out of distrust of reused software; reuse is a fundamental and reinventing the wheel wastes resources and time.
Self-check: What are the four fundamentals that apply to all software systems?
Connects to: The Software Process, Reuse-Oriented Development
Reuse-Oriented Development
Must-know: Reuse is extensive in other engineering fields (IC chips; automobile built without redesigning the wheel); software developers hesitate to reuse because they do not understand others' code; in industry, assembling existing components delivers faster and cheaper; reuse-oriented development is one of the four course themes; no programming assignments and no specific language in this course.
⚠️ Top pitfall: Preferring to write everything from scratch because of the trust risk of reuse; in industry this makes delivery slower and costlier.
Self-check: Why do college students prefer writing their own code, and what is the industry approach to reuse?
Connects to: Fundamentals That Apply to All Systems, Web-Based and Cloud-Based Systems
Web-Based and Cloud-Based Systems
Must-know: Software as a service is the standard delivery approach for web systems (Google Apps, Office 365, Adobe); a computing cloud is a huge number of linked computer systems shared by users — pay-per-use or ad-supported (YouTube); web changed development: (1) reuse dominant, assembled from pre-existing components in frameworks like J2EE/.NET; (2) requirements impractical to specify in advance — always incremental and agile; (3) service-oriented computing with standalone web services; (4) rich interfaces via React, Angular.
⚠️ Top pitfall: Treating the web as an exception where software engineering does not apply; fundamentals apply equally, and web systems must be engineered (reuse-first, incremental, service-based).
Self-check: What is software as a service, and what are the four ways the web changed software development?
Connects to: Software Engineering Methods: No One-Size-Fits-All, Reuse-Oriented Development, Software Engineering Challenges Ahead
Professional Ethics in Software Engineering
Must-know: Ethical behavior: honesty and integrity; professional responsibility: confidentiality, competence, intellectual property rights, misuse of computer resources; codes of ethics by ACM, IEEE, British Computer Society (joint ACM/IEEE code, short and long forms); dilemmas: releasing safety-critical systems without testing, military/nuclear work; potential damage, extent, and people affected guide the decision.
⚠️ Top pitfall: Reducing professional behavior to following the law; areas like confidentiality, competence, and IP protection are governed by professional responsibility even without formal agreements.
Self-check: What are the four areas of professional responsibility, and which bodies publish codes of ethics?
Connects to: Engineers Make Things Work, Attributes of Good Software
Exam Guidance Summary
Must-know: Primary textbook Pressman (7th or 8th edition); syllabus covers class topics, courseware, and relevant textbook chapters; no programming assignments; the triple constraint, the four process activities (specification, development, validation, evolution), the four fundamental notions (managed process, dependability and performance, requirements management, reuse-oriented development), and the essential attributes of good software are examinable.
⚠️ Top pitfall: Assuming the exam only covers class topics; the syllabus also includes courseware and relevant textbook chapters.
Self-check: What does the exam syllabus cover, and what is the course roadmap?
Connects to: The Triple Constraint: Good, Fast, Cheap, The Software Process, Attributes of Good Software, What Is Software Engineering?, Reuse-Oriented Development, Professional Ethics in Software Engineering
Key Industry Applications
Must-know: Named applications: Microsoft/Google generic products, Tally; SAP/Oracle ERP adaptation; SaaS with Google Apps, Office 365, Adobe; YouTube ad-supported model; J2EE/.NET frameworks, React/Angular interfaces; embedded systems and recalls; batch payroll/billing; weather sensor big data; ACM/IEEE/BCS codes of ethics.
⚠️ Top pitfall:
Self-check: Which products exemplify software as a service, and which are generic-adapted ERP examples?
Connects to: Software Products: Generic vs Customized, Application Types, Web-Based and Cloud-Based Systems, Professional Ethics in Software Engineering
Was this lecture useful?
BitsNotes AI Assistant
Subject Notes AssistantConfigure AI Chat
Choose how to access the chatbotSigned in as
Powered by BitsNotes — 20 messages per day. No API key needed. Want unlimited access? Use "Bring Your Own Key" mode.
Sign in to use AI Chat
Get 20 free AI messages per day to ask questions about your lecture notes. Sign in with Google or GitHub — it takes 5 seconds.
Sign In to BitsNotesSwitch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.