Learning Outcomes

• By the end of this course, students should be able to define software engineering and explain why disciplined development is necessary;
• By the end of this course, students should be able to distinguish software products, processes, projects and services;
• By the end of this course, students should be able to describe major software life-cycle activities and common process models;
• By the end of this course, students should be able to identify and document basic functional and non-functional requirements;
• By the end of this course, students should be able to explain fundamental principles of software design and architecture;
• By the end of this course, students should be able to describe the roles of programming standards, version control and configuration management;
• By the end of this course, students should be able to apply basic testing and quality-assurance concepts;
• By the end of this course, students should be able to explain software maintenance, evolution and technical debt;
• By the end of this course, students should be able to recognise the importance of teamwork, project planning, risk and professional ethics; and
• By the end of this course, students should be able to identify entry-level software engineering roles and emerging areas of practice.

Unit 1: Meaning, Scope and Evolution of Software Engineering

Software engineering is the disciplined application of engineering principles to the development, operation and improvement of software systems. It combines technical knowledge with planning, communication, quality assurance and professional responsibility. The aim is not merely to write code, but to produce software that solves the correct problem, works reliably and can be maintained over time.

Software is a collection of programs, data, documentation and operating procedures that enable a computer system to perform useful work. Software engineering is the systematic and measurable approach used to specify, develop, test, deploy and maintain such software. It applies the discipline of engineering to the full life of a software product.

Early computer programs were often small and written by individuals. As systems became larger, many projects exceeded their budgets, missed deadlines, failed to satisfy users or became too difficult to maintain. These recurring problems were described as the software crisis. Software engineering emerged to address them through defined processes, modular design, documentation, testing, teamwork and management.

The field covers requirements, architecture, design, programming, testing, deployment, maintenance, quality assurance, configuration management, project management, security, usability and professional practice. Software engineers work in almost every sector because modern organisations depend on dependable digital systems.

Key Takeaways

Check Your Understanding

Unit 2: Software Products, Stakeholders and Quality Attributes

A software product may be generic or customised. Generic products are developed for many users, such as word processors and accounting packages. Customised systems are built for a particular organisation, such as a university result-processing system. Software may also be embedded inside devices, delivered through the web, installed on mobile phones or offered as a cloud service.

A stakeholder is any person or group affected by a system. Stakeholders may include users, customers, managers, developers, regulators, support staff and members of the public. Their needs may differ. For example, students may value ease of use, administrators may value accurate reports, and management may emphasise cost and security.

Software quality describes how well a system satisfies stated and implied needs. Important attributes include correctness, reliability, usability, efficiency, security, maintainability, portability and scalability. Quality attributes sometimes conflict; stronger security controls may reduce convenience, while rapid delivery may reduce time available for testing. Engineers therefore make informed trade-offs.

Key Takeaways

Check Your Understanding

Unit 3: Software Processes and the Development Life Cycle

A software process is an organised set of activities used to create and evolve software. Most processes include communication with stakeholders, planning, requirements analysis, design, implementation, testing, deployment and maintenance. These activities may overlap and repeat rather than occur only once.

The waterfall model arranges development in largely sequential stages. It is easy to understand and can suit projects with stable requirements, but late changes may be expensive. Iterative and incremental development delivers the system in smaller versions, allowing feedback and improvement. Prototyping creates an early model to clarify uncertain needs.

Agile development emphasises short delivery cycles, working software, customer collaboration and response to change. Scrum commonly organises work into short sprints and uses a product backlog. Kanban visualises work and limits tasks in progress. Agile does not mean working without documentation or planning; it means using only the level of process that creates value.

Key Takeaways

Check Your Understanding

Unit 4: Requirements Engineering

A requirement is a statement of a service the system should provide or a constraint under which it must operate. Requirements engineering involves discovering, analysing, documenting, validating and managing requirements. Weak requirements are a major source of rework because even well-written code is useless if it solves the wrong problem.

