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
- Software engineering concerns the complete software life cycle, not coding alone.
- The discipline arose because informal methods were inadequate for large and critical systems.
- Technical work must be combined with communication, quality and management.
Check Your Understanding
- Differentiate software from software engineering.
- State three problems associated with the software crisis.
Practical activity: Choose one application you use regularly and list its programs, data, documents and operating procedures.
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.
| Quality Attribute | Meaning | Simple Example |
|---|---|---|
| Reliability | Performs correctly for an expected period | A payment is processed once without duplication |
| Usability | Can be learned and used effectively | Clear labels and understandable error messages |
| Maintainability | Can be corrected and improved efficiently | Well-structured modules and documentation |
| Security | Protects data and services from misuse | Authorised access and protected passwords |
| Scalability | Continues to perform as demand grows | A portal supports rising student numbers |
Key Takeaways
- Different software products serve different users and operating environments.
- Stakeholder needs must be identified and balanced.
- Software quality includes many attributes beyond the absence of errors.
Check Your Understanding
- Differentiate generic software from customised software.
- Explain why quality attributes may conflict.
Practical activity: Identify four stakeholders of a university registration system and state one concern of each.
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.
| Approach | Strength | Possible Limitation |
|---|---|---|
| Waterfall | Clear stages and documentation | Difficult to accommodate late change |
| Incremental | Useful features delivered gradually | Requires careful integration |
| Prototyping | Clarifies unclear requirements | Users may mistake a prototype for the final system |
| Agile | Frequent feedback and adaptability | Needs active collaboration and disciplined teams |
Key Takeaways
- Software development consists of related life-cycle activities.
- No single process model is best for every project.
- Process choice depends on risk, requirements, team, regulation and project size.
Check Your Understanding
- List six common software life-cycle activities.
- Why is agile development not the same as an absence of planning?
Practical activity: Select a process model for a small school library application and justify your choice.
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.
| Requirement Type | Example |
|---|---|
| Functional | The system shall generate a receipt after payment. |
| Performance | Search results shall appear within three seconds under normal load. |
| Security | Only authorised staff shall change student records. |
| Usability | A first-time user shall complete registration without external assistance. |
| Business rule | A student with unpaid fees cannot complete final registration. |
Key Takeaways
- Requirements define the problem before developers define the solution.
- Functional requirements describe services; non-functional requirements describe qualities and constraints.
- Good requirements are clear, feasible, testable and traceable.
Check Your Understanding
- Differentiate functional and non-functional requirements.
- Mention four techniques for gathering requirements.
Practical activity: Write three functional and three non-functional requirements for a simple hostel allocation system.
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.
| Design Idea | Purpose |
|---|---|
| Abstraction | Focus on important features while hiding unnecessary detail |
| Modularity | Divide a system into manageable components |
| Information hiding | Protect internal details behind clear interfaces |
| High cohesion | Keep closely related responsibilities together |
| Low coupling | Reduce unnecessary dependence between components |
Key Takeaways
- Design provides the bridge between requirements and implementation.
- Modular systems are easier to test, maintain and reuse.
- Models are communication tools, not ends in themselves.
Check Your Understanding
- Differentiate software architecture from detailed design.
- Explain high cohesion and low coupling.
Practical activity: Draw a context diagram for an online food-ordering system, showing at least three external actors.
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.
| Practice | Benefit |
|---|---|
| Meaningful names | Makes intent easier to understand |
| Code review | Finds defects and shares knowledge |
| Refactoring | Improves structure without changing behaviour |
| Version control | Preserves history and supports collaboration |
| Configuration management | Controls versions of all important project items |
Key Takeaways
- Professional implementation values readability and maintainability as well as correctness.
- Version control is essential for individual and team projects.
- Refactoring and review help control complexity.
Check Your Understanding
- What is the difference between a commit and a branch?
- Why should comments not be used to excuse unclear code?
Practical activity: Create a small version-control repository, make two commits and write meaningful commit messages.
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.
| Test Level | Main Question |
|---|---|
| Unit test | Does this small component work correctly? |
| Integration test | Do connected components work together? |
| System test | Does the complete system meet its requirements? |
| Acceptance test | Is the system acceptable to the customer or user? |
| Regression test | Did a change damage existing behaviour? |
Key Takeaways
- Testing provides evidence about quality and reduces risk.
- Different test levels address different kinds of defects.
- Quality assurance includes prevention and process improvement, not testing alone.
Check Your Understanding
- Differentiate system testing from acceptance testing.
- Why are boundary values useful in testing?
Practical activity: Design five test cases for a login form, including normal, boundary and invalid inputs.
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.
| Maintenance Type | Example |
|---|---|
| Corrective | Fixing an incorrect fee calculation |
| Adaptive | Updating an application for a new operating system |
| Perfective | Adding a dashboard requested by users |
| Preventive | Refactoring fragile code before it fails |
Key Takeaways
- Deployment requires preparation, monitoring and recovery planning.
- Maintenance is a normal and significant part of software engineering.
- Technical debt creates future cost when shortcuts are not controlled.
Check Your Understanding
- List the four common categories of software maintenance.
- Why do organisations continue using legacy systems?
Practical activity: For a familiar application update, identify whether the change was corrective, adaptive, perfective or preventive.
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.
| Risk | Possible Response |
|---|---|
| Key team member becomes unavailable | Share knowledge and maintain documentation |
| Requirements change repeatedly | Use prioritisation, prototypes and controlled change |
| New technology proves difficult | Run an early technical experiment |
| Security weakness is discovered | Prioritise correction and reassess related components |
| Release fails | Use backups, staged deployment and rollback procedures |
Key Takeaways
- Software projects require continuous planning and adjustment.
- Team communication is a technical success factor.
- DevOps combines collaboration, automation and operational feedback.
Check Your Understanding
- What four constraints are commonly balanced in project management?
- State three principles associated with DevOps.
Practical activity: Create a simple task board with “To Do”, “In Progress” and “Done” columns for a group project.
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
- Security, privacy, usability and accessibility are design concerns.
- Responsible software engineering considers both direct users and wider society.
- Professional judgement is required when technical choices affect safety, rights or fairness.
Check Your Understanding
- Explain the principle of least privilege.
- Why can a functionally correct system still be unsuccessful?
Practical activity: Review a mobile or web application and list two security, two usability and two accessibility improvements.
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
- Software engineering creates opportunities across almost every sector.
- Employability depends on practical projects and professional habits as well as certificates.
- Emerging tools assist engineers but do not remove the need for judgement and verification.
Check Your Understanding
- Mention five career paths related to software engineering.
- State three local factors that may influence software development in Nigeria.
Practical activity: Prepare a one-page learning plan for one software engineering career, including skills, tools and a beginner project.
General Revision Questions
- Explain why software engineering involves more than programming.
- Discuss five important quality attributes of a university information system.
- Compare waterfall, incremental and agile development.
- Write two functional and two non-functional requirements for a clinic appointment system.
- Explain how modularity, cohesion and coupling affect maintainability.
- Describe how version control and code review support team development.
- Design a basic testing strategy for an online examination system.
- Differentiate corrective, adaptive, perfective and preventive maintenance.
- Discuss three project risks and appropriate responses.
- 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
| Term | Meaning |
|---|---|
| Acceptance testing | Testing used to decide whether a system satisfies customer or user needs. |
| Agile development | Iterative development that emphasises feedback, collaboration and response to change. |
| Architecture | The high-level structure of a software system and the relationships among its components. |
| Configuration management | Control of versions and changes to software project items. |
| Functional requirement | A statement of a service or behaviour the system must provide. |
| Maintenance | Modification of software after delivery to correct, adapt or improve it. |
| Non-functional requirement | A quality, performance or constraint requirement. |
| Refactoring | Improving internal code structure without changing observable behaviour. |
| Regression testing | Repeating tests to ensure that changes have not damaged existing behaviour. |
| Repository | A version-controlled store containing project files and their history. |
| Stakeholder | A person or group affected by, interested in or able to influence a system. |
| Technical debt | Future cost caused by choosing a quick or weak technical solution. |
| User story | A brief requirement written from the perspective of a user. |
| Version control | A system for recording and coordinating changes to project files. |
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.