Unit 1: Introduction [4 Hours]
This unit lays the foundation of the entire course. Before learning how to build software properly, you need to know what software actually is, what makes it good, why it costs what it costs, and what makes software engineering different from just "writing code."
1.1 Definition of Software
Core Definition
Software is a collection of executable programs, the data structures that enable the programs to manipulate information, and the documentation that describes the operation and use of the programs.
Software is not just the code you write. It is the program, plus all the data it works with, plus the manuals and documents that explain how to use it. If any one of these three is missing, you don't really have a complete piece of software, you have a fragment of one.
Detailed Explanation
Software exists in two broad forms inside this definition:
Programs → the instructions (code) that, when executed, produce the desired function and performance.
Data structures → the information the program needs to store, access, and process to behave correctly.
Documentation → user manuals, technical specs, and design documents that describe how the software was built and how to operate it.
Software is intangible: you cannot touch it the way you touch a circuit board. It is also logical rather than physical, which is why it behaves and fails very differently from hardware. A hardware fault is usually a physical defect; a software fault is almost always a design or logic flaw.
Common Mistake
Students often equate "software" with "the program" alone. In exams, forgetting to mention data and documentation as parts of software is a common reason marks are cut, since the standard definition explicitly includes all three.
Summary
- Software = programs + data structures + documentation.
- It is intangible and logical, not physical like hardware.
- Missing any one component means the software is incomplete.
One-Liner Revision
Software is programs plus data plus documentation, working together to deliver a function.
1.2 Type of Software
Core Definition
Software is classified into different types based on the function it performs and the domain it serves, ranging from low-level system control programs to complex, intelligent applications.
Not all software does the same job. Some software runs your computer in the background (like an operating system), some helps you do a specific task (like a calculator app), and some controls machines you don't even see, like the chip inside a washing machine.
Detailed Explanation
The major categories of software are explained below.
System software → a collection of programs written to service other programs. It manages internal resources (memory, processors, devices) and provides a platform for application software to run on. Example: operating systems, compilers, device drivers.
Application software → standalone programs that solve a specific business or personal need and directly process data for the user. Example: payroll systems, billing software, word processors.
Engineering and scientific software → software built for number-crunching algorithms, simulations, and analysis in technical domains. Example: CAD systems, orbital simulation software, weather forecasting models.
Embedded software → software placed inside hardware to control and manage features of the device from read-only memory. Example: software inside a microwave keypad or an automobile dashboard.
Product-line software → software built once and configured for use by many different customers with specific capabilities, focused on a limited marketplace. Example: inventory management products sold to different retail chains.
Web/mobile applications → network-centric software spanning a wide array of applications, from simple webpages to complex, content-rich and computation-intensive applications running across browsers or devices.
Artificial intelligence software → software that uses non-numerical algorithms to solve problems not easily handled by direct computation, such as pattern recognition, reasoning, and decision-making. Example: robotics control software, expert systems.
Let's Break It Down
Think of a smartphone: the Android OS underneath is system software running the show, your camera app is application software doing one job for you, the chip-level firmware inside the fingerprint sensor is embedded software, and the face-unlock feature using pattern recognition is a small slice of AI software, all coexisting in one device.
| Type | Purpose | Example |
|---|---|---|
| System software | Manages hardware and provides platform for other software | Windows OS, Linux kernel |
| Application software | Solves a specific user/business need | MS Word, billing software |
| Engineering/scientific software | Number-crunching, simulation, analysis | CAD tools, weather models |
| Embedded software | Controls features of a hardware device | Microwave keypad firmware |
| Product-line software | One core product configured for many customers | POS systems for retail chains |
| Web/mobile applications | Network-centric, browser/device-based software | Online banking apps |
| AI software | Solves problems using non-numerical/pattern-based logic | Chess engines, expert systems |
Test Yourself
- Why is an operating system classified as system software and not application software?
- Give one example of embedded software and explain why it fits that category.
Answers: 1) Because it manages internal hardware resources and provides a platform for other programs, rather than directly solving a user-facing task.
2) The firmware inside a car's dashboard display; it is embedded into ROM and controls a specific hardware feature, not used as a standalone program.
Summary
- Software types are classified by function and domain: system, application, engineering/scientific, embedded, product-line, web/mobile, and AI software.
- System software supports other software; application software serves the end user directly.
- Embedded software lives inside hardware devices in ROM.
- AI software handles problems that resist direct numerical computation.
One-Liner Revision
Software types range from system-level managers to user-facing applications to AI-driven, embedded, and domain-specific programs.
1.3 Characteristic of Software
Core Definition
The characteristics of software are the properties that distinguish it from physical products: it is engineered rather than manufactured, it does not wear out, and most of it is custom-built rather than assembled from ready-made parts.
Software behaves nothing like a physical product such as a car or a phone. These three characteristics explain why software fails differently, ages differently, and gets built differently than hardware.
Detailed Explanation
Software is developed or engineered, it is not manufactured in the classical sense. Hardware production has a manufacturing phase where defective units occur due to material or process variation. In software, the engineering cost is concentrated in design and development. Once a correct version is built, copies can be reproduced with no quality variation, unlike hardware units rolling off an assembly line.
Software does not wear out. A physical part degrades with friction, heat, and time. Software has no moving parts to physically erode. However, software does experience deterioration through repeated changes: as new features are patched in over years, defects accumulate and the original design erodes, a problem known as software ageing or "decay due to change," which is different from hardware wear.
Most software continues to be custom-built rather than assembled from existing components. In hardware engineering, components are standardized and combined (chips, resistors, connectors), so reuse is the norm. In software, while component-based development and reusable libraries are growing, large parts of most systems are still written from scratch because requirements differ project to project.
Let's Break It Down
Imagine two identical cars: the moment they roll off the factory line and start being driven, both wear down from friction and heat regardless of how careful the owner is. Software is the opposite: install the same app on a thousand phones and none of them "wear out" from use, but if you keep stacking patches and feature changes onto it for ten years without proper redesign, it slowly becomes fragile and bug-prone, not from use, but from change.
Common Mistake
Students often write "software wears out over time" as if it were identical to hardware wear. The correct point is that software does not physically wear out; what happens instead is deterioration through change (bugs introduced by repeated modification), which examiners specifically look for.
Summary
- Software is engineered, not manufactured on an assembly line.
- Software does not wear out physically, but it deteriorates through repeated change.
- Most software is still custom-built, though component reuse is increasing.
One-Liner Revision
Software is built, not made; it ages through change, not friction; and it is mostly custom, not assembled.
1.4 Attributes of Good Software
Core Definition
Good software must deliver the required functionality and performance to the user while remaining maintainable, dependable, efficient, and usable.
Good software is not just software that "works once." It has to keep working as it gets older, behave safely even when something goes wrong, run without wasting resources, and be easy enough for real people to actually use.
Detailed Explanation
Maintainability → software must be written so that it can evolve to meet the changing needs of customers. This means it should be easy to understand, modify, and extend without breaking existing functionality.
Dependability and security → software must be trustworthy. It should not cause physical or economic damage in the event of a failure, and malicious users should not be able to access or damage the system. This covers reliability, safety, and security together.
Efficiency → software should not waste system resources such as memory, processor cycles, and storage. It must respond within an acceptable time and use resources economically.
Acceptability/Usability → software must be usable by the actual class of users it is built for, meaning it should be understandable, compatible with other systems they use, and not unreasonably slow or awkward to operate.
Beyond these four core attributes, well-built software is also expected to be portable (works across platforms with minimal change) and reusable (components can be used in other systems without rewriting).
| Attribute | What it means |
|---|---|
| Maintainability | Easy to modify and extend as requirements change |
| Dependability & security | Reliable, safe, and resistant to misuse or attack |
| Efficiency | Economical use of memory, processing time, and storage |
| Acceptability/Usability | Understandable and usable by its intended users |
Test Yourself
- Why are dependability and security grouped together as one attribute rather than two separate ones?
- Give an example where software could be efficient but still fail the acceptability attribute.
Answers: 1) Because both relate to trust, software that is unreliable and software that is insecure both ultimately fail to protect the user or system from harm, so they are treated as one combined quality concern.
2) A banking app that processes transactions extremely fast but has a confusing interface that ordinary, non-technical customers cannot operate; it is efficient but not acceptable to its target users.
Summary
- Four essential attributes: maintainability, dependability/security, efficiency, and acceptability.
- Portability and reusability are additional desirable qualities.
- Good software balances technical quality with real-world usability.
One-Liner Revision
Good software is maintainable, dependable, efficient, and acceptable to its users.
1.5 Definition of Software Engineering
Core Definition
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 after it has gone into use.
Software engineering is not just "writing code." It is the entire disciplined process of planning, designing, building, testing, and maintaining software in a way that is reliable and economical.
Detailed Explanation
Two complementary definitions are usually quoted:
IEEE definition → the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches.
Sommerville's definition → an engineering discipline concerned with all aspects of software production.
Two key ideas sit inside these definitions. First, it is an engineering discipline, meaning engineers apply theories, methods, and tools selectively and appropriately, using judgment about cost and schedule rather than blindly following one technique. Second, it covers all aspects of production, not just coding: this includes project management, requirements engineering, design, implementation, testing, and ongoing maintenance.
Common Mistake
A frequent exam error is defining software engineering as simply "writing programs using engineering principles." The correct emphasis is that it covers the entire production lifecycle, including specification and maintenance, not coding alone.
Summary
- Software engineering applies a systematic, disciplined approach to building software.
- It spans the full lifecycle: specification, design, implementation, testing, and maintenance.
- It is an engineering discipline, requiring judgment about cost, schedule, and method, not blind rule-following.
One-Liner Revision
Software engineering is the disciplined, systematic application of engineering principles across the entire life of a software product.
1.6 Software Engineering Costs
Core Definition
Software engineering costs refer to how the total budget of a software project is distributed across its activities, typically split between development costs and maintenance costs, with maintenance frequently consuming the larger share over a system's lifetime.
Building software is not where the spending stops. Most of the money in a software project's life is actually spent after it is delivered, fixing bugs, adding features, and adapting it to new needs.
Detailed Explanation
Costs in software engineering split into two broad phases:
Development costs → spent on requirements analysis, design, implementation (coding), and testing before the system is delivered to the customer.
Maintenance costs → spent after delivery, on correcting defects, adapting the system to new environments, and enhancing it with new functionality. For most long-lived systems, maintenance costs exceed development costs [verify], since software is used and modified for years after its initial release.
Within development itself, cost is not spread evenly across activities. Testing and validation typically consume a disproportionately large share compared to actual coding, because finding and fixing defects late in development is far more expensive than fixing them early. This gives the rough cost order: → requirements/design → implementation (coding) → testing/validation, with testing often costing more than coding alone.
| Cost area | What it covers |
|---|---|
| Development cost | Requirements, design, coding, and testing before delivery |
| Maintenance cost | Bug fixes, adaptation, and enhancement after delivery |
| Testing/validation cost | Often the single largest activity-level cost within development |
Test Yourself
- Why does maintenance often cost more than the original development of a software system?
- Why is testing usually more expensive than coding within the development phase?
Answers: 1) Because the system continues to be used, fixed, and extended for many years after release, and the cumulative cost of those changes adds up beyond the original build cost.
2) Because thoroughly finding and fixing defects requires extensive effort across many test cases and scenarios, and the later a defect is caught, the more expensive it is to trace and correct.
Summary
- Costs split into development costs and post-delivery maintenance costs.
- Maintenance often exceeds development cost over a system's full lifetime.
- Within development, testing/validation is typically more expensive than coding itself.
One-Liner Revision
Most software spending happens after delivery, in maintenance, not during the original build.
1.7 Key Challenges that Software Engineering is Facing
Core Definition
The key challenges facing software engineering today are heterogeneity, the pace of business and social change, security and trust, and the demand to build systems at both very large and very small scales.
Building software today is harder than it used to be, because software now has to run everywhere, adapt to fast-changing demands, stay safe from attackers, and work whether it's a tiny app or a massive system serving millions.
Detailed Explanation
The heterogeneity challenge → modern software must run across a huge range of platforms, operating systems, and devices, and must operate as distributed systems across networks that include different kinds of computers and mobile devices. Engineers must design systems flexible enough to handle this diversity rather than assuming one fixed environment.
The business and social change challenge → businesses and society now change at a much faster pace than before, meaning software must be developed and delivered quickly, and must be capable of rapidly changing to meet new requirements. This pushes software engineering toward more agile, iterative approaches instead of long, fixed development cycles.
The security and trust challenge → since software underpins critical aspects of daily life, from banking to communication, it must be demonstrably trustworthy. Users need confidence that the software is secure and that it will not be compromised by attackers, which makes building in security from the start essential rather than optional.
The scale challenge → software engineering must support an enormous range of scales, from very large, enterprise-wide systems serving millions of users, down to small, resource-constrained software embedded in everyday devices. A single set of techniques does not work efficiently across this entire range, so methods must adapt to the scale of the system being built.
Let's Break It Down
Think of a ride-sharing app: it has to run on countless different phone models (heterogeneity), update its pricing and features every few weeks as the market shifts (business and social change), protect millions of users' payment and location data from attackers (security and trust), and somehow work the same whether it's serving a city of ten million people or being tested on a single developer's laptop (scale).
Test Yourself
- How does the heterogeneity challenge differ from the scale challenge?
- Why has the business and social change challenge pushed software engineering toward agile approaches?
Answers: 1) Heterogeneity is about handling diverse platforms, devices, and networks at once, while scale is about handling a wide range of system sizes, from very small to very large; one is about diversity, the other is about magnitude.
2) Because requirements now change faster than traditional, long-cycle development can accommodate, so software must be built and adapted quickly and iteratively to stay relevant.
Summary
- Four key challenges: heterogeneity, business and social change, security and trust, and scale.
- Heterogeneity demands software that works across diverse platforms and networks.
- Rapid business change pushes engineering toward fast, iterative delivery.
- Security and trust, plus the need to handle both huge and tiny systems, define modern engineering pressure.
One-Liner Revision
Modern software engineering must handle diverse platforms, fast change, security threats, and extreme scale, all at once.
1.8 System Engineering and Software Engineering
Core Definition
System engineering is concerned with all aspects of computer-based systems development, including hardware, software, and process engineering, and treats software engineering as one specialized part of that larger process focused specifically on the software component.
A computer-based system is rarely just software. It also includes hardware, people, and processes. System engineering looks at the whole picture; software engineering is the slice of that picture concerned only with the software part.
Detailed Explanation
System engineers are involved in system specification, architectural design, integration, and deployment, working across multiple disciplines including hardware engineering, software engineering, and process engineering. Software engineers, by contrast, are mainly concerned with the software-related parts of this larger process: software specification, software design, software implementation, software testing, and software evolution.
The relationship works like this: → system requirements are defined first → the system is partitioned into hardware, software, and human-process components → software engineers take over the software component → hardware engineers handle the physical component → the parts are integrated back into one working system.
Because software is shaped by the hardware and processes it must integrate with, software engineers cannot work in isolation. Decisions made at the system engineering level, such as which hardware platform is chosen or how components communicate, directly constrain what the software engineer is able to build.
| Aspect | System engineering | Software engineering |
|---|---|---|
| Scope | Whole system: hardware, software, processes, people | Only the software component of the system |
| Focus | System specification, integration, deployment | Software specification, design, implementation, testing |
| Relationship | Broader discipline that contains software engineering | A specialized sub-discipline within system engineering |
Test Yourself
- Why can't a software engineer fully ignore decisions made at the system engineering level?
- What is the main difference in scope between system engineering and software engineering?
Answers: 1) Because choices like the target hardware platform or how system components must integrate are decided at the system level and directly constrain how the software must be designed and built.
2) System engineering covers the entire computer-based system (hardware, software, processes, people), while software engineering focuses only on the software portion of that system.
Summary
- System engineering covers the entire computer-based system; software engineering is one part of it.
- System-level decisions about hardware and integration constrain what software engineers can build.
- Software engineers focus on specification, design, implementation, testing, and evolution of the software piece.
One-Liner Revision
Software engineering is the software-focused slice of the much broader discipline of system engineering.
1.9 Professional Practice
Core Definition
Professional practice in software engineering refers to the technical knowledge and the responsible, ethical conduct a software engineer must apply when developing systems, going beyond pure programming skill to include legal and ethical obligations toward clients, users, and society.
Being a good software engineer is not only about writing correct code. It also means acting responsibly: respecting confidentiality, being honest about your own limits, and not misusing your technical skills to harm others.
Detailed Explanation
Professional practice usually rests on two pillars:
Technical competence → engineers must possess and continuously update the technical knowledge needed to do their work correctly, since software underpins systems that can affect safety, finance, and privacy.
Professional and ethical responsibility → engineers must behave in an honest and ethically responsible way, which includes maintaining confidentiality (not disclosing client information without authorization), respecting intellectual property rights, being competent (not misrepresenting one's own skill level), and not knowingly using their skills to cause harm or misuse computer resources.
Professional bodies such as the ACM and IEEE publish codes of ethics that formalize these obligations, giving software engineers a shared standard of conduct similar to codes followed by doctors or lawyers, recognizing that software failures can have serious real-world consequences.
Personal Side Note
This topic feels abstract until you actually ship something used by real people, then "don't misuse access to client data" or "don't overstate what you can deliver" stop being textbook lines and start being daily decisions.
Summary
- Professional practice combines technical competence with ethical responsibility.
- Confidentiality, honesty about competence, and respecting intellectual property are core obligations.
- Professional codes of ethics (e.g. ACM, IEEE) formalize expected conduct for software engineers.
One-Liner Revision
Professional practice means combining technical skill with honest, ethical, and confidential conduct.
Whole Chapter Summary
Whole Chapter Summary
- Definition of Software: software is programs, data, and documentation combined, not code alone.
- Type of Software: system, application, engineering/scientific, embedded, product-line, web/mobile, and AI software each serve different purposes.
- Characteristic of Software: software is engineered not manufactured, does not wear out (but deteriorates through change), and is mostly custom-built.
- Attributes of Good Software: maintainability, dependability/security, efficiency, and acceptability define quality software.
- Definition of Software Engineering: the disciplined, systematic application of engineering principles across the entire software lifecycle.
- Software Engineering Costs: maintenance often costs more than development, and testing usually outweighs coding cost.
- Key Challenges: heterogeneity, business and social change, security and trust, and scale shape modern software engineering.
- System Engineering and Software Engineering: software engineering is the software-focused part of the broader system engineering discipline.
- Professional Practice: being a software engineer requires technical competence plus ethical, responsible conduct.
Last-Minute Revision Sheet
Last-Minute Revision Sheet
Software → programs + data + documentation
Type of software → system, application, engineering/scientific, embedded, product-line, web/mobile, AI
Characteristics → engineered not manufactured, doesn't wear out (decays via change), mostly custom-built
Good software attributes → maintainable, dependable/secure, efficient, acceptable
Software engineering → systematic, disciplined approach across full lifecycle
SE costs → maintenance > development; testing > coding
Key challenges → heterogeneity, business/social change, security and trust, scale
System vs software engineering → system = whole (hardware+software+process), software = the software slice
Professional practice → technical skill + ethics + confidentiality