This document, "Software Engineering (SEN 201)," provides a comprehensive introduction to the fundamental principles, processes, and practices of software engineering. Authored by Engr. A. A. Adebayo, it serves as a foundational text for understanding how to systematically design, develop, test, and maintain high-quality software systems. The material covers a broad spectrum of topics, starting from the basic definition and importance of software engineering, delving into various software process models, and exploring modern agile methodologies.

The document meticulously outlines the entire software development lifecycle, from initial requirements gathering and analysis through system design, implementation, testing, and eventual evolution and maintenance. It introduces key concepts such as different types of software requirements, various modeling techniques using UML, architectural design patterns, and essential project management activities like scheduling, risk management, and quality assurance. Emphasis is placed on both the technical aspects of software development and the professional responsibilities and ethical considerations inherent in the field.

Ultimately, this course material aims to equip students with a solid understanding of the disciplined approach required for creating reliable, efficient, and maintainable software. It highlights the challenges faced in software development and presents established methodologies and best practices to overcome them, ensuring that software products meet user needs and industry standards. The detailed explanations of concepts, along with practical examples and discussions on professional ethics, make it a valuable resource for anyone studying software engineering.

This section defines software engineering as a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. It emphasizes the application of engineering principles to software.

* Definition (IEEE): "The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software."

* Importance: Software engineering is crucial due to the increasing complexity and criticality of software systems, the need for cost-effective development, and the demand for reliable and efficient software.

* Software Products:

* Generic Products: Stand-alone systems marketed to a wide range of customers (e.g., word processors, CAD software).

* Customized Products: Developed for a single customer according to their specific needs (e.g., air traffic control systems, embedded systems).

* Attributes of Good Software:

* Maintainability: Ease of modifying the software to correct faults, improve performance, or adapt to new environments.

* Dependability and Security: Reliability, security, and safety of the software.

* Efficiency: Responsiveness, processing time, and memory utilization.

* Usability: Ease of use by its target users.

* Key Challenges: Coping with increasing diversity, demands for reduced time to market, and developing trustworthy software.

* Software Engineering Ethics: Professionals must adhere to ethical principles, including confidentiality, competence, intellectual property rights, and honesty. The ACM/IEEE Code of Ethics outlines eight principles: Public, Client & Employer, Product, Judgment, Management, Profession, Colleagues, Self.

A software process is a structured set of activities required to develop a software system. A software process model is a simplified representation of a software process.

* Software Process Activities:

* Software Specification: Defining what the system should do.

* Software Design and Implementation: Designing the software structure and writing the code.

* Software Validation: Checking that the software meets its specifications and user needs.

* Software Evolution: Modifying the software to reflect changing customer and market requirements.

* Generic Process Models:

* Waterfall Model: A linear sequential approach where each phase must be completed before the next begins.

* Phases: Requirements definition, System and software design, Implementation and unit testing, Integration and system testing, Operation and maintenance.

* Pros: Simple, easy to manage for well-understood requirements.

* Cons: Inflexible, difficult to accommodate changes, late discovery of errors.

* Incremental Development: Combines elements of the waterfall model with iterative development. The system is developed in increments, with each increment adding functionality.

* Phases: Specification, Development, Validation (repeated for each increment).

* Pros: Rapid feedback, lower risk of project failure, faster delivery of essential functionality.

* Cons: Can lack overall architectural coherence, requires clear definition of increments.

* Reuse-Oriented Software Engineering: Focuses on maximizing the reuse of existing software components.

* Phases: Component analysis, Requirements modification, System design with reuse, Development and integration.

* Pros: Reduced cost and risk, faster delivery.

* Cons: Requires a robust component database, potential for integration issues.

* Process Improvement: A continuous cycle of measuring, analyzing, changing, and re-measuring the software process to enhance efficiency and quality.

* CMMI (Capability Maturity Model Integration): A framework for process improvement, defining five maturity levels:

1. Initial: Processes are unpredictable and reactive.

2. Managed: Processes are planned and executed according to policy.

3. Defined: Processes are well-characterized and understood.

4. Quantitatively Managed: Processes are measured and controlled.

5. Optimizing: Processes are continuously improved.

Agile methods are iterative approaches to software development that prioritize flexibility, customer collaboration, and rapid delivery of working software.

* Principles: Customer involvement, incremental delivery, people not process, embrace change, maintain simplicity.

* Agile Manifesto:

* Individuals and interactions over processes and tools.

* Working software over comprehensive documentation.

* Customer collaboration over contract negotiation.

* Responding to change over following a plan.

* Scrum: A popular agile framework.

* Roles:

* Product Owner: Represents stakeholders, manages the Product Backlog.

* Scrum Master: Facilitates the Scrum process, removes impediments.

