Unit 1: Introduction [4 Hours]
Software engineering is not just about writing code. It is a discipline that covers what software is, how to classify it, what separates a good software product from a poor one, and how to build it in a systematic, professional way. This unit lays the vocabulary for everything that follows: definitions, types, quality attributes, costs, challenges, and the ethical responsibilities of anyone who builds systems other people depend on.
Tested Topics
- Definition & challenges of software engineering — 5x (2026, 2025, 2024, 2022, 2021)
- Attributes / characteristics of good software — 3x (2025, 2024, 2022)
- System engineering vs software engineering — 2x (2026, 2021)
- Types of software — 1x (2026)
- Professional and ethical responsibility — 1x (2022)
1.1 Definition of Software
Definition
Software is the complete set of programs, data structures, and documentation that together enable a computer to perform a useful task. It is distinct from hardware: hardware is the physical machine; software is the set of instructions and information that tells the machine what to do.
Most people think software means the app you open on your phone. But the app is only the visible tip. Software also includes the data it reads and writes, and the manuals or help pages that tell you how to use it. Take away any of the three components and the product is incomplete.
Detailed Explanation
Software has three inseparable components:
- Programs: the executable instructions that carry out the required functions, from sorting a list to processing a bank payment.
- Data structures: the organised information the programs create, transform, and act on; ranging from a single variable in memory to a multi-gigabyte database on disk.
- Documentation: descriptive material that explains the operation, installation, and use of the programs, for both end users and the engineers who will maintain the system later.
Software is a logical, intangible product. Unlike a bridge or a turbine, it has no physical substance and cannot be seen or touched directly. This intangibility creates real management problems: you cannot walk past a construction site and see how much is finished the way you can with a physical structure.
Common Mistake
Students write "software = programs" and stop there. That is incomplete. Software is programs plus data structures plus documentation.
Summary
- Software = programs + data structures + documentation, not code alone.
- Hardware is the physical machine; software is the logical set of instructions and information that drives it.
- Software is intangible, which makes measuring progress and quality inherently harder than in physical engineering.
- All three components are necessary; missing any one leaves the product unusable or unmaintainable.
1.2 Types of Software
Definition
Types of software are categories that group software products by the kind of problem they solve and the environment they operate in. A compiler, a payroll system, and an aircraft-guidance system are all software, but they have almost nothing in common in terms of design constraints, users, or performance requirements.
Sorting software into types is like sorting transport vehicles. A bicycle, a cargo truck, and a fighter jet are all "vehicles," but that label tells you almost nothing useful about how each one is built, operated, or maintained. The same gap exists between a word processor and an embedded sensor controller.
Detailed Explanation
Seven main categories are widely recognised:
| Type | What it does | Real example |
|---|---|---|
| System software | Manages hardware and provides services to other programs. Sits close to the machine. | Operating systems (Windows, Linux), compilers, device drivers |
| Application software | Solves a specific business or personal need directly for the end user. | Word processors, billing systems, payroll software |
| Engineering / scientific software | Handles number-intensive, algorithm-heavy tasks in technical fields. | CAD tools, weather-simulation programs, finite-element analysis |
| Embedded software | Runs inside a device's hardware with a fixed, limited set of functions. The user rarely sees it directly. | Firmware in a microwave, engine-control unit in a car |
| Web / internet-based software | Delivered through a browser or network; driven by user interaction and linked data. | E-commerce platforms, online banking portals, web apps |
| Artificial Intelligence (AI) software | Uses non-numerical algorithms to solve problems too complex for direct computation, such as pattern recognition, reasoning, and learning. | Expert systems, speech recognition, game-playing engines |
| Product-line software | Built once, then configured or slightly customised and sold to many different customers. | Generic accounting packages, inventory-management systems |
One product can span multiple categories. A web-based AI recommendation engine is simultaneously web-based software and Artificial Intelligence (AI) software. Knowing the type shapes engineering decisions: an embedded system has strict memory and power constraints that an application program never faces.
Summary
- Seven types: system, application, engineering/scientific, embedded, web-based, AI, and product-line software.
- Type is determined by the problem the software solves and the environment it runs in, not by the programming language used.
- A single product can belong to more than one category.
- Knowing the type is the first step in choosing the right engineering approach, since constraints differ radically across types.
Test Yourself
- What is system engineering? Explain different types of software. (2026)
- Name and briefly describe four types of software with one example each.
Hints:
- Define system engineering (see 1.8 below); then list and describe all seven software types using the table above, with one example per type.
- Pick any four from the table: state the name, what it does, and one example. Keep each description to two sentences.
1.3 Characteristics of Software
Definition
Characteristics of software are the fundamental properties that make software different from any physical, manufactured product. These differences explain why the management approaches used in civil or mechanical engineering cannot be applied unchanged to software development.
A car engine wears out the more you use it. Run the same program ten million times and it behaves identically on attempt ten million as it did on attempt one, because no physical part is eroding. That single difference, along with two others, reshapes how software must be built, priced, and maintained.
Detailed Explanation
Three defining characteristics:
- Software is engineered, not manufactured: the expensive, skilled part is the design and development process. Once development is finished, copying software costs almost nothing, a stark contrast to physical manufacturing where each unit requires real materials and labour. However, the absence of a physical assembly line does not make software easier to manage; the quality problems that manufacturing solves with tooling and process control must instead be solved in the design phase itself.
- Software does not wear out, but it does deteriorate: physical components follow a bathtub-shaped failure curve: many failures when new, a long stable period, then rising failures near end of life as parts wear. Software has no physical wear, so it does not follow this pattern from use. But it does deteriorate over its lifetime through software ageing: as patches are applied and new features are bolted on over years, the original design erodes, undocumented dependencies accumulate, and change-related defects increase. The software works the same after ten million runs; it may start failing after ten years of incremental modification.
- Software is mostly custom-built rather than assembled from parts: in mechanical and electronic engineering, engineers routinely reach for standard, tested, off-the-shelf components. Software engineering is moving toward component reuse and shared libraries, but a truly component-based assembly culture, comparable to what exists in hardware engineering, is still not the norm. Most software systems still involve significant custom design and custom code.
Let's Clarify
Imagine two cars. One is driven daily for five years; one sits untouched in a garage. The driven car has worn brakes and a tired engine. The garage car is still new. Now imagine two copies of the same program. One has been run continuously for five years. One has never been opened. Both execute identically, because running the code does not erode it.
What ages software is not execution but change. A program that has accumulated five years of bug patches, urgent feature additions, and "quick fixes" by different developers is structurally fragile, hard to modify, and increasingly error-prone. The ageing comes from human intervention, not from use.
Common Mistake
Many students write "software never deteriorates" as a blanket statement. This is wrong. The correct claim is that software does not deteriorate from use, the way hardware does. It does deteriorate from change over its maintenance lifetime. Dropping that distinction produces an incorrect answer.
Summary
- Software is engineered: the costly phase is design and development; after that, copying costs almost nothing.
- Software does not wear out from use, so the hardware bathtub-failure curve does not apply in the same way.
- Software does deteriorate through software ageing: accumulated changes erode the original design over years.
- Most software is still custom-built; full component-based assembly, as in hardware engineering, remains rare.
1.4 Attributes of Good Software
Definition
The attributes of good software are the essential quality properties a software product must possess beyond simply executing its stated functions correctly. Software that "runs" is not automatically good software: it must also be reliable, efficient, secure, and adaptable to survive real-world use.
A banking app that calculates account balances correctly but crashes under heavy load, exposes customer data, and cannot be updated without rewriting half the codebase is functionally correct but fails every other test of quality. These four attributes are the difference between software that ships and software that lasts.
Detailed Explanation
Four essential attributes, building on 1.3 Characteristics of Software since these attributes directly counteract the deterioration and fragility that poorly built software exhibits:
| Attribute | What it requires | Example of failure |
|---|---|---|
| Maintainability | Software must be written so it can evolve as customer needs change, without excessive cost or introducing new defects. | A feature request that should take two hours takes two weeks because no one understands the existing code. |
| Dependability and security | Covers three sub-properties: reliability (works correctly under stated conditions), safety (does not cause harm when it fails), and security (resists unauthorised access and malicious attack). | A medical device that gives a wrong dosage when the network is slow; a banking app that leaks credentials under SQL injection. |
| Efficiency | Should not waste system resources such as memory, CPU cycles, or battery power; must respond within acceptable time limits for its context. | A mobile app that drains a phone battery in two hours when performing simple tasks. |
| Acceptability | Must be understandable, usable, and compatible with the other systems and processes the user already relies on. Must behave as users expect. | Software that works correctly but whose interface is so confusing users refuse to adopt it. |
These four attributes are not independent and often conflict. Aggressive optimisation to improve efficiency can produce dense, clever code that damages maintainability. Adding comprehensive security checks adds overhead that may reduce efficiency. Real engineering is a constant negotiation between them.
Summary
- Four essential attributes of good software: maintainability, dependability and security, efficiency, and acceptability.
- Functional correctness alone is insufficient; a product must also meet these quality attributes to be considered good.
- Dependability covers reliability, safety, and security as a combined property.
- The four attributes regularly conflict, so software engineering involves deliberate trade-off decisions.
Test Yourself
- What are the key challenges that the software engineering is facing? What are the attributes of good software? (2025)
- List and explain the four attributes of good software with one example for each.
Hints:
- For the attributes half: name and explain all four attributes from the table above. For the challenges half, see 1.7.
- Use the table directly: one row per attribute, state the requirement, then give a concrete scenario where the attribute fails.
1.5 Definition of Software Engineering
Definition
Software Engineering (SE) is the application of a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software — treating the production of software as an engineering activity rather than an individual creative exercise.
A single developer writing a personal script is programming. A team of fifty engineers building a hospital records system that ten thousand staff depend on, that must be updated without downtime, and that must not lose patient data under any failure condition, is doing software engineering. The difference is not the code; it is the process, discipline, and accountability that surrounds it.
Detailed Explanation
The word "engineering" carries specific meaning. Engineering disciplines apply theory, methods, and tools in a principled way; they select the best available approach under real constraints; and they deliver cost-effective solutions even when no perfect answer exists. Software Engineering (SE) applies the same discipline to software.
SE covers the full software lifecycle through four core activities:
- Specification: defining what the system must do, its constraints, and its acceptance criteria before a line of code is written.
- Development: designing the architecture, implementing the code, and testing that it meets the specification.
- Validation: confirming that the delivered system actually fulfils what the customer and users need, not just what the specification document said.
- Evolution: modifying and adapting the system over its operational lifetime as requirements, environments, and technology change.
This lifecycle framing separates SE from plain programming. A programmer writes code that works. A software engineer ensures the right code gets written, in the right order, by the right process, and that it can be maintained long after the original author has left.
Summary
- Software Engineering (SE) is a systematic, disciplined, quantifiable approach to building and maintaining software.
- It covers the full lifecycle: specification, development, validation, and evolution.
- SE differs from programming in its emphasis on process, repeatability, teamwork, and long-term maintainability.
- Engineering discipline is what makes it possible for large systems to be built reliably by teams, rather than by skilled individuals working alone.
Test Yourself
- What is software engineering? Explain the challenges facing software engineering. (2021)
- What is the difference between programming and software engineering?
Hints:
- Define SE as above; then cover the three challenges from 1.7: heterogeneity, business and social change, security and trust.
- Programming = writing working code for a specific task. SE = the full discipline surrounding that code: specification, process, validation, team coordination, maintenance. SE applies when scale, reliability, and longevity matter.
1.6 Software Engineering Costs
Definition
Software engineering costs describe how financial and human effort is distributed across a software project's lifecycle, and why software, once an afterthought in computing budgets, now routinely accounts for the majority of total system cost.
In the early decades of computing, the hardware was the expensive part; the programs were almost incidental. That balance has reversed completely. Today, commodity hardware is cheap, but the skilled human effort needed to design, build, test, and maintain the software running on it drives the budget.
Detailed Explanation
- Software now dominates system costs: as hardware became faster and cheaper through successive generations, the relative cost of software grew. For many modern systems, software development and maintenance represent the largest single cost category in the total project budget. [verify exact historical percentages for your course notes]
- No universal cost-distribution rule exists: there is no fixed formula for what percentage of a budget should go to specification, design, implementation, or testing. The split depends on the type of system, the development process chosen, and the reliability required. A safety-critical aerospace system spends a far higher proportion on testing and validation than a consumer web app.
- Maintenance and evolution often cost more than initial development: for large systems with long operational lives, the total cumulative cost of maintaining and evolving the software after its first release frequently exceeds the cost of building it in the first place. Every new feature request, bug fix, and platform upgrade adds to this total over years or decades of operation.
- Team size does not scale linearly with productivity: beyond a certain team size, adding more engineers slows progress rather than accelerating it. Coordination, communication, and integration overhead grows faster than the additional capacity added, making smaller, experienced teams often more cost-effective for many project types.
Summary
- Software's share of total system cost has grown as hardware became cheaper; software now dominates project budgets.
- No fixed rule exists for splitting a budget across specification, design, coding, and testing; it depends on the system and process.
- For long-lifetime systems, maintenance and evolution costs cumulatively exceed the original development cost.
- Adding engineers does not proportionally increase speed; coordination overhead limits the benefit of larger teams.
1.7 Key Challenges That Software Engineering Is Facing
Definition
The key challenges facing software engineering are the major, ongoing pressures the discipline must respond to as the world around it, the platforms software runs on, the pace of business, and the trust users place in digital systems, keeps changing faster than any single engineering method can anticipate.
Software engineering is not a problem that was solved in the 1980s and documented in a textbook since. The computing landscape shifts continuously: new devices emerge, business cycles compress, and software now underpins infrastructure that, if it fails or is breached, causes real harm to real people. The discipline must keep adapting its methods to match.
Detailed Explanation
Three major challenges, building on 1.5 Definition of Software Engineering because each challenge directly stresses one of the four lifecycle activities SE must manage:
- Heterogeneity challenge: software no longer runs on a predictable, uniform platform. Modern systems must operate across powerful cloud servers, personal computers, smartphones, tablets, wearables, and tiny embedded devices, all potentially talking to one another over different network protocols. Engineers must design systems flexible enough to work correctly across this diversity without rebuilding separate products for each environment.
Heterogeneity → forces cross-platform design decisions → increases integration complexity → raises testing burden across device and OS combinations
- Business and social change challenge: organisations and markets now change at a pace that earlier software development models, which assumed stable requirements over long planning cycles, were not built to handle. A business may need its software updated in weeks rather than years. This pressure has driven the rise of iterative and agile development methods that deliver working software in short cycles and respond to changing requirements throughout development rather than locking them down at the start.
Rapid business change → requirements shift mid-project → long waterfall plans become invalid → iterative/agile methods gain importance
- Security and trust challenge: software is now embedded in banking, healthcare, communications, transport, and government. Users and organisations must be able to trust that software will not fail dangerously, leak private data, or be compromised by hostile actors. Building that demonstrable trustworthiness into systems from the design phase, rather than patching it in afterward, is one of the hardest open problems in the field.
Software in critical domains → failure or breach causes real harm → security and reliability must be designed in from the start → retrofitting is expensive and often incomplete
Summary
- Three key challenges: heterogeneity, business and social change, and security and trust.
- Heterogeneity: software must run correctly across a wide, diverse mix of hardware platforms and operating environments.
- Business and social change: requirements shift faster than traditional long-cycle development can track, driving iterative methods.
- Security and trust: software embedded in critical infrastructure must be demonstrably secure and reliable, not just functionally correct.
Test Yourself
- What are the key challenges that the software engineering is facing? What are the attributes of good software? (2025)
- Describe the challenges faced in software engineering. (2024)
- What is software engineering? Explain the challenges facing software engineering. (2021)
- Explain challenges faced by software engineering along with professional and ethical responsibility. (2022)
Hints:
- Explain all three challenges in detail; then list the four attributes of good software from 1.4.
- Name and explain each of the three challenges; give one real-world consequence per challenge.
- Define SE (1.5) first, then explain heterogeneity, business and social change, and security and trust.
- Explain the three challenges, then cover the four ethical duties from 1.9: confidentiality, competence, intellectual property, responsible use.
1.8 System Engineering and Software Engineering
Definition
System engineering is the broader discipline concerned with designing, integrating, and managing complex systems that include hardware, software, people, and processes working together as a whole. Software Engineering (SE), introduced in 1.5, is one of its component activities, focused specifically on the software element within that larger system.
Building an aircraft's flight-control system is not a pure software project. Someone must decide how the physical sensors, hydraulic actuators, pilot displays, wiring harnesses, and the control software all fit together so the aircraft flies safely. That bigger coordination job is system engineering. The team that designs and tests the control software itself is doing software engineering, inside that larger effort.
Detailed Explanation
System engineers work at the level of the whole system. Their responsibilities include:
- Defining overall system requirements before deciding how they will be allocated to hardware or software components.
- Deciding the architecture: which functions are handled in hardware, which in software, and how human operators interact with both.
- Managing the interfaces between subsystems so that individually correct components work correctly when combined.
- Integrating and validating the final assembled system.
Software engineers operate at the software component level: specifying, designing, implementing, and verifying the software that the system engineer has assigned to software, then handing back a verified component for system-level integration.
| Aspect | System Engineering | Software Engineering |
|---|---|---|
| Scope | Whole system: hardware + software + people + processes | The software component within that system |
| Primary concern | System requirements, architecture, subsystem allocation, integration | Software specification, design, implementation, verification |
| Disciplines involved | Electrical, mechanical, software, human factors, and others together | Primarily software specialists |
| Relationship | Broader discipline; treats software as one subsystem | A component activity within system engineering |
Summary
- System engineering covers the whole system: hardware, software, people, and processes.
- Software engineering is the component of system engineering focused on the software subsystem.
- System engineers define overall requirements and manage integration across all subsystems; software engineers deliver the software piece.
- Every software project sits inside a larger system context, even when that context is informal or implicit.
Test Yourself
- What is system engineering? Explain different types of software. (2026)
- Differentiate between system engineering and software engineering.
Hints:
- Define system engineering as above; then cover all seven software types from 1.2 with one example each.
- Use the comparison table: scope, primary concern, disciplines involved, and the broader-vs-component relationship.
1.9 Professional Practice
Definition
Professional practice in software engineering means combining technical competence with a commitment to ethical conduct, because software engineers routinely build systems that hold private data, process financial transactions, and control equipment that can harm people if it fails.
Being a professional software engineer is not limited to writing correct code. It also means keeping client information confidential, being honest about what you do and do not know, respecting intellectual property that belongs to others, and not using your technical access to systems for purposes they were not intended for. The same expectations apply to a doctor or a lawyer, and software engineers working on safety-critical systems face comparable stakes.
Detailed Explanation
Professional practice has two connected sides:
- Technical competence: having the knowledge of methods, tools, and processes needed to produce quality software, and knowing the limits of that knowledge. A competent professional does not accept a project whose requirements exceed their expertise without making that limitation clear.
- Professional and ethical responsibility: four core duties that go beyond any individual contract or assignment:
- Confidentiality: not disclosing employer or client information without proper authorisation, whether or not a formal non-disclosure agreement exists. The obligation is professional, not merely contractual.
- Competence: not misrepresenting one's skills, and not deliberately accepting work that one knows is beyond one's current abilities without disclosing that fact.
- Intellectual Property (IP) rights: understanding and respecting patents, copyright, licensing terms, and trade secrets when reusing code, tools, or designs developed by others.
- Responsible use of computers: not exploiting technical skills or system access to interfere with, damage, or misuse other people's systems or data, even when the capability to do so exists.
Professional bodies such as the Association for Computing Machinery (ACM) and the Institute of Electrical and Electronics Engineers (IEEE) publish formal codes of ethics that codify these responsibilities for practising engineers. [verify current edition details]
Summary
- Professional practice combines technical competence with ethical and legal responsibility.
- Four core ethical duties: confidentiality, honesty about competence, respect for Intellectual Property (IP), and responsible use of computer access.
- These obligations apply beyond the terms of any individual contract.
- The ACM and IEEE publish codes of ethics that formalise these duties for software engineers.
Test Yourself
- Explain challenges faced by software engineering along with professional and ethical responsibility. (2022)
- What are the key professional and ethical responsibilities of a software engineer?
Hints:
- Cover the three challenges from 1.7, then explain all four ethical duties: confidentiality, competence, IP rights, responsible computer use.
- State the four duties and briefly explain each. Add that these obligations exist beyond contractual terms and are codified by the ACM and IEEE.
Extra: Topics Asked in Exams But Not in Syllabus
These topics have appeared in past papers. They are not listed in the syllabus but you should know them.
Software Life Cycle Models (2023 exam)
A Software Development Life Cycle (SDLC) model is a structured plan that describes the phases a software project moves through from initial requirements to deployment and long-term maintenance, and defines the order and conditions under which those phases occur.
Without a lifecycle model, teams have no shared structure for sequencing work: requirements may be written after code, testing may be skipped under deadline pressure, and there is no agreed point at which a phase is complete. A lifecycle model prevents this by making the process explicit and repeatable.
Well-known models include:
- Waterfall model: phases proceed in a strict linear sequence: requirements, design, implementation, testing, deployment, maintenance. Each phase must be complete before the next begins. Straightforward to manage but inflexible when requirements change mid-project.
- Incremental model: the system is designed and delivered in a series of increments. Each increment adds new functionality to the previous working system. Users can start using core features earlier, and feedback can be incorporated into later increments.
- Spiral model: combines iterative development with systematic risk analysis. Each cycle of the spiral covers planning, risk assessment, engineering, and evaluation. Suited to large, high-risk projects where requirements are uncertain.
This topic is treated in depth in later units covering software process models.
Exam Questions
- What is system engineering? Explain different types of software. (2026)
- What are the key challenges that the software engineering is facing? What are the attributes of good software? (2025)
- Describe the challenges faced in software engineering. (2024)
- What is software engineering? Explain the need of software life cycle models Engineering. (2023)
- Explain challenges faced by software engineering along with professional and ethical responsibility. (2022)
- What is software engineering? Explain the challenges facing software engineering. (2021)
Whole Chapter Summary
- Definition of Software: software is programs, data structures, and documentation combined; it is an intangible logical product distinct from hardware.
- Types of Software: seven categories grouped by purpose and environment: system, application, engineering/scientific, embedded, web-based, AI, and product-line software.
- Characteristics of Software: engineered not manufactured; does not wear out from use but deteriorates through change (software ageing); mostly still custom-built rather than assembled from standard parts.
- Attributes of Good Software: maintainability, dependability and security, efficiency, and acceptability — all four are necessary and they frequently trade off against one another.
- Definition of Software Engineering: a systematic, disciplined, quantifiable approach covering specification, development, validation, and evolution; it is a discipline around software, not merely the act of coding.
- Software Engineering Costs: software now dominates system budgets; there is no fixed cost-distribution formula; evolution costs often exceed original development cost over a system's lifetime.
- Key Challenges: heterogeneity (diverse platforms), business and social change (faster requirements), and security and trust (software in critical infrastructure).
- System Engineering vs Software Engineering: system engineering covers the whole hardware-software-people system; software engineering is its software-focused component activity.
- Professional Practice: technical competence plus four ethical duties: confidentiality, honest competence, respect for IP, and responsible computer use.
Key Formulas and Points Sheet
| Rule / Point | Meaning |
|---|---|
| Software = programs + data structures + documentation | All three components together constitute software |
| 7 types of software | System, application, engineering/scientific, embedded, web-based, AI, product-line |
| 3 characteristics of software | Engineered not manufactured; ages through change not wear; mostly custom-built |
| 4 attributes of good software | Maintainability, dependability and security, efficiency, acceptability |
| 4 lifecycle activities of SE | Specification, development, validation, evolution |
| 3 key challenges | Heterogeneity, business and social change, security and trust |
| 4 ethical duties | Confidentiality, competence, IP rights, responsible computer use |
| Evolution cost vs development cost | For long-lifetime systems, cumulative maintenance/evolution cost often exceeds original build cost |
Last-Minute Revision Sheet
- Software → programs + data structures + docs (not code alone)
- 7 types → system / application / engineering-scientific / embedded / web / AI / product-line
- 3 characteristics → engineered not manufactured | ages via change not use | mostly custom-built
- 4 good-software attributes → maintainability | dependability+security | efficiency | acceptability
- SE → systematic + disciplined + quantifiable | 4 activities: specify → develop → validate → evolve
- SE costs → SW dominates budgets | no fixed split rule | evolution cost often > dev cost
- 3 SE challenges → heterogeneity | business/social change | security and trust
- System Eng vs SE → SE = software slice of the broader hardware+software+people system
- Ethics → confidentiality | competence | IP rights | responsible use | codified by ACM & IEEE