Functional requirements describe what the system must do, such as “the system shall allow a student to view registered courses.” Non-functional requirements describe qualities or constraints, such as response time, security, accessibility, legal compliance or availability. Business rules specify organisational policies that the system must enforce.

Requirements may be gathered through interviews, observation, questionnaires, document study, workshops and prototypes. A user story expresses a need from the user’s perspective: “As a librarian, I want to record returned materials so that availability is updated.” Requirements should be clear, consistent, feasible, testable and traceable to their source.

Key Takeaways

Check Your Understanding

Unit 5: Software Design, Architecture and Modelling

Software design transforms requirements into a structure that developers can implement. Architecture describes the high-level organisation of a system, including its major components, responsibilities and interactions. Detailed design defines classes, functions, interfaces, data structures and algorithms.

Good design aims for simplicity, separation of concerns, information hiding and reuse. High cohesion means that the elements of a module belong closely together. Low coupling means that modules depend on one another as little as reasonably possible. These principles make systems easier to understand, test and modify.

Models provide simplified views of a system. A context diagram shows the system and external actors. A use-case model shows how users interact with the system. Activity diagrams show workflows, class diagrams show data and relationships, and sequence diagrams show the order of interactions. Models support communication; they should be created when they improve understanding.

Key Takeaways

Check Your Understanding

Unit 6: Implementation, Coding Practices and Version Control

Implementation converts the design into executable code. Correctness is essential, but professional code should also be readable, consistent and easy to change. Useful practices include meaningful names, small functions, limited duplication, appropriate comments, input validation and adherence to an agreed coding standard.

Code review is the systematic examination of source code by another developer or by the team. Reviews can detect defects, improve consistency and spread knowledge. Refactoring improves the internal structure of existing code without changing its observable behaviour. It reduces complexity and helps prevent technical debt.

Version control records changes to project files. A repository stores the history, a commit records a meaningful set of changes, and a branch allows independent work. Developers merge branches after review and resolve conflicts when changes overlap. Configuration management extends beyond code to requirements, test data, libraries, builds and release records.

Key Takeaways

Check Your Understanding

Unit 7: Software Testing and Quality Assurance

Software testing evaluates a system or component to discover defects and provide evidence about quality. Testing cannot prove that a non-trivial program contains no defects, but it can reduce uncertainty. A test case normally specifies the input, execution conditions and expected result.

Unit testing checks individual functions or classes. Integration testing checks interactions among components. System testing checks the complete system, while acceptance testing determines whether stakeholder needs are satisfied. Regression testing repeats previous tests after changes to ensure that working behaviour has not been broken.

Black-box testing derives tests from requirements without examining internal code. White-box testing considers internal structure and execution paths. Useful test values include normal cases, boundary values and invalid inputs. Quality assurance is broader than testing; it also includes standards, reviews, audits, process improvement and defect prevention.

Key Takeaways

Check Your Understanding

Unit 8: Deployment, Maintenance and Software Evolution

Deployment makes a software system available for use. It may involve installation, configuration, data migration, user training, release notes, monitoring and rollback planning. A release should be identifiable so that the organisation knows which features and corrections are in production.

Software maintenance includes corrective maintenance to fix defects, adaptive maintenance to respond to a changed environment, perfective maintenance to improve features or performance, and preventive maintenance to reduce future problems. Maintenance often consumes a large share of the total cost of a long-lived system.

Software evolves because user needs, laws, devices, operating systems, security threats and business conditions change. Technical debt is the future cost created when a team chooses a quick but weak solution. Some debt may be deliberate, but unmanaged debt slows future work. Legacy systems remain in use because they contain valuable data and business rules, even when their technology is old.

Key Takeaways

Check Your Understanding

Unit 9: Project Management, Teamwork, Risk and DevOps

A software project must balance scope, time, cost and quality. Project planning identifies tasks, estimates effort, assigns responsibilities and establishes milestones. Estimates are uncertain because requirements, technology and team productivity may change. Plans should therefore be reviewed as new information becomes available.