* Development Team: Self-organizing, cross-functional team that builds the increment.

* Artifacts:

* Product Backlog: Prioritized list of all desired features.

* Sprint Backlog: Subset of the Product Backlog selected for a specific sprint.

* Increment: The sum of all Product Backlog items completed during a sprint and previous sprints.

* Events:

* Sprint: A time-boxed iteration (typically 2-4 weeks).

* Sprint Planning: Team plans work for the upcoming sprint.

* Daily Scrum: Short daily meeting to synchronize activities and plan for the next 24 hours.

* Sprint Review: Team demonstrates completed work to stakeholders.

* Sprint Retrospective: Team reflects on the sprint and identifies improvements.

The process of discovering, analyzing, documenting, and managing system requirements.

* Types of Requirements:

* User Requirements: High-level statements in natural language and diagrams of what services the system should provide and its operational constraints.

* System Requirements: More detailed descriptions of the system's functions, services, and operational constraints, often used as a contract.

* Functional Requirements: Describe the functions that the system must perform.

* Non-functional Requirements: Constraints on the services or functions offered by the system, such as performance, security, reliability, and usability.

* Product Requirements: Performance, reliability, usability, security.

* Organizational Requirements: Operational, environmental, developmental.

* External Requirements: Ethical, legislative, privacy.

* Requirements Engineering Processes:

* Feasibility Study: Assesses if the system is technically and financially viable.

* Elicitation and Analysis: Discovering requirements from stakeholders. Techniques include interviewing, scenarios, ethnography, and use cases.

* Specification: Documenting the requirements clearly and precisely. Methods include natural language, structured natural language, design description languages, graphical notations (UML), and mathematical specifications.

* Validation: Checking that the requirements are complete, consistent, and reflect stakeholder needs. Techniques include reviews, prototyping, and test-case generation.

* Requirements Management: Planning and controlling changes to requirements throughout the system lifecycle.

Creating abstract models of a system to understand its structure and behavior.

* UML (Unified Modeling Language): A standard graphical notation for modeling object-oriented systems.

* Context Models: Illustrate the operational context of a system, showing its boundaries and external entities.

* Interaction Models: Describe how users interact with the system and how the system components interact with each other.

* Use Case Diagrams: Show the interactions between actors (users or other systems) and the system's use cases (functions).

* Sequence Diagrams: Show the sequence of interactions between objects in a time-ordered manner.

* Structural Models: Illustrate the organization and architecture of a system.

* Class Diagrams: Show the classes in a system, their attributes, operations, and relationships (association, aggregation, composition, inheritance).

* Behavioral Models: Describe the dynamic behavior of the system.

* State Diagrams: Show how a system or object changes its state in response to events.

The process of defining the fundamental structure of a software system, including its components, their relationships, and the principles guiding its design and evolution.

* Architectural Views: Different perspectives on the system architecture (e.g., logical, process, development, physical views).

* Architectural Patterns: Reusable solutions to common architectural problems.

* Layered Architecture: Organizes the system into layers, each providing services to the layer above it (e.g., Presentation, Application, Business Logic, Data Access).

* Repository Architecture: Components share a common data store (repository).

* Client-Server Architecture: A distributed system where clients request services from servers.

* Pipe and Filter Architecture: Data flows through a sequence of processing steps (filters), each transforming the data.

* Application Architectures: Specific architectural styles for common application types, such as transaction processing systems and language processing systems.

The stage where the software architecture is translated into a detailed design and then coded.

* Object-Oriented Design (OOD): A design paradigm based on objects, which are instances of classes. Key concepts include:

* Classes: Blueprints for objects, defining attributes (data) and operations (methods).

* Objects: Instances of classes.

* Inheritance: A mechanism where a new class (subclass) derives properties and behavior from an existing class (superclass).

* Polymorphism: The ability of an object to take on many forms, allowing methods to behave differently based on the object type.

* Design Principles (SOLID): A set of principles for object-oriented design to make software more understandable, flexible, and maintainable.

* S - Single Responsibility Principle: A class should have only one reason to change.

* O - Open/Closed Principle: Software entities should be open for extension but closed for modification.

* L - Liskov Substitution Principle: Subtypes must be substitutable for their base types without altering the correctness of the program.

* I - Interface Segregation Principle: Clients should not be forced to depend on interfaces they do not use.

* D - Dependency Inversion Principle: High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.

* Implementation Issues: Practical considerations during coding, such as programming language choice, development environment, configuration management, and host-target development.

The process of executing a program with the intent of finding errors.

* Goals of Testing:

* Verification: Checking that the software meets its specifications.

* Validation: Checking that the software meets user expectations.

* Defect Detection: Finding bugs and errors.

* Testing Process:

* Unit Testing: Testing individual components or modules in isolation.

* Component Testing: Testing integrated components.

* System Testing: Testing the complete integrated system.

* Acceptance Testing: Formal testing conducted by users to verify the system meets business requirements.

* Testing Strategies:

* Black-box Testing (Functional Testing): Testing based on the system's specifications without knowledge of its internal structure.

* White-box Testing (Structural Testing): Testing based on the internal structure and logic of the code.

* Test-Driven Development (TDD): A development practice where tests are written before the code, driving the design and implementation.

The process of changing a software system after it has been delivered to the customer.

* Evolution Processes: Change identification, impact analysis, change implementation, release planning.

* Lehman's Laws of Software Evolution: Eight laws describing the dynamics of software systems, such as continuing change, increasing complexity, and self-regulation.

* Continuing Change: E-type systems must be continually adapted or they become progressively less useful.

* Increasing Complexity: As an E-type system evolves, its complexity increases unless work is done to reduce it.

* Self-Regulation: The evolution process is self-regulating, with feedback mechanisms.

* Conservation of Organizational Stability: The average effective global activity rate in an evolving system is invariant.

* Conservation of Familiarity: The increment of change in an evolving system is roughly constant.

* Continuing Growth: The functional content of E-type systems must be continually increased to maintain user satisfaction.

* Declining Quality: The quality of E-type systems will appear to be declining unless they are rigorously maintained.

* Feedback System: E-type evolution processes constitute multi-level, multi-loop feedback systems.

* Software Maintenance: The modification of a software product after delivery to correct faults, improve performance or other attributes, or adapt the product to a modified environment.

* Types: Corrective (fixing bugs), Adaptive (adapting to new environments), Perfective (improving functionality/performance), Preventive (preventing future problems).

* Maintenance Costs: Often exceed development costs, influenced by factors like team stability, program age, and documentation quality.

The application of knowledge, skills, tools, and techniques to project activities to meet project requirements.

* Activities: Planning, Organizing, Staffing, Directing, Controlling.

* Project Planning: Defining project scope, schedule, resources, risks, and quality objectives.

* Project Scheduling: Creating a timetable for project activities.

* Gantt Charts: Bar charts illustrating project schedules.

* PERT (Program Evaluation and Review Technique): A method to analyze the tasks involved in completing a given project, especially the time needed to complete each task, and to identify the minimum time needed to complete the total project.

* CPM (Critical Path Method): Identifies the longest sequence of dependent activities (critical path) that determines the minimum project duration.

* Risk Management: Identifying, analyzing, planning for, and monitoring potential risks.

* Types of Risks: Project risks (affect schedule/resources), Product risks (affect quality/performance), Business risks (affect organizational viability).

* Quality Management: Ensuring that the software product meets specified quality standards.

* Activities: Quality Planning, Quality Assurance, Quality Control.

* Standards: ISO 9000, CMMI.

* Configuration Management: Managing changes to software artifacts throughout the development lifecycle.

* Activities: Version control, System building, Change management, Release management.

* Software Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

* Software Process: A structured set of activities required to develop a software system, typically including specification, design, implementation, validation, and evolution.

* Software Process Model: A simplified, abstract representation of a software process, presenting a particular perspective on the process.

* Agile Software Development: A group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

* Scrum: An agile framework for managing complex knowledge work, emphasizing iterative, incremental delivery and continuous improvement.

* Requirements Engineering: The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

* Functional Requirements: Statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations.

* Non-functional Requirements: Constraints on the services or functions offered by the system, such as timing constraints, constraints on the development process, and standards.

* UML (Unified Modeling Language): A standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, particularly object-oriented systems.

* Architectural Design: The process of defining the fundamental structure of a software system, including its components, their external properties, and the relationships among them.

* Object-Oriented Design (OOD): A design approach that structures software around objects, which encapsulate data and behavior, and interact through messages.

* SOLID Principles: A set of five design principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) intended to make software designs more understandable, flexible, and maintainable.

* Software Testing: The process of executing a program with the intent of finding errors, verifying that the software meets its specifications, and validating that it meets user needs.

* Software Evolution: The process of changing a software system after it has been delivered to the customer, encompassing maintenance and continuous adaptation.

* Software Maintenance: Modifications made to a software product after delivery to correct faults, improve performance or other attributes, or adapt the product to a modified environment.

* Project Management: The application of knowledge, skills, tools, and techniques to project activities to meet project requirements, including planning, organizing, staffing, directing, and controlling.

* Risk Management: The process of identifying, analyzing, planning for, and monitoring potential risks that could impact a project's success.

* Configuration Management: A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

* Generic vs. Customized Software Products:

* Example (Generic): Microsoft Word, Adobe Photoshop, AutoCAD. These are off-the-shelf products sold to a broad market.