Software is usually built by multidisciplinary teams. Common roles include product owner, business analyst, designer, developer, tester, security specialist, database specialist, operations engineer and project manager. Effective teams communicate openly, document decisions, manage conflict respectfully and share responsibility for quality.

Risk management identifies uncertain events that may harm the project, assesses their likelihood and impact, and plans responses. DevOps brings development and operations closer together through collaboration, automation, continuous integration, delivery pipelines, monitoring and rapid feedback. It aims to deliver reliable changes more frequently, but automation must still be governed and tested.

Key Takeaways

Check Your Understanding

Unit 10: Secure, Usable and Responsible Software

Security and privacy should be considered throughout development rather than added at the end. Secure design applies principles such as least privilege, defence in depth, secure defaults, input validation and protection of sensitive data. Threat modelling asks what must be protected, who might attack it, how an attack could occur and what controls are appropriate.

Usability concerns how effectively, efficiently and satisfactorily people can use a system. Accessibility ensures that people with disabilities can also use it. Developers should use clear language, consistent navigation, readable layouts, keyboard support and helpful error recovery. A technically correct system may still fail if users cannot understand it.

Software professionals must respect privacy, intellectual property, confidentiality, fairness and public safety. They should not conceal serious defects or misuse access to data. Systems may create bias or exclude groups when requirements, data or testing are incomplete. Responsible engineering therefore includes impact assessment and accountability.

Key Takeaways

Check Your Understanding

Unit 11: Applications, Careers and Emerging Practice

Software engineering supports banking, telecommunications, education, healthcare, agriculture, transportation, entertainment, public administration and scientific research. In Nigeria, engineers build payment platforms, school-management systems, logistics applications, identity services, health records, e-commerce tools and solutions for small businesses. Local systems must consider infrastructure limits, cost, device diversity, language and user trust.

Career paths include software developer, front-end engineer, back-end engineer, mobile developer, quality-assurance engineer, DevOps engineer, business analyst, systems analyst, security engineer, cloud engineer, user-experience designer, product manager and technical support specialist. Entry-level professionals need programming ability, problem-solving, communication, version control, testing habits and evidence of projects.

Emerging practice includes cloud-native systems, microservices, platform engineering, low-code tools, artificial-intelligence-assisted development and automated testing. These tools can improve productivity, but engineers must still verify requirements, architecture, security, licensing and generated code. Strong fundamentals remain important because tools and platforms change.

Key Takeaways

Check Your Understanding

General Revision Questions

1. Explain why software engineering involves more than programming.
2. Discuss five important quality attributes of a university information system.
3. Compare waterfall, incremental and agile development.
4. Write two functional and two non-functional requirements for a clinic appointment system.
5. Explain how modularity, cohesion and coupling affect maintainability.
6. Describe how version control and code review support team development.
7. Design a basic testing strategy for an online examination system.
8. Differentiate corrective, adaptive, perfective and preventive maintenance.
9. Discuss three project risks and appropriate responses.
10. Explain why security, usability, accessibility and ethics should be considered throughout development.

Suggested Practical Exercises

• Interview a potential user and write a short requirements list for a simple application.
• Create a context diagram and a basic use-case diagram for a school portal.
• Prepare a product backlog containing ten user stories and prioritise them.
• Use version control to manage changes to a small programming exercise.
• Write and execute test cases for a calculator, registration form or login page.
• Conduct a peer code review using a simple checklist.
• Prepare a risk register for a semester software project.

Concise words

References and Further Reading

• Pressman, R. S. and Maxim, B. R. Software Engineering: A Practitioner’s Approach.
• Sommerville, I. Software Engineering.
• Pfleeger, S. L. and Atlee, J. M. Software Engineering: Theory and Practice.
• Hunt, A. and Thomas, D. The Pragmatic Programmer.
• Martin, R. C. Clean Code: A Handbook of Agile Software Craftsmanship.
• International professional guidance on software engineering knowledge, ethics and quality practice.