* Example (Customized): An air traffic control system for a specific airport, an embedded control system for a unique industrial machine. These are developed for a particular client's unique needs.

* Waterfall Model Application:

* Application: Ideal for projects with very stable and well-understood requirements, such as embedded systems with fixed hardware where changes are costly. For instance, software for medical devices that undergo rigorous regulatory approval processes.

* Incremental Development Application:

* Application: Web-based e-commerce systems where initial core functionality (e.g., product catalog, shopping cart) can be delivered quickly, and then features like user reviews, recommendation engines, and payment gateway integrations are added in subsequent increments. This allows for early user feedback and market entry.

* Reuse-Oriented Software Engineering Application:

* Application: Developing enterprise resource planning (ERP) systems or customer relationship management (CRM) systems by integrating commercial off-the-shelf (COTS) components for modules like accounting, inventory, or sales, rather than building them from scratch.

* Scrum in Agile Development:

* Application: A software company developing a new mobile application might use Scrum. The Product Owner defines features in the Product Backlog. The Development Team works in 2-week Sprints, delivering a working increment of the app (e.g., login functionality in Sprint 1, user profile in Sprint 2). Daily Scrums ensure coordination, and Sprint Reviews gather feedback from stakeholders.

* UML Use Case Diagram:

* Application: For an online banking system, a use case diagram would show actors like "Customer" and "Bank Teller" interacting with use cases such as "Withdraw Funds," "Deposit Funds," "Check Balance," and "Transfer Money." This helps define the system's functional scope from a user perspective.

* UML Sequence Diagram:

* Application: To model the "Withdraw Funds" use case, a sequence diagram would show the interaction sequence: Customer enters PIN, ATM verifies PIN with Bank Server, Bank Server checks balance, ATM dispenses cash, Bank Server updates balance, ATM prints receipt. This illustrates the dynamic flow of messages between objects.

* Layered Architecture:

* Application: Most enterprise web applications follow a layered architecture. The "Presentation Layer" handles the user interface (e.g., web browser). The "Application Layer" manages business logic. The "Business Logic Layer" contains core business rules. The "Data Access Layer" interacts with the database. This separation of concerns improves maintainability and scalability.

* Client-Server Architecture:

* Application: A typical web application where a web browser (client) requests web pages and data from a web server (server). The server processes the request and sends back the appropriate response.

* SOLID Principles in Object-Oriented Design:

* Application (Single Responsibility Principle): Instead of having one `Report` class that handles both generating the report data and formatting it for printing, separate it into a `ReportDataGenerator` class and a `ReportFormatter` class. Each class now has only one reason to change.

* Black-box Testing:

* Application: Testing a login screen by entering valid and invalid usernames/passwords to ensure it correctly authenticates users and displays appropriate error messages, without knowing the underlying code logic.

* White-box Testing:

* Application: Testing a function that calculates a discount by creating test cases that cover all possible branches in the `if-else` statements within the function's code, ensuring each path is executed and produces the correct result.

* Gantt Chart:

* Application: A project manager uses a Gantt chart to visualize the schedule for developing a new software module. It shows tasks like "Design Database," "Develop API," "Implement UI," with their start/end dates and dependencies, helping track progress and identify potential delays.

The "Software Engineering (SEN 201)" document provides a comprehensive and structured introduction to the discipline of software engineering, emphasizing a systematic approach to software development, operation, and maintenance. It begins by defining software engineering according to IEEE standards, highlighting its critical importance in managing the complexity, cost, and reliability of modern software systems. The document distinguishes between generic and customized software products and outlines key attributes of good software, such as maintainability, dependability, efficiency, and usability, while also addressing the ethical responsibilities of software professionals through the ACM/IEEE Code of Ethics.

A significant portion of the document is dedicated to Software Process Models, which are frameworks for organizing the activities involved in software development. It details the traditional Waterfall Model, explaining its sequential phases (requirements, design, implementation, testing, maintenance) and its suitability for projects with stable requirements, alongside its limitations in handling change. In contrast, Incremental Development is presented as an iterative approach that delivers software in successive increments, allowing for early feedback and reduced risk. The Reuse-Oriented Software Engineering model is also discussed, focusing on leveraging existing components to accelerate development and reduce costs. The concept of Process Improvement and the CMMI (Capability Maturity Model Integration) framework are introduced as means to continuously enhance software development processes through five maturity levels.

The document then transitions to Agile Software Development, a modern paradigm emphasizing flexibility, customer collaboration, and rapid delivery of working software. It covers the core principles of the Agile Manifesto and delves into Scrum, a popular agile framework. Scrum's key elements are explained, including its roles (Product Owner, Scrum Master, Development Team), artifacts (Product Backlog, Sprint Backlog, Increment), and events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), illustrating how it facilitates iterative and adaptive development.