Topic 1: Introduction - Nature of Software

The first topic in the Software Engineering course introduces the Nature of Software, which lays the
foundation for understanding what software is, its characteristics, and why it requires a disciplined
engineering approach. Software is a critical component of modern systems, and its unique properties
distinguish it from other engineering artifacts like bridges or cars. Below, I’ll explain the nature of
software in detail, including its definitions, characteristics, types, and challenges, supplemented with
examples.

What is Software?
Software is a set of instructions (programs) that, when executed, provides desired features, functions,
and performance. It includes not just the executable code but also associated data and documentation
that make it operational and maintainable. According to Ian Sommerville in Software Engineering (10th
Edition), software is "more than just a program code; it includes all the documentation and configuration
data needed to make it work correctly."
Software can be thought of as:
• Instructions (Code): The logic that directs hardware to perform tasks.
• Data Structures: Enable efficient management and manipulation of information.
• Documentation: Guides users and developers on how to use and maintain the software.
Example: Consider Microsoft Word. The software includes the executable program (code), data
structures to manage text and formatting, and user manuals or help files (documentation).

Characteristics of Software
Software differs from physical products due to its intangible and malleable nature. Sommerville identifies
several key characteristics:
1. Software is Developed or Engineered, Not Manufactured:
o Unlike hardware, software isn’t "built" on an assembly line. It’s crafted through
intellectual effort, design, and coding.
o Example: Writing a mobile app like a calculator involves designing algorithms and coding
them, not physically assembling parts.
2. Software Doesn’t Wear Out:
o Hardware degrades over time due to physical wear, but software doesn’t. However, it
can become obsolete or "decay" due to changing requirements or bugs.
o Example: An old version of Windows (e.g., XP) still "works" technically but is outdated
due to security vulnerabilities and lack of updates.
3. Software is Custom-Built:
o Most software is tailored to specific needs rather than mass-produced as standard
components.
o Example: A payroll system designed for a specific company includes unique features like
tax rules or employee benefits specific to that organization.
4. Complexity:
o Software can be incredibly intricate, with millions of lines of code interacting in
unpredictable ways.
o Example: The Linux kernel has over 20 million lines of code, managing everything from
file systems to network protocols.
 5. Flexibility and Changeability:
o Software can be modified easily compared to hardware, but frequent changes can
introduce errors.
o Example: Adding a new feature to an e-commerce website (e.g., a discount calculator) is
possible but might break existing payment logic if not tested properly.

Types of Software
Software can be categorized based on its purpose and usage. Sommerville and Ghezzi et al.
(Fundamentals of Software Engineering) outline several types:
1. System Software:
o Manages hardware and provides a platform for other software (e.g., operating systems).
o Example: Windows 11 or Red Hat Enterprise Linux manages hardware resources like CPU
and memory.
2. Application Software:
o Solves specific user problems or performs tasks.
o Example: A student grade management system built for a university.
3. Embedded Software:
o Controls devices and is embedded within hardware.
o Example: Firmware in a smart thermostat that adjusts temperature based on sensor
data.
4. Web and Mobile Applications:
o Software accessed via browsers or mobile devices.
o Example: Google Chrome or a weather app on your phone.
5. Artificial Intelligence Software:
o Incorporates machine learning or reasoning.
o Example: A chatbot like me (Grok) built by xAI to assist users.

Challenges in Software Development

The nature of software introduces unique challenges:
• Evolving Requirements: Users often change their minds about what they want.
o Example: A client asks for a simple website but later requests an online store feature
mid-development.
• Invisibility: Software’s intangible nature makes it hard to visualize progress or problems.
o Example: A bug in a banking app might not be obvious until a transaction fails.
• Quality Assurance: Ensuring reliability, security, and performance is complex.
o Example: A game like Cyberpunk 2077 launched with bugs because testing couldn’t
cover all scenarios.
• Maintenance: Software needs updates to fix bugs or adapt to new environments.
o Example: Regular updates to antivirus software to combat new threats.

Why Study the Nature of Software?

Understanding the nature of software is crucial for software engineering because it:
• Highlights why traditional engineering approaches don’t fully apply.
 • Emphasizes the need for structured processes (e.g., Waterfall, Agile) to manage complexity and
change.
• Prepares students to tackle real-world software problems systematically.
Practical Example for BSIT Students: Imagine you’re tasked with building a library management system
for your university. It’s not just about coding a program to track books—it involves:
• Understanding user needs (librarians, students).
• Designing flexible features (e.g., book search, fine calculation).
• Ensuring it doesn’t "wear out" by making it maintainable for future updates (e.g., adding e-books
later).

Key Takeaways
• Software is an intangible, engineered product that’s complex and adaptable.
• Its unique nature (no wear-out, custom-built, invisible) drives the need for software engineering
practices.
• Examples like operating systems, apps, and embedded firmware illustrate its diversity and
challenges.

Topic 2: Overview of Software Engineering

The second topic in the Software Engineering course provides an Overview of Software Engineering,
building on the understanding of the nature of software. This section introduces the discipline of
software engineering, its goals, principles, and how it addresses the challenges of developing high-
quality software systematically and efficiently. Below, I’ll explain the concept in detail, including its
definition, importance, key activities, and examples to make it relatable for BSIT students.

What is Software Engineering?

Software engineering is the application of a systematic, disciplined, and quantifiable approach to the
development, operation, and maintenance of software. Ian Sommerville (Software Engineering, 10th
Edition) defines it as "an engineering discipline that is concerned with all aspects of software production
from the early stages of system specification through to maintaining the system after it has gone into
use."
In simpler terms, software engineering is about:
• Turning ideas into working software.
• Managing the complexity and unpredictability of software development.
• Ensuring the software meets user needs and performs reliably.
Example: Building a ride-sharing app like Uber isn’t just about coding—it involves planning, designing,
testing, and maintaining the app to ensure it works for millions of users across different devices.

Why Software Engineering?

The nature of software (complex, invisible, changeable) makes ad-hoc development risky and inefficient.
Software engineering emerged to:
1. Handle Complexity: Large-scale software (e.g., operating systems) requires structured methods
to avoid chaos.
2. Ensure Quality: Users expect software to be reliable, secure, and efficient.
3. Control Costs and Time: Unplanned development often leads to delays and budget overruns.
 4. Support Maintenance: Software must evolve over time without breaking.
Example: Imagine coding a student portal without a plan. You might finish the login page, only to realize
later that the database can’t handle thousands of users—software engineering prevents such oversights
by planning ahead.

Key Characteristics of Software Engineering

According to Carlo Ghezzi et al. (Fundamentals of Software Engineering), software engineering
combines:
• Science: Using proven theories and models (e.g., algorithms, data structures).
• Engineering: Applying practical techniques to build reliable systems.
• Management: Coordinating people, resources, and timelines.
It’s distinct from programming because it encompasses the entire lifecycle, not just coding.
Example: A programmer writes code for a game, but a software engineer designs the game’s
architecture, tests it for bugs, and ensures it runs on multiple platforms.

Core Activities in Software Engineering

Software engineering involves a set of interconnected activities, often referred to as the software
development lifecycle (SDLC). Sommerville outlines these key processes:
1. Specification (Requirements Engineering):
o Defining what the software should do.
o Example: For a university app, specifying features like “view grades” or “register for
courses.”
2. Design and Development:
o Planning the software’s structure and writing the code.
o Example: Designing a database schema for student records and coding the app’s
backend.
3. Validation (Testing):
o Ensuring the software works as intended and meets requirements.
o Example: Testing the app to confirm students can log in and grades display correctly.
4. Evolution (Maintenance):
o Updating the software to fix bugs, add features, or adapt to new environments.
o Example: Adding a “pay tuition online” feature to the university app after launch.
These activities are iterative and may overlap, depending on the process model used (e.g., Waterfall or
Agile).

Software Engineering vs. Other Disciplines

• Compared to Civil Engineering: Both aim to build reliable systems, but software lacks physical
constraints and is more flexible.
• Compared to Computer Science: Computer science focuses on theory (e.g., algorithms), while
software engineering applies those theories practically.
Example: A computer scientist might invent a new sorting algorithm, while a software engineer uses it to
optimize a search feature in an e-commerce app.

Importance of Software Engineering

Software engineering is critical because:
• Economic Impact: Poorly engineered software leads to costly failures (e.g., the 1999 Mars
Climate Orbiter crash due to a unit conversion error cost NASA $327 million).
• User Dependence: People rely on software for daily tasks (e.g., banking apps, GPS).
• Scalability: Modern systems (e.g., cloud platforms like AWS) require engineering rigor to handle
millions of users.
Real-World Example: The Healthcare.gov website launch in 2013 failed due to inadequate planning and
testing, costing millions to fix—proper software engineering could have prevented this.

Principles of Software Engineering

Software engineering is guided by principles to ensure success:
1. Modularity: Break software into manageable pieces.
o Example: Separating a website’s login, database, and UI into distinct modules.
2. Abstraction: Focus on essential details, hiding complexity.
o Example: Using a simple “send email” function without worrying about SMTP protocols.
3. Reusability: Design components that can be used in multiple projects.
o Example: A login system reused across different university apps.
4. Verification and Validation: Check that the software is built right (verification) and meets user
needs (validation).

Practical Example for BSIT Students

Suppose you’re tasked with creating a library management system:
• Without Software Engineering: You jump straight to coding, miss key features (e.g., overdue
fines), and deliver a buggy system late.
• With Software Engineering: You:
1. Gather requirements (e.g., “track books, notify users”).
2. Design a modular system (e.g., separate book database and user interface).
3. Test it (e.g., simulate borrowing a book).
4. Maintain it (e.g., add e-book support later).
This structured approach ensures the system is usable, reliable, and delivered on time.

Key Takeaways
• Software engineering is a disciplined approach to creating and maintaining software.
• It addresses the challenges of complexity, quality, and change through structured processes.
• Examples like ride-sharing apps, student portals, and library systems show its real-world
relevance.

Topic 3: Professional Software Development

The third topic in the Software Engineering course, Professional Software Development, shifts focus
from the theoretical foundations to the practical realities of developing software in a professional
context. This topic emphasizes the skills, tools, processes, and ethical considerations that distinguish
professional software development from casual or academic programming. Below, I’ll explore this topic
in detail, including its definition, key aspects, challenges, and examples tailored for BSIT students.
What is Professional Software Development?
Professional software development refers to the creation of software by individuals or teams within an
organized, structured, and often commercial or institutional environment. Ian Sommerville (Software
Engineering, 10th Edition) highlights that it involves applying software engineering principles to deliver
reliable, efficient, and maintainable software that meets client or user needs, often under constraints like
time, budget, and quality standards.
Unlike hobbyist programming (e.g., writing a small game for fun), professional development:
• Involves collaboration with stakeholders (clients, users, testers).
• Follows established processes and standards.
• Prioritizes long-term usability and maintainability.
Example: Developing a banking app isn’t just about coding transactions—it’s about ensuring security,
scalability, and compliance with financial regulations, all while meeting deadlines.

Key Aspects of Professional Software Development

Professional software development encompasses several critical elements:
1. Teamwork and Collaboration:
o Software is rarely built by one person. Teams include developers, designers, testers, and
project managers.
o Example: A team building an e-commerce platform splits tasks: one group designs the
UI, another codes the payment system, and testers verify functionality.
2. Systematic Processes:
o Professionals use frameworks like Waterfall, Agile, or DevOps to manage development.
o Example: An Agile team working on a mobile game releases small updates (sprints)
every two weeks based on user feedback.
3. Tools and Technologies:
o Version control (e.g., Git), IDEs (e.g., Visual Studio), and testing tools (e.g., JUnit) are
standard.
o Example: Using GitHub to collaborate on a university timetable app, tracking changes
and merging contributions from multiple developers.
4. Quality Assurance:
o Emphasis on testing, debugging, and meeting requirements (functional and non-
functional).
o Example: A hospital management system must be tested to ensure patient data is secure
and accessible 24/7.
5. Documentation:
o Essential for maintenance and handover, including user manuals and technical specs.
o Example: Documenting how a payroll system calculates taxes so future developers can
update it.
6. Ethical and Legal Responsibilities:
o Developers must consider privacy, security, and intellectual property laws.
o Example: Ensuring a social media app complies with GDPR by protecting user data.

Challenges in Professional Software Development

Professional software development faces unique hurdles:
 • Time and Budget Constraints: Clients expect delivery within deadlines and costs.
o Example: A startup needs a minimum viable product (MVP) in three months to secure
funding.
• Changing Requirements: Users or clients often modify needs mid-project.
o Example: A client requests a “dark mode” feature for an app after development starts.
• Scalability: Software must handle growth in users or data.
o Example: A video streaming service crashes if not designed for millions of simultaneous
viewers.
• Maintenance: Bugs and updates persist long after deployment.
o Example: Fixing a bug in a tax software after a new law changes calculations.

Roles in Professional Software Development

Professional projects involve various roles, each contributing to success:
• Software Developer: Writes and tests code.
o Example: Coding the search feature for an online bookstore.
• Project Manager: Oversees timelines, resources, and communication.
o Example: Ensuring a team delivers a CRM system by quarter-end.
• Quality Assurance (QA) Engineer: Tests software for defects.
o Example: Verifying a game doesn’t crash on low-end devices.
• Systems Analyst: Bridges client needs and technical solutions.
o Example: Translating a retailer’s inventory needs into software requirements.
Team Example: Building a university registration system might involve a developer coding the backend, a
QA engineer testing course enrollment, and a manager coordinating with university staff.

Professional Practices and Standards

Professional software development adheres to best practices:
1. Code Quality: Writing clean, readable, and reusable code.
o Example: Using meaningful variable names like studentGrade instead of x.
2. Version Control: Tracking changes to collaborate effectively.
o Example: Rolling back a buggy update to a shopping cart feature using Git.
3. Continuous Integration/Deployment (CI/CD): Automating testing and deployment.
o Example: Automatically deploying a weather app update after passing tests.
4. Agile Methodologies: Iterating based on feedback.
o Example: Releasing a beta version of a fitness app to gather user input.

Importance of Professionalism
Professional software development ensures:
• Reliability: Software works as expected (e.g., an ATM doesn’t lose money).
• User Satisfaction: Meets real-world needs (e.g., a navigation app gives accurate routes).
• Economic Viability: Balances cost, time, and quality (e.g., delivering a product within budget).
Real-World Example: The 737 MAX aircraft crashes (2018-2019) were partly due to software flaws and
poor engineering practices, costing Boeing billions and highlighting the stakes of professionalism.

Practical Example for BSIT Students

Imagine you’re part of a team developing a student attendance system:
• Hobbyist Approach: You hack together a script to track attendance, but it fails when 500
students use it simultaneously.
• Professional Approach:
1. Gather requirements from professors (e.g., “mark absences, generate reports”).
2. Use Git for team collaboration.
3. Design a scalable database and test it with mock data.
4. Document the system for future semesters.
5. Deliver on time for the academic year.
This mirrors a real job, preparing you for industry roles.

Key Takeaways
• Professional software development applies engineering principles in a structured, team-based
environment.
• It tackles challenges like deadlines, quality, and scalability with tools and processes.
• Examples like banking apps, e-commerce platforms, and attendance systems show its practical
impact.

Topic 4: Software Engineering Practice

The fourth topic in the Software Engineering course, Software Engineering Practice, focuses on the
practical application of software engineering principles and techniques to develop software effectively.
This topic bridges the theoretical aspects of software engineering with the hands-on skills and best
practices professionals use in real-world projects. Below, I’ll dive into the details, covering its definition,
core practices, essential activities, and examples tailored for BSIT students.

What is Software Engineering Practice?

Software engineering practice refers to the collection of methods, techniques, and guidelines that
professionals use to design, develop, test, and maintain software systems. Ian Sommerville (Software
Engineering, 10th Edition) emphasizes that it’s about "translating software engineering theory into
action" to produce reliable, efficient, and maintainable software under real-world constraints like time,
budget, and user expectations.
It’s the "how-to" of software engineering—applying knowledge systematically to solve problems.
Example: Building a weather app involves not just coding but also planning the architecture, testing for
accuracy, and ensuring it runs on various devices—all guided by software engineering practices.

Core Elements of Software Engineering Practice

Software engineering practice is built around several key elements:
1. Understanding the Problem:
o Before coding, engineers must fully grasp the problem they’re solving.
o Involves communication with stakeholders to define goals and constraints.
o Example: For a library system, understanding that librarians need to track overdue books
and students want a simple interface.
2. Planning and Modeling:
o Creating a blueprint (e.g., diagrams, prototypes) to guide development.
 o Reduces risks by anticipating challenges.
o Example: Sketching a flowchart for a student registration system to map out course
selection and payment steps.
3. Implementing Solutions:
o Writing clean, efficient code based on the plan.
o Emphasizes modularity and reusability.
o Example: Coding a reusable “login” module for multiple university apps.
4. Verification and Validation:
o Ensuring the software is built correctly (verification) and meets user needs (validation).
o Includes testing and reviews.
o Example: Testing a payroll system to confirm it calculates taxes accurately and meets
legal standards.
5. Managing Change:
o Adapting to evolving requirements or fixing issues post-deployment.
o Example: Updating an e-commerce app to handle a new payment method like
cryptocurrency.

Essential Software Engineering Practices

These practices, drawn from Sommerville and Carlo Ghezzi et al. (Fundamentals of Software
Engineering), form the backbone of professional development:
1. Requirements Analysis:
o Gathering and documenting what the software must do.
o Example: Interviewing teachers to list features for a gradebook app (e.g., “calculate
averages,” “export to PDF”).
2. Design Practices:
o Structuring the software into components (e.g., architecture, modules).
o Emphasizes simplicity and scalability.
o Example: Designing a modular online store with separate components for products, cart,
and checkout.
3. Coding Standards:
o Following conventions for readability and maintainability (e.g., naming variables clearly,
commenting code).
o Example: Using calculateTotalPrice() instead of ctp() in a shopping app.
4. Testing Practices:
o Systematically checking functionality, performance, and security.
o Example: Writing unit tests to verify a calculator app adds numbers correctly.
5. Configuration Management:
o Tracking versions and changes to code and documents.
o Example: Using Git to revert a buggy update in a chat app.
6. Review and Refactoring:
o Regularly inspecting code and improving it without changing functionality.
o Example: Simplifying a complex function in a game to make it easier to debug.

Tools Supporting Software Engineering Practice

Professionals rely on tools to execute these practices efficiently:
• Version Control Systems (VCS): Git, SVN (e.g., managing team contributions to a project).
• Integrated Development Environments (IDEs): Visual Studio, Eclipse (e.g., debugging a web
app).
• Testing Frameworks: JUnit, Selenium (e.g., automating tests for a login page).
• Project Management Tools: Jira, Trello (e.g., tracking tasks for a mobile game).
Example: A team uses GitHub to collaborate on a fitness app, Jira to assign tasks (e.g., “add step
counter”), and Selenium to test the UI across browsers.

Challenges in Software Engineering Practice

Applying these practices isn’t always straightforward:
• Balancing Speed and Quality: Rushing can lead to bugs.
o Example: Releasing a banking app too quickly might miss a security flaw.
• Team Coordination: Miscommunication can derail projects.
o Example: One developer codes in Python, another in Java, causing integration issues.
• Legacy Systems: Working with outdated codebases is tricky.
o Example: Updating a 1990s inventory system to support modern APIs.

Practical Example for BSIT Students

Imagine you’re tasked with developing a student feedback system for your university:
1. Understand the Problem: Meet with faculty to define needs (e.g., “anonymous feedback,”
“rating scale”).
2. Plan: Draw a UML diagram showing how feedback flows from students to a database.
3. Code: Write a modular system with a frontend (HTML/CSS) and backend (Python/Django).
4. Test: Check that feedback submits correctly and ratings average accurately.
5. Manage Change: Add a “view summary” feature after faculty request it.
Scenario: You use Git to track changes, test with dummy data (e.g., “Course was great, 5 stars”), and
refactor messy code (e.g., simplify a 50-line function into 10 lines). This mirrors professional workflows.

Why Software Engineering Practice Matters

• Reliability: Ensures software works under real conditions (e.g., a traffic app during rush hour).
• Efficiency: Saves time and resources by avoiding rework.
• Professionalism: Prepares students for industry expectations.
Real-World Example: The Ariane 5 rocket failure (1996) cost $370 million due to a software error from
poor practice (reusing untested code). Rigorous testing and review could have prevented it.

Key Takeaways
• Software engineering practice is the practical execution of engineering principles.
• It involves understanding problems, planning, coding, testing, and managing change.
• Examples like feedback systems, online stores, and weather apps show how practices lead to
success.

Topic 5: Software Process Structure

The fifth topic in the Software Engineering course, Software Process Structure, introduces the
framework that organizes the activities involved in software development. It provides a systematic way
to manage the complexity of building software by defining a sequence of steps, tasks, and deliverables.
Below, I’ll explain this topic in detail, covering its definition, components, types of process structures,
and examples tailored for BSIT students.

What is a Software Process?

A software process is a structured set of activities, methods, and practices used to develop, maintain,
and deliver software. Ian Sommerville (Software Engineering, 10th Edition) describes it as "the set of
activities and associated results that produce a software product." It’s like a recipe for cooking—without
a clear process, you might end up with a mess instead of a meal.
The process structure provides the "skeleton" for these activities, ensuring they’re performed in an
orderly, repeatable way.
Example: Developing a student portal involves steps like gathering requirements (e.g., “show grades”),
designing the system, coding it, and testing it—organized by a process structure.

Why Software Process Structure Matters

A well-defined process structure:
• Reduces Chaos: Coordinates tasks across teams and phases.
• Improves Quality: Ensures critical steps (e.g., testing) aren’t skipped.
• Enhances Predictability: Helps estimate time and resources.
• Supports Maintenance: Makes future updates easier.
Example: Without a process, a team building a mobile banking app might skip security testing, leading to
vulnerabilities.

Components of a Software Process Structure

According to Sommerville and Carlo Ghezzi et al. (Fundamentals of Software Engineering), a software
process typically includes four core activities, which are structured differently depending on the model
used:
1. Specification:
o Defining what the software should do (requirements).
o Example: Documenting that a library app must “track borrowed books” and “send
overdue reminders.”
2. Development (Design and Implementation):
o Designing the system and writing code.
o Example: Creating a database schema for books and coding a search feature.
3. Validation:
o Verifying the software works and meets requirements.
o Example: Testing the library app to ensure it flags overdue books correctly.
4. Evolution:
o Maintaining and updating the software over time.
o Example: Adding a “reserve book” feature after the app launches.
These activities are supported by process management (planning, monitoring) and tools (e.g., Git,
testing frameworks).
Generic Software Process Framework
Most process structures follow a generic framework:
• Inputs: Requirements, resources, and constraints.
• Activities: Tasks like analysis, design, coding, and testing.
• Outputs: Deliverables like code, documentation, or a working system.
• Roles: People involved (e.g., developers, testers).
• Milestones: Checkpoints to assess progress (e.g., “design complete”).
Example: For a university timetable app:
• Input: List of courses and schedules.
• Activity: Design a UI and code the backend.
• Output: A functional app.
• Role: UI designer, coder, tester.
• Milestone: Prototype ready for review.

Types of Software Process Structures

The way these activities are organized defines the process structure. Common approaches include:
1. Linear (Sequential):
o Activities occur one after another (e.g., Waterfall model).
o Example: Finish all requirements for a payroll system before starting design.
2. Iterative:
o Activities repeat in cycles, refining the software (e.g., Spiral, Incremental models).
o Example: Build a basic chat app, then add features like emojis in later iterations.
3. Evolutionary:
o Software evolves through prototypes or continuous feedback (e.g., Prototyping, Agile).
o Example: Release a rough version of a game, then polish it based on player input.
4. Parallel:
o Activities overlap or run simultaneously (e.g., Agile with multiple teams).
o Example: One team codes the frontend of an e-commerce site while another tests the
backend.

Characteristics of a Good Process Structure

• Adaptability: Fits the project’s size, complexity, and team.
• Clarity: Easy to understand and follow.
• Measurability: Allows tracking progress and quality.
• Flexibility: Handles changes in requirements.
Example: A small team building a calculator app might use a simple linear process, while a large team on
a cloud platform might need an iterative Agile structure.

Practical Example for BSIT Students

Imagine you’re developing a campus event management system:
• Process Structure: Iterative (to incorporate feedback).
• Steps:
1. Specification: List features (e.g., “create events,” “RSVP”).
 2. Development: Build a basic event creation page.
3. Validation: Test if events save correctly.
4. Evolution: Add RSVP functionality after student feedback.
• Tools: Use Git for version control and Trello to track tasks.
• Milestone: Demo a working prototype to the student council.
Scenario: You start with a linear plan but switch to iterative when students request a “share event”
feature mid-project—showing how process structure adapts.

Real-World Example
The development of Google Chrome followed an iterative process structure:
• Initial specification: A fast, secure browser.
• Development: Released basic versions with core features.
• Validation: Tested across platforms.
• Evolution: Added extensions and sync features over time.
Contrast this with a failed project like the UK’s NHS IT system (abandoned in 2011, costing £10 billion),
where a rigid linear structure couldn’t handle changing needs.

Key Takeaways
• Software process structure organizes development into manageable activities.
• It includes specification, development, validation, and evolution, tailored by the chosen model.
• Examples like event systems and browsers show how structure ensures success.

Topic 6: Software Process Models - Waterfall Model

The sixth topic in the Software Engineering course introduces Software Process Models, starting with
the Waterfall Model. This is one of the earliest and most structured approaches to software
development, often used as a baseline for understanding other models. Below, I’ll explain the Waterfall
Model in detail, including its definition, phases, advantages, disadvantages, and examples tailored for
BSIT students.

What is the Waterfall Model?

The Waterfall Model is a linear and sequential software development process where each phase must be
completed before the next begins, resembling a waterfall cascading downward. Introduced by Winston
Royce in 1970, it’s one of the first formalized process models. Ian Sommerville (Software Engineering,
10th Edition) describes it as "a plan-driven process where you plan everything in advance and then
execute it in a systematic way."
Think of it like building a house: you finish the foundation before the walls, and the walls before the
roof—no overlap.
Example: Developing a payroll system for a small company might follow the Waterfall Model—define all
requirements (e.g., tax calculations), design the system, code it, test it, and deploy it, step by step.

Phases of the Waterfall Model

The Waterfall Model typically consists of distinct phases, each producing a deliverable that feeds into the
next:
1. Requirements Analysis and Specification:
 o Gather and document all system requirements.
o Output: Requirements document.
o Example: For a library app, specify “track books,” “calculate fines,” and “generate
reports.”
2. System Design:
o Create a detailed blueprint (architecture, modules, interfaces).
o Output: Design specification.
o Example: Design a database schema for books and a UI layout for the app.
3. Implementation (Coding):
o Write the actual code based on the design.
o Output: Working software.
o Example: Code the library app using Python for the backend and HTML/CSS for the
frontend.
4. Integration and Testing:
o Combine modules and test the system for bugs and compliance with requirements.
o Output: Tested software.
o Example: Test if the app correctly flags overdue books and generates fine reports.
5. Deployment:
o Install the software in the production environment.
o Output: Deployed system.
o Example: Install the library app on university servers for staff use.
6. Maintenance:
o Fix bugs and update the software as needed.
o Output: Updated system.
o Example: Add a “renew book” feature after deployment.
Note: Royce’s original model included feedback loops (e.g., revisiting design if testing fails), but the
classic Waterfall is often interpreted as strictly sequential.

Characteristics of the Waterfall Model

• Sequential: One phase ends before the next starts.
• Plan-Driven: Requires thorough upfront planning.
• Document-Heavy: Produces detailed deliverables at each stage.
• Milestone-Based: Progress is measured by phase completion.
Example: A team building a tax software might spend weeks documenting requirements (e.g., tax laws)
before any coding begins.

Advantages of the Waterfall Model

1. Simplicity and Clarity:
o Easy to understand and manage due to its linear flow.
o Example: A small team can follow a clear checklist for a simple calculator app.
2. Well-Defined Requirements:
o Works best when requirements are stable and fully known upfront.
o Example: A government contract for a records system with fixed specs.
3. Strong Documentation:
 o Useful for projects needing traceability or handover.
o Example: A medical system where every step must be auditable.
4. Early Problem Detection:
o Issues in requirements or design are caught before coding.
o Example: Spotting a missing “export data” feature in the design phase of a reporting
tool.

Disadvantages of the Waterfall Model

1. Inflexibility:
o Hard to accommodate changes once a phase is complete.
o Example: If users want “dark mode” in a finished app, you can’t easily backtrack.
2. Late Feedback:
o Users see the product only after deployment, risking misalignment.
o Example: A delivered student portal lacks a requested “drop course” feature.
3. High Risk:
o Errors found late (e.g., in testing) are costly to fix.
o Example: A bug in a banking app’s interest calculation discovered after coding.
4. Not Suited for Complex Projects:
o Struggles with uncertainty or evolving needs.
o Example: A social media app with shifting trends can’t wait months for a full cycle.

When to Use the Waterfall Model

• Stable Requirements: Projects with clear, unchanging needs (e.g., embedded systems in
hardware).
• Small or Simple Projects: Less complexity reduces risks.
• Regulated Environments: Where documentation and audits are critical (e.g., aerospace,
healthcare).
Example: Developing firmware for a thermostat—requirements (e.g., “adjust temperature”) are fixed,
and safety standards demand a rigid process.

Practical Example for BSIT Students

Imagine you’re tasked with building a grade reporting system for your university using the Waterfall
Model:
1. Requirements: Document needs like “enter grades,” “calculate GPA,” and “export reports.”
2. Design: Plan a database for student records and a web interface.
3. Implementation: Code the system using PHP and MySQL.
4. Testing: Verify GPA calculations and test with sample data (e.g., “Alice: 3.5 GPA”).
5. Deployment: Install it on the university server.
6. Maintenance: Fix a bug where grades don’t save properly.
Scenario: You finish the design phase and realize professors want a “comments” field. Since
requirements are locked, you’d need to wait for version 2—highlighting Waterfall’s rigidity.

Real-World Example
 • Success: NASA’s early space missions (e.g., Apollo) used Waterfall-like processes for software
controlling hardware—requirements were fixed, and documentation was critical.
• Failure: The UK’s NHS Connecting for Health project (2000s) aimed for a national IT system but
collapsed partly due to Waterfall’s inability to handle shifting healthcare needs.

Key Takeaways
• The Waterfall Model is a linear, plan-driven approach with distinct phases.
• It excels with stable requirements and documentation needs but struggles with change.
• Examples like grade systems and thermostats show its practical use and limitations.

Topic 7: Software Process Models - Incremental Model

The seventh topic in the Software Engineering course continues the exploration of Software Process
Models with the Incremental Model. This model builds on the limitations of the Waterfall Model by
introducing an iterative approach, allowing software to be developed and delivered in smaller,
manageable increments. Below, I’ll explain the Incremental Model in detail, including its definition,
phases, advantages, disadvantages, and examples tailored for BSIT students.

What is the Incremental Model?

The Incremental Model is a software development process where the system is designed, implemented,
and tested in small, incremental portions rather than all at once. Ian Sommerville (Software Engineering,
10th Edition) describes it as "a process where the software is developed and delivered in increments,
with each increment adding functionality to the previous one." It combines elements of the Waterfall
Model’s structure with iterative refinement.
Think of it like building a car piece by piece: you start with the chassis, add the engine, then the
wheels—testing each part as you go—rather than assembling the whole car before testing.
Example: Developing a student management system might start with a basic “student registration”
feature, then add “grade entry,” and later “report generation,” delivering usable versions at each step.

How the Incremental Model Works

The Incremental Model breaks development into a series of mini-cycles, each following a Waterfall-like
sequence but focusing on a subset of features:
1. Requirements Analysis:
o Gather all requirements upfront, but prioritize them into increments.
o Example: For a library app, list “borrow books,” “return books,” and “fine calculation,”
then decide “borrow books” comes first.
2. Design:
o Plan the architecture for the entire system, but design details for the current increment.
o Example: Design a database and UI for “borrow books” first.
3. Implementation:
o Code and build the increment.
o Example: Code the borrowing feature with a simple interface.
4. Testing:
o Test the increment to ensure it works and integrates with previous increments.
o Example: Test that users can borrow books and the system tracks them.
 5. Delivery:
o Deploy the working increment for use.
o Example: Release the borrowing feature to librarians.
6. Repeat:
o Return to design for the next increment (e.g., “return books”), building on the existing
system.
Each increment adds functionality, and the process continues until the full system is complete.

Characteristics of the Incremental Model

• Iterative: Builds the system in cycles, refining it over time.
• Incremental Delivery: Users get usable software early and often.
• Flexible: Can adjust later increments based on feedback.
• Cumulative: Each increment integrates with previous ones.
Example: A team building a game might release a basic version with one level, then add more levels and
features in later increments.

Advantages of the Incremental Model

1. Early Delivery of Core Features:
o Users can start using parts of the system sooner.
o Example: A banking app delivers “view balance” first, then adds “transfer money” later.
2. Flexibility:
o Easier to adapt to changing requirements within later increments.
o Example: If students want a “course feedback” feature mid-project, it can be added in
the next increment.
3. Reduced Risk:
o Problems are caught early in smaller chunks, not at the end.
o Example: A bug in “grade entry” is fixed before coding “report generation.”
4. Customer Feedback:
o Early increments provide insights to improve later ones.
o Example: Users test a shopping cart and suggest adding a “save for later” option.
5. Easier Testing:
o Smaller increments are simpler to test than a full system.
o Example: Testing just the “login” feature before adding “profile management.”

Disadvantages of the Incremental Model

1. Upfront Planning Required:
o Core architecture must be solid from the start to support all increments.
o Example: A poorly designed database for a store app might break when adding “order
history.”
2. Integration Challenges:
o Combining increments can introduce conflicts.
o Example: Adding “fine calculation” to a library app might clash with the “borrow books”
code.
3. Higher Management Overhead:
 o Coordinating multiple deliveries takes effort.
o Example: Tracking progress across five increments for a large CRM system.
4. Costly if Misplanned:
o Badly chosen increments can waste resources.
o Example: Building “fancy UI” first instead of “core functionality” delays usable software.

When to Use the Incremental Model

• Large Projects: Break complexity into manageable parts.
• Uncertain Requirements: Start with known features, refine others later.
• Early Delivery Needed: Clients want usable software quickly.
• Risk Mitigation: Test critical components first.
Example: A startup building a fitness app might use increments to release “step tracking” first, then
“calorie counting,” ensuring early user adoption.

Practical Example for BSIT Students

Imagine you’re developing a campus event app using the Incremental Model:
• Increment 1: Event Listing
o Requirements: “List upcoming events.”
o Design: Simple UI and database.
o Code: Display events like “Career Fair, March 10.”
o Test: Verify events load correctly.
o Deliver: Release to students.
• Increment 2: RSVP Feature
o Add “RSVP to events” to the existing app.
o Test integration with event listing.
o Deliver updated version.
• Increment 3: Notifications
o Add reminders for RSVP’d events.
Scenario: After Increment 1, students request “event categories” (e.g., “sports,” “academic”). You adjust
Increment 2 to include it—showing flexibility.

Real-World Example
• Microsoft Windows: Early versions (e.g., Windows 1.0) delivered basic features (GUI, file
management), with increments adding multitasking, networking, etc.
• Contrast with Waterfall Failure: The FBI’s Virtual Case File system (2000s) used a rigid Waterfall
approach and failed ($170 million lost), while an incremental approach might have salvaged it
with early usable parts.

Key Takeaways
• The Incremental Model builds software in small, testable, deliverable chunks.
• It offers flexibility and early feedback but requires careful planning.
• Examples like event apps and Windows show its practical value.

Topic 8: Software Process Models - Prototyping Model

The eighth topic in the Software Engineering course continues the discussion of Software Process
Models with the Prototyping Model. This model emphasizes building early, simplified versions of the
software—prototypes—to refine requirements and design through user feedback. Below, I’ll explain the
Prototyping Model in detail, including its definition, process, types, advantages, disadvantages, and
examples tailored for BSIT students.

What is the Prototyping Model?

The Prototyping Model is a software development approach where a working prototype (a preliminary
version of the system) is created early in the process to explore requirements, test ideas, and gather user
feedback before building the final product. Ian Sommerville (Software Engineering, 10th Edition)
describes it as "a process that helps developers and users understand requirements by building and
evaluating prototypes."
Think of it like sketching a rough draft of a painting: you show it to the client, adjust based on their input,
and then create the masterpiece.
Example: For a university app, you might build a basic prototype with a “course schedule” feature to see
if students like the layout before coding the full system.

How the Prototyping Model Works

The Prototyping Model follows an iterative process:
1. Requirements Gathering:
o Collect initial, often vague, requirements from stakeholders.
o Example: Students say they want “easy access to grades” but aren’t specific.
2. Prototype Design:
o Quickly create a simple, functional version focusing on key features.
o Example: Design a basic UI showing dummy grades (e.g., “Math: A”).
3. Prototype Development:
o Build the prototype using rapid tools (e.g., mockup software, simple code).
o Example: Code a clickable grade display in Python with a basic interface.
4. User Evaluation:
o Show the prototype to users and gather feedback.
o Example: Students test it and say, “Add a GPA calculator.”
5. Refinement:
o Update the prototype based on feedback, repeating steps as needed.
o Example: Add a GPA calculator and retest.
6. Final Development:
o Once requirements are clear, build the full system using the prototype as a guide.
o Example: Develop the complete app with grades, GPA, and polished UI.
The process loops between prototyping and refinement until the prototype is mature enough to become
(or guide) the final product.

Types of Prototyping
1. Throwaway (Rapid) Prototyping:
o Built quickly to clarify requirements, then discarded.
o Tools: Mockup tools (e.g., Figma), paper sketches.
 o Example: A paper sketch of a shopping app’s checkout screen to test layout ideas.
2. Evolutionary Prototyping:
o The prototype evolves into the final system through continuous refinement.
o Example: Start with a basic “to-do list” app, then add reminders and sharing features
over iterations.
3. Incremental Prototyping:
o Separate prototypes for different parts are built and later integrated.
o Example: Prototype a “login” feature separately from a “profile” feature, then combine
them.

Characteristics of the Prototyping Model

• Iterative: Relies on cycles of feedback and improvement.
• User-Centric: Focuses on involving users early.
• Flexible: Adapts to unclear or changing requirements.
• Exploratory: Tests feasibility and usability before full commitment.
Example: A team prototyping a game might build a level to test mechanics (e.g., jumping) before
designing the whole world.

Advantages of the Prototyping Model

1. Improved Requirements Clarity:
o Users see and refine what they want early.
o Example: A client vague about a CRM system sees a prototype and specifies “add
contact sorting.”
2. Early User Feedback:
o Reduces misunderstandings and rework.
o Example: Students dislike a timetable app’s colors, so you adjust them before coding
further.
3. Reduced Risk:
o Identifies design flaws or unmet needs early.
o Example: A prototype reveals a payment app’s “confirm” button is too small.
4. Better User Satisfaction:
o Users feel involved, leading to a product they like.
o Example: Faculty approve a prototype of a grading tool, ensuring it fits their workflow.
5. Feasibility Testing:
o Checks if ideas work before heavy investment.
o Example: Prototype a voice-controlled app to see if the tech is reliable.

Disadvantages of the Prototyping Model

1. Scope Creep:
o Users might keep adding features, delaying completion.
o Example: A simple chat app prototype balloons into a full social platform.
2. Incomplete Initial Planning:
o Focus on prototyping can skip critical architecture design.
o Example: A rushed prototype for a store app lacks scalability for high traffic.
 3. User Confusion:
o Users might expect the prototype’s speed or look in the final product.
o Example: A flashy prototype UI sets unrealistic expectations for a basic tool.
4. Higher Costs for Throwaway:
o Building and discarding prototypes wastes resources.
o Example: A discarded mockup of a fitness app costs time with no reusable code.
5. Management Complexity:
o Iterations require careful tracking.
o Example: Coordinating feedback on multiple prototype versions.

When to Use the Prototyping Model

• Unclear Requirements: When users don’t know exactly what they want.
• Innovative Projects: To test new ideas or technologies.
• UI/UX Focus: When usability is critical.
• Small to Medium Projects: Where iteration is manageable.
Example: A startup prototyping a new food delivery app to test unique features like “live chef updates.”

Practical Example for BSIT Students

Imagine you’re building a campus parking app:
• Step 1: Gather vague needs (e.g., “find parking spots”).
• Step 2: Prototype a map showing dummy parking locations using a tool like Figma.
• Step 3: Show it to students; they suggest “show available spots.”
• Step 4: Refine the prototype to mark free spots in green.
• Step 5: After approval, code the full app with real-time data.
Scenario: You use throwaway prototyping to test the map UI, then switch to evolutionary prototyping to
build the final system—showing flexibility.

Real-World Example
• Success: Adobe Photoshop started with prototypes to test image editing tools, evolving based
on user input into a polished product.
• Contrast: The Waterfall-built Healthcare.gov (2013) lacked prototyping, leading to a buggy
launch—early prototypes could’ve caught issues.

Key Takeaways
• The Prototyping Model builds early versions to refine requirements and design.
• It excels with unclear needs and user involvement but risks scope creep.
• Examples like parking apps and Photoshop highlight its practical use.

Topic 9: Software Process Models - Spiral Model

The ninth topic in the Software Engineering course continues the exploration of Software Process
Models with the Spiral Model. This model combines iterative development with risk management,
making it ideal for large, complex, and high-risk projects. Below, I’ll explain the Spiral Model in detail,
including its definition, process, advantages, disadvantages, and examples tailored for BSIT students.
What is the Spiral Model?
The Spiral Model is a risk-driven software development process that iterates through cycles (spirals),
each addressing a subset of the system while progressively refining it and managing risks. Introduced by
Barry Boehm in 1986, it integrates elements of the Waterfall Model (structured phases) and prototyping
(iteration), with a strong emphasis on risk assessment. Ian Sommerville (Software Engineering, 10th
Edition) describes it as "a process that repeats a sequence of steps, with each cycle producing a more
complete version of the software and addressing risks explicitly."
Imagine it like climbing a spiral staircase: each loop builds on the last, and you check for hazards (risks) at
every step before moving higher.
Example: Developing a university exam system might use the Spiral Model to first build a basic
scheduling feature, assess risks (e.g., server crashes), and then add secure grade submission in later
spirals.

How the Spiral Model Works

The Spiral Model operates in iterative cycles, with each spiral consisting of four quadrants:
1. Determine Objectives, Alternatives, and Constraints:
o Define goals for the cycle (e.g., features, performance), explore options, and identify
limits (e.g., budget, time).
o Example: Goal: “Secure login for an app”; Alternatives: Password vs. biometric;
Constraint: Must finish in two months.
2. Evaluate Risks and Alternatives:
o Analyze potential risks (e.g., technical, cost, schedule) and choose the best solution,
often using prototypes.
o Example: Risk: “Biometric login might fail on old devices”; Prototype it to test feasibility.
3. Develop and Test (Engineering):
o Build the increment (e.g., code, prototype) and test it.
o Example: Code a password-based login and test it for security breaches.
4. Plan the Next Iteration:
o Review progress, gather feedback, and plan the next spiral based on results and
remaining risks.
o Example: Feedback: “Users want two-factor authentication”; Plan: Add it in the next
spiral.
Each spiral produces a deliverable (e.g., prototype, partial system), and the process repeats until the full
system is complete, with risks reduced at every step.

Characteristics of the Spiral Model

• Iterative: Builds the system in cycles, like Incremental and Prototyping Models.
• Risk-Focused: Prioritizes identifying and mitigating risks.
• Flexible: Adapts to changing needs and uncertainties.
• Cumulative: Each spiral adds functionality and refines the product.
Example: A team building a drone control system might start with basic flight controls, assess crash risks,
and later add navigation features.

Advantages of the Spiral Model

 1. Risk Management:
o Explicitly addresses risks, reducing the chance of failure.
o Example: Testing a payment app’s security early avoids late-stage breaches.
2. Flexibility:
o Handles changing requirements or new risks mid-process.
o Example: Adding “offline mode” to a mobile app after user feedback.
3. Early Prototyping:
o Uses prototypes to validate ideas and requirements.
o Example: A rough UI for a game lets developers test player controls early.
4. Progressive Development:
o Delivers increasingly complete versions, building confidence.
o Example: A CRM system starts with contact management, then adds sales tracking.
5. Suitable for Large Projects:
o Breaks complexity into manageable spirals.
o Example: A national voting system can be built incrementally with security checks.

Disadvantages of the Spiral Model

1. Complexity:
o Managing risk analysis and iterations requires expertise.
o Example: A small team might struggle to assess risks for a cloud app.
2. High Cost:
o Risk analysis, prototyping, and multiple cycles increase expenses.
o Example: Prototyping a smartwatch app’s battery usage adds development time.
3. Time-Intensive:
o Detailed planning slows progress compared to simpler models.
o Example: A simple calculator app doesn’t need multiple risk-focused spirals.
4. Risk Assessment Dependency:
o Poor risk evaluation can derail the process.
o Example: Ignoring “server overload” risks in an e-commerce app leads to crashes.
5. Not Ideal for Small Projects:
o Overkill for straightforward tasks with low risk.
o Example: A basic to-do list app doesn’t justify the overhead.

When to Use the Spiral Model

• High-Risk Projects: Where failure is costly (e.g., medical, aerospace).
• Large and Complex Systems: Needing phased development.
• Uncertain Requirements: When needs evolve over time.
• Innovative Technology: To test feasibility.
Example: A company developing an AI-driven chatbot (like me!) might use the Spiral Model to test
language processing, assess accuracy risks, and refine features iteratively.

Practical Example for BSIT Students

Imagine you’re building a campus security app using the Spiral Model:
• Spiral 1: Basic Alert System
 o Objective: “Send emergency alerts.”
o Risk: “Network failure”; Prototype a text alert system.
o Develop: Code a simple SMS feature.
o Plan: Next spiral adds location tracking.
• Spiral 2: Location Tracking
o Objective: “Report incident location.”
o Risk: “GPS inaccuracy”; Test on campus.
o Develop: Add a map feature.
o Plan: Add secure reporting.
• Spiral 3: Secure Reporting
o Objective: “Encrypt reports.”
o Risk: “Data breaches”; Test encryption.
Scenario: After Spiral 1, students suggest “photo upload” for incidents. You assess the risk (e.g., storage
limits) and add it in Spiral 4—showing adaptability.

Real-World Example
• Success: The U.S. Department of Defense used the Spiral Model for military software (e.g.,
missile systems), managing risks like hardware failures and security threats.
• Contrast: The Waterfall-based London Ambulance System (1992) failed due to unaddressed risks
(e.g., system overload), costing lives—Spiral’s risk focus might have helped.

Key Takeaways
• The Spiral Model iterates through cycles, emphasizing risk management.
• It’s flexible and robust for complex, risky projects but costly and complex.
• Examples like security apps and military systems show its value.

Topic 10: Software Process Models - RAD Model

The tenth topic in the Software Engineering course continues the exploration of Software Process
Models with the RAD Model (Rapid Application Development). This model prioritizes speed and
flexibility, aiming to deliver software quickly by using prototyping and minimal planning. Below, I’ll
explain the RAD Model in detail, including its definition, process, advantages, disadvantages, and
examples tailored for BSIT students.

What is the RAD Model?

The RAD Model is a software development process that emphasizes rapid prototyping and iterative
delivery to produce functional software in a short timeframe. Introduced by James Martin in the 1990s,
it focuses on building applications quickly by involving users early and often, using reusable components
and automated tools. Ian Sommerville (Software Engineering, 10th Edition) notes that RAD is "designed
to produce usable systems quickly, especially when speed of development is more important than other
quality attributes."
Think of it like assembling a Lego set: you use pre-made pieces, test as you build, and adjust based on
what the user wants—all in a hurry.
Example: Creating a student feedback app for a university might use RAD to deliver a working version in
weeks, starting with a prototype and refining it with faculty input.
How the RAD Model Works
The RAD Model follows a condensed, iterative process with these phases:
1. Business Modeling:
o Define the problem and information flow (what the system needs to do).
o Example: For a feedback app, identify that faculty need to “collect student opinions” and
“generate summary reports.”
2. Data Modeling:
o Identify and organize data objects (e.g., entities like users, feedback).
o Example: Define data like “student ID,” “rating,” and “comments.”
3. Process Modeling:
o Specify how data is processed (e.g., functions, workflows).
o Example: Design a process to “submit feedback” and “calculate average ratings.”
4. Application Generation:
o Build the system using rapid tools (e.g., GUI builders, code generators) and reusable
components.
o Example: Use a tool like OutSystems to create a feedback form and database quickly.
5. Testing and Turnover:
o Test each component as it’s built, then deliver to users.
o Example: Test the feedback form works, then deploy it for a trial run.
Unlike Waterfall, RAD skips lengthy upfront planning, relying on prototypes and user feedback to shape
the system iteratively.

Characteristics of the RAD Model

• Speed-Oriented: Focuses on quick delivery (weeks or months, not years).
• Iterative: Builds and refines through prototypes.
• User-Driven: Heavy user involvement ensures alignment with needs.
• Tool-Dependent: Leverages automation and pre-built components.
Example: A team might use RAD to whip up a basic e-commerce site in a month, starting with a shopping
cart prototype and adding payment features based on client feedback.

Advantages of the RAD Model

1. Fast Development:
o Delivers software quickly, ideal for tight deadlines.
o Example: A startup launches a booking app in weeks to beat competitors.
2. User Involvement:
o Early feedback ensures the product meets expectations.
o Example: Students test a timetable app prototype and suggest “color-coded schedules.”
3. Flexibility:
o Adapts to changing requirements during development.
o Example: Adding “offline access” to a note-taking app mid-process.
4. Reduced Development Time:
o Reusable components and tools cut effort.
o Example: Using a pre-built login module saves coding time for a portal.
 5. Early Usability:
o Users get a working system sooner.
o Example: Faculty use a basic feedback app while features like “export data” are still
being added.

Disadvantages of the RAD Model

1. Limited Scalability:
o Suits small to medium projects, not large, complex systems.
o Example: RAD struggles with a nationwide banking system needing robust architecture.
2. Dependency on Tools and Skills:
o Requires expertise in rapid development tools.
o Example: A team unfamiliar with RAD tools (e.g., Mendix) might falter.
3. Compromised Quality:
o Speed can sacrifice thorough testing or documentation.
o Example: A rushed app might crash under heavy use due to untested edge cases.
4. High User Commitment:
o Needs constant user availability for feedback.
o Example: If faculty skip prototype reviews, the feedback app misses key needs.
5. Not for High-Risk Projects:
o Lacks the risk focus of the Spiral Model.
o Example: A medical system needing strict safety checks isn’t suited for RAD.

When to Use the RAD Model

• Short Deadlines: When time-to-market is critical.
• Well-Defined but Flexible Needs: Clear goals with room for refinement.
• Small to Medium Projects: Manageable scope and team size.
• Available Resources: Skilled developers and RAD tools.
Example: A company rushing to launch a promotional event app for a festival might use RAD to meet the
deadline.

Practical Example for BSIT Students

Imagine you’re building a campus survey app using the RAD Model:
• Business Modeling: Define the need: “Collect student opinions on courses.”
• Data Modeling: Set up entities: “student,” “survey,” “response.”
• Process Modeling: Plan “submit response” and “view results.”
• Application Generation: Use a tool like Bubble to create a survey form and dashboard in days.
• Testing/Turnover: Test with a small group, tweak based on feedback (e.g., “add multiple-choice
options”), and deploy.
Scenario: Students test the prototype and request “anonymous submissions.” You quickly adjust and
deliver—showing RAD’s speed and adaptability.

Real-World Example
• Success: Early versions of Microsoft Access used RAD-like principles, leveraging pre-built
database components to deliver a usable tool fast.
 • Contrast: The Waterfall-based FBI Virtual Case File (2000s) took years and failed—RAD could’ve
delivered functional pieces sooner.

Key Takeaways
• The RAD Model prioritizes rapid development through prototyping and tools.
• It’s fast and flexible but limited to smaller, less risky projects.
• Examples like survey apps and Access show its practical strengths.

Topic 11: Agile Software Development - Agile Process Models

The eleventh topic in the Software Engineering course shifts focus to Agile Software Development,
specifically Agile Process Models. Agile represents a modern, flexible approach to software
development, emphasizing adaptability, collaboration, and delivering working software frequently.
Below, I’ll explain Agile process models in detail, including their definition, principles, key models,
advantages, disadvantages, and examples tailored for BSIT students.

What is Agile Software Development?

Agile Software Development is an iterative and incremental approach that prioritizes delivering small,
functional pieces of software quickly while adapting to changing requirements. It’s guided by the Agile
Manifesto (2001), which values:
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.
Ian Sommerville (Software Engineering, 10th Edition) describes Agile as "a set of methods that focus on
rapid delivery of software and close interaction with users, accepting that requirements will change."
Think of it like cooking for a party: you serve appetizers as they’re ready, adjust the menu based on
guests’ tastes, and keep improving dishes throughout the event.
Example: Building a student portal might use Agile to release a “login” feature first, then add “view
grades” and “register courses” based on student feedback.

Core Principles of Agile

Agile process models share these principles:
• Iterative Development: Deliver software in short cycles (e.g., 2-week sprints).
• Customer Collaboration: Regular user input shapes the product.
• Flexibility: Embrace changing requirements, even late in development.
• Team Empowerment: Small, self-organizing teams drive progress.
• Continuous Improvement: Reflect and refine processes after each cycle.
Example: A team adjusts a game app’s difficulty after players find it too hard in the first sprint.

Key Agile Process Models

Several frameworks embody Agile principles. Here are the most prominent:
1. Scrum:
o Structure: Uses fixed-length iterations (sprints, typically 2-4 weeks), with roles like
Product Owner, Scrum Master, and Development Team.
 o Artifacts: Product Backlog (list of features), Sprint Backlog (tasks for the sprint),
Increment (delivered software).
o Events: Sprint Planning, Daily Standups, Sprint Review, Retrospective.
o Example: A team builds a chat app, planning “send messages” for Sprint 1 and “add
emojis” for Sprint 2.
2. Extreme Programming (XP):
o Focus: Engineering practices like pair programming, test-driven development (TDD), and
continuous integration.
o Cycles: Very short iterations (days or weeks).
o Example: Developers pair up to code a calculator app, writing tests before functions like
“add” or “multiply.”
3. Kanban:
o Structure: Visualizes work on a board (e.g., To Do, In Progress, Done) with no fixed
iterations—focus on continuous flow.
o Example: A team uses a Kanban board to track tasks for a blog app, moving “design
homepage” to “Done” as it’s completed.
4. Feature-Driven Development (FDD):
o Focus: Delivers specific features in short iterations, guided by a feature list.
o Example: Build a shopping app feature-by-feature: “add to cart,” then “checkout.”
5. Lean Software Development:
o Principle: Eliminate waste, deliver value fast (inspired by Lean manufacturing).
o Example: Skip unnecessary documentation for a weather app to focus on “display
forecast.”

Characteristics of Agile Process Models

• Iterative and Incremental: Deliver small, working pieces frequently.
• Adaptive: Adjust to new requirements or priorities.
• Collaborative: Emphasize teamwork and user involvement.
• Lightweight: Minimize overhead (e.g., less focus on heavy documentation).
Example: A team releases a basic e-commerce site with “browse products,” then adds “reviews” in the
next sprint based on user demand.

Advantages of Agile Process Models

1. Flexibility:
o Adapts to changes easily.
o Example: Adding “dark mode” to a note app mid-project after user requests.
2. Frequent Delivery:
o Users get working software early and often.
o Example: A music app releases “play songs” in Sprint 1, “create playlists” in Sprint 2.
3. Improved Quality:
o Continuous testing and feedback catch issues early.
o Example: Fixing a login bug in a portal during a sprint review.
4. Customer Satisfaction:
o Close collaboration ensures the product meets needs.
 oExample: Students guide a timetable app’s features through regular demos.
5. Team Morale:
o Empowerment and quick wins boost motivation.
o Example: A team celebrates finishing a “search” feature in a library app.

Disadvantages of Agile Process Models

1. Less Predictability:
o No fixed end-date or full scope upfront.
o Example: A CRM project’s timeline stretches as clients keep adding features.
2. Requires Discipline:
o Teams must self-manage and communicate well.
o Example: A disorganized team misses sprint goals for a game app.
3. Limited Documentation:
o Can complicate maintenance or onboarding.
o Example: New developers struggle to update an app with minimal notes.
4. Customer Dependency:
o Needs active user involvement, which isn’t always possible.
o Example: Faculty unavailable to review a grading app slows progress.
5. Not for All Projects:
o Struggles with fixed-budget or highly regulated systems.
o Example: A safety-critical medical device needs Waterfall’s rigor, not Agile’s flexibility.

When to Use Agile Process Models

• Dynamic Requirements: When needs evolve (e.g., startups, web apps).
• Small to Medium Teams: Easier to coordinate.
• User-Focused Projects: Where feedback drives design.
• Fast-Paced Environments: Needing quick releases.
Example: A startup building a social media app uses Scrum to release “post updates” fast and adapt to
trends.

Practical Example for BSIT Students

Imagine you’re developing a campus event app using Scrum:
• Sprint 1 (2 weeks):
o Backlog: “List events,” “RSVP.”
o Plan: Focus on “List events.”
o Daily Standups: “Coded event display today.”
o Deliver: App shows events like “Hackathon, March 15.”
• Sprint 2:
o Add “RSVP” based on student feedback from Sprint 1 review.
o Retrospective: “Improve UI responsiveness next time.”
Scenario: Students suggest “event reminders” mid-project. You add it to the backlog for Sprint 3—
showing Agile’s adaptability.

Real-World Example
 • Success: Spotify uses Agile (Scrum with “Squads”) to roll out features like “Discover Weekly”
iteratively, adapting to user habits.
• Contrast: Waterfall’s rigidity sank the UK NHS IT project (2000s)—Agile’s flexibility might have
delivered usable parts sooner.

Key Takeaways
• Agile process models (e.g., Scrum, XP, Kanban) prioritize speed, flexibility, and collaboration.
• They excel in dynamic settings but require discipline and user input.
• Examples like event apps and Spotify show their real-world impact.

Topic 12: Agile Software Development - Agile Development Techniques

The twelfth topic in the Software Engineering course delves deeper into Agile Software Development,
focusing on Agile Development Techniques. These are specific practices and methods used within Agile
process models (e.g., Scrum, XP) to ensure rapid, high-quality software delivery while maintaining
flexibility and collaboration. Below, I’ll explain these techniques in detail, including their definitions, key
examples, benefits, and practical applications tailored for BSIT students.

What are Agile Development Techniques?

Agile development techniques are hands-on practices that support the Agile principles of delivering
working software frequently, adapting to change, and fostering collaboration. Ian Sommerville (Software
Engineering, 10th Edition) notes that these techniques "enable Agile teams to produce software that
meets user needs with minimal overhead, emphasizing practical engineering over rigid processes."
Think of them as the tools in a chef’s kitchen: Agile models (like Scrum) set the recipe, while techniques
(like pair programming) are the knives and pans that make it happen.
Example: A team building a student app might use test-driven development (TDD) to write tests before
coding a “grade calculator,” ensuring it works from the start.

Key Agile Development Techniques

Here are the most widely used techniques, rooted in frameworks like Extreme Programming (XP) and
Scrum:
1. Test-Driven Development (TDD):
o Definition: Write automated tests before coding, then develop just enough code to pass
the tests.
o Process: Write a test (e.g., “add(2, 3) = 5”), code the function, run the test, refactor if
needed.
o Example: For a quiz app, write a test to check “score increases by 10 for a correct
answer,” then code the scoring logic.
2. Pair Programming:
o Definition: Two developers work together at one workstation—one writes code (driver),
the other reviews and suggests (navigator).
o Benefit: Reduces bugs, improves code quality.
o Example: Two students pair up to code a chat app’s “send message” feature, catching
errors in real-time.
3. Continuous Integration (CI):
 o Definition: Frequently integrate code changes into a shared repository (e.g., Git),
running automated tests to catch issues early.
o Tools: Jenkins, GitHub Actions.
o Example: A team commits code for a timetable app daily, with CI testing that new “add
event” code doesn’t break “view schedule.”
4. Refactoring:
o Definition: Improve code structure without changing its behavior to keep it clean and
maintainable.
o Example: Simplify a 50-line “calculate GPA” function into 10 readable lines after it passes
tests.
5. User Stories:
o Definition: Describe features from the user’s perspective in simple terms (e.g., “As a
[user], I want [feature] so that [benefit]”).
o Example: “As a student, I want to see my grades so I can track my progress”—guides
development of a portal feature.
6. Daily Standups (Daily Scrum):
o Definition: Short (15-minute) team meetings to share progress, plans, and blockers.
o Example: “Yesterday, I coded the login UI; today, I’ll test it; I’m stuck on authentication
errors.”
7. Sprint Planning and Reviews:
o Definition: Plan tasks for a sprint (e.g., 2 weeks) and review deliverables with
stakeholders at the end.
o Example: Plan to build “event RSVP” in a sprint, then demo it to students for feedback.
8. Behavior-Driven Development (BDD):
o Definition: Extend TDD by writing tests in natural language tied to user behavior (e.g.,
“Given [condition], when [action], then [result]”).
o Tools: Cucumber, Gherkin.
o Example: “Given a student logs in, when they view grades, then they see their scores”—
tests a portal feature.
9. Continuous Deployment (CD):
o Definition: Automatically deploy tested code to production, ensuring frequent releases.
o Example: A weather app updates its “forecast display” in real-time after each successful
CI test.
10. Retrospectives:
o Definition: Reflect after each sprint to improve processes (e.g., “What went well? What
can we improve?”).
o Example: “We finished the search feature, but testing took too long—let’s automate
more tests next sprint.”

Characteristics of Agile Development Techniques

• Incremental: Build and test small pieces of functionality.
• Collaborative: Involve team members and users closely.
• Quality-Focused: Emphasize working software through testing and review.
• Adaptive: Adjust based on feedback and lessons learned.
Example: A team uses TDD and CI to ensure a game’s “jump” mechanic works flawlessly before adding
“run.”

Benefits of Agile Development Techniques

1. Higher Quality:
o TDD and CI catch bugs early.
o Example: A login system passes all tests before release, avoiding crashes.
2. Faster Feedback:
o Pair programming and reviews spot issues instantly.
o Example: A partner suggests fixing a slow search query during coding.
3. Improved Collaboration:
o Standups and user stories align the team and users.
o Example: Daily updates keep a library app team on track.
4. Maintainability:
o Refactoring keeps code clean for future changes.
o Example: A refactored payment module is easier to update with new methods.
5. Efficiency:
o Automation (CI/CD) reduces manual work.
o Example: Auto-deploying a blog app saves hours of manual updates.

Challenges of Agile Development Techniques

1. Learning Curve:
o Techniques like TDD require skill and practice.
o Example: A student struggles to write tests before code for a calculator.
2. Team Dependency:
o Pair programming needs good communication.
o Example: A shy teammate slows down progress.
3. Initial Overhead:
o Setting up CI/CD takes time upfront.
o Example: Configuring Jenkins delays a small project’s start.
4. Risk of Overfocus:
o Too much refactoring can delay delivery.
o Example: Perfecting a “sort” function stalls a to-do app.
5. Resource Intensive:
o Constant user feedback and automation need resources.
o Example: Faculty unavailable to review a grading app slows iterations.

Practical Example for BSIT Students

Imagine you’re building a campus parking app with Agile techniques:
• User Story: “As a student, I want to find open spots so I can park quickly.”
• TDD: Write a test: “findSpots() returns 3 when 3 spots are free,” then code it.
• Pair Programming: One student codes the map, another checks for errors.
• CI: Push code to GitHub; tests run automatically.
• Sprint Review: Show the “spot finder” to students; they suggest “show distance.”
 • Refactoring: Simplify the map code for speed.
• Retrospective: “Testing was slow—let’s add more automation.”
Scenario: After the first sprint, students love the feature but want “real-time updates.” You adjust the
next sprint—showing Agile’s adaptability.

Real-World Example
• Success: Netflix uses CI/CD and TDD to deploy updates daily, ensuring a seamless streaming
experience.
• Contrast: Waterfall’s rigid planning delayed the UK’s NHS IT system—Agile techniques could’ve
delivered working parts faster.

Key Takeaways
• Agile development techniques (e.g., TDD, CI, pair programming) enable rapid, quality-focused
development.
• They boost collaboration and adaptability but require skill and discipline.
• Examples like parking apps and Netflix highlight their impact.

Comparison of Software Process Models

Before moving to the next topic, let’s compare the software process models covered so far: Waterfall,
Incremental, Prototyping, Spiral, RAD, and Agile. This comparison highlights their strengths,
weaknesses, and ideal use cases, providing a clear perspective for BSIT students.

1. Structure and Approach

• Waterfall: Linear and sequential; one phase completes before the next begins.
o Example: Building a payroll system with fixed requirements.
• Incremental: Linear within increments; builds software in cumulative chunks.
o Example: Adding features to a student portal over time.
• Prototyping: Iterative; focuses on early prototypes to refine requirements.
o Example: Testing a UI for a parking app before full development.
• Spiral: Iterative with risk management; cycles through phases with risk analysis.
o Example: Developing a secure exam system with phased risk checks.
• RAD: Iterative and rapid; uses prototypes and tools for quick delivery.
o Example: Launching a survey app in weeks.
• Agile: Iterative and incremental; emphasizes flexibility and frequent releases.
o Example: Releasing a game app feature-by-feature with user input.

2. Flexibility
• Waterfall: Rigid; changes are difficult once a phase is complete.
o Weakness: Can’t add “dark mode” mid-project easily.
• Incremental: Moderately flexible; later increments can adjust.
o Strength: Add “RSVP” to an event app after initial release.
• Prototyping: Highly flexible; evolves based on feedback.
o Strength: Adjust a timetable app’s layout mid-process.
• Spiral: Flexible within spirals; adapts to risks and feedback.
 o Strength: Add encryption to a security app after risk assessment.
• RAD: Very flexible; rapid iterations accommodate changes.
o Strength: Tweak a feedback app based on early trials.
• Agile: Most flexible; embraces change at any stage.
o Strength: Add “notifications” to a chat app mid-sprint.

3. Risk Management
• Waterfall: Poor; risks surface late (e.g., in testing).
o Weakness: Bug found after deployment is costly.
• Incremental: Moderate; risks are spread across increments.
o Strength: Fix a grade entry bug before adding reports.
• Prototyping: Moderate; early prototypes reduce requirement risks.
o Strength: Catch UI issues before coding.
• Spiral: Excellent; explicit risk analysis per cycle.
o Strength: Test server load for an e-commerce app early.
• RAD: Low; speed trumps risk focus.
o Weakness: Might miss scalability issues in a rushed app.
• Agile: Good; frequent testing and feedback mitigate risks.
o Strength: Fix a login flaw in a sprint review.

4. Delivery Speed
• Waterfall: Slow; delivers only at the end.
o Weakness: Users wait months for a full system.
• Incremental: Moderate; delivers usable parts incrementally.
o Strength: Release “view grades” before “register courses.”
• Prototyping: Moderate; early prototypes, final system later.
o Strength: Demo a basic app quickly.
• Spiral: Slow to moderate; risk analysis delays delivery.
o Weakness: Thoroughness slows initial release.
• RAD: Fast; prioritizes rapid deployment.
o Strength: Deliver a survey app in weeks.
• Agile: Fast; frequent releases (e.g., every 2 weeks).
o Strength: Launch “play music” in a sprint.

5. User Involvement
• Waterfall: Low; users see the product at the end.
o Weakness: Misaligned needs (e.g., missing features).
• Incremental: Moderate; feedback after each increment.
o Strength: Adjust a portal after initial use.
• Prototyping: High; users shape the system via prototypes.
o Strength: Refine a parking app based on trials.
• Spiral: Moderate; feedback per spiral, but less frequent.
o Strength: Users test security features early.
• RAD: High; constant user input drives rapid iterations.
 o Strength: Faculty guide a feedback app’s design.
• Agile: Very high; continuous collaboration.
o Strength: Students steer a game app’s features.

6. Documentation
• Waterfall: Heavy; detailed docs at every phase.
o Strength: Great for regulated systems.
• Incremental: Moderate; docs per increment.
o Strength: Balances detail and progress.
• Prototyping: Low; focus on prototypes, not docs.
o Weakness: Hard to maintain later.
• Spiral: Moderate to high; includes risk reports.
o Strength: Useful for complex projects.
• RAD: Low; minimal docs for speed.
o Weakness: Future updates may suffer.
• Agile: Low; prioritizes working software.
o Weakness: New devs might struggle.

7. Ideal Use Cases

• Waterfall: Stable, well-defined projects (e.g., firmware, regulated systems).
• Incremental: Large projects needing phased delivery (e.g., enterprise software).
• Prototyping: Unclear requirements or UI-focused apps (e.g., startups).
• Spiral: High-risk, complex systems (e.g., aerospace, security).
• RAD: Small, urgent projects with flexible needs (e.g., promotional apps).
• Agile: Dynamic, user-driven projects (e.g., web/mobile apps, startups).

Summary Table
Model Flexibility Risk Mgmt Speed User Involvement Documentation Best For
Waterfall Low Poor Slow Low High Stable projects
Incremental Moderate Moderate Moderate Moderate Moderate Phased delivery
Prototyping High Moderate Moderate High Low Unclear needs
Spiral High Excellent Slow Moderate Moderate-High High-risk projects
RAD Very High Low Fast High Low Quick, small projects
Agile Very High Good Fast Very High Low Dynamic, user-focused

Practical Example for BSIT Students

Imagine building a library app:
• Waterfall: Finish all features (borrow, return, fines) in one go—slow, risky if needs change.
• Incremental: Release “borrow” first, then “return”—steady progress.
• Prototyping: Test a “search books” prototype—great for UI feedback.
• Spiral: Build “borrow” with security checks—safe but slow.
• RAD: Rush a basic “book list” app—fast but limited.
• Agile: Deliver “borrow” in a sprint, add “fines” next—flexible and quick.
Topic 13: Introduction to Project Management
The thirteenth topic in the Software Engineering course shifts focus from development processes to
Introduction to Project Management. This topic explores how to plan, organize, and oversee software
projects to ensure they meet goals within constraints like time, budget, and quality. Below, I’ll explain
project management in the context of software engineering, including its definition, key components,
roles, techniques, and examples tailored for BSIT students.

What is Project Management?

Project management is the discipline of planning, executing, monitoring, and closing projects to achieve
specific objectives while managing resources, risks, and stakeholders. In software engineering, it applies
these principles to guide the development of software systems. Ian Sommerville (Software Engineering,
10th Edition) defines it as "the process of managing the resources and activities needed to deliver a
software product on time, within budget, and to the required quality."
Think of it like directing a movie: you need a script (plan), actors (team), a budget, and a schedule to
produce a hit—without losing control.
Example: Managing a team building a student portal involves setting deadlines for features like “grade
display,” assigning tasks, and ensuring it’s ready before the semester starts.

Why Project Management Matters in Software Engineering

Software projects are complex, with unique challenges:
• Uncertainty: Requirements can change (e.g., adding “notifications” mid-project).
• Team Coordination: Multiple roles (developers, testers) need alignment.
• Constraints: Time, cost, and scope must balance.
• Quality: The software must work reliably.
Effective project management ensures success by keeping everything on track.
Example: Poor management delayed the Denver Airport baggage system (1990s), costing $560 million—
proper planning could’ve avoided it.

Key Components of Project Management

Project management in software engineering involves several core elements:
1. Project Planning:
o Define goals, scope, timeline, budget, and resources.
o Example: Plan a 3-month schedule to build a library app with $5,000 and 4 developers.
2. Task Breakdown:
o Divide the project into manageable tasks (e.g., Work Breakdown Structure - WBS).
o Example: Split a portal into “design UI,” “code backend,” and “test login.”
3. Scheduling:
o Set deadlines and dependencies (e.g., Gantt charts, milestones).
o Example: “Code backend” must finish before “test integration.”
4. Resource Management:
o Allocate people, tools, and budget effectively.
o Example: Assign two coders to a game app and one tester, with a Git license.
5. Risk Management:
 o Identify and mitigate potential issues (e.g., delays, bugs).
o Example: Plan for “server downtime” by adding backup testing time.
6. Monitoring and Control:
o Track progress and adjust as needed.
o Example: Check weekly if a feedback app’s sprint is on schedule.
7. Closure:
o Deliver the product, review outcomes, and document lessons.
o Example: Deploy a timetable app and hold a team debrief.

Project Management Roles

Key players ensure smooth execution:
• Project Manager: Oversees the project, coordinates the team, and communicates with
stakeholders.
o Example: Ensures a CRM system meets the client’s deadline.
• Team Members: Developers, testers, designers who execute tasks.
o Example: A coder builds a “search” feature.
• Stakeholders: Clients, users, or sponsors who define needs and approve results.
o Example: Faculty requesting a grading tool.
• Scrum Master (Agile-specific): Facilitates Agile processes.
o Example: Runs daily standups for a mobile app team.

Project Management Techniques and Tools

Software project management uses specific methods:
1. Traditional (Waterfall):
o Detailed upfront planning, linear execution.
o Example: Schedule a payroll system with fixed phases.
2. Agile Project Management:
o Iterative planning with sprints (e.g., Scrum, Kanban).
o Example: Plan a 2-week sprint for a chat app’s “send message” feature.
3. Critical Path Method (CPM):
o Identifies the longest sequence of dependent tasks to determine project duration.
o Example: “Test login” depends on “code login,” setting the timeline.
4. PERT (Program Evaluation and Review Technique):
o Estimates time with optimistic, pessimistic, and likely scenarios.
o Example: Estimate coding a game level as 5-10 days, averaging 7.
5. Tools:
o Jira: Tracks Agile tasks.
o Trello: Visualizes Kanban boards.
o MS Project: Creates Gantt charts.
o Git: Manages code versions.
o Example: Use Trello to assign “design UI” to a student.

Characteristics of Effective Project Management

• Clear Goals: Everyone knows the target (e.g., “deploy by June”).
 • Communication: Regular updates prevent misalignment.
• Adaptability: Adjusts to surprises (e.g., team member illness).
• Measurement: Tracks progress with metrics (e.g., tasks completed).
Example: A well-managed team delivers a weather app on time by adjusting for a delayed API
integration.

Practical Example for BSIT Students

Imagine managing a project to build a campus event app:
• Planning: Set a 2-month timeline, $1,000 budget, and goal: “list and RSVP events.”
• Tasks: Break into “design database,” “code frontend,” “test RSVP.”
• Schedule: Use a Gantt chart: Week 1-2 for design, Week 3-5 for coding, Week 6 for testing.
• Resources: Assign 3 students (coder, tester, designer) and use Git.
• Risks: Plan for “server crash” by adding a buffer week.
• Monitoring: Weekly check-ins via Zoom.
• Closure: Deploy the app and review: “Testing was slow—automate next time.”
Scenario: Students request “notifications” mid-project. You adjust the schedule, showing adaptability.

Real-World Example
• Success: The Apollo 11 moon landing (1969) used meticulous project management to coordinate
software and hardware, meeting a tight deadline.
• Failure: The 2013 Healthcare.gov launch failed due to poor management (no clear oversight,
missed deadlines), costing millions to fix.

Key Takeaways
• Project management organizes software development to meet goals within constraints.
• It involves planning, scheduling, resource allocation, and risk management.
• Examples like event apps and Apollo show its critical role.

Topic 14: Introduction to Requirements Engineering

The fourteenth topic in the Software Engineering course introduces Requirements Engineering, a critical
phase in software development that focuses on defining what a system should do and how it should
perform. This topic lays the groundwork for building software that meets user needs and expectations.
Below, I’ll explain requirements engineering in detail, including its definition, process, types of
requirements, importance, and examples tailored for BSIT students.

What is Requirements Engineering?

Requirements Engineering (RE) is the process of eliciting, analyzing, documenting, validating, and
managing the requirements for a software system. Ian Sommerville (Software Engineering, 10th Edition)
defines it as "the process of establishing the services that the customer requires from a system and the
constraints under which it must operate."
Think of it like designing a custom house: you ask the homeowner what they want (e.g., 3 bedrooms, a
big kitchen) and note constraints (e.g., budget, location)—then ensure everyone agrees before building.
Example: For a student portal, requirements engineering determines needs like “view grades” and
constraints like “accessible on mobile devices.”
Why Requirements Engineering Matters
Good requirements engineering is crucial because:
• Aligns Expectations: Ensures the software matches user needs.
• Reduces Rework: Prevents costly changes later (e.g., adding a forgotten feature).
• Guides Development: Provides a blueprint for design and coding.
• Manages Risks: Identifies issues (e.g., unclear goals) early.
Example: Misunderstood requirements sank the Ariane 5 rocket (1996)—a $370 million loss due to a
reused component not meeting new needs.

The Requirements Engineering Process

Requirements engineering follows a structured process:
1. Elicitation:
o Gather requirements from stakeholders (users, clients, managers) through interviews,
surveys, workshops, or observation.
o Example: Ask students, “What do you need in a library app?” They say, “Search books,
check availability.”
2. Analysis:
o Refine and prioritize requirements, resolving conflicts or ambiguities.
o Example: Clarify “fast search” means “results in under 2 seconds”; prioritize it over
“fancy UI.”
3. Specification:
o Document requirements clearly in a Software Requirements Specification (SRS)
document.
o Example: Write: “The system shall allow users to search books by title, returning results
in under 2 seconds.”
4. Validation:
o Check requirements for completeness, consistency, and feasibility with stakeholders.
o Example: Show faculty a draft SRS for a grading tool; they confirm “calculate GPA” is
included.
5. Management:
o Track and update requirements as they evolve during the project.
o Example: Add “export grades to PDF” after initial feedback, updating the SRS.

Types of Requirements
Requirements are broadly categorized into two types, with subcategories:
1. Functional Requirements:
o Specify what the system should do (features, behaviors).
o Examples:
▪ “The app shall allow users to log in with a username and password.”
▪ “The system shall calculate fines for overdue books.”
o For BSIT: “A quiz app shall display 10 questions and score answers.”
2. Non-Functional Requirements:
o Define how the system should perform (quality attributes, constraints).
 oSubtypes:
▪ Performance: “The system shall handle 1,000 users simultaneously.”
▪ Usability: “The UI shall be intuitive for first-time users.”
▪ Security: “Data shall be encrypted during transmission.”
▪ Reliability: “The system shall have 99.9% uptime.”
o Example: “A student portal shall load grades in under 3 seconds and protect user data.”
3. Domain Requirements (Optional):
o Specific to the application area.
o Example: “A medical app shall comply with HIPAA regulations.”

Characteristics of Good Requirements

• Clear: Unambiguous (e.g., “fast” becomes “under 2 seconds”).
• Complete: Covers all needs and constraints.
• Testable: Measurable (e.g., “99% uptime” can be verified).
• Consistent: No contradictions (e.g., “fast” vs. “slow” in different sections).
• Feasible: Achievable within resources.
Example: “The app shall crash” is unclear; “The app shall recover from crashes within 5 seconds” is
better.

Techniques for Requirements Engineering

• Interviews: One-on-one discussions with stakeholders.
o Example: Ask professors what they need in a grading tool.
• Surveys: Collect input from many users.
o Example: Poll students on portal features.
• Use Cases: Describe how users interact with the system.
o Example: “Student logs in, views grades, logs out.”
• Prototyping: Build a mockup to refine needs.
o Example: Show a basic timetable app to test usability.
• Observation: Watch users in their environment.
o Example: Observe librarians to identify checkout needs.

Practical Example for BSIT Students

Imagine you’re defining requirements for a campus event app:
• Elicitation: Interview students: “We want to see events and RSVP.”
• Analysis: Prioritize “list events” over “share on social media.”
• Specification: Write in SRS: “The system shall display a list of upcoming events with date, time,
and location.”
• Validation: Show students the SRS; they add, “Include a map link.”
• Management: Update the SRS when “push notifications” is requested later.
Scenario: A vague “make it cool” becomes “The UI shall use a modern color scheme (blue and white)”—
showing clarification.

Real-World Example
 • Success: Google Maps’ requirements (e.g., “provide real-time directions”) were well-defined,
leading to a reliable product.
• Failure: The 2013 Healthcare.gov launch suffered from unclear requirements (e.g., untested
scalability), causing crashes.

Key Takeaways
• Requirements engineering defines what a system should do and how it should perform.
• It involves elicitation, analysis, specification, validation, and management.
• Examples like event apps and Maps show its role in success.

Topic 15: Functional and Non-Functional Requirements

The fifteenth topic in the Software Engineering course builds on Requirements Engineering by diving
deeper into Functional and Non-Functional Requirements. These two categories form the backbone of a
software system’s specification, defining what the system does and how it performs. Below, I’ll explain
them in detail, including their definitions, differences, examples, and practical applications tailored for
BSIT students.

What are Functional and Non-Functional Requirements?

Requirements specify what a software system must achieve. They are split into two main types:
1. Functional Requirements (FRs):
o Describe what the system should do—the specific features, behaviors, or services it
provides to users.
o Focus on functionality and user interactions.
o Ian Sommerville (Software Engineering, 10th Edition) defines them as "statements of
services the system should provide, how it should react to inputs, and how it should
behave in particular situations."
2. Non-Functional Requirements (NFRs):
o Define how the system should perform—the quality attributes, constraints, or standards
it must meet.
o Focus on performance, usability, security, and other operational characteristics.
o Sommerville describes them as "constraints on the services or functions offered by the
system, such as timing constraints, constraints on the development process, or
standards."
Analogy: Think of building a car. Functional requirements are “it must drive and turn” (what it does),
while non-functional requirements are “it must go 120 mph and be fuel-efficient” (how well it does it).
Example: For a student portal, a functional requirement is “display grades,” while a non-functional
requirement is “load grades in under 2 seconds.”

Key Differences
Aspect Functional Requirements Non-Functional Requirements
Focus What the system does How the system performs
Examples “Calculate GPA” “System must handle 1,000 users”
Testability Direct (does it work?) Indirect (how well does it work?)
Aspect Functional Requirements Non-Functional Requirements
Scope Specific features Overall quality and constraints
Impact of Failure Feature doesn’t work System works but poorly (e.g., slow)
Example: If a library app doesn’t “track borrowed books” (FR fails), the feature is broken. If it tracks
books but takes 10 seconds (NFR fails), it’s usable but frustrating.

Functional Requirements in Detail

Functional requirements outline the system’s capabilities. They are:
• User-Oriented: Tied to what users need or do.
• Specific: Clearly state actions or outputs.
• Testable: Can be verified with a yes/no test.
Examples:
• “The system shall allow users to log in with a username and password.”
• “The app shall send an email notification when a book is overdue.”
• “The software shall generate a PDF report of student attendance.”
Subcategories:
• Input/Output: “Accept credit card details and display confirmation.”
• Processing: “Calculate total sales tax.”
• User Interaction: “Provide a search bar to find courses.”
BSIT Example: For a quiz app, “The system shall display 5 multiple-choice questions and calculate the
score” is a functional requirement.

Non-Functional Requirements in Detail

Non-functional requirements specify quality attributes or constraints. They are:
• System-Oriented: Focus on performance or behavior.
• Qualitative or Quantitative: Often include measurable criteria.
• Broad Impact: Affect the entire system, not just one feature.
Categories and Examples:
1. Performance:
o “The system shall process 100 transactions per second.”
o “The app shall load in under 3 seconds.”
2. Usability:
o “The interface shall be intuitive for users with no training.”
o “The system shall support colorblind-friendly design.”
3. Reliability:
o “The system shall have 99.9% uptime.”
o “The app shall recover from crashes within 5 seconds.”
4. Security:
o “User data shall be encrypted with AES-256.”
o “The system shall log all failed login attempts.”
5. Scalability:
o “The system shall support 10,000 concurrent users.”
6. Maintainability:
o “Code shall follow modular design for easy updates.”
 7. Portability:
o “The app shall run on Android and iOS.”
8. Legal/Standards:
o “The system shall comply with GDPR.”
BSIT Example: For the quiz app, “The app shall handle 500 simultaneous users” (scalability) and
“Questions shall load in under 1 second” (performance) are non-functional requirements.

How They Work Together

• Complementary: FRs define the “what,” NFRs ensure the “how well.”
• Conflict Potential: A feature might meet FRs but fail NFRs (e.g., “calculate GPA” works but takes
10 seconds).
• Documentation: Both are captured in the Software Requirements Specification (SRS).
Example: For a banking app:
• FR: “The system shall transfer money between accounts.”
• NFR: “Transfers shall complete in under 2 seconds with 99.99% reliability.”

Practical Example for BSIT Students

Imagine specifying requirements for a campus event app:
• Functional Requirements:
o “The system shall allow users to RSVP to events.”
o “The app shall display a list of upcoming events with date and time.”
o “The system shall send a confirmation email after RSVP.”
• Non-Functional Requirements:
o “The app shall support 1,000 users during peak registration.”
o “Event lists shall load in under 2 seconds.”
o “The system shall use HTTPS to secure user data.”
Scenario: Students test the app. The RSVP feature works (FR met), but it’s slow under load (NFR
unmet)—showing the need for both types.

Challenges
• Ambiguity: “Make it fast” (NFR) vs. “Load in under 2 seconds.”
• Trade-offs: High security (NFR) might slow performance (NFR).
• Elicitation: Users focus on FRs, overlooking NFRs like scalability.
• Validation: NFRs are harder to test (e.g., “intuitive” vs. “logs in”).
Example: A vague “secure app” becomes “encrypt data with AES-256” after clarification.

Real-World Example
• Success: Netflix’s FRs (e.g., “stream videos”) pair with NFRs (e.g., “buffer in under 1 second”),
ensuring a smooth experience.
• Failure: The 1999 Mars Climate Orbiter crashed due to an unmet NFR (unit consistency), costing
$327 million.

Key Takeaways
• Functional requirements define what the system does (e.g., features).
 • Non-functional requirements specify how well it performs (e.g., speed, security).
• Examples like event apps and Netflix show their combined importance.

Topic 16: Analysis Model - Context Models

The sixteenth topic in the Software Engineering course transitions into the Analysis Model, starting with
Context Models. This topic focuses on understanding and representing the system’s environment and its
interactions with external entities. Below, I’ll explain context models in detail, including their definition,
purpose, components, creation process, and examples tailored for BSIT students.

What is a Context Model?

A context model is a high-level representation of a software system that defines its boundaries and
shows how it interacts with external entities (e.g., users, other systems) in its environment. Ian
Sommerville (Software Engineering, 10th Edition) describes it as "a model that demonstrates the
operational context of a system—what lies outside the system boundaries and how the system interacts
with those external entities."
Think of it like a map of a city: the system is the city center, and the context model shows the roads
(interactions) connecting it to suburbs (external entities).
Example: For a student portal, the context model shows the portal as the system, interacting with
students (to view grades), faculty (to enter grades), and a database (to store data).

Purpose of Context Models

Context models serve several key purposes in requirements analysis:
• Define System Boundaries: Clarify what’s inside the system and what’s outside.
• Identify External Interactions: Show how the system connects to users, devices, or other
systems.
• Scope the Project: Prevent scope creep by focusing on relevant entities.
• Communicate Context: Provide a simple overview for stakeholders.
Example: A library app’s context model ensures the team focuses on “book borrowing” (inside) and not
“library building maintenance” (outside).

Components of a Context Model

A context model typically includes:
1. System: The software being developed, represented as a single entity.
o Example: “Library Management System.”
2. External Entities: People, systems, or devices that interact with the system (also called actors).
o Examples: “Student,” “Librarian,” “Payment Gateway.”
3. Interactions: Data or control flows between the system and external entities (shown as arrows).
o Examples: “Student sends login request,” “System returns book list.”
These are usually depicted in a context diagram, a simple visual tool.

How to Create a Context Model

The process involves these steps:
1. Identify the System:
o Name the software and define its core purpose.
 o Example: “Event Management App” to manage campus events.
2. List External Entities:
o Determine who or what interacts with the system.
o Example: “Students,” “Event Organizers,” “Notification Service.”
3. Define Interactions:
o Specify what data or actions flow between the system and entities.
o Example: “Students RSVP to events,” “System sends reminders.”
4. Draw the Context Diagram:
o Place the system in the center, surround it with entities, and connect them with labeled
arrows.
o Tools: UML tools (e.g., Rational Rose), drawing software (e.g., Lucidchart).

Representation: Context Diagram

A context diagram is the standard way to visualize a context model:
• Central Box: The system.
• Ovals/Circles: External entities.
• Arrows: Interactions with labels.
Example Context Diagram for a Library App:
text
CollapseWrapCopy
[Student] ----(Search Books)----> [Library System] <----(Update Book Records)---- [Librarian]
| |
(View Availability) (Check Out Books)
| |
\/ \/
[Database] <----(Store Data)---- [Payment System] ----(Process Fines)---->
• System: Library System.
• Entities: Student, Librarian, Database, Payment System.
• Interactions: Search, update, store, process.

Characteristics of a Good Context Model

• Simple: High-level, not cluttered with internal details.
• Clear Boundaries: Distinguishes system from environment.
• Complete: Includes all relevant external entities.
• Understandable: Stakeholders (even non-technical) can grasp it.
Example: A vague “users” entity becomes “Students” and “Faculty” for clarity.

Practical Example for BSIT Students

Imagine you’re modeling a campus parking app:
• Step 1: Define System: “Parking Management App” to help students find parking.
• Step 2: Identify Entities:
o “Students” (users finding spots).
o “Parking Sensors” (report availability).
o “Admin” (manage spot data).
 o “Notification Service” (send alerts).
• Step 3: Define Interactions:
o Students: “Request spot availability.”
o Parking Sensors: “Send real-time data.”
o Admin: “Update spot status.”
o Notification Service: “Send ‘spot free’ alerts.”
• Step 4: Draw Diagram:
text
CollapseWrapCopy
[Students] ----(Request Availability)----> [Parking App] <----(Update Status)---- [Admin]
| |
(View Spots) (Send Sensor Data)
| |
\/ \/
[Notification Service] <----(Send Alerts)---- [Parking Sensors]
Scenario: The team realizes “Payment System” (for fines) is missing and adds it—showing iterative
refinement.

Benefits of Context Models

• Clarity: Stakeholders agree on scope (e.g., “no car maintenance features”).
• Focus: Developers target relevant interactions.
• Early Validation: Catch missing entities early.
Example: A context model for a game app excludes “hardware drivers” (outside scope), focusing on
“players” and “servers.”

Real-World Example
• Success: Amazon’s order system context model includes “Customer,” “Warehouse,” and
“Payment Gateway,” ensuring clear boundaries for a scalable design.
• Failure: The London Ambulance System (1992) lacked a clear context model, missing key entities
like “dispatchers,” leading to failure.

Key Takeaways
• Context models define a system’s boundaries and external interactions.
• They use simple diagrams to show the system, entities, and flows.
• Examples like parking apps and Amazon illustrate their role in analysis.

Topic 17: Analysis Model - Interaction Models

The seventeenth topic in the Software Engineering course continues the exploration of the Analysis
Model with Interaction Models. These models focus on how a system interacts with users and other
components, detailing the dynamic behavior and sequence of actions. Below, I’ll explain interaction
models in detail, including their definition, types, purpose, creation process, and examples tailored for
BSIT students.

What are Interaction Models?

Interaction models are representations of how a software system behaves by showing the sequence of
actions and exchanges between the system and its users, or between internal components. Ian
Sommerville (Software Engineering, 10th Edition) describes them as "models that represent how users
interact with the system and how the system components interact with one another to achieve some
goal."
Think of it like a script for a play: it shows who says what and when, ensuring the story (system behavior)
flows correctly.
Example: For a library app, an interaction model might show a student searching for a book, the system
retrieving data, and displaying results—all in order.

Purpose of Interaction Models

Interaction models serve key purposes in the analysis phase:
• Detail Behavior: Specify how the system responds to inputs or events.
• Clarify Sequences: Show the order of actions for a task.
• Validate Requirements: Ensure the system meets user expectations dynamically.
• Guide Design: Provide a blueprint for coding interactions.
Example: An interaction model for a student portal ensures “login” happens before “view grades,”
catching issues early.

Types of Interaction Models

Interaction models are typically represented using UML (Unified Modeling Language) diagrams. The two
main types are:
1. Sequence Diagrams:
o Show the time-ordered sequence of interactions between actors (e.g., users) and objects
(e.g., system components).
o Components:
▪ Actors: External entities (e.g., “Student”).
▪ Objects: System parts (e.g., “Database”).
▪ Messages: Actions or data flows (e.g., “request book”).
▪ Lifelines: Vertical lines showing an object’s existence over time.
o Example: A student requests a book, the system queries the database, and results are
returned.
2. Collaboration Diagrams (or Communication Diagrams):
o Show interactions with a focus on the relationships (links) between objects, not just the
sequence.
o Components:
▪ Objects: Same as in sequence diagrams.
▪ Links: Connections between objects.
▪ Messages: Numbered to indicate order.
o Example: The library app’s “Search Engine” talks to “Database” and “UI” to display book
results.
Note: Sequence diagrams emphasize timing; collaboration diagrams emphasize structure.

How to Create an Interaction Model

The process involves these steps:
1. Identify Use Case:
o Pick a specific scenario from requirements (e.g., “Borrow a Book”).
2. List Actors and Objects:
o Determine who interacts (e.g., “Student”) and what’s involved (e.g., “Library System,”
“Database”).
3. Define Interactions:
o Map the steps and data flows (e.g., “Student searches, system queries, results
returned”).
4. Draw the Diagram:
o Use UML tools like Rational Rose or draw manually.
o Sequence: Show timeline with arrows.
o Collaboration: Show links with numbered messages.

Example: Sequence Diagram for a Library App

Scenario: Student searches for a book.
text
CollapseWrapCopy
Actors/Objects: [Student] [Library UI] [Search Engine] [Database]
| | | |
|---search(book)-->| | |
| |---query(book)->| |
| | |---fetch(book)->|
| | |<--book data----|
| |<--results-----| |
|<--display(results)-| | |
• Flow:
1. Student sends “search(book)” to Library UI.
2. UI forwards “query(book)” to Search Engine.
3. Search Engine requests “fetch(book)” from Database.
4. Database returns book data.
5. Search Engine sends results to UI.
6. UI displays results to Student.

Example: Collaboration Diagram for the Same Scenario

text
CollapseWrapCopy
[Student] ----1: search(book)----> [Library UI]
| |
| 2: query(book)
| |
| [Search Engine]
| |
| 3: fetch(book)
 | |
| [Database]
| |
| 4: book data
| |
| 5: results
| |
|<----6: display(results)---- [Library UI]
• Focus: Links between objects with numbered steps.

Characteristics of Good Interaction Models

• Clear: Easy to follow, with labeled actions.
• Complete: Covers all steps in the scenario.
• Accurate: Matches requirements (e.g., FR: “search books”).
• Simple: Avoids unnecessary detail (e.g., no code-level specifics).
Example: A vague “user gets data” becomes “Student requests book, Database returns title.”

Practical Example for BSIT Students

Imagine modeling interactions for a campus event app:
• Use Case: “RSVP to an Event.”
• Actors/Objects: Student, Event App UI, Event Manager, Database.
• Sequence Diagram:
text
CollapseWrapCopy
[Student] [Event App UI] [Event Manager] [Database]
| | | |
|---RSVP(event)->| | |
| |---register(event)->| |
| | |---store(event)->|
| | |<--confirmation--|
| |<--success--------| |
|<--display(success)-| | |
• Flow:
1. Student sends RSVP request.
2. UI forwards to Event Manager.
3. Manager stores it in Database.
4. Database confirms.
5. Manager sends success to UI.
6. UI displays to Student.
Scenario: Testing reveals “send notification” is missing—add it to the model, showing refinement.

Benefits of Interaction Models

• Behavioral Insight: Shows how the system works dynamically.
• Error Detection: Spots missing steps (e.g., no confirmation).
 • Communication: Helps developers and stakeholders visualize flows.
Example: A game’s “shoot” interaction ensures the “gun” checks “ammo” before firing.

Real-World Example
• Success: PayPal’s payment flow uses interaction models to ensure “user pays” triggers “bank
debits” correctly.
• Failure: The 1992 London Ambulance System lacked interaction models, missing critical dispatch
flows, leading to delays.

Key Takeaways
• Interaction models (sequence and collaboration diagrams) detail system behavior.
• They show sequences or relationships between actors and components.
• Examples like event apps and PayPal highlight their role in analysis.

Topic 18: Analysis Model - Structural Models

The eighteenth topic in the Software Engineering course continues the exploration of the Analysis Model
with Structural Models. These models focus on the static structure of a software system, representing its
components and their relationships rather than dynamic behavior. Below, I’ll explain structural models in
detail, including their definition, types, purpose, creation process, and examples tailored for BSIT
students.

What are Structural Models?

Structural models are representations of a software system’s architecture, showing its key elements (e.g.,
objects, classes, modules) and how they are organized and connected. Ian Sommerville (Software
Engineering, 10th Edition) describes them as "models that show the organization of a system in terms of
the components that make up that system and their relationships."
Think of it like a blueprint of a building: it shows the rooms (components) and how they’re linked (doors,
hallways), without detailing how people move through it.
Example: For a library app, a structural model might show “Book,” “User,” and “Loan” as components,
with relationships like “User borrows Book.”

Purpose of Structural Models

Structural models serve key purposes in the analysis phase:
• Define System Organization: Identify the main parts and their interconnections.
• Clarify Relationships: Show how components depend on or relate to each other.
• Support Design: Provide a foundation for breaking the system into manageable pieces.
• Communicate Structure: Offer a clear view for developers and stakeholders.
Example: A structural model for a student portal ensures “Grade” connects to “Student,” guiding
database and code design.

Types of Structural Models

Structural models are typically represented using UML diagrams. The two primary types in analysis are:
1. Class Diagrams:
 o Show the static structure of the system in terms of classes (blueprints for objects), their
attributes, operations, and relationships.
o Components:
▪ Classes: Represent entities (e.g., “Student”).
▪ Attributes: Properties (e.g., “name,” “ID”).
▪ Operations: Behaviors (e.g., “registerCourse()”).
▪ Relationships: Associations, inheritance, aggregation (e.g., “Student enrolls in
Course”).
o Example: “Book” has attributes “title” and “ISBN,” related to “User” via “borrows.”
2. Object Diagrams:
o Show a snapshot of the system at a specific moment, with instances (objects) of classes
and their links.
o Components:
▪ Objects: Instances (e.g., “Book1:Book”).
▪ Links: Specific relationships (e.g., “User1 borrows Book1”).
o Example: “Alice:Student” linked to “Math101:Course” at enrollment time.
Note: Class diagrams are more common in analysis for defining general structure, while object diagrams
are used for specific instances.

How to Create a Structural Model

The process involves these steps:
1. Identify Entities:
o List key concepts from requirements (e.g., “Student,” “Event”).
2. Define Attributes and Operations:
o Specify properties and behaviors (e.g., “Student: name, viewGrades()”).
3. Determine Relationships:
o Establish connections (e.g., “Student attends Event”).
4. Draw the Diagram:
o Use UML tools (e.g., Rational Rose) to represent classes/objects and links.
o Class Diagram: Boxes with sections (name, attributes, operations).
o Object Diagram: Similar, but with instance names (e.g., “Book1:Book”).

Example: Class Diagram for a Library App

text
CollapseWrapCopy
+----------------+ +----------------+ +----------------+
| Book | | User | | Loan |
|----------------| |----------------| |----------------|
| title: String |1..* 1 | name: String |1 0..*| loanDate: Date |
| ISBN: String |<------->| ID: String |<--------->| dueDate: Date |
| author: String |borrows | | | returnBook() |
| getDetails() | | borrowBook() | | |
+----------------+ +----------------+ +----------------+
• Classes: Book, User, Loan.
 • Attributes: “title” (Book), “name” (User), “loanDate” (Loan).
• Operations: “getDetails()” (Book), “borrowBook()” (User).
• Relationships:
o “User borrows Book” (1 User to many Books).
o “Loan links User and Book” (1 User to many Loans, 1 Loan to 1 Book).

Example: Object Diagram for the Same Scenario

text
CollapseWrapCopy
+----------------+ +----------------+ +----------------+
| Book1:Book | | Alice:User | | Loan1:Loan |
|----------------| |----------------| |----------------|
| title: "CS101" |1..* 1 | name: "Alice" |1 0..*| loanDate: 3/1 |
| ISBN: "12345" |<------->| ID: "S001" |<--------->| dueDate: 3/15 |
+----------------+borrows +----------------+ +----------------+
• Objects: Specific instances (e.g., “Book1:Book”).
• Links: “Alice borrows Book1 via Loan1.”

Characteristics of Good Structural Models

• Clear: Easy to read, with meaningful names (e.g., “Book” vs. “Thing”).
• Complete: Includes all key entities and relationships.
• Consistent: Matches requirements (e.g., FR: “track loans”).
• Abstract: Focuses on structure, not behavior details.
Example: A vague “data” class becomes “Student” and “Course” for precision.

Practical Example for BSIT Students

Imagine modeling the structure for a campus event app:
• Step 1: Entities: “Event,” “Student,” “Registration.”
• Step 2: Attributes/Operations:
o Event: “title,” “date,” “getDetails().”
o Student: “name,” “ID,” “registerEvent().”
o Registration: “regDate,” “cancel().”
• Step 3: Relationships:
o “Student registers for Event” (many-to-many via Registration).
• Class Diagram:
text
CollapseWrapCopy
+----------------+ +----------------+ +----------------+
| Event | | Student | | Registration |
|----------------| |----------------| |----------------|
| title: String |1..* 0..*| name: String |1 0..*| regDate: Date |
| date: Date |<------->| ID: String |<--------->| cancel() |
| getDetails() |attends | registerEvent()| | |
+----------------+ +----------------+ +----------------+
Scenario: Testing reveals “Organizer” is missing—add it with “creates Event” relationship, refining the
model.

Benefits of Structural Models

• Organization: Breaks the system into logical parts.
• Clarity: Shows how components fit together.
• Foundation: Guides detailed design and coding.
Example: A game’s “Player” and “Weapon” classes ensure “shoot” links to “ammo” correctly.

Real-World Example
• Success: Amazon’s order system uses structural models (e.g., “Order,” “Customer,” “Payment”)
to ensure scalable design.
• Failure: The 2000s FBI Virtual Case File lacked clear structure, leading to integration issues and
abandonment.

Key Takeaways
• Structural models (class and object diagrams) show a system’s static organization.
• They define components, attributes, and relationships.
• Examples like event apps and Amazon highlight their role in analysis.

Topic 19: Analysis Model - Behavioral Models

The nineteenth topic in the Software Engineering course continues the exploration of the Analysis
Model with Behavioral Models. These models focus on the dynamic behavior of a software system,
capturing how it responds to events and changes over time. Below, I’ll explain behavioral models in
detail, including their definition, types, purpose, creation process, and examples tailored for BSIT
students.

What are Behavioral Models?

Behavioral models are representations of a software system’s dynamic behavior, showing how it reacts
to inputs, events, or internal triggers over time. Unlike structural models (which focus on static
organization), behavioral models emphasize actions, states, and transitions. Ian Sommerville (Software
Engineering, 10th Edition) describes them as "models that represent the behavior of a system as it
responds to external and internal events."
Think of it like a choreography chart: it shows the steps (actions) and transitions (state changes) a dancer
(system) performs in response to music (events).
Example: For a library app, a behavioral model might show how the system transitions from “Book
Available” to “Book Borrowed” when a student checks out a book.

Purpose of Behavioral Models

Behavioral models serve key purposes in the analysis phase:
• Describe Dynamics: Capture how the system behaves during operation.
• Model Responses: Show reactions to user actions or system events.
• Validate Requirements: Ensure the system handles scenarios correctly.
• Guide Implementation: Provide a basis for coding logic and workflows.
Example: A behavioral model for a student portal ensures “submit assignment” updates the state from
“Pending” to “Submitted.”

Types of Behavioral Models

Behavioral models are typically represented using UML diagrams. The two primary types are:
1. State Machine Diagrams (State Diagrams):
o Show the states a system or object can be in and how it transitions between them in
response to events.
o Components:
▪ States: Conditions or modes (e.g., “Available,” “Borrowed”).
▪ Transitions: Changes between states, triggered by events (e.g., “borrow”).
▪ Events: Triggers (e.g., “user clicks borrow”).
▪ Actions: Optional responses (e.g., “update database”).
o Example: A book’s states: “Available” → “Borrowed” (on “borrow”) → “Returned.”
2. Activity Diagrams:
o Show the workflow or sequence of activities in a process, including decisions and
parallel actions.
o Components:
▪ Activities: Tasks (e.g., “Check Availability”).
▪ Transitions: Flow between activities (arrows).
▪ Decision Nodes: Choices (e.g., “Book available? Yes/No”).
▪ Start/End Points: Begin and end of the process.
o Example: “Search book → Check availability → Borrow if available.”
Note: State diagrams focus on an object’s lifecycle; activity diagrams focus on process flow.

How to Create a Behavioral Model

The process involves these steps:
1. Identify Scenarios:
o Pick key use cases or behaviors (e.g., “Borrow a Book”).
2. Define States or Activities:
o List states (for state diagrams) or tasks (for activity diagrams).
o Example: States: “Available,” “Borrowed”; Activities: “Search,” “Borrow.”
3. Map Transitions or Flows:
o Specify events causing state changes or activity sequences.
o Example: “Borrow” event moves from “Available” to “Borrowed.”
4. Draw the Diagram:
o Use UML tools (e.g., Rational Rose) to visualize.
o State Diagram: Circles (states), arrows (transitions).
o Activity Diagram: Rounded rectangles (activities), arrows (flows).

Example: State Diagram for a Library Book

Scenario: Book borrowing process.
text
CollapseWrapCopy
[Available] ---borrow---> [Borrowed]
^ |
| return
| |
+--------<----------------+
• States: “Available,” “Borrowed.”
• Transitions:
o “borrow”: Available → Borrowed.
o “return”: Borrowed → Available.
• Events: User actions (borrow, return).

Example: Activity Diagram for Borrowing a Book

Scenario: Student borrows a book.
text
CollapseWrapCopy
[Start]
|
v
[Search Book]
|
v
[Check Availability] --> [Not Available] --> [End]
| Yes
v
[Borrow Book]
|
v
[Update Database]
|
v
[End]
• Activities: Search, check, borrow, update.
• Decision: “Available?” splits the flow.
• Flow: Sequential steps with a decision point.

Characteristics of Good Behavioral Models

• Clear: Easy to follow, with labeled states or activities.
• Complete: Covers all key behaviors for the scenario.
• Accurate: Matches requirements (e.g., FR: “borrow book”).
• Simple: Avoids excessive detail (e.g., no code-level logic).
Example: A vague “do stuff” becomes “Search → Borrow” for clarity.

Practical Example for BSIT Students

Imagine modeling behavior for a campus event app:
 • Use Case: “RSVP to an Event.”
• State Diagram:
text
CollapseWrapCopy
[Open] ---RSVP---> [Registered]
^ |
| cancel
| |
+--------<---------+
• States: “Open” (event available), “Registered” (student RSVP’d).
• Transitions: “RSVP” (Open → Registered), “cancel” (Registered → Open).
• Activity Diagram:
text
CollapseWrapCopy
[Start]
|
v
[View Events]
|
v
[Select Event]
|
v
[RSVP] --> [Full?] --> [End]
| No
v
[Confirm Registration]
|
v
[Send Notification]
|
v
[End]
• Activities: View, select, RSVP, confirm, notify.
• Decision: “Full?” checks event capacity.
Scenario: Testing reveals “waitlist” is missing—add a “Waitlisted” state or activity branch.

Benefits of Behavioral Models

• Dynamic Insight: Shows how the system operates over time.
• Error Detection: Spots missing transitions (e.g., no “cancel” option).
• Implementation Guide: Helps code logic and workflows.
Example: A game’s “Player” state model ensures “Dead” follows “Hit” when health is zero.

Real-World Example
 • Success: ATM systems use behavioral models to ensure “Insert Card → Enter PIN → Withdraw”
flows correctly.
• Failure: The 1996 Ariane 5 crash ignored behavioral modeling, missing a state mismatch in
reused software.

Key Takeaways
• Behavioral models (state and activity diagrams) capture dynamic system behavior.
• They show states/transitions or activity flows for specific scenarios.
• Examples like event apps and ATMs highlight their analysis role.
Comparison of Analysis Models: Context, Interaction, Structural, and Behavioral Models
Before moving to the next topic, let’s compare the four analysis models covered so far: Context Models,
Interaction Models, Structural Models, and Behavioral Models. These models serve distinct yet
complementary purposes in understanding and specifying a software system during the analysis phase.
Below, I’ll provide a detailed comparison based on their focus, representation, purpose, complexity, and
use cases, tailored for BSIT students.

1. Focus
• Context Models:
o Focus: The system’s boundaries and external environment.
o What it Shows: How the system interacts with external entities (e.g., users, other
systems).
o Example: A library app interacts with “Student,” “Librarian,” and “Database.”
o Scope: High-level, external perspective; no internal details.
• Interaction Models:
o Focus: Dynamic interactions between the system and actors or components.
o What it Shows: The sequence or communication of actions (e.g., “Student searches,
system responds”).
o Example: A sequence diagram for “Borrow a Book” shows steps between “Student” and
“Library System.”
o Scope: Specific scenarios, moderate detail.
• Structural Models:
o Focus: Static organization of the system’s components.
o What it Shows: Classes or objects and their relationships (e.g., “User borrows Book”).
o Example: A class diagram links “Student,” “Event,” and “Registration.”
o Scope: System-wide structure, internal perspective.
• Behavioral Models:
o Focus: Dynamic behavior and state changes over time.
o What it Shows: How the system responds to events (e.g., states like “Available” to
“Borrowed”).
o Example: A state diagram for a book shows transitions like “borrow” and “return.”
o Scope: Specific behaviors or workflows, internal dynamics.

2. Representation (UML Diagrams)

• Context Models:
 o Diagram: Context Diagram.
o Elements: Single system box, external entities (ovals), labeled arrows for interactions.
o Example: [Student] ---> [Library App] <--- [Database].
o Style: Simple, one-level view.
• Interaction Models:
o Diagrams: Sequence Diagrams, Collaboration Diagrams.
o Elements: Actors, objects, lifelines (sequence), messages, links (collaboration).
o Example: Sequence: [Student] --> [UI] --> [Database]; Collaboration: numbered links.
o Style: Time-ordered (sequence) or relational (collaboration).
• Structural Models:
o Diagrams: Class Diagrams, Object Diagrams.
o Elements: Classes/objects, attributes, operations, relationships (associations,
inheritance).
o Example: [Book] ---borrows---> [User].
o Style: Box-and-line, static hierarchy.
• Behavioral Models:
o Diagrams: State Machine Diagrams, Activity Diagrams.
o Elements: States, transitions, events (state); activities, flows, decisions (activity).
o Example: State: [Available] ---borrow---> [Borrowed]; Activity: [Search] --> [Borrow].
o Style: State-based or flowchart-like.

3. Purpose
• Context Models:
o Purpose: Define scope and external interfaces.
o Why Use It: To agree on what’s in/out of the system.
o Example: Ensures a parking app focuses on “Students” and “Sensors,” not “Car
Maintenance.”
• Interaction Models:
o Purpose: Detail how interactions occur for specific use cases.
o Why Use It: To validate dynamic requirements and guide coding flows.
o Example: Confirms “RSVP” triggers “confirmation” in an event app.
• Structural Models:
o Purpose: Organize the system’s components and relationships.
o Why Use It: To provide a static blueprint for design and implementation.
o Example: Links “Student” and “Course” for a portal’s database design.
• Behavioral Models:
o Purpose: Capture how the system behaves dynamically.
o Why Use It: To ensure correct responses to events and workflows.
o Example: Ensures a game’s “Player” moves from “Alive” to “Dead” on “hit.”

4. Complexity and Detail

• Context Models:
o Complexity: Low; simplest model, high-level overview.
o Detail: Minimal, no internal structure or behavior.
 o Example: One diagram for an entire app.
• Interaction Models:
o Complexity: Moderate; focuses on specific scenarios.
o Detail: Shows sequence or communication, not full structure.
o Example: One diagram per use case (e.g., “Search Book”).
• Structural Models:
o Complexity: Moderate to high; system-wide but static.
o Detail: Includes classes, attributes, and relationships, no dynamics.
o Example: One diagram for all app entities.
• Behavioral Models:
o Complexity: Moderate to high; detailed for specific behaviors.
o Detail: Shows states or workflows, not static structure.
o Example: One diagram per object (state) or process (activity).

5. Use Cases and Examples

• Context Models:
o Best For: Early analysis, scoping projects.
o Example: A timetable app’s context includes “Student,” “Faculty,” “Schedule DB.”
o When: Start of analysis to set boundaries.
• Interaction Models:
o Best For: Detailing user-system or component interactions.
o Example: Sequence for “Student registers for event” in an event app.
o When: To refine functional requirements.
• Structural Models:
o Best For: Defining system architecture and entities.
o Example: Class diagram for a quiz app with “Question,” “Student,” “Score.”
o When: To plan design and database.
• Behavioral Models:
o Best For: Modeling dynamic responses or workflows.
o Example: State diagram for a “Book” (Available → Borrowed) in a library app.
o When: To validate behavior and logic.

6. Strengths and Weaknesses

• Context Models:
o Strengths: Simple, clarifies scope, stakeholder-friendly.
o Weaknesses: Lacks internal detail, static view only.
o Example: Misses how “Student” searches books.
• Interaction Models:
o Strengths: Shows dynamic flow, catches sequence errors.
o Weaknesses: Limited to specific scenarios, no structure.
o Example: Doesn’t show “Book” attributes.
• Structural Models:
o Strengths: Comprehensive static view, design foundation.
o Weaknesses: No behavior or timing details.
 oExample: Doesn’t show “borrow” process.
• Behavioral Models:
o Strengths: Captures dynamics, ensures correct responses.
o Weaknesses: Limited to behavior, no structural overview.
o Example: Misses “Student” relationships.

Summary Table
Model Focus Diagram Purpose Complexity Best For
External
Context Context Diagram Define scope Low Scoping
boundaries
Dynamic Use case
Interaction Sequence/Collaboration Detail flows Moderate
interactions behavior
Static Organize Moderate-
Structural Class/Object Design blueprint
organization components High
Dynamic Moderate-
Behavioral State/Activity Model responses Workflow/logic
behavior High

Practical Example for BSIT Students

Imagine analyzing a campus parking app:
• Context Model: Shows “Parking App” with “Student,” “Sensors,” “Admin” interacting externally.
• Interaction Model: Sequence diagram for “Student requests spot” → “System checks sensors”
→ “Displays result.”
• Structural Model: Class diagram with “Student,” “ParkingSpot,” “Reservation” and their
relationships.
• Behavioral Model: State diagram for “ParkingSpot”: “Free” → “Reserved” (on “book”) →
“Occupied.”
Scenario: Together, these models ensure the app’s scope (context), flow (interaction), structure
(structural), and behavior (behavioral) are fully understood.

Topic 20: Analysis Model - Model-Driven Engineering

What is Model-Driven Engineering (MDE)?
Model-Driven Engineering (MDE) is an approach to software development where models are the primary
artifacts, driving the design, implementation, and maintenance of a system. Rather than starting with
code, developers create abstract models that are transformed into executable software, often
automatically. Ian Sommerville (Software Engineering, 10th Edition) describes MDE as "an approach
where models are the central focus of development, and code is generated from these models using
automated tools."
Think of it like building a house with a 3D model: you design it in software, tweak it, and then a machine
(tool) prints the parts—less manual hammering.
Example: For a student portal, you model “Student,” “Course,” and “Grade” in UML, then generate code
for a database and UI automatically.

Key Concepts of MDE

 • Models as Primary Artifacts: Abstract representations (e.g., UML diagrams) replace handwritten
code as the main focus.
• Transformation: Tools convert models into code, documentation, or other models.
• Abstraction: Focus on high-level design, hiding low-level details.
• Automation: Reduces manual coding, speeding up development.
Example: A class diagram for a library app becomes a Java application via a code generator.

Process of Model-Driven Engineering

1. Model Creation:
o Build abstract models (e.g., class, state diagrams) based on requirements.
o Example: Model “Event” and “Student” for an event app.
2. Model Refinement:
o Add details (e.g., attributes, constraints) and validate.
o Example: Specify “Event.date” and “Student.ID.”
3. Transformation:
o Use tools to generate code, tests, or deployment scripts.
o Example: Transform UML to Python code with a tool like Enterprise Architect.
4. Implementation and Testing:
o Refine generated code if needed and test the system.
o Example: Test the event app’s RSVP feature.
5. Maintenance:
o Update models, regenerate code as requirements change.
o Example: Add “Notifications” to the model and regenerate.

Tools and Standards

• UML: Core modeling language for MDE (e.g., class, sequence diagrams).
• MOF (Meta-Object Facility): Standard for defining models.
• Tools: Rational Rose, Eclipse Modeling Framework (EMF), MagicDraw.
• Example: Use Rational Rose to model a quiz app, then generate C# code.

Practical Example for BSIT Students

Imagine developing a campus parking app with MDE:
• Model: Create a UML class diagram with “Student,” “ParkingSpot,” and “Reservation.”
• Refine: Add “Spot.location” and “Student.ID” attributes.
• Transform: Use a tool to generate a Python Flask app and SQL database schema.
• Test: Run the app to ensure “reserve spot” works.
• Update: Add “Payment” class later, regenerate code.
Scenario: The generated UI is basic—you tweak it manually, showing MDE’s flexibility.

Benefits and Challenges

• Benefits:
o Faster development via automation.
o Easier maintenance (update models, not code).
o Consistency between design and implementation.
 o Example: A game’s “Player” model generates consistent code across platforms.
• Challenges:
o Learning curve for tools and modeling.
o Limited flexibility for custom code.
o Tool dependency risks.
o Example: A unique UI might require manual coding outside MDE.

Real-World Example
• Success: Automotive systems use MDE (e.g., Simulink) to model and generate control software.
• Contrast: Traditional coding delayed the FBI’s Virtual Case File—MDE might have streamlined it.

Key Takeaways
• MDE uses models as the core, automating code generation.
• It enhances efficiency but requires tool mastery.
• Examples like parking apps show its potential.
Let me know if you’d like more details or if we should move to the next topic: Data Modeling!

Topic 21: Data Modeling

The twenty-first topic in the Software Engineering course shifts focus to Data Modeling, a critical aspect
of designing a software system’s data structure. Data modeling defines how data is organized, stored,
and related, providing a foundation for databases and system functionality. Below, I’ll explain data
modeling in detail, including its definition, purpose, types, process, and examples tailored for BSIT
students.

What is Data Modeling?

Data modeling is the process of creating a structured representation of the data required by a software
system, including entities, their attributes, and relationships. Ian Sommerville (Software Engineering,
10th Edition) describes it as "the process of developing a data model for the information to be stored in a
system, which can be used as a basis for database design."
Think of it like organizing a filing cabinet: you decide what folders (entities) you need (e.g., “Students,”
“Courses”), what goes in them (attributes like “name,” “ID”), and how they connect (e.g., “Students
enroll in Courses”).
Example: For a library app, a data model might define “Book” (with “title,” “ISBN”) and “User” (with
“name,” “ID”), linked by “borrows.”

Purpose of Data Modeling

Data modeling serves several key purposes:
• Organize Data: Structures information for efficient storage and retrieval.
• Support Requirements: Ensures data meets functional needs (e.g., “track loans”).
• Enable Database Design: Guides the creation of tables and relationships.
• Facilitate Communication: Helps stakeholders and developers understand data needs.
Example: A student portal’s data model ensures “Grades” link to “Students” and “Courses,” supporting
“view grades” functionality.
Types of Data Models
Data models are developed at different levels of abstraction:
1. Conceptual Data Model:
o High-level, abstract view focusing on entities and relationships.
o No technical details (e.g., data types).
o Example: “Student enrolls in Course” with entities “Student” and “Course.”
o Tool: Entity-Relationship Diagram (ERD).
2. Logical Data Model:
o Adds detail like attributes and keys, independent of specific database systems.
o Example: “Student (ID, name)” and “Course (code, title)” with a “Student-Course”
relationship.
o Tool: Enhanced ERD or UML class diagram.
3. Physical Data Model:
o Detailed, database-specific design with tables, columns, data types, and constraints.
o Example: Table “Students” (ID: INT, name: VARCHAR(50)) linked to “Courses” via foreign
keys.
o Tool: Database schema (e.g., SQL DDL).

Components of a Data Model

• Entities: Objects or concepts (e.g., “Book,” “User”).
• Attributes: Properties of entities (e.g., “title,” “name”).
• Relationships: Connections between entities (e.g., “borrows,” “enrolls in”).
o Types:
▪ One-to-One (1:1): “User has one Library Card.”
▪ One-to-Many (1:N): “User borrows many Books.”
▪ Many-to-Many (M:N): “Students enroll in many Courses” (requires a junction
table).
• Keys:
o Primary Key: Unique identifier (e.g., “Student.ID”).
o Foreign Key: Links entities (e.g., “Loan.studentID” references “Student.ID”).
Example: “Book (ISBN, title)” and “Loan (loanID, ISBN, userID)” with “ISBN” as a foreign key.

How to Create a Data Model

The process involves these steps:
1. Identify Entities:
o List key objects from requirements (e.g., “Event,” “Student”).
2. Define Attributes:
o Specify properties (e.g., “Event: title, date”).
3. Establish Relationships:
o Connect entities (e.g., “Student attends Event”).
4. Add Keys:
o Assign primary and foreign keys (e.g., “Event.ID,” “Student.eventID”).
5. Draw the Model:
o Use tools like ERD (e.g., Lucidchart, MySQL Workbench) or UML.
 6. Refine:
o Validate with stakeholders and normalize (remove redundancy).

Example: Conceptual Data Model (ERD) for a Library App

text
CollapseWrapCopy
[Book] -------- [Loan] -------- [User]
| | |
title loanID name
ISBN (PK) ISBN (FK) userID (PK)
author userID (FK) email
loanDate
dueDate
• Entities: Book, Loan, User.
• Relationships: “User borrows Book” via “Loan” (M:N resolved with junction entity).
• Keys: “ISBN” (Book), “userID” (User), “loanID” (Loan).

Example: Logical Data Model

text
CollapseWrapCopy
Book (ISBN: String, title: String, author: String)
User (userID: String, name: String, email: String)
Loan (loanID: String, ISBN: String, userID: String, loanDate: Date, dueDate: Date)
• Attributes: Added with types.
• Relationships: “Loan” links “Book” and “User” via foreign keys.

Example: Physical Data Model (SQL Schema)

sql
CollapseWrapCopy
CREATE TABLE Book (
ISBN VARCHAR(13) PRIMARY KEY,
title VARCHAR(100),
author VARCHAR(50)
);

CREATE TABLE User (

userID VARCHAR(10) PRIMARY KEY,
name VARCHAR(50),
email VARCHAR(100)
);

CREATE TABLE Loan (

loanID INT PRIMARY KEY AUTO_INCREMENT,
ISBN VARCHAR(13),
 userID VARCHAR(10),
loanDate DATE,
dueDate DATE,
FOREIGN KEY (ISBN) REFERENCES Book(ISBN),
FOREIGN KEY (userID) REFERENCES User(userID)
);
• Details: Tables, data types, constraints (e.g., foreign keys).

Practical Example for BSIT Students

Imagine modeling data for a campus event app:
• Step 1: Entities: “Event,” “Student,” “Registration.”
• Step 2: Attributes:
o Event: “eventID, title, date.”
o Student: “studentID, name.”
o Registration: “regID, eventID, studentID, regDate.”
• Step 3: Relationships: “Student registers for Event” (M:N via Registration).
• ERD:
text
CollapseWrapCopy
[Event] -------- [Registration] -------- [Student]
| | |
eventID (PK) regID (PK) studentID (PK)
title eventID (FK) name
date studentID (FK)
regDate
Scenario: Faculty suggest “capacity” for events—add “Event.capacity” and refine.

Benefits of Data Modeling

• Clarity: Ensures data supports system goals.
• Efficiency: Optimizes storage and retrieval (e.g., normalization).
• Scalability: Prepares for growth (e.g., more students).
Example: A game’s “Player” and “Score” model ensures fast leaderboard queries.

Real-World Example
• Success: Amazon’s data model links “Customer,” “Order,” and “Product” for efficient e-
commerce.
• Failure: The 2000s NHS IT system lacked a clear data model, causing data integration issues.

Key Takeaways
• Data modeling structures entities, attributes, and relationships.
• It progresses from conceptual to physical levels.
• Examples like event apps and Amazon show its design role.

Topic 22: Functional Modeling

The twenty-second topic in the Software Engineering course explores Functional Modeling, a technique
used to represent the functional aspects of a software system—what it does and how its processes work.
This topic focuses on breaking down the system into functions or processes that transform inputs into
outputs. Below, I’ll explain functional modeling in detail, including its definition, purpose, techniques,
creation process, and examples tailored for BSIT students.

What is Functional Modeling?

Functional modeling is the process of representing a software system’s functionality by identifying and
describing its processes, inputs, outputs, and data flows. Ian Sommerville (Software Engineering, 10th
Edition) describes it as "a way to model a system in terms of the functions it performs and the data that
flows between these functions."
Think of it like a recipe: it lists the steps (functions) like “chop vegetables,” “cook,” and “serve,” along
with ingredients (inputs) and the final dish (output).
Example: For a library app, functional modeling might show a “Borrow Book” function that takes “book
ID” and “user ID” as inputs and produces a “loan record” as output.

Purpose of Functional Modeling

Functional modeling serves several key purposes:
• Define What the System Does: Breaks down requirements into specific processes.
• Show Data Flow: Illustrates how data moves through the system.
• Support Design: Guides implementation by detailing functional components.
• Validate Requirements: Ensures all necessary functions are captured.
Example: A student portal’s “Calculate GPA” function ensures the system meets the requirement to
“display academic performance.”

Techniques for Functional Modeling

Functional modeling is typically represented using diagrams that focus on processes and data flows.
Common techniques include:
1. Data Flow Diagrams (DFDs):
o Show how data flows between processes, external entities, and data stores.
o Components:
▪ Processes: Functions or transformations (e.g., “Borrow Book”).
▪ External Entities: Users or systems outside the app (e.g., “Student”).
▪ Data Flows: Arrows showing data movement (e.g., “book ID”).
▪ Data Stores: Places where data is held (e.g., “Book Database”).
o Levels:
▪ Context Level (Level 0): High-level view (like a context model).
▪ Level 1 and Beyond: Detailed breakdowns of processes.
2. Function Flow Diagrams:
o Less common, focus on the sequence of functions without heavy data emphasis.
o Example: “Search Book → Check Availability → Borrow.”
3. Use Case Diagrams (Related):
o While not purely functional, they identify high-level functions (use cases) tied to actors.
o Example: “Student borrows book” as a use case.
Note: DFDs are the most widely used for functional modeling in traditional approaches.

How to Create a Functional Model (Using DFDs)

The process involves these steps:
1. Identify External Entities:
o List users or systems interacting with the app (e.g., “Student,” “Librarian”).
2. Define Processes:
o Break down the system into key functions (e.g., “Search Book,” “Borrow Book”).
3. Map Data Flows:
o Specify inputs and outputs for each process (e.g., “book ID” in, “availability” out).
4. Identify Data Stores:
o Note where data is stored (e.g., “Loan Records”).
5. Draw the Diagram:
o Use circles (processes), rectangles (entities), arrows (flows), and open-ended boxes
(stores).
o Tools: Visio, Lucidchart, or UML software like Rational Rose.

Example: Context-Level DFD (Level 0) for a Library App

text
CollapseWrapCopy
[Student] ----book request----> [Library System] ----book details---->
| |
book ID availability
| |
\/ \/
[Book Database] <----store/update---->
• Entities: Student, Book Database.
• Process: Library System (single process at this level).
• Flows: Book request, book details, store/update.

Example: Level 1 DFD for Borrowing a Book

text
CollapseWrapCopy
[Student] ----book ID----> [1. Search Book] ----availability----> [2. Borrow Book] ----loan confirmation---->
| | | |
| book details | |
| | | |
| \/ | |
| [Book DB] <----update-----[3. Record Loan] ---->
| | | |
| store loan | |
| | | |
| \/ \/ |
| [Loan DB] <----loan record------------------->
 • Processes: Search Book, Borrow Book, Record Loan.
• Data Stores: Book DB, Loan DB.
• Flows: Book ID, availability, loan record.

Characteristics of Good Functional Models

• Clear: Processes and flows are well-labeled (e.g., “Search Book” vs. “Do Stuff”).
• Complete: Covers all key functions from requirements.
• Consistent: Matches functional requirements (e.g., “calculate GPA”).
• Hierarchical: Breaks down complex processes into sub-levels.
Example: A vague “handle books” becomes “Search Book → Borrow Book” for clarity.

Practical Example for BSIT Students

Imagine modeling functions for a campus event app:
• Step 1: Entities: “Student,” “Event Database.”
• Step 2: Processes: “View Events,” “RSVP Event,” “Send Notification.”
• Step 3: Flows:
o “Student → View Events: event request → event list.”
o “View Events → RSVP Event: event ID → registration.”
o “RSVP Event → Send Notification: confirmation → alert.”
• Step 4: Stores: “Event DB” (events), “Registration DB” (RSVP records).
• Level 1 DFD:
text
CollapseWrapCopy
[Student] ----event request----> [1. View Events] ----event list---->
| | |
event ID event details
| | |
| \/ |
| [Event DB] |
| | |
| RSVP request |
| | |
| \/ |
| [2. RSVP Event] ----confirmation----> [3. Send Notification] ----alert---->
| | |
| store registration |
| | |
| \/ |
| [Registration DB] |
Scenario: Students suggest “cancel RSVP”—add a “Cancel Registration” process and update flows.

Benefits of Functional Modeling

• Clarity: Shows how functions transform data.
• Modularity: Breaks system into manageable parts.
 • Validation: Ensures all required processes are included.
Example: A game’s “Score Points” function links “hit target” to “update score.”

Real-World Example
• Success: PayPal’s payment system uses functional modeling to map “Enter Amount → Verify
Card → Transfer Funds.”
• Failure: The 1992 London Ambulance System skipped functional modeling, missing key dispatch
processes.

Key Takeaways
• Functional modeling (e.g., DFDs) details system processes and data flows.
• It supports requirements validation and design.
• Examples like event apps and PayPal show its practical role.

Topic 23: Software Design - Data Design

The twenty-third topic in the Software Engineering course transitions into the Software Design phase,
starting with Data Design. This topic focuses on transforming the data model from the analysis phase
into a concrete, optimized structure for implementation, typically as a database or data storage system.
Below, I’ll explain data design in detail, including its definition, purpose, principles, process, and
examples tailored for BSIT students.

What is Data Design?

Data design is the process of defining how data will be structured, stored, accessed, and managed within
a software system. It builds on the data modeling done during analysis (e.g., conceptual, logical models)
and refines it into a practical, implementation-ready design. Ian Sommerville (Software Engineering, 10th
Edition) describes data design as "the process of designing the data structures and databases that will
store the information required by the system."
Think of it like turning a sketch of a filing cabinet into a real one: you decide the drawer sizes (data
types), labels (attributes), and how files link (relationships) for efficient use.
Example: For a library app, data design converts a model of “Book” and “User” into database tables with
columns like “ISBN” and “userID,” optimized for fast queries.

Purpose of Data Design

Data design serves several key purposes in software development:
• Support Functionality: Ensures data structures meet system requirements (e.g., “track loans”).
• Optimize Performance: Designs efficient storage and retrieval mechanisms.
• Enable Scalability: Prepares data for growth (e.g., more users).
• Facilitate Maintenance: Structures data for easy updates and integrity.
Example: A student portal’s data design ensures “Grades” are linked to “Students” for quick access and
future expansion.

Principles of Data Design

Effective data design follows these principles:
1. Accuracy: Data structures match requirements (e.g., all attributes included).
 2. Efficiency: Minimizes redundancy and optimizes queries (e.g., normalization).
3. Consistency: Ensures data integrity across the system (e.g., no duplicate records).
4. Scalability: Supports increased data volume or users.
5. Simplicity: Avoids unnecessary complexity for maintainability.
Example: A game’s “Player” table avoids redundant “score” fields by linking to a separate “Score” table.

Components of Data Design

Data design typically involves:
• Entities/Tables: Core data objects (e.g., “Book,” “User”).
• Attributes/Columns: Properties with data types (e.g., “title: VARCHAR(100)”).
• Relationships: Links between tables (e.g., foreign keys).
• Keys:
o Primary Key (PK): Unique identifier (e.g., “userID”).
o Foreign Key (FK): Connects tables (e.g., “loan.userID” references “User.userID”).
• Indexes: Speed up queries (e.g., index on “ISBN”).
• Constraints: Rules like “NOT NULL” or “UNIQUE.”
Example: “Loan” table with “loanID (PK),” “ISBN (FK),” and “dueDate (NOT NULL).”

How to Create a Data Design

The process builds on the data model from analysis:
1. Start with Logical Data Model:
o Use entities, attributes, and relationships (e.g., “Student,” “Course”).
2. Map to Physical Structure:
o Define tables, columns, and data types (e.g., “Student: ID INT, name VARCHAR”).
3. Apply Normalization:
o Eliminate redundancy and ensure data integrity (e.g., split “Student-Course” into
separate tables).
4. Add Constraints and Indexes:
o Enforce rules and optimize performance (e.g., “UNIQUE ID,” index on “name”).
5. Specify Storage:
o Choose database type (e.g., relational like MySQL, NoSQL like MongoDB).
6. Validate:
o Check against requirements and test with sample data.

Example: Data Design for a Library App

Logical Model (from Analysis):
• Book (ISBN, title, author)
• User (userID, name, email)
• Loan (loanID, ISBN, userID, loanDate, dueDate)
Physical Data Design (SQL Schema):
sql
CollapseWrapCopy
CREATE TABLE Book (
ISBN VARCHAR(13) PRIMARY KEY,
 title VARCHAR(100) NOT NULL,
author VARCHAR(50),
INDEX (title) -- For faster searches
);

CREATE TABLE User (

userID VARCHAR(10) PRIMARY KEY,
name VARCHAR(50) NOT NULL,
email VARCHAR(100) UNIQUE
);

CREATE TABLE Loan (

loanID INT PRIMARY KEY AUTO_INCREMENT,
ISBN VARCHAR(13),
userID VARCHAR(10),
loanDate DATE NOT NULL,
dueDate DATE NOT NULL,
FOREIGN KEY (ISBN) REFERENCES Book(ISBN) ON DELETE CASCADE,
FOREIGN KEY (userID) REFERENCES User(userID) ON DELETE RESTRICT
);
• Tables: Book, User, Loan.
• Constraints: “NOT NULL” for critical fields, “UNIQUE” for email.
• Indexes: On “title” for quick searches.
• Relationships: Foreign keys link “Loan” to “Book” and “User.”

Normalization in Data Design

Normalization removes redundancy and ensures data integrity:
• 1NF (First Normal Form): No repeating groups (e.g., split “books borrowed” into “Loan”).
• 2NF: No partial dependencies (e.g., “author” depends only on “ISBN,” not “loanID”).
• 3NF: No transitive dependencies (e.g., move “user email” to “User” table).
Example: Unnormalized “Loan (userID, name, ISBN, title)” splits into “User” and “Book” tables.

Practical Example for BSIT Students

Imagine designing data for a campus event app:
• Logical Model:
o Event (eventID, title, date)
o Student (studentID, name)
o Registration (regID, eventID, studentID, regDate)
• Physical Design:
sql
CollapseWrapCopy
CREATE TABLE Event (
eventID INT PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(100) NOT NULL,
 date DATE NOT NULL,
INDEX (date) -- For sorting by date
);

CREATE TABLE Student (

studentID VARCHAR(10) PRIMARY KEY,
name VARCHAR(50) NOT NULL
);

CREATE TABLE Registration (

regID INT PRIMARY KEY AUTO_INCREMENT,
eventID INT,
studentID VARCHAR(10),
regDate DATE NOT NULL,
FOREIGN KEY (eventID) REFERENCES Event(eventID),
FOREIGN KEY (studentID) REFERENCES Student(studentID)
);
Scenario: Add “capacity” to “Event” (e.g., “capacity INT”) and a check constraint (e.g., “capacity > 0”)—
optimizing for event limits.

Benefits of Data Design

• Efficiency: Fast queries (e.g., indexed “title”).
• Integrity: Prevents errors (e.g., no orphan loans).
• Scalability: Handles growth (e.g., more events).
Example: A game’s “Player” and “Score” design ensures quick leaderboard updates.

Real-World Example
• Success: Netflix’s data design links “User,” “Movie,” and “Watch History” for fast streaming
recommendations.
• Failure: The 2000s NHS IT system had poor data design, causing data mismatches.

Key Takeaways
• Data design transforms data models into optimized structures.
• It uses tables, keys, and constraints for efficiency and integrity.
• Examples like event apps and Netflix show its critical role.

Topic 24: Software Design - Architectural Design

The twenty-fourth topic in the Software Engineering course continues the Software Design phase with
Architectural Design. This topic focuses on defining the overall structure of a software system, organizing
its components, and specifying how they interact. Below, I’ll explain architectural design in detail,
including its definition, purpose, principles, types, process, and examples tailored for BSIT students.

What is Architectural Design?

Architectural design is the process of defining a high-level structure for a software system, identifying its
major components, their responsibilities, and how they interact to fulfill the system’s requirements. Ian
Sommerville (Software Engineering, 10th Edition) describes it as "the process of identifying the sub-
systems making up a system and the framework for sub-system control and communication."
Think of it like designing a city: you plan the districts (components like residential, commercial), roads
(interactions), and utilities (support services) before building individual houses.
Example: For a library app, architectural design might split the system into “User Interface,” “Business
Logic,” and “Database,” with defined interactions like “UI requests book data from Logic.”

Purpose of Architectural Design

Architectural design serves several key purposes:
• Structure the System: Breaks complexity into manageable parts.
• Define Interactions: Specifies how components communicate.
• Meet Requirements: Ensures functional and non-functional needs (e.g., scalability).
• Guide Development: Provides a blueprint for detailed design and coding.
Example: A student portal’s architecture ensures “Grade Display” (UI) connects to “Grade Calculation”
(Logic) and “Grade Storage” (Database) efficiently.

Principles of Architectural Design

Effective architectural design follows these principles:
1. Modularity: Divide the system into independent, cohesive components.
2. Separation of Concerns: Assign distinct roles (e.g., UI vs. data storage).
3. Abstraction: Hide implementation details, exposing only interfaces.
4. Scalability: Design for growth (e.g., more users).
5. Reusability: Use components across projects where possible.
Example: A game’s “Graphics Engine” is separate from “Game Logic” for modularity and reuse.

Architectural Styles (Patterns)

Architectural design often adopts common patterns:
1. Layered Architecture:
o Components are organized in layers (e.g., Presentation, Business, Data).
o Example: A web app with UI (browser), Logic (server), and Database layers.
o Pros: Clear separation, easy maintenance.
o Cons: Can be rigid, performance overhead.
2. Client-Server:
o Clients request services from a centralized server.
o Example: A chat app where clients (users) connect to a messaging server.
o Pros: Centralized control, scalability.
o Cons: Server bottleneck risk.
3. Model-View-Controller (MVC):
o Splits into Model (data), View (UI), Controller (logic).
o Example: A portal where Model stores grades, View displays them, and Controller
handles requests.
o Pros: Flexible UI updates, reusable logic.
 o Cons: Complexity in small systems.
4. Microservices:
o Independent, small services communicate over a network.
o Example: An e-commerce app with separate “Order,” “Payment,” and “Inventory”
services.
o Pros: Scalability, independent deployment.
o Cons: Complex coordination.
5. Repository (Centralized Data):
o Components access a shared data store.
o Example: A library app where all modules use one “Book Database.”
o Pros: Data consistency.
o Cons: Single point of failure.

How to Create an Architectural Design

The process involves these steps:
1. Understand Requirements:
o Review functional (e.g., “borrow book”) and non-functional (e.g., “handle 1,000 users”)
needs.
2. Identify Components:
o Break the system into sub-systems (e.g., “UI,” “Logic,” “Data”).
3. Define Interactions:
o Specify communication (e.g., “UI calls Logic via API”).
4. Choose an Architectural Style:
o Match the pattern to needs (e.g., MVC for a web app).
5. Document the Design:
o Use diagrams (e.g., UML architecture diagram) and descriptions.
6. Validate:
o Check against requirements (e.g., scalability, performance).

Example: Architectural Design for a Library App (Layered Style)

Diagram:
text
CollapseWrapCopy
+-------------------+
| Presentation | (UI: Web forms, mobile screens)
| (User Interface) |
+-------------------+
|
v
+-------------------+
| Application | (Logic: Book search, loan processing)
| (Business Logic) |
+-------------------+
|
 v
+-------------------+
| Data Layer | (Database: MySQL with Book, User tables)
| (Storage) |
+-------------------+
• Components:
o Presentation: Displays books, accepts inputs.
o Application: Processes requests (e.g., “borrow book”).
o Data: Stores and retrieves data.
• Interactions: UI sends requests to Logic, Logic queries Data.

Practical Example for BSIT Students

Imagine designing the architecture for a campus event app using MVC:
• Components:
o Model: “Event” (data: title, date), “Registration” (data: studentID, regDate).
o View: Web/mobile UI showing event lists and RSVP buttons.
o Controller: Logic to handle “RSVP” requests and update registrations.
• Diagram:
text
CollapseWrapCopy
[Student] ----(view events)----> [View]
| |
| (display events)
| |
|----(RSVP request)----> [Controller] ----(update data)----> [Model]
| | |
| (confirmation) (store)
| | |
|<----(display success)-- [View] <----------------------- [Database]
• Interactions: Student interacts with View, Controller processes, Model updates Database.
Scenario: Need scalability? Switch to Microservices (e.g., “Event Service,” “Registration Service”).

Benefits of Architectural Design

• Clarity: Defines system structure for all team members.
• Flexibility: Easier to modify or scale (e.g., add a new module).
• Reliability: Reduces risks with clear component roles.
Example: A game’s “Physics Engine” separate from “UI” allows easy updates.

Real-World Example
• Success: Netflix uses a microservices architecture (e.g., “Streaming,” “Recommendation”) for
scalability and resilience.
• Failure: The 1990s Denver Airport baggage system had a poor architecture, causing delays and
cost overruns.
Key Takeaways
• Architectural design structures a system into components and interactions.
• It uses patterns like Layered, MVC, or Microservices.
• Examples like event apps and Netflix show its foundational role.

Topic 25: Software Design - Component-Level Design

The twenty-fifth topic in the Software Engineering course continues the Software Design phase with
Component-Level Design. This topic focuses on refining the architectural design into detailed,
implementable components—essentially translating high-level sub-systems into specific modules or
units ready for coding. Below, I’ll explain component-level design in detail, including its definition,
purpose, principles, process, and examples tailored for BSIT students.

What is Component-Level Design?

Component-level design (also called detailed design) is the process of defining the internal structure,
behavior, and interfaces of individual components within a software system’s architecture. It bridges the
gap between architectural design (system structure) and implementation (coding). Ian Sommerville
(Software Engineering, 10th Edition) describes it as "the process of defining the data structures,
algorithms, and interfaces for each component identified in the architectural design."
Think of it like detailing a car’s engine after sketching the car: architectural design outlines “engine,”
“wheels,” etc., while component-level design specifies the pistons, fuel injectors, and how they connect.
Example: For a library app, component-level design might detail the “Borrow Book” component with its
data (book ID, user ID), logic (check availability), and interface (input/output methods).

Purpose of Component-Level Design

Component-level design serves several key purposes:
• Refine Components: Breaks sub-systems into specific, coded units.
• Specify Behavior: Defines how each component works internally.
• Enable Implementation: Provides a clear plan for developers to code.
• Ensure Integration: Ensures components work together as designed.
Example: In a student portal, component-level design details the “Calculate GPA” component so it can be
coded and linked to the UI.

Principles of Component-Level Design

Effective component-level design follows these principles:
1. Modularity: Each component should be self-contained and focused on one task.
2. Cohesion: Elements within a component should work toward a single purpose (e.g., “manage
loans”).
3. Low Coupling: Minimize dependencies between components for flexibility.
4. Reusability: Design components to be used in multiple contexts.
5. Abstraction: Expose only necessary interfaces, hiding internal details.
Example: A “Search Book” component is cohesive (searches only), loosely coupled (uses a database
interface), and reusable across apps.

Elements of Component-Level Design

Component-level design includes:
• Data Structures: Variables and storage (e.g., arrays, objects).
• Algorithms: Logic or procedures (e.g., sorting, validation).
• Interfaces: Inputs/outputs and method signatures (e.g., “borrowBook(bookID)”).
• Control Flow: How execution moves within the component (e.g., if-then-else).
Example: “Borrow Book” component:
• Data: “bookID, userID.”
• Algorithm: “Check availability, update loan status.”
• Interface: “borrowBook(bookID, userID) → Boolean.”

How to Create a Component-Level Design

The process involves these steps:
1. Start with Architecture:
o Use architectural components (e.g., “Business Logic” layer).
2. Decompose into Components:
o Break into smaller units (e.g., “Search,” “Borrow”).
3. Define Interfaces:
o Specify inputs, outputs, and method calls (e.g., “getBookDetails(ISBN)”).
4. Detail Internals:
o Design data structures and algorithms (e.g., “array of loans,” “if available, then borrow”).
5. Document:
o Use pseudocode, flowcharts, or UML (e.g., class diagrams with methods).
6. Validate:
o Check against requirements and architecture (e.g., meets “track loans”).

Representation Tools
• Pseudocode: Informal code-like description.
o Example: if book.available then updateLoan(bookID, userID).
• Flowcharts: Visual control flow.
o Example: [Start] → [Check Availability] → [Yes: Borrow] → [End].
• UML Diagrams:
o Class Diagrams: Show component structure with methods.
o Sequence Diagrams: Detail interactions within components.

Example: Component-Level Design for “Borrow Book” in a Library App

Architecture Component: Business Logic. Detailed Design:
• Component Name: BorrowBook
• Interface:
o borrowBook(bookID: String, userID: String): Boolean
• Data Structures:
o book: {ISBN, title, available}
o loan: {loanID, bookID, userID, loanDate}
• Algorithm (Pseudocode):
text
CollapseWrapCopy
function borrowBook(bookID, userID):
book = getBook(bookID) // Fetch from database
if book.available then
loan = createLoan(bookID, userID, currentDate)
book.available = false
updateBook(book)
saveLoan(loan)
return true
else
return false
• Flowchart:
text
CollapseWrapCopy
[Start] → [Get Book] → [Available?] → [Yes: Create Loan, Update Book] → [Return True]
| No |
+------> [Return False] → [End]

Practical Example for BSIT Students

Imagine designing a component for a campus event app:
• Architecture Component: Controller (MVC).
• Component: RegisterEvent
• Interface:
o registerEvent(eventID: Int, studentID: String): Boolean
• Data Structures:
o event: {eventID, title, capacity}
o registration: {regID, eventID, studentID, regDate}
• Algorithm (Pseudocode):
text
CollapseWrapCopy
function registerEvent(eventID, studentID):
event = getEvent(eventID)
if event.capacity > countRegistrations(eventID) then
registration = createRegistration(eventID, studentID, currentDate)
saveRegistration(registration)
return true
else
return false
• Validation: Ensures “RSVP” meets capacity limits.
Scenario: Add “send notification” after registration—update the algorithm to call
notifyStudent(studentID).

Benefits of Component-Level Design

• Clarity: Developers know exactly what to code.
 • Testability: Small units are easier to test (e.g., “borrowBook”).
• Maintainability: Isolated changes (e.g., tweak “Search” without affecting “Borrow”).
Example: A game’s “MovePlayer” component can be updated without touching “RenderGraphics.”

Real-World Example
• Success: Google Maps’ “Route Calculator” component is modular, interfacing with “Map Data”
for efficient navigation.
• Failure: The 1990s Denver Airport baggage system lacked clear component design, causing
integration chaos.

Key Takeaways
• Component-level design details individual modules from the architecture.
• It defines data, algorithms, and interfaces for coding.
• Examples like event apps and Maps show its implementation role.

Topic 26: Software Design - User Interface Design

The twenty-sixth topic in the Software Engineering course continues the Software Design phase with
User Interface Design (UI Design). This topic focuses on designing the part of the software that users
interact with, ensuring it is intuitive, efficient, and visually appealing. Below, I’ll explain UI design in
detail, including its definition, purpose, principles, process, and examples tailored for BSIT students.

What is User Interface Design?

User Interface Design is the process of creating the visual and interactive elements of a software system
that enable users to communicate with it effectively. It encompasses layout, controls, and feedback
mechanisms. Ian Sommerville (Software Engineering, 10th Edition) describes UI design as "the process of
designing the interface between the user and the system, focusing on how information is presented and
how users interact with it."
Think of it like designing a car’s dashboard: you decide where the speedometer (display) and steering
wheel (controls) go, ensuring they’re easy to use and understand.
Example: For a library app, UI design might involve a search bar, book list display, and a “Borrow” button,
all arranged for quick access.

Purpose of User Interface Design

UI design serves several key purposes:
• Enable Interaction: Allows users to perform tasks (e.g., “view grades”).
• Enhance Usability: Makes the system intuitive and efficient.
• Meet User Expectations: Aligns with user needs and preferences.
• Support Functionality: Presents system features effectively.
Example: A student portal’s UI ensures “Calculate GPA” is a clear, clickable option, not buried in menus.

Principles of User Interface Design

Effective UI design follows these principles:
1. Clarity: Interface elements should be easy to understand (e.g., clear labels).
2. Consistency: Use uniform styles and layouts (e.g., same button color).
 3. Simplicity: Avoid clutter, focus on essentials (e.g., minimal clicks).
4. Feedback: Provide immediate responses (e.g., “Book borrowed” message).
5. User-Centered: Design for the target audience (e.g., students vs. experts).
6. Accessibility: Support diverse users (e.g., colorblind-friendly colors).
Example: A game’s UI keeps “Shoot” as a big, red button, consistent across levels, with a “Bang!” sound
for feedback.

Types of User Interfaces

• Graphical User Interface (GUI): Visual elements like windows, buttons (e.g., web apps).
• Command-Line Interface (CLI): Text-based commands (e.g., terminal).
• Touch Interface: Gestures on screens (e.g., mobile apps).
• Voice Interface: Spoken commands (e.g., Siri).
• Web Interface: Browser-based (e.g., online portals).
Focus: This topic typically emphasizes GUI design, common in modern software.

How to Create a User Interface Design

The process involves these steps:
1. Understand Users and Requirements:
o Identify audience and tasks (e.g., students need “view events”).
2. Sketch Initial Layouts:
o Draft wireframes or mockups (e.g., event list with RSVP button).
3. Define Interaction Elements:
o Choose controls (e.g., buttons, text fields) and displays (e.g., tables).
4. Apply Design Principles:
o Ensure clarity, consistency, etc. (e.g., same font throughout).
5. Prototype:
o Build interactive versions (e.g., using Figma, Adobe XD).
6. Test and Refine:
o Get user feedback and adjust (e.g., move “Submit” for better visibility).
7. Document:
o Specify UI specs (e.g., “Button: Blue, 50x20px”).

UI Design Elements
• Input Controls: Buttons, text fields, dropdowns (e.g., “Search” button).
• Navigation: Menus, tabs, breadcrumbs (e.g., “Home > Events”).
• Information Displays: Tables, charts, text (e.g., event list).
• Feedback: Messages, alerts, progress bars (e.g., “RSVP confirmed”).
Example: A library app UI:
• Input: “Search” text field.
• Navigation: “Books | Loans” tabs.
• Display: Table of book titles.
• Feedback: “Book unavailable” popup.

Example: UI Design for a Library App

Wireframe:
text
CollapseWrapCopy
+-------------------------------+
| [Search: ____] [Search Btn] |
+-------------------------------+
| Books | Loans |
+-------------------------------+
| Title | Author | Status |
|-------------|--------|--------|
| CS101 | Smith | Available |
| Math202 | Jones | Borrowed |
+-------------------------------+
| [Borrow] [Details] |
+-------------------------------+
• Layout: Search bar at top, tabbed navigation, table below, buttons at bottom.
• Feedback: Clicking “Borrow” shows “Success” or “Not Available.”

Practical Example for BSIT Students

Imagine designing the UI for a campus event app:
• Step 1: Requirements: “View events, RSVP.”
• Step 2: Sketch:
o Top: “Event App” title.
o Middle: List of events (“Hackathon, 3/15, RSVP”).
o Bottom: “RSVP” button.
• Step 3: Elements:
o Input: “Filter by date” dropdown.
o Display: Event list in a scrollable table.
o Feedback: “Registered!” popup.
• Step 4: Prototype:
text
CollapseWrapCopy
+---------------------+
| Event App |
+---------------------+
| Filter: [All v] |
+---------------------+
| Hackathon 3/15 |
| Seminar 3/20 |
+---------------------+
| [RSVP] |
+---------------------+
• Step 5: Test: Students find “RSVP” hard to spot—enlarge and color it green.
Benefits of User Interface Design
• Usability: Reduces learning curve (e.g., intuitive event RSVP).
• Efficiency: Speeds up tasks (e.g., one-click borrowing).
• Satisfaction: Pleasing design retains users.
Example: A game’s clean UI (e.g., “Play” button front and center) keeps players engaged.

Real-World Example
• Success: Google’s minimalist search UI (one text box, two buttons) is clear and efficient.
• Failure: The 2013 Healthcare.gov UI was cluttered and confusing, frustrating users.

Key Takeaways
• UI design creates the user-facing part of a system.
• It emphasizes clarity, consistency, and usability.
• Examples like event apps and Google show its impact.

Topic 27: Object-Oriented Analysis & Design Basics - Introduction to UML

The twenty-seventh topic in the Software Engineering course introduces Object-Oriented Analysis and
Design (OOAD), starting with an Introduction to UML (Unified Modeling Language). This topic lays the
foundation for using object-oriented principles and UML to model and design software systems. Below,
I’ll explain UML in the context of OOAD, including its definition, purpose, key diagrams, and examples
tailored for BSIT students.

What is Object-Oriented Analysis and Design (OOAD)?

OOAD is an approach to software development that models a system as a collection of interacting
objects, each encapsulating data and behavior. It consists of:
• Object-Oriented Analysis (OOA): Identifies objects, their attributes, and relationships based on
requirements.
• Object-Oriented Design (OOD): Defines how these objects collaborate to implement the system,
refining them into classes and interfaces.
Unified Modeling Language (UML): UML is a standardized visual language used in OOAD to represent
system models through diagrams. Ian Sommerville (Software Engineering, 10th Edition) describes UML
as "a set of notations for modeling systems as a collection of objects, providing a standard way to
visualize design."
Think of UML like architectural blueprints: it shows the rooms (objects), their layout (relationships), and
how people move through (behavior) in a consistent format.
Example: For a library app, OOAD identifies “Book” and “User” objects, and UML diagrams show their
structure and interactions.

Purpose of UML in OOAD

UML serves several key purposes:
• Visualization: Represents complex systems clearly for stakeholders.
• Specification: Details objects, relationships, and behaviors for design.
• Communication: Bridges technical and non-technical team members.
• Documentation: Provides a reference for implementation and maintenance.
Example: A UML class diagram for a student portal shows “Student” and “Course” classes, helping
developers code them accurately.

Key Features of UML

• Object-Oriented: Focuses on objects, classes, and their interactions.
• Standardized: Defined by the Object Management Group (OMG), ensuring consistency.
• Diagram-Based: Uses graphical notations (e.g., boxes, arrows).
• Versatile: Applies to analysis, design, and beyond.
Tools: Rational Rose, Enterprise Architect, Lucidchart.

Types of UML Diagrams

UML includes two main categories: Structural (static) and Behavioral (dynamic). Here are the most
common diagrams:
1. Structural Diagrams:
o Class Diagram:
▪ Shows classes, attributes, operations, and relationships.
▪ Example: “Book (title, ISBN)” linked to “User (name, ID)” via “borrows.”
o Object Diagram:
▪ Snapshot of objects at a moment (e.g., “Book1:Book” borrowed by “Alice:User”).
o Component Diagram:
▪ High-level components (e.g., “UI,” “Database”).
o Deployment Diagram:
▪ Physical deployment (e.g., “App Server,” “DB Server”).
2. Behavioral Diagrams:
o Use Case Diagram:
▪ Shows system functions (use cases) and actors.
▪ Example: “Student” interacts with “Borrow Book.”
o Sequence Diagram:
▪ Time-ordered interactions (e.g., “Student → UI → Database”).
o State Machine Diagram:
▪ States and transitions (e.g., “Book: Available → Borrowed”).
o Activity Diagram:
▪ Workflows (e.g., “Search → Borrow → Confirm”).
o Collaboration Diagram:
▪ Object interactions with links (e.g., “UI talks to Database”).
Note: Class, use case, and sequence diagrams are foundational for OOAD basics.

How to Use UML in OOAD

1. Analysis Phase (OOA):
o Identify objects and relationships from requirements.
o Use use case diagrams to capture functions and class diagrams for structure.
o Example: “Student registers for Event” (use case) → “Student” and “Event” classes.
2. Design Phase (OOD):
o Refine objects into detailed classes with methods.
 o Use sequence diagrams for behavior and class diagrams for implementation details.
o Example: Sequence for “Register” details “Controller calls Model.”

Example: UML Diagrams for a Library App

1. Use Case Diagram:
text
CollapseWrapCopy
[Student] ----> [Borrow Book]
| |
| [Search Book]
|
[Librarian] ----> [Add Book]
• Actors: Student, Librarian.
• Use Cases: Borrow Book, Search Book, Add Book.
2. Class Diagram:
text
CollapseWrapCopy
+----------------+ +----------------+
| Book | | User |
|----------------|1..* 1 |----------------|
| title: String |<------->| name: String |
| ISBN: String |borrows | ID: String |
| author: String | | borrowBook() |
| getDetails() | +----------------+
+----------------+
• Classes: Book, User.
• Relationship: “User borrows Book” (1-to-many).
3. Sequence Diagram (Borrow Book):
text
CollapseWrapCopy
[Student] [Library UI] [Logic] [Database]
| | | |
|---borrow-->| | |
| |---check-->| |
| | |---fetch-->|
| | |<--data---|
| |<--avail---| |
|<--success--| | |
• Flow: Student initiates borrow, UI checks with Logic, Logic queries Database.

Practical Example for BSIT Students

Imagine modeling a campus event app:
• Use Case Diagram:
text
CollapseWrapCopy
[Student] ----> [View Events]
| |
| [RSVP Event]
• Class Diagram:
text
CollapseWrapCopy
+----------------+ +----------------+
| Event | | Student |
|----------------|1..* 0..*|----------------|
| eventID: Int |<------->| studentID: String |
| title: String |attends | name: String |
| date: Date | | registerEvent()|
+----------------+ +----------------+
• Sequence Diagram (RSVP):
text
CollapseWrapCopy
[Student] [UI] [Controller] [Event Model]
| | | |
|---RSVP-->| | |
| |---reg--->| |
| | |---update-->|
| | |<--success--|
|<--done---| | |
Scenario: Add “Cancel RSVP”—update use case and sequence diagrams.

Benefits of UML in OOAD

• Clarity: Visualizes complex systems (e.g., event app structure).
• Precision: Reduces ambiguity for coding.
• Collaboration: Aligns team and stakeholders.
Example: A game’s UML ensures “Player” and “Weapon” interact as intended.

Real-World Example
• Success: Amazon uses UML to model “Order” and “Customer” interactions for scalable design.
• Failure: The 1990s Denver Airport baggage system lacked clear UML, causing integration issues.

Key Takeaways
• UML is a visual language for OOAD, modeling structure and behavior.
• Key diagrams include class (structure), use case, and sequence (behavior).
• Examples like event apps and Amazon show its role in design.

Topic 28: Object-Oriented Analysis & Design Basics - UML Diagrams

The twenty-eighth topic in the Software Engineering course builds on the introduction to UML by diving
deeper into UML Diagrams within the context of Object-Oriented Analysis and Design (OOAD). This
topic explores the specific UML diagrams used to model a system’s structure and behavior, providing a
comprehensive toolkit for BSIT students. Below, I’ll explain the key UML diagrams in detail, including
their definitions, purposes, components, and examples.

What are UML Diagrams?

UML Diagrams are graphical representations used in OOAD to model a software system’s structure,
behavior, and interactions. They provide a standardized way to visualize objects, classes, and processes,
supporting both analysis (understanding requirements) and design (planning implementation). Ian
Sommerville (Software Engineering, 10th Edition) notes that "UML diagrams offer a range of perspectives
on a system, from high-level requirements to detailed design."
Think of UML diagrams like a multi-view map: each diagram shows a different angle—roads (structure),
traffic flow (behavior), or key stops (use cases)—to guide construction.
Example: For a library app, UML diagrams might include a class diagram (structure), use case diagram
(functions), and sequence diagram (interactions).

Purpose of UML Diagrams in OOAD

• Analysis: Capture requirements (e.g., use cases, initial classes).
• Design: Refine into implementable components (e.g., detailed classes, workflows).
• Communication: Share ideas across team members and stakeholders.
• Documentation: Record the system for future reference.
Example: A student portal’s UML diagrams ensure “View Grades” is modeled from user need to code-
ready design.

Key UML Diagrams

UML offers a variety of diagrams, split into Structural (static) and Behavioral (dynamic) categories. Below
are the most relevant ones for OOAD basics:

Structural Diagrams
These describe the system’s static architecture.
1. Class Diagram:
o Definition: Shows classes, their attributes, operations, and relationships.
o Purpose: Defines the system’s object-oriented structure.
o Components:
▪ Classes: Boxes with name, attributes, operations (e.g., “Book”).
▪ Relationships: Lines for association (e.g., “borrows”), inheritance, aggregation.
▪ Multiplicity: Numbers (e.g., “1..*” for one-to-many).
o Example:
text
CollapseWrapCopy
+----------------+ +----------------+
| Book | | User |
|----------------|1..* 1 |----------------|
| title: String |<------->| name: String |
| ISBN: String |borrows | ID: String |
| getDetails() | | borrowBook() |
+----------------+ +----------------+
• Use: Design database and code classes.
2. Object Diagram:
o Definition: Shows instances of classes at a specific moment.
o Purpose: Illustrates real data scenarios.
o Components: Objects (e.g., “Book1:Book”), links.
o Example:
text
CollapseWrapCopy
[Book1:Book] ----borrows----> [Alice:User]
|title: "CS101" |name: "Alice"
|ISBN: "12345" |ID: "S001"
• Use: Validate class diagram with examples.

Behavioral Diagrams
These describe the system’s dynamic behavior.
3. Use Case Diagram:
o Definition: Shows system functions (use cases) and actors interacting with them.
o Purpose: Captures functional requirements from a user perspective.
o Components:
▪ Actors: Stick figures (e.g., “Student”).
▪ Use Cases: Ovals (e.g., “Borrow Book”).
▪ Associations: Lines connecting actors to use cases.
o Example:
text
CollapseWrapCopy
[Student] ----> [Borrow Book]
| |
| [Search Book]
|
[Librarian] ----> [Add Book]
• Use: Early analysis to define what the system does.
4. Sequence Diagram:
o Definition: Shows time-ordered interactions between objects or actors.
o Purpose: Details how a use case is executed.
o Components:
▪ Lifelines: Vertical dashed lines (e.g., “Student,” “UI”).
▪ Messages: Arrows (e.g., “request book”).
▪ Activation Bars: Thin rectangles (processing time).
o Example:
text
CollapseWrapCopy
[Student] [UI] [Logic] [Database]
 | | | |
|---search->| | |
| |---query->| |
| | |---fetch-->|
| | |<--data---|
| |<--results-| |
|<--display-| | |
• Use: Design interaction flows.
5. State Machine Diagram:
o Definition: Shows states of an object and transitions triggered by events.
o Purpose: Models object behavior over time.
o Components:
▪ States: Rounded rectangles (e.g., “Available”).
▪ Transitions: Arrows with events (e.g., “borrow”).
o Example:
text
CollapseWrapCopy
[Available] ---borrow---> [Borrowed]
^ |
| return
| |
+--------<-------------+
• Use: Define object lifecycles.
6. Activity Diagram:
o Definition: Shows the workflow of a process, including decisions.
o Purpose: Models procedural logic or use case steps.
o Components:
▪ Activities: Rounded rectangles (e.g., “Search Book”).
▪ Transitions: Arrows.
▪ Decision Nodes: Diamonds (e.g., “Available?”).
o Example:
text
CollapseWrapCopy
[Start] → [Search Book] → [Available?] → [Yes: Borrow] → [End]
| No |
+----> [End]
• Use: Plan workflows.

Practical Example for BSIT Students

Imagine modeling a campus event app:
• Use Case Diagram:
text
CollapseWrapCopy
[Student] ----> [View Events]
 | |
| [RSVP Event]
|
[Organizer] ----> [Create Event]
• Class Diagram:
text
CollapseWrapCopy
+----------------+ +----------------+
| Event |1..* 0..*| Student |
|----------------|<------->|----------------|
| eventID: Int |attends | studentID: String |
| title: String | | name: String |
| date: Date | | registerEvent()|
+----------------+ +----------------+
• Sequence Diagram (RSVP):
text
CollapseWrapCopy
[Student] [UI] [Controller] [Event Model]
| | | |
|---RSVP-->| | |
| |---reg--->| |
| | |---update-->|
| | |<--success--|
|<--done---| | |
• State Diagram (Event):
text
CollapseWrapCopy
[Open] ---RSVP---> [Full]
^ |
| cancel
| |
+--------<------+
Scenario: Add “Cancel RSVP”—update use case, sequence, and state diagrams.

Benefits of UML Diagrams

• Comprehensive: Covers structure and behavior.
• Standardized: Ensures team alignment.
• Iterative: Supports refinement from analysis to design.
Example: A game’s UML diagrams ensure “Player” moves and “Score” updates are consistent.

Real-World Example
• Success: Netflix uses UML to model “User,” “Stream,” and interactions for a seamless experience.
• Failure: The 1992 London Ambulance System lacked UML clarity, missing critical flows.
Key Takeaways
• UML diagrams model structure (class) and behavior (use case, sequence, etc.).
• They guide OOAD from requirements to implementation.
• Examples like event apps and Netflix show their utility.

Topic 29: Use Case Modeling

The twenty-ninth topic in the Software Engineering course delves into Use Case Modeling, a key
technique in Object-Oriented Analysis and Design (OOAD) that uses UML to capture and describe a
system’s functional requirements from a user’s perspective. Below, I’ll explain use case modeling in
detail, including its definition, purpose, components, process, and examples tailored for BSIT students.

What is Use Case Modeling?

Use case modeling is the process of identifying, describing, and visualizing the interactions between a
software system and its users (or other systems) to define what the system should do. It uses UML use
case diagrams and textual descriptions to specify system functionality. Ian Sommerville (Software
Engineering, 10th Edition) describes use cases as "a way to represent the functional requirements of a
system by showing how actors interact with it to achieve specific goals."
Think of it like a restaurant menu: it lists what you (the user) can order (functions) and who serves it (the
system), without detailing how the kitchen cooks (implementation).
Example: For a library app, use case modeling might define “Borrow Book” as an interaction between a
“Student” (user) and the system.

Purpose of Use Case Modeling

Use case modeling serves several key purposes:
• Capture Functional Requirements: Specifies what the system must do (e.g., “search books”).
• Focus on Users: Emphasizes user goals and interactions.
• Guide Analysis: Provides a starting point for identifying objects and behaviors.
• Support Communication: Bridges stakeholders and developers with a clear, high-level view.
Example: A student portal’s “View Grades” use case ensures the system meets a core student need.

Components of Use Case Modeling

Use case modeling involves two main parts: diagrams and descriptions.
1. Use Case Diagram:
o Actors: External entities (e.g., people, systems) interacting with the system, shown as
stick figures.
▪ Example: “Student,” “Librarian.”
o Use Cases: System functions or services, shown as ovals.
▪ Example: “Borrow Book,” “Return Book.”
o Associations: Lines connecting actors to use cases they perform.
▪ Example: “Student → Borrow Book.”
o Relationships:
▪ Include: One use case requires another (e.g., “Borrow Book includes Check
Availability”).
▪ Extend: Optional extension (e.g., “Notify Overdue extends Return Book”).
 ▪ Generalization: Actor/use case inheritance (e.g., “Staff” inherits from “User”).
2. Use Case Description:
o Textual details for each use case, typically in a template:
▪ Name: e.g., “Borrow Book.”
▪ Actors: e.g., “Student.”
▪ Preconditions: What must be true before (e.g., “User is logged in”).
▪ Basic Flow: Normal steps (e.g., “1. Enter book ID, 2. System checks, 3. Loan
recorded”).
▪ Alternative Flows: Exceptions (e.g., “Book unavailable”).
▪ Postconditions: Outcome (e.g., “Book is marked borrowed”).

How to Create a Use Case Model

The process involves these steps:
1. Identify Actors:
o List users or systems interacting with the app (e.g., “Student,” “Database”).
2. Define Use Cases:
o List key functions from requirements (e.g., “Register for Event”).
3. Map Associations:
o Connect actors to use cases (e.g., “Student performs Register”).
4. Specify Relationships:
o Add include/extend if needed (e.g., “Register includes Login”).
5. Draw the Diagram:
o Use UML tools (e.g., Lucidchart) to create the visual.
6. Write Descriptions:
o Detail each use case in text.
7. Validate:
o Review with stakeholders (e.g., ensure “View Grades” covers needs).

Example: Use Case Diagram for a Library App

text
CollapseWrapCopy
[Student] ----> [Borrow Book]
| |
| [Search Book]
| |
| [Return Book]
|
[Librarian] ----> [Add Book]
• Actors: Student, Librarian.
• Use Cases: Borrow Book, Search Book, Return Book, Add Book.
With Relationships:
text
CollapseWrapCopy
[Student] ----> [Borrow Book] ----include----> [Check Availability]
 | |
| [Search Book]
• Include: “Borrow Book” requires “Check Availability.”

Example: Use Case Description

Name: Borrow Book
Actor: Student
Preconditions: Student is logged in, book exists in system.
Basic Flow:
1. Student enters book ID.
2. System checks availability.
3. System records loan.
4. System confirms success.
Alternative Flow:
• 2a. If book is unavailable, system displays “Not Available.”
Postconditions: Book is marked as borrowed, loan record is created.

Practical Example for BSIT Students

Imagine modeling use cases for a campus event app:
• Step 1: Actors: “Student,” “Organizer.”
• Step 2: Use Cases: “View Events,” “RSVP Event,” “Create Event.”
• Step 3: Diagram:
text
CollapseWrapCopy
[Student] ----> [View Events]
| |
| [RSVP Event] ----include----> [Login]
|
[Organizer] ----> [Create Event]
• Step 4: Description (RSVP Event):
o Name: RSVP Event
o Actor: Student
o Preconditions: Student is logged in, event is open.
o Basic Flow:
1. Student selects event.
2. System checks capacity.
3. System registers student.
4. System sends confirmation.
o Alternative Flow:
▪ 2a. If event is full, system offers waitlist.
o Postconditions: Student is registered for event.
Scenario: Add “Cancel RSVP”—new use case linked to “Student.”

Benefits of Use Case Modeling

 • User-Focused: Ensures system meets user goals.
• Clarity: Simplifies requirements into actionable functions.
• Foundation: Feeds into class and sequence diagrams.
Example: A game’s “Play Level” use case ensures “move” and “shoot” are covered.

Real-World Example
• Success: Amazon’s “Place Order” use case drives a clear checkout process.
• Failure: The 2013 Healthcare.gov lacked use case clarity, leading to usability issues.

Key Takeaways
• Use case modeling captures system functions via diagrams and descriptions.
• It links actors to use cases, detailing interactions.
• Examples like event apps and Amazon show its analysis role.

Topic 30: Class-Based Modeling

The thirtieth topic in the Software Engineering course continues the exploration of Object-Oriented
Analysis and Design (OOAD) with Class-Based Modeling. This topic focuses on identifying and defining
classes—the blueprints for objects—in a software system, using UML class diagrams to represent their
structure and relationships. Below, I’ll explain class-based modeling in detail, including its definition,
purpose, components, process, and examples tailored for BSIT students.

What is Class-Based Modeling?

Class-based modeling is the process of identifying and specifying the classes in a software system,
including their attributes (data), operations (behaviors), and relationships with other classes. It’s a core
technique in OOAD, transforming requirements and use cases into a structured, object-oriented
representation. Ian Sommerville (Software Engineering, 10th Edition) describes it as "the process of
identifying the objects in a system and organizing them into classes that can be used as the basis for
design and implementation."
Think of it like designing Lego pieces: each piece (class) has specific features (attributes) and functions
(operations), and they connect (relationships) to build a complete model (system).
Example: For a library app, class-based modeling might define “Book” (with “title,” “getDetails()”) and
“User” (with “name,” “borrowBook()”), linked by a “borrows” relationship.

Purpose of Class-Based Modeling

Class-based modeling serves several key purposes:
• Structure Requirements: Translates use cases into objects and classes.
• Define System Entities: Identifies the building blocks of the system.
• Support Design: Provides a foundation for coding and database schemas.
• Enable Reusability: Classes can be reused across projects or modules.
Example: A student portal’s “Student” and “Course” classes ensure “enroll” functionality is structured for
implementation.

Components of Class-Based Modeling

Class-based modeling uses UML class diagrams with these elements:
 1. Classes:
o Represent entities or concepts, shown as boxes with three sections:
▪ Name: Top section (e.g., “Book”).
▪ Attributes: Middle section (e.g., “title: String”).
▪ Operations: Bottom section (e.g., “getDetails(): String”).
o Example: “User” with “name: String” and “borrowBook().”
2. Attributes:
o Properties or data of a class, with types (e.g., “ISBN: String”).
o Visibility: Public (+), Private (-), Protected (#).
3. Operations:
o Behaviors or methods, with parameters and return types (e.g., “borrowBook(bookID:
String): Boolean”).
o Define what the class can do.
4. Relationships:
o Association: General connection (e.g., “User borrows Book”), shown as a line.
▪ Multiplicity: Numbers (e.g., “1..*” means one-to-many).
o Aggregation: “Whole-part” relationship (e.g., “Library contains Books”), shown with a
hollow diamond.
o Composition: Stronger aggregation (e.g., “Order contains OrderItems”), shown with a
filled diamond.
o Inheritance: “Is-a” relationship (e.g., “Student is a User”), shown with a hollow arrow.
o Dependency: Temporary use (e.g., “UI depends on Logic”), shown with a dashed arrow.

How to Create a Class-Based Model

The process involves these steps:
1. Analyze Requirements and Use Cases:
o Extract nouns (entities) and verbs (actions) (e.g., “Student registers for Event” →
“Student,” “Event”).
2. Identify Classes:
o Define key entities (e.g., “Student,” “Event”).
3. Specify Attributes:
o Add properties (e.g., “Student: name, ID”).
4. Define Operations:
o Add behaviors (e.g., “Student: registerEvent()”).
5. Establish Relationships:
o Link classes (e.g., “Student attends Event”).
6. Draw the UML Class Diagram:
o Use tools like Rational Rose or Lucidchart.
7. Validate:
o Ensure it supports use cases (e.g., “Borrow Book” works).

Example: Class Diagram for a Library App

text
CollapseWrapCopy
+----------------+ +----------------+ +----------------+
| Book | | User | | Loan |
|----------------|1..* 1 |----------------|1 0..*|---------------|
| -title: String |<------->| -name: String |<--------->| -loanID: Int |
| -ISBN: String |borrows | -ID: String | | -loanDate: Date|
| -author: String| | +borrowBook() | | -dueDate: Date |
| +getDetails() | +----------------+ +---------------+
+----------------+
• Classes: Book, User, Loan.
• Attributes: Private data (e.g., “-title”).
• Operations: Public methods (e.g., “+borrowBook()”).
• Relationships:
o “User borrows Book” (1-to-many).
o “Loan links User and Book” (1 User to many Loans, 1 Loan to 1 Book).

Practical Example for BSIT Students

Imagine modeling classes for a campus event app:
• Step 1: Use Case: “Student registers for Event.”
• Step 2: Classes: “Student,” “Event,” “Registration.”
• Step 3: Attributes and Operations:
o Student: “-studentID: String, -name: String, +registerEvent()”
o Event: “-eventID: Int, -title: String, -date: Date, +getDetails()”
o Registration: “-regID: Int, -eventID: Int, -studentID: String, -regDate: Date”
• Step 4: Relationships: “Student attends Event” (many-to-many via Registration).
• Class Diagram:
text
CollapseWrapCopy
+----------------+ +----------------+ +----------------+
| Event | | Student | | Registration |
|----------------|1..* 0..*|---------------|1 0..*|---------------|
| -eventID: Int |<------->| -studentID: String |<----->| -regID: Int |
| -title: String |attends | -name: String | | -eventID: Int |
| -date: Date | | +registerEvent()| | -studentID: String |
| +getDetails() | +----------------+ | -regDate: Date |
+----------------+ +----------------+
Scenario: Add “Organizer” class with “createEvent()”—link it to “Event” with “creates” relationship.

Benefits of Class-Based Modeling

• Clarity: Defines system structure in an object-oriented way.
• Reusability: Classes like “User” can be reused.
• Foundation: Leads to code and database design.
Example: A game’s “Player” and “Weapon” classes ensure “shoot” is well-structured.

Real-World Example
 • Success: Google Maps’ “Location” and “Route” classes support scalable navigation.
• Failure: The 2000s FBI Virtual Case File lacked clear class models, causing integration issues.

Key Takeaways
• Class-based modeling defines classes, attributes, operations, and relationships.
• It uses UML class diagrams to structure a system.
• Examples like event apps and Maps show its design role.

Topic 31: Object-Oriented Design Concepts

The thirty-first topic in the Software Engineering course continues the exploration of Object-Oriented
Analysis and Design (OOAD) with Object-Oriented Design Concepts. This topic introduces the
foundational principles and techniques that underpin object-oriented design (OOD), enabling the
creation of robust, reusable, and maintainable software systems. Below, I’ll explain these concepts in
detail, including their definitions, significance, and examples tailored for BSIT students.

What are Object-Oriented Design Concepts?

Object-Oriented Design Concepts are the core principles and practices that guide the design of software
systems using an object-oriented approach. They focus on how objects (instances of classes) interact,
encapsulate data, and provide functionality. Ian Sommerville (Software Engineering, 10th Edition)
emphasizes that "object-oriented design is based on the idea of creating systems as collections of
interacting objects, leveraging concepts like encapsulation and inheritance."
Think of it like designing a team of robots: each robot (object) has specific tasks (methods), internal parts
(data), and rules for working with others (relationships)—all built on key principles.
Example: In a library app, “Book” and “User” objects follow OOD concepts to manage borrowing
efficiently.

Purpose of Object-Oriented Design Concepts

These concepts serve several key purposes:
• Structure Systems: Organize software into modular, object-based units.
• Improve Quality: Enhance reusability, flexibility, and maintainability.
• Support Implementation: Provide a framework for coding and testing.
• Align with Reality: Model real-world entities naturally (e.g., “Student” as an object).
Example: A student portal uses OOD to ensure “Grade” objects are encapsulated and reusable across
features.

Key Object-Oriented Design Concepts

Below are the foundational concepts of OOD:
1. Objects and Classes:
o Definition: Objects are instances of classes; classes are blueprints defining attributes
(data) and operations (behaviors).
o Significance: The basic units of OOD, representing real-world entities.
o Example: Class “Book” (title, ISBN) → Object “Book1” (title: “CS101”, ISBN: “12345”).
2. Encapsulation:
 o Definition: Bundling data (attributes) and methods (operations) within a class, hiding
internal details and exposing only necessary interfaces.
o Significance: Protects data integrity and reduces complexity.
o Example: “User” class hides “password” and provides “login(password)” method.
o Implementation: Use private attributes (e.g., “-name”) and public methods (e.g.,
“+getName()”).
3. Inheritance:
o Definition: A class (subclass) inherits attributes and operations from another class
(superclass), promoting reuse.
o Significance: Avoids redundancy and supports hierarchical design.
o Example: “Student” inherits from “User,” adding “studentID” while reusing “name” and
“login().”
o UML: Hollow arrow from subclass to superclass.
4. Polymorphism:
o Definition: The ability of different classes to be treated as instances of a common
superclass, with methods behaving differently based on the object type.
o Significance: Increases flexibility and extensibility.
o Example: “User.printDetails()” outputs “name” for “User,” but “name + studentID” for
“Student.”
o Types: Method overriding (redefine in subclass), method overloading (same name,
different parameters).
5. Abstraction:
o Definition: Simplifying complex systems by modeling only essential features, hiding
unnecessary details.
o Significance: Reduces complexity, focuses on “what” not “how.”
o Example: “Vehicle” abstract class with “move()” method, implemented differently by
“Car” and “Bike.”
o Implementation: Abstract classes or interfaces.
6. Association:
o Definition: A relationship between classes where objects interact (e.g., “uses,” “owns”).
o Significance: Defines how objects collaborate.
o Example: “User borrows Book” (simple association).
o Subtypes:
▪ Aggregation: “Whole-part” (e.g., “Library contains Books”), weaker link.
▪ Composition: Stronger ownership (e.g., “Order contains OrderItems”), part dies
with whole.
7. Cohesion and Coupling:
o Cohesion: Degree to which a class’s elements work toward a single purpose.
▪ Goal: High cohesion (e.g., “Book” only handles book data).
o Coupling: Degree of dependency between classes.
▪ Goal: Low coupling (e.g., “UI” uses “Logic” via interface, not direct access).
o Significance: High cohesion and low coupling improve modularity and maintainability.

How to Apply OOD Concepts

 1. Identify Classes: From use cases (e.g., “Student registers” → “Student,” “Event”).
2. Encapsulate: Define private attributes, public methods (e.g., “-name,” “+getName()”).
3. Use Inheritance: Extend where appropriate (e.g., “Student” from “User”).
4. Leverage Polymorphism: Design flexible behaviors (e.g., “printDetails()” varies).
5. Abstract Complexity: Use interfaces/abstract classes (e.g., “Borrowable”).
6. Model Relationships: Define associations (e.g., “Student attends Event”).
7. Optimize: Ensure high cohesion, low coupling.

Example: OOD Concepts in a Library App

Class Diagram:
text
CollapseWrapCopy
+----------------+ +----------------+
| User | | Book |
|----------------|1 *|----------------|
| -name: String |<------->| -title: String |
| -ID: String |borrows | -ISBN: String |
| +login() | | +getDetails() |
| +printDetails()| +----------------+
+----------------+
^
|
+----------------+
| Student |
|----------------|
| -studentID: String |
| +printDetails()|
+----------------+
• Objects/Classes: “User,” “Book,” “Student.”
• Encapsulation: “-name” is private, accessed via “+login().”
• Inheritance: “Student” inherits from “User.”
• Polymorphism: “printDetails()” overridden in “Student” to include “studentID.”
• Association: “User borrows Book” (1-to-many).
• Cohesion: “Book” focuses on book data; Coupling: Low via method calls.

Practical Example for BSIT Students

Imagine designing a campus event app:
• Classes:
o “Event” (-eventID: Int, -title: String, +getDetails())
o “Person” (-name: String, +register())
o “Student” (-studentID: String, +register()) inherits from “Person”
• Diagram:
text
CollapseWrapCopy
+----------------+ +----------------+
| Event |1..* 0..*| Person |
|----------------|<------->|---------------|
| -eventID: Int |attends | -name: String |
| -title: String | | +register() |
| +getDetails() | +----------------+
+----------------+ ^
|
+----------------+
| Student |
|---------------|
| -studentID: String |
| +register() |
+----------------+
• Encapsulation: “-title” hidden, accessed via “+getDetails().”
• Inheritance/Polymorphism: “Student” customizes “register().”
• Association: “Student attends Event.”
Scenario: Add “Organizer” inheriting from “Person” with “createEvent()”—extends the hierarchy.

Benefits of OOD Concepts

• Modularity: Easy to update (e.g., change “Book” without affecting “User”).
• Reusability: “User” class reusable in other apps.
• Flexibility: Polymorphism adapts to new types (e.g., “Teacher”).
Example: A game’s “Character” class reused across levels with varying behaviors.

Real-World Example
• Success: Java’s “InputStream” hierarchy uses inheritance and polymorphism for flexible I/O.
• Failure: Early monolithic systems lacked OOD, making updates hard.

Key Takeaways
• OOD concepts (encapsulation, inheritance, etc.) structure object-oriented systems.
• They enhance design quality and implementation.
• Examples like event apps and Java show their power.

Topic 32: Pattern-Based Design

The thirty-second topic in the Software Engineering course continues the exploration of Object-Oriented
Analysis and Design (OOAD) with Pattern-Based Design. This topic introduces the concept of design
patterns—reusable solutions to common software design problems—enhancing the efficiency and
quality of object-oriented design. Below, I’ll explain pattern-based design in detail, including its
definition, purpose, types of patterns, application process, and examples tailored for BSIT students.

What is Pattern-Based Design?

Pattern-based design is an approach to software design that applies design patterns, which are proven,
reusable templates for solving recurring problems in a specific context. These patterns leverage object-
oriented principles (e.g., encapsulation, inheritance) to provide standardized solutions. Ian Sommerville
(Software Engineering, 10th Edition) describes design patterns as "generalized descriptions of good
design practices that can be adapted and applied to solve particular problems in software design."
Think of it like using a cookbook: instead of inventing a recipe from scratch, you adapt a tried-and-true
one (e.g., “cake pattern”) to bake your dessert (software solution).
Example: In a library app, the Singleton pattern ensures only one “LibraryCatalog” instance exists,
managing all book data consistently.

Purpose of Pattern-Based Design

Pattern-based design serves several key purposes:
• Solve Common Problems: Provides tested solutions (e.g., managing object creation).
• Improve Reusability: Standardizes components across projects.
• Enhance Maintainability: Uses well-understood structures.
• Reduce Design Time: Leverages existing knowledge instead of reinventing solutions.
Example: A student portal uses the Observer pattern to notify students of grade updates, avoiding
custom notification logic.

Key Characteristics of Design Patterns

Each pattern has:
• Name: Identifies it (e.g., “Factory”).
• Problem: Describes when to use it (e.g., “complex object creation”).
• Solution: Provides a general design (e.g., “use a factory class”).
• Consequences: Lists pros/cons (e.g., “flexible but adds complexity”).
Source: Popularized by the “Gang of Four” (GoF) book, Design Patterns: Elements of Reusable Object-
Oriented Software (1994).

Types of Design Patterns

The GoF categorizes patterns into three types:
1. Creational Patterns:
o Focus on object creation mechanisms.
o Examples:
▪ Singleton: Ensures one instance (e.g., one “DatabaseConnection”).
▪ Factory Method: Creates objects via a method (e.g., “createUser()” for different
user types).
▪ Abstract Factory: Groups related object creation (e.g., “UI factory” for
web/mobile).
2. Structural Patterns:
o Address class/object composition and relationships.
o Examples:
▪ Adapter: Converts one interface to another (e.g., adapt legacy “Payment” to
new system).
▪ Composite: Treats objects and groups uniformly (e.g., “Menu” with sub-menus).
 ▪ Decorator: Adds behavior dynamically (e.g., add “PremiumFeatures” to “User”).
3. Behavioral Patterns:
o Manage object collaboration and responsibilities.
o Examples:
▪ Observer: Notifies dependents of changes (e.g., “Grade update notifies
Student”).
▪ Strategy: Swaps algorithms (e.g., “Sort” by date or name).
▪ Command: Encapsulates requests as objects (e.g., “Undo” borrow action).

How to Apply Pattern-Based Design

The process involves these steps:
1. Identify the Problem:
o Analyze design needs (e.g., “need unique catalog instance”).
2. Select a Pattern:
o Match to a known pattern (e.g., Singleton).
3. Adapt the Pattern:
o Customize to the system (e.g., “LibraryCatalog” as Singleton).
4. Implement:
o Code the solution using OOD principles.
5. Validate:
o Ensure it meets requirements and integrates well.
6. Document:
o Note the pattern used (e.g., “Singleton for catalog”).

Example: Singleton Pattern in a Library App

Problem: Ensure one catalog instance manages all books. Solution:
java
CollapseWrapCopy
public class LibraryCatalog {
private static LibraryCatalog instance = null;
private List<Book> books;

private LibraryCatalog() { // Private constructor

books = new ArrayList<>();
}

public static LibraryCatalog getInstance() {

if (instance == null) {
instance = new LibraryCatalog();
}
return instance;
}

public void addBook(Book book) {

 books.add(book);
}
}
• Use: LibraryCatalog catalog = LibraryCatalog.getInstance();
• Consequence: Ensures consistency, but limits flexibility (e.g., no multiple catalogs).

Practical Example for BSIT Students

Imagine designing a campus event app:
• Problem: Notify students when an event’s status changes (e.g., “canceled”).
• Pattern: Observer
• Design:
o Subject: “Event” class with “addObserver(),” “notifyObservers().”
o Observer: “Student” class with “update()” method.
• Class Diagram:
text
CollapseWrapCopy
+----------------+ +----------------+
| Event |1 *| Student |
|----------------|<------->|---------------|
| -eventID: Int |observes | -studentID: String |
| -status: String| | -name: String |
| +addObserver() | | +update(status)|
| +notifyObservers() +----------------+
+----------------+
• Code Snippet:
java
CollapseWrapCopy
class Event {
private List<Student> observers = new ArrayList<>();
private String status;

public void addObserver(Student s) { observers.add(s); }

public void setStatus(String status) {
this.status = status;
notifyObservers();
}
public void notifyObservers() {
for (Student s : observers) s.update(status);
}
}

class Student {
private String name;
public void update(String status) {
 System.out.println(name + " notified: Event is " + status);
}
}
• Use: Event changes to “canceled,” all students get notified.
• Consequence: Flexible notifications, but adds overhead.

Benefits of Pattern-Based Design

• Efficiency: Reuses proven solutions (e.g., Observer for updates).
• Quality: Patterns are robust and tested.
• Consistency: Standardizes design across teams.
Example: A game’s “EnemyFactory” ensures consistent enemy creation.

Real-World Example
• Success: Java’s “Iterator” pattern (Behavioral) simplifies list traversal.
• Failure: Early ad-hoc designs (e.g., 1990s baggage systems) lacked patterns, causing chaos.

Key Takeaways
• Pattern-based design applies reusable solutions to design problems.
• It includes creational, structural, and behavioral patterns.
• Examples like event apps and Java show its practical value.

Topic 33: Software Implementation Basics

The thirty-third topic in the Software Engineering course transitions from design to Software
Implementation Basics. This topic focuses on the process of translating the design (e.g., architectural,
component-level, and UI designs) into executable code, marking the shift from planning to building the
software system. Below, I’ll explain software implementation in detail, including its definition, purpose,
principles, process, and examples tailored for BSIT students.

What is Software Implementation?

Software implementation is the phase of the software development lifecycle where developers write,
test, and refine code to realize the system’s design. It involves converting models, diagrams, and
specifications into a working program. Ian Sommerville (Software Engineering, 10th Edition) describes
implementation as "the process of realizing the design as a program, typically by writing code in a
programming language and integrating it with existing systems or libraries."
Think of it like constructing a house: the blueprints (design) are turned into walls, floors, and a roof
(code) using tools and materials (languages and frameworks).
Example: For a library app, implementation turns a “Borrow Book” component design into Python code
that checks availability and updates a database.

Purpose of Software Implementation

Implementation serves several key purposes:
• Realize the Design: Transforms abstract plans into a functional system.
• Meet Requirements: Ensures the code delivers specified functionality (e.g., “search books”).
• Enable Testing: Produces a tangible product to verify and validate.
 • Support Deployment: Prepares the system for real-world use.
Example: A student portal’s “View Grades” feature is coded to display data as per the UI design.

Principles of Software Implementation

Effective implementation follows these principles:
1. Fidelity to Design: Code should match the architectural and component-level designs.
2. Readability: Write clear, well-commented code for maintainability.
3. Modularity: Break code into reusable, independent units (e.g., functions, classes).
4. Efficiency: Optimize performance within constraints (e.g., fast queries).
5. Error Handling: Anticipate and manage failures (e.g., “book unavailable”).
Example: A game’s “MovePlayer” function is modular, readable, and handles “out-of-bounds” errors.

Key Elements of Implementation

• Programming Languages: Chosen based on needs (e.g., Python for simplicity, Java for
robustness).
• Libraries/Frameworks: Reuse existing code (e.g., Flask for web apps).
• Coding Standards: Naming conventions, indentation (e.g., PEP 8 for Python).
• Version Control: Track changes (e.g., Git).
• Testing: Write unit tests alongside code (e.g., “testBorrowBook()”).
Example: A library app uses Python, SQLite, and Git, with tests for “Borrow Book.”

How to Implement Software

The process involves these steps:
1. Set Up Environment:
o Choose tools (e.g., IDE like VS Code, database like MySQL).
2. Translate Design to Code:
o Map classes, methods, and UI to code (e.g., “Book” class from UML).
3. Write Code:
o Implement functions/classes, following design specs.
4. Integrate Components:
o Connect modules (e.g., UI calls Logic).
5. Test Incrementally:
o Run unit tests (e.g., “does borrowBook() work?”).
6. Debug and Refine:
o Fix errors, optimize (e.g., reduce query time).
7. Document:
o Add comments, update README (e.g., “How to run the app”).

Example: Implementing “Borrow Book” for a Library App

Design (Component-Level):
• Interface: borrowBook(bookID: String, userID: String): Boolean
• Logic: Check availability, update loan status.
Implementation (Python):
python
CollapseWrapCopy
class Book:
def __init__(self, isbn, title, available=True):
self.isbn = isbn
self.title = title
self.available = available

class Library:
def __init__(self):
self.books = {} # Dictionary to store books
self.loans = [] # List to store loans

def borrowBook(self, bookID, userID):

if bookID in self.books:
book = self.books[bookID]
if book.available:
book.available = False
self.loans.append({"bookID": bookID, "userID": userID, "date": "2025-03-06"})
return True
else:
print("Book is not available")
return False
else:
print("Book not found")
return False

# Test
library = Library()
library.books["12345"] = Book("12345", "CS101")
result = library.borrowBook("12345", "S001")
print("Borrow successful:", result) # True
• Fidelity: Matches design (checks availability, updates status).
• Modularity: Separate “Book” and “Library” classes.
• Error Handling: Handles unavailable or missing books.

Practical Example for BSIT Students

Imagine implementing a campus event app’s “RSVP Event” feature:
• Design (Class Diagram):
o “Event” (-eventID, -title, -capacity, +register())
o “Student” (-studentID, -name)
• Implementation (Python):
python
CollapseWrapCopy
class Event:
 def __init__(self, eventID, title, capacity):
self.eventID = eventID
self.title = title
self.capacity = capacity
self.registrations = []

def register(self, studentID):

if len(self.registrations) < self.capacity:
self.registrations.append(studentID)
return True
else:
print("Event is full")
return False

class Student:
def __init__(self, studentID, name):
self.studentID = studentID
self.name = name

# Test
event = Event(1, "Hackathon", 50)
student = Student("S001", "Alice")
result = event.register("S001")
print("RSVP successful:", result) # True
• Setup: Python with simple list-based storage.
• Code: Implements “register()” with capacity check.
• Test: Verifies RSVP works.
Scenario: Add database integration (e.g., SQLite) later—refine to saveRegistration().

Benefits of Software Implementation

• Tangibility: Turns ideas into a working product.
• Verification: Allows testing against requirements.
• Iteration: Enables refinement based on feedback.
Example: A game’s “Shoot” function is coded, tested, and tweaked for accuracy.

Real-World Example
• Success: Google Maps implements “Route Calculation” with modular, tested code.
• Failure: The 1992 London Ambulance System had rushed implementation, missing key
integrations.

Key Takeaways
• Software implementation turns design into executable code.
• It follows principles like modularity and fidelity to design.
• Examples like event apps and Maps show its execution role.
Topic 34: Software Testing Basics
The thirty-fourth topic in the Software Engineering course moves into Software Testing Basics, a critical
phase that ensures the implemented software meets its requirements and functions correctly. This topic
introduces the fundamental concepts, techniques, and processes of testing software systems. Below, I’ll
explain software testing in detail, including its definition, purpose, principles, types, process, and
examples tailored for BSIT students.

What is Software Testing?

Software testing is the process of evaluating a software system or its components to verify that it meets
specified requirements and to identify defects or errors. It involves executing the software with test
cases to check its behavior against expected outcomes. Ian Sommerville (Software Engineering, 10th
Edition) defines testing as "the process of executing a program with the intent of finding errors and
ensuring that it behaves as expected."
Think of it like quality control in a factory: you test each product (software) to ensure it works (meets
specs) and doesn’t break (has no defects) before shipping.
Example: For a library app, testing checks if “Borrow Book” correctly updates the book’s status and
handles “unavailable” cases.

Purpose of Software Testing

Software testing serves several key purposes:
• Verify Functionality: Ensures the system does what it’s supposed to (e.g., “search books” works).
• Validate Quality: Confirms it meets non-functional needs (e.g., fast, reliable).
• Detect Defects: Finds bugs or errors (e.g., crash on invalid input).
• Reduce Risk: Prevents failures in production (e.g., lost data).
Example: A student portal’s “Calculate GPA” is tested to ensure accurate results and no crashes.

Principles of Software Testing

Effective testing follows these principles:
1. Testing Shows Presence of Defects: It can prove bugs exist, not that they don’t.
2. Exhaustive Testing is Impossible: Test selectively based on risk and priority.
3. Early Testing: Start during requirements/design to catch issues sooner.
4. Defect Clustering: Bugs often group in certain areas (e.g., complex code).
5. Pesticide Paradox: Repeating tests loses effectiveness—update test cases.
6. Testing is Context-Dependent: Varies by system type (e.g., game vs. banking).
7. Absence-of-Errors Fallacy: Bug-free doesn’t mean useful if requirements are wrong.
Example: A game’s “MovePlayer” test focuses on edge cases (e.g., wall collisions) where bugs cluster.

Types of Software Testing

Testing is categorized by level, approach, and purpose:
1. Levels of Testing:
o Unit Testing: Tests individual components (e.g., “borrowBook()” function).
o Integration Testing: Tests interactions between components (e.g., UI → Logic).
o System Testing: Tests the entire system (e.g., library app end-to-end).
 o Acceptance Testing: Validates against user needs (e.g., “Does it meet student
expectations?”).
2. Approaches:
o Black-Box Testing: Tests functionality without knowing internals (e.g., input book ID,
check output).
o White-Box Testing: Tests internal logic (e.g., check if “if” condition works).
o Gray-Box Testing: Combines both (e.g., test UI with some code knowledge).
3. Purposes:
o Functional Testing: Verifies features (e.g., “RSVP Event” works).
o Non-Functional Testing: Checks performance, security (e.g., “handles 1,000 users”).
o Regression Testing: Ensures new changes don’t break old functionality.

How to Perform Software Testing

The process involves these steps:
1. Plan Testing:
o Define objectives, scope, and resources (e.g., “test Borrow Book”).
2. Design Test Cases:
o Specify inputs, expected outputs, and conditions (e.g., “bookID: 123, expect: True”).
3. Set Up Environment:
o Prepare tools, data (e.g., Python, test database).
4. Execute Tests:
o Run the software with test cases (manual or automated).
5. Analyze Results:
o Compare actual vs. expected outcomes (e.g., “Did it crash?”).
6. Report Defects:
o Log bugs (e.g., “Book not marked borrowed”).
7. Retest:
o Verify fixes and rerun tests.

Example: Testing “Borrow Book” in a Library App

Code (from Topic 33):
python
CollapseWrapCopy
class Library:
def borrowBook(self, bookID, userID):
if bookID in self.books:
book = self.books[bookID]
if book.available:
book.available = False
self.loans.append({"bookID": bookID, "userID": userID})
return True
return False
return False
Test Cases:
 1. TC1: Valid Borrow
o Input: bookID=“12345” (available), userID=“S001”
o Expected: True, book.available=False
2. TC2: Unavailable Book
o Input: bookID=“12345” (borrowed), userID=“S002”
o Expected: False
3. TC3: Invalid Book
o Input: bookID=“99999” (not in system), userID=“S001”
o Expected: False
Unit Test (Python with unittest):
python
CollapseWrapCopy
import unittest
from library import Library, Book

class TestLibrary(unittest.TestCase):
def setUp(self):
self.lib = Library()
self.lib.books["12345"] = Book("12345", "CS101")

def test_valid_borrow(self):
result = self.lib.borrowBook("12345", "S001")
self.assertTrue(result)
self.assertFalse(self.lib.books["12345"].available)

def test_unavailable_borrow(self):
self.lib.borrowBook("12345", "S001") # Borrow first
result = self.lib.borrowBook("12345", "S002")
self.assertFalse(result)

def test_invalid_book(self):
result = self.lib.borrowBook("99999", "S001")
self.assertFalse(result)

if __name__ == "__main__":
unittest.main()
• Result: Tests pass if code behaves as expected.

Practical Example for BSIT Students

Imagine testing a campus event app’s “RSVP Event”:
• Code:
python
CollapseWrapCopy
class Event:
 def register(self, studentID):
if len(self.registrations) < self.capacity:
self.registrations.append(studentID)
return True
return False
• Test Cases:
1. TC1: Successful RSVP
▪ Input: studentID=“S001”, capacity=2, registrations=0
▪ Expected: True
2. TC2: Event Full
▪ Input: studentID=“S003”, capacity=2, registrations=2
▪ Expected: False
• Unit Test:
python
CollapseWrapCopy
import unittest
from event import Event

class TestEvent(unittest.TestCase):
def setUp(self):
self.event = Event(1, "Hackathon", 2)

def test_successful_rsvp(self):
result = self.event.register("S001")
self.assertTrue(result)
self.assertEqual(len(self.event.registrations), 1)

def test_event_full(self):
self.event.register("S001")
self.event.register("S002")
result = self.event.register("S003")
self.assertFalse(result)

if __name__ == "__main__":
unittest.main()
Scenario: Bug found—capacity not checked correctly; fix and retest.

Benefits of Software Testing

• Reliability: Ensures the system works (e.g., no crashes).
• Quality: Meets user expectations (e.g., fast RSVP).
• Cost Savings: Fixes bugs early, not in production.
Example: A game’s “Shoot” test prevents infinite ammo glitches.

Real-World Example
 • Success: Google tests Maps’ routing to ensure accuracy and speed.
• Failure: The 2013 Healthcare.gov skipped thorough testing, causing launch failures.

Key Takeaways
• Software testing verifies functionality and finds defects.
• It includes unit, integration, and system levels.
• Examples like event apps and Maps show its critical role.

Topic 35: Software Testing Strategies

The thirty-fifth topic in the Software Engineering course builds on Software Testing Basics by exploring
Software Testing Strategies. This topic focuses on the systematic approaches and plans used to organize
and execute testing effectively across a software system’s development lifecycle. Below, I’ll explain
testing strategies in detail, including their definition, purpose, types, components, and examples tailored
for BSIT students.

What are Software Testing Strategies?

A software testing strategy is a high-level plan that defines how testing will be conducted to ensure a
software system meets its requirements and quality goals. It outlines the scope, levels, types, and timing
of testing activities, integrating them into the development process. Ian Sommerville (Software
Engineering, 10th Edition) describes a testing strategy as "an approach to testing that defines the testing
stages, the techniques to be used, and how testing fits into the overall development process."
Think of it like a battle plan: you decide when to deploy scouts (unit tests), coordinate squads
(integration tests), and launch a full assault (system tests) to win (deliver a bug-free system).
Example: For a library app, a testing strategy might specify unit testing “Borrow Book,” integration
testing UI-to-database connections, and system testing the entire app flow.

Purpose of Software Testing Strategies

Testing strategies serve several key purposes:
• Organize Testing: Provide a structured approach to cover all aspects of the system.
• Ensure Coverage: Verify all components and requirements are tested.
• Optimize Resources: Balance time, cost, and quality (e.g., prioritize critical features).
• Reduce Risks: Catch defects early and systematically.
Example: A student portal’s strategy ensures “Calculate GPA” is thoroughly tested before release,
avoiding grade errors.

Principles of Testing Strategies

Effective strategies follow these principles:
1. Comprehensive: Test all levels (unit, integration, system).
2. Incremental: Build confidence step-by-step (e.g., units before system).
3. Risk-Based: Focus on high-risk areas (e.g., payment processing).
4. Adaptable: Adjust to project needs (e.g., Agile vs. Waterfall).
5. Traceable: Link tests to requirements (e.g., “View Grades” test tied to spec).
Example: A game’s strategy prioritizes “Player Movement” (critical) over “Settings Menu” (less risky).
Components of a Testing Strategy
A testing strategy typically includes:
• Scope: What to test (e.g., features, performance).
• Levels: Unit, integration, system, acceptance.
• Types: Functional, non-functional (e.g., security, usability).
• Techniques: Black-box, white-box, automated vs. manual.
• Tools: Testing frameworks (e.g., JUnit, Selenium).
• Schedule: When to test (e.g., after coding, during sprints).
• Responsibilities: Who tests (e.g., developers, QA team).
Example: A library app strategy: Test “Borrow Book” (unit), UI-database link (integration), and full app
(system) using Python’s unittest.

Types of Testing Strategies

Testing strategies vary by development process and goals:
1. V-Model (Verification and Validation Model):
o Approach: Sequential, aligns testing with development phases (e.g., requirements →
acceptance test).
o Levels: Unit → Integration → System → Acceptance.
o Example: Waterfall project tests “Search Book” at each stage.
o Pros: Structured, traceable.
o Cons: Rigid, late defect detection.
2. Incremental Testing:
o Approach: Tests components as they’re built, integrating incrementally.
o Example: Test “Event” class, then “Event + RSVP,” then full event app.
o Pros: Early feedback, modular.
o Cons: Requires stubs/mocks.
3. Agile Testing:
o Approach: Continuous testing within sprints, emphasizing automation.
o Example: Test “RSVP Event” in Sprint 1, “Cancel RSVP” in Sprint 2.
o Pros: Flexible, fast feedback.
o Cons: Needs discipline, tool reliance.
4. Risk-Based Testing:
o Approach: Prioritizes testing based on risk (impact, likelihood).
o Example: Focus on “Payment” over “View Profile” in an e-commerce app.
o Pros: Efficient resource use.
o Cons: May miss low-risk bugs.
5. Big Bang Testing:
o Approach: Tests the entire system at once after integration.
o Example: Test library app only after all coding is done.
o Pros: Simple for small systems.
o Cons: Late defect discovery, hard to isolate issues.

How to Develop a Testing Strategy

The process involves these steps:
 1. Analyze Requirements:
o Identify what to test (e.g., “Borrow Book,” “Handle 500 users”).
2. Define Objectives:
o Set goals (e.g., “No critical bugs,” “95% code coverage”).
3. Choose Levels and Types:
o Plan unit, integration, system tests (e.g., functional, performance).
4. Select Techniques and Tools:
o Decide on black-box, automation (e.g., unittest, Selenium).
5. Plan Execution:
o Schedule (e.g., unit tests daily, system tests pre-release).
6. Assign Roles:
o Developers for unit, QA for system tests.
7. Document:
o Write a test plan (e.g., “Test Strategy for Event App”).

Example: Testing Strategy for a Library App

Strategy:
• Scope: Test “Search Book,” “Borrow Book,” “Return Book” features.
• Levels:
o Unit: Test “borrowBook()” function.
o Integration: Test UI-to-database connection.
o System: Test end-to-end borrowing flow.
• Types:
o Functional: Verify borrowing works.
o Performance: Ensure <2s response for 100 users.
• Techniques: Black-box for system, white-box for unit.
• Tools: unittest (Python), JMeter (performance).
• Schedule: Unit tests after coding, integration weekly, system pre-release.
Test Case (Unit):
• Input: bookID=“12345” (available), userID=“S001”
• Expected: True, book marked unavailable

Practical Example for BSIT Students

Imagine a testing strategy for a campus event app:
• Strategy:
o Scope: “View Events,” “RSVP Event,” “Cancel RSVP.”
o Levels:
▪ Unit: Test “register()” in “Event” class.
▪ Integration: Test “Controller → Model” interaction.
▪ System: Test full RSVP flow.
o Types: Functional (RSVP works), Usability (UI intuitive).
o Tools: unittest for unit, manual for usability.
o Schedule: Agile—test each sprint’s features.
• Test Case (Integration):
 o Input: Student clicks “RSVP” on UI.
o Expected: Controller calls “register(),” database updates.
Scenario: Bug in “Cancel RSVP”—adjust strategy to retest after fix.

Benefits of Testing Strategies

• Efficiency: Targets critical areas (e.g., RSVP over minor UI).
• Coverage: Ensures all levels are tested.
• Quality: Delivers a reliable system.
Example: A game’s strategy ensures “Shoot” works across levels.

Real-World Example
• Success: Netflix’s Agile testing catches streaming bugs per sprint.
• Failure: The 1992 London Ambulance System used Big Bang, missing integration flaws.

Key Takeaways
• Testing strategies plan how to test systematically.
• They vary by approach (e.g., V-Model, Agile).
• Examples like event apps and Netflix show their role in quality.

Topic 36: Software Maintenance Basics

The thirty-sixth topic in the Software Engineering course shifts focus to Software Maintenance Basics,
the phase that follows development and testing to ensure a software system remains functional,
relevant, and efficient over time. Below, I’ll explain software maintenance in detail, including its
definition, purpose, types, process, and examples tailored for BSIT students.

What is Software Maintenance?

Software maintenance is the process of modifying and updating a software system after its initial
deployment to correct faults, improve performance, adapt to changes, or add new features. Ian
Sommerville (Software Engineering, 10th Edition) defines it as "the activities involved in modifying
software products after delivery to correct defects, improve attributes, or adapt to a changed
environment."
Think of it like car upkeep: after building and delivering the car (software), you fix breakdowns (bugs),
tune the engine (performance), or add a GPS (new features) to keep it running smoothly.
Example: For a library app, maintenance might involve fixing a “Borrow Book” crash, optimizing search
speed, or adding a “Reserve Book” feature.

Purpose of Software Maintenance

Software maintenance serves several key purposes:
• Fix Defects: Correct bugs found post-release (e.g., “book not marked borrowed”).
• Enhance Functionality: Add new features based on user feedback (e.g., “event reminders”).
• Adapt to Changes: Update for new environments (e.g., OS upgrades).
• Improve Quality: Optimize performance or usability (e.g., faster load times).
• Extend Lifespan: Keep the software relevant and usable.
Example: A student portal is maintained to fix GPA calculation errors and add “export to PDF”
functionality.

Principles of Software Maintenance

Effective maintenance follows these principles:
1. Preserve Integrity: Changes shouldn’t break existing functionality.
2. Minimize Disruption: Updates should be seamless for users.
3. Document Changes: Track modifications for future reference.
4. Test Thoroughly: Verify fixes and enhancements work as intended.
5. Plan Ahead: Anticipate future needs (e.g., scalability).
Example: A game’s “Shoot” fix is tested to ensure “Move” still works, with changes logged in Git.

Types of Software Maintenance

Maintenance is categorized into four types (based on Lehman’s classification):
1. Corrective Maintenance:
o Fixes defects or bugs reported by users.
o Example: Patch a crash when “RSVP Event” fails for invalid input.
o Effort: ~20% of maintenance (varies by system).
2. Adaptive Maintenance:
o Updates software for new environments (e.g., OS, hardware).
o Example: Modify a library app for a new Android version.
o Effort: ~20-25% of maintenance.
3. Perfective Maintenance:
o Enhances performance or adds features based on user needs.
o Example: Add “Cancel RSVP” to an event app.
o Effort: ~50% of maintenance (most common).
4. Preventive Maintenance:
o Proactively improves reliability or maintainability (e.g., refactoring).
o Example: Rewrite a messy “Search Book” function to avoid future bugs.
o Effort: ~5-10% of maintenance.
Note: Percentages are approximate and depend on the system’s age and complexity.

How to Perform Software Maintenance

The process involves these steps:
1. Identify the Need:
o Gather bug reports, user requests, or environment changes (e.g., “UI freezes”).
2. Analyze Impact:
o Assess how changes affect the system (e.g., “Will ‘Cancel RSVP’ break registration?”).
3. Plan the Change:
o Define scope, resources, and timeline (e.g., “1-week fix”).
4. Implement the Change:
o Modify code (e.g., update “register()” to include cancellation).
5. Test the Change:
o Run regression tests (e.g., “Does ‘RSVP’ still work?”).
 6. Deploy the Update:
o Release to users (e.g., app store update).
7. Document:
o Log changes (e.g., “Added Cancel RSVP, v1.1”).

Example: Maintenance for a Library App

Issue: Users report “Borrow Book” fails for unavailable books without feedback.
• Type: Corrective.
• Code (Before):
python
CollapseWrapCopy
def borrowBook(self, bookID, userID):
if bookID in self.books and self.books[bookID].available:
self.books[bookID].available = False
self.loans.append({"bookID": bookID, "userID": userID})
return True
return False
• Code (After):
python
CollapseWrapCopy
def borrowBook(self, bookID, userID):
if bookID not in self.books:
print("Error: Book not found")
return False
if not self.books[bookID].available:
print("Error: Book is unavailable")
return False
self.books[bookID].available = False
self.loans.append({"bookID": bookID, "userID": userID})
print("Success: Book borrowed")
return True
• Test: Run cases (valid borrow, unavailable book, invalid ID).
• Deploy: Update app with feedback messages.

Practical Example for BSIT Students

Imagine maintaining a campus event app:
• Issue: Users want “Event Reminders” (Perfective).
• Change:
o Add to “Event” class:
python
CollapseWrapCopy
class Event:
def __init__(self, eventID, title, date):
self.eventID = eventID
 self.title = title
self.date = date
self.registrations = []

def sendReminder(self):
for studentID in self.registrations:
print(f"Reminder: {self.title} on {self.date} for {studentID}")
• Test: Verify reminders print for registered students.
• Impact: Check “register()” still works (regression test).
• Deploy: Release v1.2 with reminders.
Scenario: OS update breaks UI (Adaptive)—adjust layout and retest.

Benefits of Software Maintenance

• Reliability: Keeps the system bug-free (e.g., no RSVP crashes).
• Relevance: Adds features users want (e.g., reminders).
• Longevity: Extends software life (e.g., OS compatibility).
Example: A game’s maintenance adds “multiplayer” and fixes lag.

Real-World Example
• Success: Microsoft Windows updates fix bugs and add features (e.g., Windows 11
enhancements).
• Failure: The 2000s NHS IT system neglected maintenance, leading to obsolescence.

Key Takeaways
• Software maintenance fixes bugs, adapts, and enhances post-deployment.
• It includes corrective, adaptive, perfective, and preventive types.
• Examples like event apps and Windows show its ongoing role.

Topic 37: Software Quality Assurance

The thirty-seventh topic in the Software Engineering course introduces Software Quality Assurance
(SQA), a systematic approach to ensuring that a software product meets specified quality standards
throughout its development lifecycle. Below, I’ll explain SQA in detail, including its definition, purpose,
principles, activities, and examples tailored for BSIT students.

What is Software Quality Assurance?

Software Quality Assurance (SQA) is a set of planned and systematic activities designed jon to ensure
that a software process and its products conform to requirements, standards, and best practices. It
focuses on preventing defects rather than just detecting them (as in testing). Ian Sommerville (Software
Engineering, 10th Edition) defines SQA as "a set of activities that define and assess the quality of
software processes and products, ensuring that the software meets its specified requirements."
Think of it like a chef’s quality checklist: before serving (deployment), you ensure ingredients (code) are
fresh, recipes (processes) are followed, and the dish (software) tastes great (meets standards).
Example: For a library app, SQA ensures “Borrow Book” is reliable, usable, and coded to standards, not
just functional.
Purpose of Software Quality Assurance
SQA serves several key purposes:
• Ensure Quality: Meets functional (e.g., “search works”) and non-functional (e.g., “fast”)
requirements.
• Prevent Defects: Identifies issues early in the process, reducing rework.
• Build Confidence: Assures stakeholders (e.g., users, clients) of a reliable product.
• Improve Processes: Enhances development practices for consistency.
Example: A student portal’s SQA ensures “Calculate GPA” is accurate and the code is maintainable.

Principles of Software Quality Assurance

Effective SQA follows these principles:
1. Proactive: Focus on prevention over correction (e.g., catch issues in design).
2. Continuous: Applies throughout the lifecycle, not just at the end.
3. Standards-Based: Adheres to guidelines (e.g., ISO 9001, IEEE standards).
4. Measurable: Uses metrics (e.g., defect rate, code coverage).
5. Collaborative: Involves all team members, not just a QA team.
Example: A game’s SQA checks “MovePlayer” coding standards during development, not just after bugs
appear.

Quality Attributes
SQA targets these software quality attributes (from ISO/IEC 25010):
• Functionality: Does it work as intended? (e.g., “RSVP Event” registers users).
• Reliability: Can it handle failures? (e.g., no crashes on overload).
• Usability: Is it easy to use? (e.g., intuitive UI).
• Efficiency: Is it fast and resource-light? (e.g., <2s response).
• Maintainability: Is it easy to update? (e.g., modular code).
• Portability: Does it work across platforms? (e.g., Android/iOS).
• Security: Is it safe? (e.g., encrypted data).
Example: A library app’s SQA ensures “Borrow Book” is reliable, usable, and secure.

SQA Activities
SQA involves these key activities:
1. Process Definition:
o Establish standards and methodologies (e.g., Agile with coding guidelines).
2. Reviews and Audits:
o Check requirements, design, code (e.g., peer review of “Event” class).
3. Testing Oversight:
o Ensure testing aligns with quality goals (e.g., verify unit tests cover “Borrow Book”).
4. Metrics Collection:
o Measure quality (e.g., bugs per module, response time).
5. Training:
o Educate team on best practices (e.g., OOD principles).
6. Configuration Management:
 o Track changes (e.g., Git commits for “RSVP fix”).
7. Risk Management:
o Identify and mitigate risks (e.g., “database failure”).

How to Implement SQA

The process involves these steps:
1. Define Quality Goals:
o Set targets (e.g., “99% uptime,” “no critical bugs”).
2. Develop an SQA Plan:
o Outline activities, tools, and responsibilities (e.g., “QA reviews design”).
3. Execute Activities:
o Conduct reviews, monitor processes (e.g., check “Event” code).
4. Measure and Analyze:
o Collect data (e.g., “5 bugs in UI”) and assess.
5. Improve Processes:
o Adjust based on findings (e.g., “add UI testing earlier”).
6. Document:
o Record SQA results (e.g., “SQA Report v1.0”).

Example: SQA for a Library App

SQA Plan:
• Goal: Ensure “Borrow Book” is reliable and efficient.
• Activities:
o Review “Borrow Book” requirements for clarity.
o Audit code for PEP 8 compliance (Python style).
o Verify unit tests cover all cases (available, unavailable book).
o Measure response time (<1s target).
• Execution:
o Code review finds missing error message—fixed.
o Test coverage: 95% (good).
o Response time: 0.8s (meets goal).
• Outcome: “Borrow Book” meets quality standards.
Code Snippet (Post-SQA):
python
CollapseWrapCopy
def borrowBook(self, bookID, userID):
if bookID not in self.books:
raise ValueError("Book not found")
book = self.books[bookID]
if not book.available:
raise ValueError("Book unavailable")
book.available = False
self.loans.append({"bookID": bookID, "userID": userID})
return True
Practical Example for BSIT Students
Imagine SQA for a campus event app:
• Goal: “RSVP Event” is usable and reliable.
• SQA Activities:
o Review use case: “RSVP Event” must confirm registration.
o Code audit: Ensure “register()” is modular, documented.
o Test oversight: Check unit tests for capacity limits.
o Usability check: UI button is visible, clear.
• Metrics:
o Bugs: 2 minor (fixed).
o Test coverage: 90%.
o User feedback: “Easy to RSVP” (positive).
• Improvement: Add input validation to “register()”.
Scenario: Security risk found—encrypt studentID; update SQA plan.

Benefits of Software Quality Assurance

• Reliability: Fewer failures (e.g., no RSVP crashes).
• User Satisfaction: Meets expectations (e.g., intuitive UI).
• Cost Savings: Prevents costly post-release fixes.
Example: A game’s SQA ensures “Shoot” is bug-free and responsive.

Real-World Example
• Success: NASA’s SQA for Mars Rover software ensured zero critical failures.
• Failure: The 2013 Healthcare.gov skipped robust SQA, leading to launch issues.

Key Takeaways
• SQA ensures software meets quality standards proactively.
• It includes reviews, testing oversight, and metrics.
• Examples like event apps and NASA show its quality role.

Topic 38: Software Configuration Management

The thirty-eighth topic in the Software Engineering course introduces Software Configuration
Management (SCM), a critical discipline for managing changes to software artifacts throughout the
development lifecycle. Below, I’ll explain SCM in detail, including its definition, purpose, principles,
activities, and examples tailored for BSIT students.

What is Software Configuration Management?

Software Configuration Management (SCM) is the process of identifying, organizing, controlling, and
tracking changes to software artifacts (e.g., code, documents, designs) to maintain their integrity and
consistency. Ian Sommerville (Software Engineering, 10th Edition) defines SCM as "the discipline of
managing and controlling change in software systems, ensuring that the system evolves in a controlled
manner."
Think of it like a librarian for a digital library: SCM keeps track of every book (file), ensures versions don’t
get mixed up, and manages updates (changes) so everyone has the right copy.
Example: For a library app, SCM tracks versions of the “Borrow Book” code, ensuring bug fixes and
feature additions are managed properly.

Purpose of Software Configuration Management

SCM serves several key purposes:
• Control Changes: Manages modifications to prevent chaos (e.g., “Who changed this?”).
• Maintain Integrity: Ensures all parts (code, docs) work together consistently.
• Track History: Records what changed, when, and why (e.g., “v1.1 fixed crash”).
• Support Collaboration: Enables teams to work concurrently without conflicts.
• Facilitate Rollback: Reverts to stable versions if needed (e.g., undo a bad update).
Example: A student portal’s SCM ensures “Calculate GPA” updates don’t break “View Grades.”

Principles of Software Configuration Management

Effective SCM follows these principles:
1. Identification: Label all artifacts uniquely (e.g., “v1.0”).
2. Version Control: Manage multiple versions of each artifact.
3. Change Control: Formalize how changes are proposed and approved.
4. Consistency: Keep configurations aligned (e.g., code matches design).
5. Auditability: Track changes for accountability (e.g., “Who fixed this bug?”).
Example: A game’s SCM labels “MovePlayer v1.2” and logs a bug fix for auditing.

Key SCM Activities

SCM involves these core activities:
1. Configuration Identification:
o Define and name artifacts (e.g., “Event.py,” “README.md”).
o Establish baselines (stable versions, e.g., “Release 1.0”).
2. Version Control:
o Track revisions (e.g., “v1.0 → v1.1”).
o Use tools like Git, SVN to manage versions.
3. Change Management:
o Process change requests (e.g., “Add Cancel RSVP”).
o Approve/reject via a Change Control Board (CCB) or team consensus.
4. Configuration Status Accounting:
o Record and report changes (e.g., “v1.1: Added reminders, 3/6/2025”).
o Maintain logs or commit histories.
5. Configuration Auditing:
o Verify artifacts match specifications (e.g., “Does code reflect design?”).
o Check compliance (e.g., coding standards).

SCM Tools
• Git: Distributed version control (e.g., GitHub, GitLab).
• Subversion (SVN): Centralized version control.
 • Mercurial: Another distributed option.
• Supporting Tools: JIRA (change tracking), Jenkins (build integration).
Example: A library app uses Git to manage “Borrow Book” code versions.

How to Implement SCM

The process involves these steps:
1. Set Up SCM System:
o Choose a tool (e.g., Git) and repository (e.g., GitHub).
2. Identify Artifacts:
o List items to manage (e.g., code, UML diagrams).
3. Establish Baselines:
o Mark stable points (e.g., “v1.0 after testing”).
4. Track Changes:
o Commit updates with messages (e.g., git commit -m "Fixed borrow bug").
5. Manage Branches:
o Use branches for features/bugs (e.g., “feature/reminders”).
6. Review and Merge:
o Pull requests for approval (e.g., merge “bugfix” into “main”).
7. Audit and Report:
o Check logs (e.g., git log), ensure consistency.

Example: SCM for a Library App

Scenario: Team adds “Reserve Book” feature.
• Tool: Git on GitHub.
• Steps:
1. Baseline: “v1.0” (stable app).
2. Branch: git checkout -b feature/reserve-book
3. Code Change:
python
CollapseWrapCopy
class Library:
def reserveBook(self, bookID, userID):
if bookID in self.books and not self.books[bookID].available:
self.reservations.append({"bookID": bookID, "userID": userID})
return True
return False
4. Commit: git commit -m "Added reserveBook function"
5. Pull Request: Team reviews, merges to “main.”
6. New Baseline: “v1.1” after testing.
• Log: git log shows “Added reserveBook, 3/6/2025.”

Practical Example for BSIT Students

Imagine SCM for a campus event app:
• Setup: Git repository on GitLab.
 • Artifacts: “Event.py,” “Student.py,” test files.
• Change: Add “Cancel RSVP.”
o Branch: git checkout -b feature/cancel-rsvp
o Code:
python
CollapseWrapCopy
class Event:
def cancelRSVP(self, studentID):
if studentID in self.registrations:
self.registrations.remove(studentID)
return True
return False
• Commit: git commit -m "Added cancelRSVP"
• Merge: Pull request approved, merged to “main.”
• Audit: Check git log—confirms “v1.1” includes cancellation.
Scenario: Bug in “RSVP”—revert to “v1.0” with git checkout v1.0.

Benefits of Software Configuration Management

• Control: Prevents version conflicts (e.g., two “Borrow” edits).
• Traceability: Tracks history (e.g., “Who added reminders?”).
• Recovery: Restores stable states (e.g., rollback bad update).
Example: A game’s SCM ensures “Shoot” feature branches don’t break “Move.”

Real-World Example
• Success: Linux kernel uses Git for SCM, managing millions of lines across thousands of
developers.
• Failure: The 2000s FBI Virtual Case File lacked SCM, causing version mismatches.

Key Takeaways
• SCM manages changes to software artifacts systematically.
• It includes version control, change management, and auditing.
• Examples like event apps and Linux show its collaboration role.

Topic 39: Software Project Estimation

The thirty-ninth topic in the Software Engineering course introduces Software Project Estimation, a
crucial aspect of project management that involves predicting the effort, time, and cost required to
develop a software system. Below, I’ll explain software project estimation in detail, including its
definition, purpose, techniques, process, and examples tailored for BSIT students.

What is Software Project Estimation?

Software project estimation is the process of forecasting the resources (effort, time, and cost) needed to
complete a software development project based on its scope, requirements, and constraints. Ian
Sommerville (Software Engineering, 10th Edition) describes it as "the process of predicting the effort
required to develop a software system, typically based on historical data, expert judgment, or analytical
models."
Think of it like planning a road trip: you estimate how long it’ll take (time), how much gas you’ll need
(effort), and the cost (budget) based on the distance (scope) and past trips (data).
Example: For a library app, estimation predicts it’ll take 3 months, 200 person-hours, and $5,000 to build
features like “Borrow Book” and “Search Book.”

Purpose of Software Project Estimation

Estimation serves several key purposes:
• Resource Planning: Determines staff, tools, and budget needs.
• Scheduling: Sets realistic timelines and milestones.
• Budgeting: Allocates funds effectively.
• Risk Management: Identifies uncertainties (e.g., “new tech delays”).
• Decision Making: Helps stakeholders approve or adjust scope.
Example: A student portal’s estimation ensures “View Grades” is delivered by semester start within
budget.

Principles of Software Project Estimation

Effective estimation follows these principles:
1. Accuracy: Strive for realistic, not overly optimistic, predictions.
2. Iterative: Refine estimates as more details emerge.
3. Data-Driven: Use historical data or benchmarks when possible.
4. Involve Experts: Leverage team experience for judgment.
5. Account for Uncertainty: Include buffers for risks (e.g., 10% extra time).
Example: A game’s “MovePlayer” estimate uses past projects and adds a buffer for debugging.

Factors Affecting Estimation

• Size: Lines of code, function points, or features (e.g., “10 use cases”).
• Complexity: Technical difficulty (e.g., database integration).
• Team Experience: Skill level impacts speed.
• Requirements Stability: Changes increase effort.
• Tools/Technology: New tools may slow initial progress.
• Constraints: Deadlines or budget limits.
Example: A library app with stable requirements and an experienced team is easier to estimate than one
with shifting needs.

Estimation Techniques
Several methods are used, often combined:
1. Expert Judgment:
o Approach: Team members estimate based on experience.
o Example: “Borrow Book took 20 hours last time—similar here.”
o Pros: Quick, leverages expertise.
o Cons: Subjective, depends on memory.
2. Analogous Estimation:
 o Approach: Uses historical data from similar projects.
o Example: “Last app took 300 hours for 5 features; this has 6, so ~360 hours.”
o Pros: Simple, data-based.
o Cons: Needs comparable projects.
3. Function Point Analysis (FPA):
o Approach: Measures size by counting inputs, outputs, queries, files, interfaces.
o Example: Library app: 3 inputs (search, borrow, return), 2 outputs (results, confirmation)
→ 20 function points → 200 hours (10 hours/FP).
o Pros: Objective, standardized.
o Cons: Complex, needs training.
4. COCOMO (Constructive Cost Model):
o Approach: Mathematical model based on size (e.g., lines of code), effort multipliers
(e.g., team skill).
o Example: Basic COCOMO: Effort = a * (KLOC)^b * EAF (e.g., 2.4 * 5^1.05 * 1.2 = ~32
person-months).
o Pros: Detailed, scalable.
o Cons: Requires size estimate first.
5. Planning Poker (Agile):
o Approach: Team assigns story points collaboratively.
o Example: “RSVP Event” = 5 points, team velocity = 20 points/sprint → 1 sprint.
o Pros: Team consensus, Agile-friendly.
o Cons: Less precise for cost.

How to Perform Software Project Estimation

The process involves these steps:
1. Define Scope:
o List features (e.g., “Search Book,” “Borrow Book”).
2. Gather Data:
o Use past projects, team input (e.g., “Search took 10 hours before”).
3. Choose Technique:
o Select method (e.g., FPA for accuracy, expert judgment for speed).
4. Estimate Size:
o Measure in lines, points, or features (e.g., 500 LOC).
5. Calculate Effort:
o Convert size to hours (e.g., 10 LOC/hour → 50 hours).
6. Determine Time:
o Factor in team size (e.g., 50 hours / 2 developers = 25 hours elapsed).
7. Estimate Cost:
o Apply rates (e.g., $50/hour * 50 hours = $2,500).
8. Adjust for Risks:
o Add buffer (e.g., +10% = 55 hours).
9. Document:
o Present estimate (e.g., “55 hours, $2,750, 1 month”).
Example: Estimation for a Library App
Scope: “Search Book,” “Borrow Book,” “Return Book.”
• Technique: Analogous + Expert Judgment.
• Data: Past app (5 features, 200 hours, 2 months, $5,000).
• Size: 3 features (60% of past project).
• Effort: 60% of 200 = 120 hours.
• Time: 120 hours / 2 developers = 60 hours elapsed ≈ 1.5 months (with part-time work).
• Cost: 120 hours * $40/hour = $4,800.
• Risk Buffer: +10% = 132 hours, ~$5,300.
• Result: “132 hours, $5,300, 1.5 months.”

Practical Example for BSIT Students

Imagine estimating a campus event app:
• Scope: “View Events,” “RSVP Event,” “Cancel RSVP.”
• Technique: Planning Poker (Agile).
• Steps:
o Team assigns: View=3 points, RSVP=5 points, Cancel=3 points (11 total).
o Velocity: 10 points/sprint (2 weeks).
o Effort: 11 / 10 = ~1.1 sprints ≈ 2 sprints (4 weeks).
o Cost: 2 developers * 40 hours/sprint * 2 sprints * $20/hour = $3,200.
• Result: “4 weeks, $3,200, 2 sprints.”
• Adjustment: Buffer for UI tweaks (+1 week, $3,600).
Scenario: Requirements add “Reminders”—re-estimate at 5 points, adjust to 3 sprints.

Benefits of Software Project Estimation

• Planning: Sets realistic goals (e.g., RSVP by deadline).
• Control: Tracks progress against estimates.
• Transparency: Aligns team and stakeholders.
Example: A game’s estimation ensures “Shoot” is ready for beta testing on time.

Real-World Example
• Success: NASA’s Mars Rover used COCOMO for precise effort planning.
• Failure: The 2000s NHS IT system underestimated scope, ballooning costs.

Key Takeaways
• Project estimation predicts effort, time, and cost.
• It uses techniques like FPA, COCOMO, and Planning Poker.
• Examples like event apps and NASA show its planning role.

Topic 40: Risk Management in Software Engineering

The fortieth topic in the Software Engineering course introduces Risk Management in Software
Engineering, a critical process for identifying, assessing, and mitigating potential issues that could
jeopardize a software project’s success. Below, I’ll explain risk management in detail, including its
definition, purpose, principles, process, and examples tailored for BSIT students.
What is Risk Management in Software Engineering?
Risk management in software engineering is the systematic process of identifying, analyzing, prioritizing,
and controlling risks that could affect a software project’s objectives, such as meeting deadlines, staying
within budget, or delivering quality software. Ian Sommerville (Software Engineering, 10th Edition)
defines it as "the process of identifying risks, assessing their potential impact, and taking steps to reduce
their likelihood or consequences."
Think of it like preparing for a hike: you check the weather (identify risks), assess if rain could delay you
(analyze), and pack a raincoat (mitigate) to ensure you reach the summit (project goals).
Example: For a library app, risk management might address the chance of a database crash delaying
“Borrow Book” deployment.

Purpose of Risk Management

Risk management serves several key purposes:
• Prevent Failure: Reduces the chance of project delays, cost overruns, or defects.
• Protect Quality: Ensures the software meets standards despite challenges.
• Optimize Resources: Allocates effort to critical areas (e.g., high-risk features).
• Increase Predictability: Improves planning by addressing uncertainties.
Example: A student portal’s risk management ensures “Calculate GPA” isn’t delayed by team
inexperience.

Principles of Risk Management

Effective risk management follows these principles:
1. Proactive: Identify risks early, before they become problems.
2. Continuous: Monitor risks throughout the project lifecycle.
3. Prioritized: Focus on high-impact, high-likelihood risks first.
4. Collaborative: Involve the team for diverse perspectives.
5. Balanced: Mitigate risks without overcomplicating the project.
Example: A game’s risk management flags “new graphics engine” early, monitoring its integration.

Types of Risks in Software Projects

Risks fall into several categories:
1. Technical Risks:
o Issues with technology (e.g., “new framework fails”).
o Example: Library app’s database crashes under load.
2. Project Risks:
o Management issues (e.g., “schedule slips”).
o Example: Event app delayed by late requirements.
3. Personnel Risks:
o Team-related (e.g., “key developer leaves”).
o Example: Student portal coder unavailable mid-project.
4. External Risks:
o Outside factors (e.g., “vendor API discontinued”).
o Example: Game’s third-party server shuts down.
 5. Quality Risks:
o Defects or unmet standards (e.g., “security flaw”).
o Example: App leaks user data.

Risk Management Process

The process involves these steps:
1. Risk Identification:
o List potential risks (e.g., brainstorming, checklists).
2. Risk Analysis:
o Assess likelihood (probability) and impact (severity).
o Example: “Database crash: 20% chance, high impact.”
3. Risk Prioritization:
o Rank risks (e.g., Risk Exposure = Likelihood * Impact).
4. Risk Mitigation:
o Plan actions:
▪ Avoid: Eliminate (e.g., use proven tech).
▪ Reduce: Minimize (e.g., add testing).
▪ Transfer: Outsource (e.g., hire expert).
▪ Accept: Live with it (e.g., small delay).
5. Risk Monitoring:
o Track risks and adjust plans (e.g., weekly reviews).
6. Documentation:
o Record risks and actions (e.g., “Risk Log”).

Example: Risk Management for a Library App

Risk Identification:
• Risk 1: “Database fails under 500 users.”
• Risk 2: “Team unfamiliar with UI framework.”
Risk Analysis:
• Risk 1: Likelihood=30%, Impact=High (delays release).
• Risk 2: Likelihood=50%, Impact=Medium (slower UI).
Risk Prioritization:
• Risk Exposure:
o Risk 1: 0.3 * 10 = 3.0 (high).
o Risk 2: 0.5 * 5 = 2.5 (medium).
Risk Mitigation:
• Risk 1: Reduce—add load testing; cost $500, 1 week.
• Risk 2: Reduce—train team; cost $200, 2 days.
Monitoring:
• Weekly checks: “Load test passed?” “UI progress on track?”
Result: Database scales, UI completed on time.

Practical Example for BSIT Students

Imagine managing risks for a campus event app:
 • Risk Identification:
1. “Requirements change mid-project.”
2. “Server downtime during launch.”
• Risk Analysis:
o Risk 1: Likelihood=40%, Impact=High (scope creep).
o Risk 2: Likelihood=20%, Impact=High (user loss).
• Prioritization:
o Risk 1: 0.4 * 8 = 3.2.
o Risk 2: 0.2 * 9 = 1.8.
• Mitigation:
o Risk 1: Avoid—freeze requirements after Week 2.
o Risk 2: Reduce—use backup server; cost $100.
• Monitoring: Sprint reviews track requirement stability, server uptime.
Scenario: New risk—“studentID leak”—add encryption, update plan.

Tools for Risk Management

• Risk Logs: Spreadsheets or docs (e.g., “Risk ID, Description, Plan”).
• Project Management Tools: JIRA, Trello (track risks).
• Simulation Tools: Monte Carlo for probability analysis.
• Version Control: Git (mitigate code risks).
Example: Event app uses JIRA to log “Server downtime” risk.

Benefits of Risk Management

• Success: Reduces project failures (e.g., on-time RSVP).
• Efficiency: Saves resources by preventing issues.
• Confidence: Assures stakeholders of control.
Example: A game’s risk plan ensures “Multiplayer” launches smoothly.

Real-World Example
• Success: Apollo 11’s risk management mitigated software overload, ensuring a moon landing.
• Failure: The 1996 Ariane 5 rocket crashed due to unaddressed reuse risks.

Key Takeaways
• Risk management identifies and mitigates project threats.
• It involves analysis, prioritization, and continuous monitoring.
• Examples like event apps and Apollo show its protective role.

Topic 41: Software Metrics and Measurement

The forty-first topic in the Software Engineering course introduces Software Metrics and Measurement,
a quantitative approach to assessing and improving the software development process and product
quality. Below, I’ll explain software metrics and measurement in detail, including their definition,
purpose, types, process, and examples tailored for BSIT students.

What are Software Metrics and Measurement?

Software metrics are quantitative measures used to evaluate specific attributes of a software process,
product, or project, while measurement is the act of collecting and analyzing these metrics. Ian
Sommerville (Software Engineering, 10th Edition) defines software metrics as "quantitative measures
that provide insight into the efficiency of the software process and the quality of the software
produced."
Think of it like a fitness tracker: it measures steps (effort), heart rate (quality), and distance (progress) to
assess your workout (software project).
Example: For a library app, metrics might track “lines of code” (size), “bugs found” (quality), and “hours
spent” (effort).

Purpose of Software Metrics and Measurement

Metrics and measurement serve several key purposes:
• Assess Quality: Evaluate reliability, usability, etc. (e.g., “Is Borrow Book reliable?”).
• Monitor Progress: Track development status (e.g., “Are we on schedule?”).
• Improve Processes: Identify inefficiencies (e.g., “Why so many bugs?”).
• Support Decisions: Guide resource allocation (e.g., “Add more testers?”).
• Predict Outcomes: Estimate effort or defects (e.g., “How long to finish?”).
Example: A student portal measures “test coverage” to ensure “Calculate GPA” is bug-free.

Principles of Software Metrics

Effective metrics follow these principles:
1. Measurable: Must be quantifiable (e.g., “bugs” vs. “feels good”).
2. Relevant: Align with goals (e.g., “response time” for performance).
3. Consistent: Uniformly applied (e.g., same bug definition).
4. Actionable: Lead to improvements (e.g., “high defect rate → more testing”).
5. Cost-Effective: Worth the effort to collect (e.g., simple tools).
Example: A game’s “crash rate” metric is measurable and actionable (fix crashes).

Types of Software Metrics

Metrics are categorized by what they measure:
1. Product Metrics:
o Assess the software itself.
o Examples:
▪ Size: Lines of Code (LOC), Function Points (FP).
▪ Complexity: Cyclomatic Complexity (number of decision points).
▪ Quality: Defect Density (bugs per LOC), Reliability (MTBF—Mean Time Between
Failures).
o Use: “Library app: 500 LOC, 2 bugs/100 LOC.”
2. Process Metrics:
o Evaluate development activities.
o Examples:
▪ Effort: Person-hours spent.
▪ Productivity: LOC/hour, features/week.
▪ Defect Removal Efficiency (DRE): Bugs found before release / total bugs.
 o Use: “Event app: 100 hours, 80% DRE.”
3. Project Metrics:
o Monitor project management.
o Examples:
▪ Schedule Variance: Planned vs. actual time.
▪ Cost Variance: Budgeted vs. actual cost.
▪ Milestone Completion: % of tasks done.
o Use: “Game project: 10% over budget, 2 weeks late.”

How to Perform Software Metrics and Measurement

The process involves these steps:
1. Define Goals:
o What to measure (e.g., “improve quality,” “track progress”).
2. Select Metrics:
o Choose relevant ones (e.g., “defect density,” “effort”).
3. Collect Data:
o Use tools or manual tracking (e.g., Git commits, bug logs).
4. Analyze Data:
o Calculate and interpret (e.g., “2 bugs/100 LOC = high risk”).
5. Report Findings:
o Share with team (e.g., “Weekly Metrics Report”).
6. Take Action:
o Adjust process/product (e.g., “more testing for high complexity”).
7. Refine:
o Update metrics as needed (e.g., add “response time”).

Tools for Metrics and Measurement

• Code Analysis: SonarQube (complexity, bugs), pylint (style).
• Project Management: JIRA (effort, milestones), MS Project (schedule).
• Testing: JUnit (test coverage), JMeter (performance).
• Version Control: Git (commits, LOC).
Example: A library app uses SonarQube to measure “cyclomatic complexity.”

Example: Metrics for a Library App

Goals: Ensure quality, track effort.
• Metrics:
o Product: LOC=600, Defect Density=1.5 bugs/100 LOC, Test Coverage=85%.
o Process: Effort=150 hours, Productivity=4 LOC/hour.
o Project: Schedule Variance=+1 week, Cost=$6,000 (vs. $5,500 planned).
• Analysis:
o Quality: “1.5 bugs/100 LOC above target (1.0)—needs more testing.”
o Effort: “4 LOC/hour is average, on track.”
o Project: “1-week delay due to UI rework.”
• Action: Increase testing, adjust timeline.
Practical Example for BSIT Students
Imagine measuring a campus event app:
• Goals: Assess quality, monitor progress.
• Metrics:
o Product: LOC=400, Cyclomatic Complexity=10 (moderate), Bugs=5.
o Process: Effort=80 hours, DRE=90% (9/10 bugs caught pre-release).
o Project: Milestone Completion=75% (3/4 features done).
• Collection:
o Git: LOC count.
o JUnit: Test coverage (80%).
o Manual: Hours logged.
• Analysis:
o “5 bugs in 400 LOC = 1.25/100, acceptable.”
o “80% coverage—add edge case tests.”
o “75% done, 1 week left—tight but doable.”
• Action: Add tests for “Cancel RSVP,” push to finish.
Scenario: “Response time” added—measure 1.5s (target <2s), no action needed.

Benefits of Software Metrics and Measurement

• Insight: Reveals issues (e.g., high bug rate).
• Control: Tracks progress (e.g., on schedule).
• Improvement: Guides fixes (e.g., refactor complex code).
Example: A game’s “frame rate” metric ensures smooth gameplay.

Real-World Example
• Success: Google uses metrics (e.g., latency, crash rate) to optimize Maps.
• Failure: The 1990s Denver Airport baggage system ignored metrics, missing delays.

Key Takeaways
• Metrics measure product, process, and project attributes.
• They support quality and progress tracking.
• Examples like event apps and Google show their analytical role.

Topic 42: Agile Software Development

The forty-second topic in the Software Engineering course introduces Agile Software Development, a
flexible and iterative approach to building software that emphasizes collaboration, adaptability, and
delivering value to customers quickly. Below, I’ll explain Agile in detail, including its definition, purpose,
principles, methodologies, and examples tailored for BSIT students.

What is Agile Software Development?

Agile Software Development is an iterative and incremental methodology that prioritizes delivering
small, working pieces of software frequently, adapting to changes, and involving customers throughout
the process. Ian Sommerville (Software Engineering, 10th Edition) describes Agile as "an approach to
software development that emphasizes flexibility, customer collaboration, and the rapid delivery of
working software rather than extensive upfront planning."
Think of it like cooking a meal in stages: you serve appetizers (features) quickly, get feedback, and adjust
the main course (software) rather than cooking everything at once without tasting.
Example: For a library app, Agile delivers “Search Book” in the first iteration, gets user feedback, then
adds “Borrow Book” in the next.

Purpose of Agile Software Development

Agile serves several key purposes:
• Deliver Value Early: Provides usable software sooner (e.g., “View Events” now, not later).
• Adapt to Change: Handles evolving requirements (e.g., “Add reminders mid-project”).
• Enhance Collaboration: Involves team and customers continuously.
• Reduce Risk: Frequent testing and feedback catch issues early.
• Improve Quality: Iterative refinement ensures a better product.
Example: A student portal uses Agile to release “Login” first, then “Grades,” adapting to student needs.

Principles of Agile (Agile Manifesto)

Agile is guided by the Agile Manifesto (2001), with four core values and 12 principles:
• Values:
1. Individuals and Interactions over processes and tools.
2. Working Software over comprehensive documentation.
3. Customer Collaboration over contract negotiation.
4. Responding to Change over following a plan.
• Key Principles:
o Deliver working software frequently (weeks rather than months).
o Welcome changing requirements, even late in development.
o Build projects around motivated individuals.
o Continuous attention to technical excellence and good design.
o Simplicity—the art of maximizing work not done—is essential.
Example: A game’s Agile team prioritizes playable “MovePlayer” over detailed docs, adjusting based on
player feedback.

Agile Methodologies
Agile includes several frameworks:
1. Scrum:
o Structure: Sprints (2-4 weeks), roles (Product Owner, Scrum Master, Team), events
(Sprint Planning, Daily Scrum, Review, Retrospective).
o Example: Library app sprints: Sprint 1=“Search,” Sprint 2=“Borrow.”
o Pros: Clear roles, time-boxed delivery.
o Cons: Needs discipline.
2. Kanban:
o Structure: Visual board (To Do, In Progress, Done), continuous flow, no fixed iterations.
o Example: Event app tasks move from “Design UI” to “Test UI” as completed.
o Pros: Flexible, real-time tracking.
 o Cons: Less structured.
3. Extreme Programming (XP):
o Structure: Pair programming, test-driven development (TDD), frequent releases.
o Example: Student portal uses TDD for “Calculate GPA.”
o Pros: High quality, rapid feedback.
o Cons: Intense for teams.
4. Lean Software Development:
o Structure: Eliminate waste, deliver fast, optimize the whole.
o Example: Game skips unused features to focus on “Shoot.”
o Pros: Efficient, customer-focused.
o Cons: May miss long-term planning.

How to Implement Agile

The process varies by methodology but generally includes:
1. Define Vision:
o Set goals with stakeholders (e.g., “usable event app in 2 months”).
2. Create Backlog:
o List features (e.g., “View Events,” “RSVP”) as user stories (e.g., “As a student, I want to
RSVP so I can attend”).
3. Plan Iterations:
o Prioritize and schedule (e.g., Sprint 1: “View Events”).
4. Develop Incrementally:
o Code, test, deliver (e.g., Python code for “View Events”).
5. Review and Adapt:
o Demo to users, gather feedback (e.g., “Add filter”).
6. Repeat:
o Next iteration (e.g., Sprint 2: “RSVP”).
7. Reflect:
o Improve process (e.g., “Test earlier”).

Example: Agile for a Library App (Scrum)

• Backlog:
o “Search Book” (5 points), “Borrow Book” (8 points), “Return Book” (3 points).
• Sprint 1 (2 weeks):
o Goal: “Search Book.”
o Code:
python
CollapseWrapCopy
class Library:
def searchBook(self, title):
return [book for book in self.books.values() if title in book.title]
• Test: Unit tests pass, demo shows search works.
• Review: Users like it but want “author search”—added to backlog.
• Sprint 2: “Borrow Book” with feedback incorporated.
Practical Example for BSIT Students
Imagine developing a campus event app with Scrum:
• Vision: “App for students to manage events by semester end.”
• Backlog:
o “View Events” (3 points), “RSVP Event” (5 points), “Cancel RSVP” (3 points).
• Sprint 1 (1 week):
o Task: “View Events.”
o Code:
python
CollapseWrapCopy
class Event:
def __init__(self, eventID, title):
self.eventID = eventID
self.title = title

class EventManager:
def viewEvents(self):
return [event.title for event in self.events]
• Daily Scrum: “Coded view, testing today.”
• Review: “Looks good, add dates”—backlog updated.
• Sprint 2: “RSVP Event.”
Scenario: Mid-sprint, “notifications” requested—prioritized for Sprint 3.

Benefits of Agile Software Development

• Speed: Delivers features fast (e.g., “Search” in 2 weeks).
• Flexibility: Adapts to changes (e.g., new RSVP needs).
• Quality: Frequent testing improves code (e.g., no bugs in “View”).
Example: A game’s Agile releases “Level 1” early, refining based on playtests.

Real-World Example
• Success: Spotify uses Scrum to roll out features like “Discover Weekly” iteratively.
• Contrast: Waterfall delayed the 2000s FBI Virtual Case File with rigid planning.

Key Takeaways
• Agile delivers software iteratively with customer focus.
• It uses frameworks like Scrum, Kanban, and XP.
• Examples like event apps and Spotify show its adaptive role.

Topic 43: Scrum Framework

The forty-third topic in the Software Engineering course dives deeper into Agile Software Development
by focusing on the Scrum Framework, one of the most popular Agile methodologies. Below, I’ll explain
Scrum in detail, including its definition, purpose, components, process, and examples tailored for BSIT
students.
What is the Scrum Framework?
Scrum is an Agile framework for managing software development projects that emphasizes iterative
progress, team collaboration, and delivering working software in short, fixed time periods called sprints.
Ian Sommerville (Software Engineering, 10th Edition) describes Scrum as "an Agile method that
structures development into sprints, with defined roles, events, and artifacts to facilitate rapid delivery
and adaptation."
Think of it like a relay race: the team (runners) works in short bursts (sprints), passing the baton
(software increments) while a coach (Scrum Master) keeps them on track and a manager (Product
Owner) sets the finish line (goals).
Example: For a library app, Scrum delivers “Search Book” in a 2-week sprint, then “Borrow Book” in the
next, adapting based on feedback.

Purpose of the Scrum Framework

Scrum serves several key purposes:
• Incremental Delivery: Releases usable software frequently (e.g., every 2 weeks).
• Adaptability: Adjusts to changing requirements (e.g., “add reminders” mid-project).
• Team Empowerment: Encourages self-organizing teams to solve problems.
• Transparency: Provides visibility into progress (e.g., daily updates).
• Quality Focus: Ensures working software through continuous testing.
Example: A student portal uses Scrum to deliver “Login” first, then “View Grades,” adapting to student
needs.

Components of Scrum
Scrum is built on three pillars—Transparency, Inspection, Adaptation—and includes:
1. Roles:
o Product Owner (PO):
▪ Defines what to build (e.g., prioritizes “Borrow Book” over “Reserve”).
▪ Manages the Product Backlog.
o Scrum Master (SM):
▪ Facilitates the process, removes impediments (e.g., “fix slow server”).
▪ Coaches the team on Scrum practices.
o Development Team:
▪ Self-organizing group (3-9 people) that builds the software (e.g., coders, testers).
2. Artifacts:
o Product Backlog:
▪ Ordered list of features/user stories (e.g., “As a student, I want to RSVP”).
o Sprint Backlog:
▪ Subset of Product Backlog for the sprint (e.g., “View Events”).
o Increment:
▪ Working software delivered at sprint’s end (e.g., “Search Book” feature).
3. Events:
o Sprint: Fixed time-box (1-4 weeks) for delivering an increment.
o Sprint Planning: Team selects backlog items and plans work (e.g., “8 points this sprint”).
 o Daily Scrum: 15-minute stand-up to sync (e.g., “What did I do? What’s next?”).
o Sprint Review: Demo increment, gather feedback (e.g., “Users want filters”).
o Sprint Retrospective: Reflect and improve (e.g., “Test earlier next time”).

How Scrum Works

The process follows this cycle:
1. Product Backlog Creation:
o PO lists all features (e.g., “Search,” “Borrow,” “Return”).
2. Sprint Planning:
o Team picks items (e.g., “Search Book,” 5 points), sets sprint goal.
3. Sprint Execution:
o Team codes/tests daily, updates in Daily Scrum.
4. Sprint Review:
o Show working software (e.g., “Search works”), adjust backlog.
5. Sprint Retrospective:
o Discuss what went well/bad (e.g., “More unit tests”), plan improvements.
6. Repeat:
o Next sprint begins (e.g., “Borrow Book”).

Example: Scrum for a Library App

• Roles:
o PO: Prioritizes “Search Book” and “Borrow Book.”
o SM: Ensures team has tools, resolves “database access” issue.
o Team: 3 developers, 1 tester.
• Artifacts:
o Product Backlog: “Search Book” (5 points), “Borrow Book” (8 points), “Return Book” (3
points).
o Sprint Backlog (Sprint 1): “Search Book.”
o Increment: Working “Search Book” feature.
• Events:
o Sprint Planning: 2-week sprint, goal: “Searchable library.”
o Daily Scrum: “Coded search yesterday, testing today.”
o Sprint Review: Demo search, users request “author filter”—added to backlog.
o Retrospective: “Pair programming helped—do more.”
Code Snippet:
python
CollapseWrapCopy
class Library:
def searchBook(self, title):
return [book for book in self.books.values() if title in book.title]

Practical Example for BSIT Students

Imagine building a campus event app with Scrum:
• Roles:
 o PO: Student rep prioritizing “View Events” and “RSVP.”
o SM: Instructor ensuring team collaboration.
o Team: 4 students (2 coders, 1 designer, 1 tester).
• Backlog:
o “View Events” (3 points), “RSVP Event” (5 points), “Cancel RSVP” (3 points).
• Sprint 1 (1 week):
o Planning: Goal: “View Events,” 3 points.
o Code:
python
CollapseWrapCopy
class EventManager:
def viewEvents(self):
return [event.title for event in self.events]
• Daily Scrum: “Designed UI yesterday, coding today.”
• Review: Demo shows events, feedback: “Add dates”—backlog updated.
• Retrospective: “Late testing delayed us—start earlier.”
• Sprint 2: “RSVP Event” with improved testing.
Scenario: Mid-sprint, “notifications” requested—PO adds to backlog for Sprint 3.

Benefits of Scrum Framework

• Speed: Delivers fast (e.g., “View Events” in 1 week).
• Flexibility: Adapts to feedback (e.g., “add dates”).
• Teamwork: Empowers collaboration (e.g., daily syncs).
• Quality: Incremental testing reduces bugs.
Example: A game’s Scrum delivers “Level 1” in Sprint 1, refining based on playtests.

Real-World Example
• Success: Atlassian uses Scrum to develop Jira, delivering features every few weeks.
• Contrast: Waterfall delayed the 1990s Denver Airport system with no early feedback.

Key Takeaways
• Scrum is an Agile framework with roles, artifacts, and events.
• It delivers increments in sprints, adapting to change.
• Examples like event apps and Atlassian show its iterative role.

Topic 44: Kanban Framework

The forty-fourth topic in the Software Engineering course continues the exploration of Agile
methodologies by introducing the Kanban Framework, a flexible and visual approach to managing
software development workflows. Below, I’ll explain Kanban in detail, including its definition, purpose,
principles, practices, and examples tailored for BSIT students.

What is the Kanban Framework?

Kanban is an Agile framework that focuses on visualizing work, limiting work in progress (WIP), and
optimizing the flow of tasks through a development process to deliver value continuously. Originating
from lean manufacturing (Toyota’s Kanban system), it was adapted for software by David J. Anderson. Ian
Sommerville (Software Engineering, 10th Edition) describes Kanban as "a method that uses visualization
and work-in-progress limits to manage and improve the flow of software development tasks."
Think of it like a restaurant order board: dishes (tasks) move from “To Cook” to “Cooking” to “Served”
(done), with limits on how many can be cooked at once to avoid chaos.
Example: For a library app, Kanban tracks “Search Book” moving from “To Do” to “In Progress” to
“Done,” ensuring smooth progress.

Purpose of the Kanban Framework

Kanban serves several key purposes:
• Visualize Workflow: Makes work transparent (e.g., “What’s being coded?”).
• Improve Efficiency: Reduces bottlenecks by limiting WIP.
• Enable Continuous Delivery: Delivers tasks as they’re completed, not in batches.
• Adapt to Change: Flexibly handles new priorities (e.g., “Fix bug now”).
• Enhance Collaboration: Aligns team on current tasks.
Example: A student portal uses Kanban to show “Calculate GPA” in “Testing,” avoiding overload.

Principles of Kanban
Kanban is guided by four core principles:
1. Start with What You Do Now:
o Build on existing processes, don’t overhaul them.
o Example: Use current coding/testing flow, add Kanban board.
2. Agree to Pursue Incremental Change:
o Improve gradually, not radically.
o Example: Limit WIP first, then optimize later.
3. Respect Current Roles and Responsibilities:
o No new roles (unlike Scrum’s PO/SM).
o Example: Team keeps coding, adds visualization.
4. Encourage Leadership at All Levels:
o Anyone can suggest improvements.
o Example: Tester proposes “faster review cycle.”

Core Practices of Kanban

Kanban relies on six practices:
1. Visualize the Workflow:
o Use a Kanban board with columns (e.g., “To Do,” “In Progress,” “Done”).
2. Limit Work in Progress (WIP):
o Cap tasks per column (e.g., max 3 in “In Progress”).
3. Manage Flow:
o Monitor task movement, reduce delays (e.g., “Why is testing slow?”).
4. Make Process Policies Explicit:
o Define rules (e.g., “Code reviewed before Done”).
5. Implement Feedback Loops:
o Review regularly (e.g., daily stand-ups, retrospectives).
 6. Improve Collaboratively, Evolve Experimentally:
o Test changes (e.g., “Lower WIP—does it speed up?”).

How Kanban Works

The process is continuous, not sprint-based:
1. Set Up Kanban Board:
o Columns: “Backlog,” “To Do,” “In Progress,” “Testing,” “Done.”
o Tasks: Cards (e.g., “Search Book”).
2. Populate Backlog:
o List all tasks (e.g., “Borrow Book,” “Return Book”).
3. Limit WIP:
o E.g., “In Progress” ≤ 2, “Testing” ≤ 1.
4. Move Tasks:
o Pull work as capacity allows (e.g., finish “Search,” start “Borrow”).
5. Monitor Flow:
o Track cycle time (e.g., “Search took 3 days”).
6. Adjust:
o Refine WIP, process (e.g., “Add ‘Review’ column”).
Tools: Trello, Jira, physical boards.

Example: Kanban for a Library App

• Board Setup:
text
CollapseWrapCopy
| Backlog | To Do (2) | In Progress (2) | Testing (1) | Done |
|---------------|-----------|-----------------|-------------|-------------|
| Return Book | Search Book | Borrow Book | | |
| Reserve Book | | | | |
• Flow:
o “Search Book” moves to “In Progress” (WIP=1).
o Code:
python
CollapseWrapCopy
class Library:
def searchBook(self, title):
return [book for book in self.books.values() if title in book.title]
• “Search” finishes, moves to “Testing”; “Borrow” stays until WIP frees up.
• Feedback: Team notes “Testing” bottleneck—adds tester.
• Result: “Search” done in 4 days, “Borrow” starts.

Practical Example for BSIT Students

Imagine building a campus event app with Kanban:
• Board:
text
CollapseWrapCopy
| Backlog | To Do (3) | In Progress (2) | Testing (1) | Done |
|---------------|-----------|-----------------|-------------|-------------|
| Cancel RSVP | View Events | RSVP Event | | |
| Notifications | | | | |
• Process:
o “View Events” in “In Progress”:
python
CollapseWrapCopy
class EventManager:
def viewEvents(self):
return [event.title for event in self.events]
• WIP=1, “RSVP Event” waits.
• “View” moves to “Testing,” “RSVP” starts.
• Flow Analysis: Cycle time=3 days/task, “Testing” slow—adjust WIP to 2.
• Feedback: “Add dates” from users—new card in “Backlog.”
Scenario: Urgent “bug fix” added—moves to “To Do,” prioritized.

Benefits of Kanban Framework

• Flexibility: No fixed sprints, adapts easily (e.g., “fix now”).
• Efficiency: WIP limits reduce overload (e.g., focused coding).
• Visibility: Team sees progress (e.g., “RSVP in Testing”).
Example: A game’s Kanban ensures “Shoot” flows smoothly without bottlenecks.

Real-World Example
• Success: Microsoft uses Kanban in Azure DevOps for continuous task flow.
• Contrast: Scrum’s fixed sprints delayed a rigid 1990s project.

Key Takeaways
• Kanban visualizes work, limits WIP, and manages flow.
• It’s continuous, flexible, and team-driven.
• Examples like event apps and Microsoft show its workflow role.

Topic 45: Lean Software Development

The forty-fifth topic in the Software Engineering course continues the exploration of Agile methodologies
by introducing Lean Software Development, an approach that applies lean manufacturing principles to
software engineering to maximize value and minimize waste. Below, I’ll explain Lean in detail, including
its definition, purpose, principles, practices, and examples tailored for BSIT students.

What is Lean Software Development?

Lean Software Development is an Agile methodology that focuses on delivering value to the customer
efficiently by eliminating waste, optimizing processes, and continuously improving the development
workflow. It adapts principles from Toyota’s Lean Production System, as outlined by Mary and Tom
Poppendieck in their book Lean Software Development: An Agile Toolkit (2003). Ian Sommerville
(Software Engineering, 10th Edition) describes Lean as "an approach that emphasizes delivering value to
the customer by removing non-value-adding activities from the software process."
Think of it like cooking a meal efficiently: you use only what’s needed (resources), skip unnecessary steps
(waste), and adjust based on taste (feedback) to serve a great dish (software) fast.
Example: For a library app, Lean delivers “Borrow Book” quickly by cutting unused features and refining
based on user needs.

Purpose of Lean Software Development

Lean serves several key purposes:
• Maximize Value: Focuses on what customers need (e.g., “Search Book” over “fancy UI”).
• Minimize Waste: Reduces effort on non-essential tasks (e.g., excess docs).
• Speed Delivery: Gets software to users faster (e.g., “RSVP in days”).
• Improve Quality: Builds right the first time (e.g., fewer bugs).
• Adapt Continuously: Evolves with feedback (e.g., “add reminders”).
Example: A student portal uses Lean to deliver “View Grades” fast, skipping low-priority “themes.”

Principles of Lean Software Development

Lean is guided by seven core principles (Poppendieck):
1. Eliminate Waste:
o Remove anything not adding value (e.g., unused code, waiting time).
2. Amplify Learning:
o Use feedback and iteration to improve (e.g., test “Search” early).
3. Decide as Late as Possible:
o Delay decisions until necessary (e.g., finalize UI after feedback).
4. Deliver as Fast as Possible:
o Release small, valuable increments (e.g., “Borrow” now, “Return” later).
5. Empower the Team:
o Let developers make decisions (e.g., “fix bug now”).
6. Build Integrity In:
o Ensure quality from the start (e.g., TDD for “RSVP”).
7. Optimize the Whole:
o Focus on system-wide efficiency (e.g., dev-test-deploy flow).
Example: A game eliminates “extra levels” (waste), delivers “Level 1” fast, and refines based on playtests.

Types of Waste in Software Development

Lean identifies seven wastes (adapted from manufacturing):
1. Partially Done Work: Incomplete features (e.g., half-coded “Search”).
2. Extra Features: Unused functionality (e.g., “fancy animations”).
3. Relearning: Redoing forgotten work (e.g., no docs for “Borrow”).
4. Handoffs: Delays passing tasks (e.g., dev to test lag).
5. Task Switching: Multitasking slows progress (e.g., juggling “RSVP” and “Cancel”).
6. Delays: Waiting (e.g., “waiting for server setup”).
7. Defects: Bugs requiring rework (e.g., “RSVP crashes”).
Example: Lean cuts “unused stats page” from an event app, focusing on “View Events.”
How Lean Works
The process is continuous and value-driven:
1. Identify Value:
o Define what users want (e.g., “RSVP Event”).
2. Map Value Stream:
o Chart steps (e.g., design → code → test → deploy).
3. Eliminate Waste:
o Remove non-value steps (e.g., skip heavy docs).
4. Create Flow:
o Ensure smooth task movement (e.g., quick code-to-test).
5. Pull Work:
o Start tasks as needed (e.g., “test when code’s ready”).
6. Pursue Perfection:
o Iterate and improve (e.g., “faster RSVP next time”).
Tools: Kanban boards, value stream mapping, lightweight docs.

Example: Lean for a Library App

• Value: “Borrow Book” is top user need.
• Value Stream:
o Design (1 day) → Code (2 days) → Test (1 day) → Deploy (1 day).
• Waste Eliminated:
o Skip “detailed UML” (extra process), use simple sketch.
o Avoid “Reserve Book” until requested (extra feature).
• Code:
python
CollapseWrapCopy
class Library:
def borrowBook(self, bookID, userID):
if self.books[bookID].available:
self.books[bookID].available = False
return True
return False
• Flow: Delivered in 5 days, tested early, feedback: “Add confirmation”—next iteration.

Practical Example for BSIT Students

Imagine building a campus event app with Lean:
• Value: “View Events” is priority.
• Value Stream:
o Code (2 days) → Test (1 day) → Deploy (1 day).
• Waste Removed:
o Skip “event stats” (unneeded now).
o Avoid “waiting for full design”—start coding with wireframe.
• Code:
python
CollapseWrapCopy
class EventManager:
def viewEvents(self):
return [event.title for event in self.events]
• Flow: Delivered in 4 days.
• Feedback: “Add dates”—next cycle adds in 2 days.
Scenario: “Notifications” requested—prioritized over “Cancel RSVP” based on value.

Benefits of Lean Software Development

• Speed: Fast delivery (e.g., “View” in days).
• Efficiency: Less waste (e.g., no unused features).
• Quality: Early focus reduces defects (e.g., “Borrow” works first try).
Example: A game’s Lean delivers “Shoot” fast, skipping “unused skins.”

Real-World Example
• Success: Toyota’s lean principles inspired Dropbox to streamline features, focusing on core file
sync.
• Contrast: Waterfall’s heavy planning delayed the 1990s NHS IT system.

Key Takeaways
• Lean maximizes value, minimizes waste in software development.
• It uses seven principles like “eliminate waste” and “deliver fast.”
• Examples like event apps and Dropbox show its efficiency role.

Topic 46: DevOps Basics

The forty-sixth topic in the Software Engineering course introduces DevOps Basics, a cultural and
technical movement that bridges development (Dev) and operations (Ops) to improve collaboration,
automate processes, and accelerate software delivery. Below, I’ll explain DevOps in detail, including its
definition, purpose, principles, practices, and examples tailored for BSIT students.

What is DevOps?
DevOps is a set of practices, tools, and a cultural philosophy that integrates software development and IT
operations to deliver high-quality software faster and more reliably. It emphasizes automation,
continuous delivery, and collaboration across teams. Ian Sommerville (Software Engineering, 10th
Edition) describes DevOps as "an approach that integrates development and operations activities,
focusing on automation and continuous deployment to reduce delivery times."
Think of it like a well-coordinated kitchen: chefs (developers) and servers (operations) work together
seamlessly, using automated tools (e.g., ovens) to cook (build) and serve (deploy) meals (software)
quickly.
Example: For a library app, DevOps ensures “Borrow Book” is coded, tested, and deployed to users in
hours, not weeks, with minimal manual effort.

Purpose of DevOps
DevOps serves several key purposes:
• Speed Delivery: Reduces time from code to production (e.g., “RSVP Event” live fast).
• Improve Quality: Automates testing and monitoring (e.g., fewer bugs).
• Enhance Collaboration: Breaks silos between Dev and Ops (e.g., “We deploy together”).
• Increase Reliability: Ensures stable releases (e.g., “no downtime”).
• Enable Scalability: Supports growth (e.g., “handle 1,000 users”).
Example: A student portal uses DevOps to deploy “View Grades” updates daily with zero crashes.

Principles of DevOps
DevOps is guided by the CALMS framework:
1. Culture:
o Foster collaboration and shared responsibility (e.g., “Dev and Ops own quality”).
2. Automation:
o Automate repetitive tasks (e.g., testing, deployment).
3. Lean:
o Minimize waste, optimize flow (e.g., “skip manual checks”).
4. Measurement:
o Track performance (e.g., “deployment time,” “error rate”).
5. Sharing:
o Share tools, knowledge (e.g., “Ops teaches Dev about servers”).
Example: A game’s DevOps culture ensures “Shoot” is auto-tested and deployed, with metrics on lag.

Key DevOps Practices

DevOps relies on these practices:
1. Continuous Integration (CI):
o Developers merge code frequently, auto-tested (e.g., Git commits trigger tests).
2. Continuous Deployment (CD):
o Code auto-deploys to production after passing tests (e.g., “Borrow Book” live instantly).
3. Infrastructure as Code (IaC):
o Manage servers with code (e.g., Docker scripts).
4. Automated Testing:
o Run tests at every stage (e.g., unit, integration).
5. Monitoring and Logging:
o Track app health (e.g., “500 users, no crashes”).
6. Collaboration Tools:
o Use shared platforms (e.g., Slack, Jira).

DevOps Tools
• CI/CD: Jenkins, GitLab CI, CircleCI.
• Version Control: Git, GitHub, Bitbucket.
• IaC: Docker, Kubernetes, Terraform.
• Testing: Selenium, JUnit.
• Monitoring: Prometheus, Grafana, ELK Stack.
• Collaboration: Slack, Microsoft Teams.
Example: A library app uses Git for code, Jenkins for CI/CD, and Docker for deployment.

How DevOps Works

The process forms a pipeline:
1. Plan:
o Define features (e.g., “Search Book” in Jira).
2. Code:
o Write and commit (e.g., git push).
3. Build:
o Compile/test automatically (e.g., Jenkins runs unittest).
4. Test:
o Run automated tests (e.g., “Search works”).
5. Deploy:
o Push to production (e.g., Docker container live).
6. Monitor:
o Check performance (e.g., “1s response time”).
7. Feedback:
o Adjust based on data (e.g., “fix slow search”).

Example: DevOps for a Library App

• Pipeline:
o Code: “Search Book” committed:
python
CollapseWrapCopy
class Library:
def searchBook(self, title):
return [book for book in self.books.values() if title in book.title]
• CI: Jenkins builds, runs tests:
python
CollapseWrapCopy
def test_searchBook(self):
self.assertEqual(len(library.searchBook("CS")), 1)
• CD: Deploys to AWS via Docker.
• Monitor: Grafana tracks “search time < 2s.”
• Result: “Search Book” live in 1 day, no manual steps.

Practical Example for BSIT Students

Imagine a campus event app with DevOps:
• Tools: GitHub, GitHub Actions (CI/CD), Docker.
• Pipeline:
o Code: “RSVP Event”:
python
CollapseWrapCopy
class Event:
 def register(self, studentID):
if len(self.registrations) < self.capacity:
self.registrations.append(studentID)
return True
return False
• CI: GitHub Actions runs:
yaml
CollapseWrapCopy
name: CI
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: python -m unittest test_event.py
• CD: Deploys to a student server via Docker.
• Monitor: Logs show “100 RSVPs, no errors.”
• Feedback: “Slow RSVP”—team optimizes database.
Scenario: “Cancel RSVP” added—pipeline auto-updates it.

Benefits of DevOps
• Speed: Fast releases (e.g., “RSVP” in hours).
• Reliability: Fewer failures (e.g., “auto-tested”).
• Collaboration: Team unity (e.g., “Dev fixes Ops issue”).
Example: A game’s DevOps deploys “Level 1” daily with no downtime.

Real-World Example
• Success: Netflix uses DevOps for CI/CD, streaming updates seamlessly.
• Contrast: Traditional silos delayed the 2000s FBI Virtual Case File.

Key Takeaways
• DevOps integrates Dev and Ops for fast, reliable delivery.
• It uses CI/CD, IaC, and monitoring.
• Examples like event apps and Netflix show its automation role.

Topic 45: Software Process Improvement

The forty-fifth topic in the Software Engineering course introduces Software Process Improvement (SPI),
a systematic approach to enhancing the efficiency, effectiveness, and quality of software development
processes. Below, I’ll explain SPI in detail, including its definition, purpose, principles, frameworks, and
examples tailored for BSIT students.

What is Software Process Improvement?

Software Process Improvement (SPI) is the practice of analyzing, refining, and optimizing the processes
used to develop software to achieve better outcomes, such as higher quality, reduced costs, or faster
delivery. Ian Sommerville (Software Engineering, 10th Edition) defines SPI as "a set of activities aimed at
improving the software process by identifying weaknesses and implementing changes to address them."
Think of it like tuning a car engine: you assess how it runs (current process), tweak the parts (practices),
and test the performance (outcomes) to make it faster and more reliable (improved software
development).
Example: For a library app, SPI might streamline the testing process to catch “Borrow Book” bugs earlier,
reducing rework.

Purpose of Software Process Improvement

SPI serves several key purposes:
• Enhance Quality: Improves software reliability and usability (e.g., fewer defects).
• Increase Efficiency: Reduces wasted effort and time (e.g., faster releases).
• Reduce Costs: Lowers expenses by fixing inefficiencies (e.g., less debugging).
• Meet Goals: Aligns processes with project objectives (e.g., “on-time delivery”).
• Adapt to Change: Prepares teams for new challenges (e.g., scaling up).
Example: A student portal’s SPI ensures “Calculate GPA” is developed faster with fewer errors.

Principles of Software Process Improvement

Effective SPI follows these principles:
1. Assessment-Driven: Base improvements on data (e.g., “high bug rate”).
2. Incremental: Make small, manageable changes (e.g., “add code reviews”).
3. Goal-Oriented: Target specific outcomes (e.g., “cut delays by 20%”).
4. Participatory: Involve the team for buy-in (e.g., “developers suggest fixes”).
5. Continuous: Improve ongoing, not one-time (e.g., “review every project”).
Example: A game’s SPI incrementally adds testing to reduce “MovePlayer” crashes.

SPI Frameworks and Models

Several models guide SPI:
1. Capability Maturity Model Integration (CMMI):
o Structure: 5 maturity levels:
▪ 1: Initial (chaotic).
▪ 2: Managed (basic processes).
▪ 3: Defined (standardized).
▪ 4: Quantitatively Managed (measured).
▪ 5: Optimizing (continuous improvement).
o Example: Library app moves from Level 1 (ad-hoc) to Level 2 (planned testing).
o Pros: Comprehensive, structured.
o Cons: Complex, resource-heavy.
2. ISO/IEC 15504 (SPICE):
o Structure: Assesses process capability (0-5 scale) across areas (e.g., coding, testing).
o Example: Event app improves “design” from 1 (incomplete) to 3 (consistent).
o Pros: Flexible, international standard.
 o Cons: Needs expertise.
3. Six Sigma:
o Structure: Reduces defects using DMAIC (Define, Measure, Analyze, Improve, Control).
o Example: Game uses Six Sigma to cut “Shoot” bugs by 50%.
o Pros: Data-driven, quality-focused.
o Cons: Statistical complexity.
4. Plan-Do-Check-Act (PDCA):
o Structure: Iterative cycle (Plan change, Do it, Check results, Act to refine).
o Example: Student portal tests “more reviews,” adjusts based on bug reduction.
o Pros: Simple, adaptable.
o Cons: Less formal.

How to Perform Software Process Improvement

The process involves these steps:
1. Assess Current Process:
o Collect data (e.g., “bugs found late,” “delays in testing”).
2. Define Goals:
o Set targets (e.g., “reduce defects by 30%”).
3. Analyze Weaknesses:
o Identify issues (e.g., “no unit tests”).
4. Plan Improvements:
o Propose changes (e.g., “add TDD”).
5. Implement Changes:
o Apply fixes (e.g., train team on testing).
6. Measure Results:
o Check metrics (e.g., “bugs down 25%”).
7. Standardize and Repeat:
o Lock in gains, improve again (e.g., “next: speed up builds”).

Example: SPI for a Library App

• Assessment: “Borrow Book” has 5 bugs found post-release, testing takes 3 days.
• Goal: Cut defects by 50%, speed testing to 1 day.
• Analysis: No early testing, manual checks slow.
• Plan: Add unit tests, automate testing.
• Implementation:
python
CollapseWrapCopy
def test_borrowBook(self):
library = Library()
library.books["123"] = Book("123", "CS101")
self.assertTrue(library.borrowBook("123", "S001"))
• Result: Bugs drop to 2, testing takes 1 day.
• Standardize: Unit tests mandatory for all features.
Practical Example for BSIT Students
Imagine improving an event app process:
• Assessment: “RSVP Event” takes 5 days, 3 bugs found late.
• Goal: Reduce cycle time to 3 days, bugs to 1.
• Analysis: No testing until end, unclear requirements.
• Plan (PDCA):
o Plan: Add daily tests, clarify user stories.
o Do: Test “register()” early:
python
CollapseWrapCopy
def test_register(self):
event = Event(1, "Hackathon", 2)
self.assertTrue(event.register("S001"))
• Check: Cycle time=3 days, 1 bug.
• Act: Standardize early testing.
• Result: Faster, cleaner “RSVP.”
Scenario: “Slow deploy” next—plan automation.

Benefits of Software Process Improvement

• Quality: Fewer bugs (e.g., “RSVP works first try”).
• Efficiency: Faster delivery (e.g., “3 days vs. 5”).
• Cost Savings: Less rework (e.g., “fix early”).
Example: A game’s SPI cuts “Shoot” debug time by 20%.

Real-World Example
• Success: Microsoft used CMMI to improve Windows reliability.
• Failure: The 1990s Denver Airport system ignored SPI, causing inefficiencies.

Key Takeaways
• SPI enhances software processes for better outcomes.
• It uses frameworks like CMMI, SPICE, and PDCA.
• Examples like event apps and Microsoft show its refinement role.

Topic 48: Software Security Basics

The forty-eighth topic in the Software Engineering course introduces Software Security Basics, focusing
on protecting software systems from threats and vulnerabilities to ensure they operate safely and
reliably. Below, I’ll explain software security in detail, including its definition, purpose, principles,
common threats, and examples tailored for BSIT students.

What is Software Security?

Software security refers to the measures, techniques, and practices used to protect software applications
from unauthorized access, use, disclosure, alteration, or destruction. It aims to ensure confidentiality,
integrity, and availability (the CIA triad). Ian Sommerville (Software Engineering, 10th Edition) defines
software security as "the protection of a software system and its data from malicious threats, ensuring it
performs its intended functions without compromise."
Think of it like securing a house: you lock doors (access control), install alarms (detection), and reinforce
windows (vulnerability fixes) to keep intruders (threats) out and valuables (data) safe.
Example: For a library app, security ensures “Borrow Book” isn’t hacked to steal user data or bypass
limits.

Purpose of Software Security

Software security serves several key purposes:
• Protect Data: Safeguards sensitive information (e.g., student IDs).
• Ensure Functionality: Prevents malicious interference (e.g., “RSVP works”).
• Maintain Trust: Builds user confidence (e.g., “app is safe”).
• Comply with Regulations: Meets legal standards (e.g., GDPR).
• Reduce Risks: Minimizes financial and reputational damage from breaches.
Example: A student portal secures “View Grades” to prevent grade tampering.

Principles of Software Security

Effective security follows these principles:
1. Least Privilege: Grant minimal access (e.g., “users can’t edit others’ data”).
2. Defense in Depth: Use multiple layers (e.g., encryption + authentication).
3. Fail Securely: Errors don’t expose vulnerabilities (e.g., “login fails safely”).
4. Secure by Design: Build security in from the start (e.g., “encrypt early”).
5. Keep It Simple: Avoid complexity that hides flaws (e.g., “simple auth”).
Example: A game’s “Score” system limits access and encrypts data to prevent cheating.

Common Security Threats

Software faces these typical threats:
1. Injection Attacks:
o Malicious input (e.g., SQL injection: SELECT * WHERE id='1; DROP TABLE users').
o Impact: Data loss, unauthorized access.
2. Cross-Site Scripting (XSS):
o Injects scripts into web pages (e.g., <script>stealCookie()</script>).
o Impact: Steals user data.
3. Authentication Bypass:
o Weak login systems (e.g., no password hashing).
o Impact: Unauthorized entry.
4. Data Exposure:
o Unencrypted data (e.g., plain-text student IDs).
o Impact: Privacy breach.
5. Denial of Service (DoS):
o Overloads system (e.g., flood “RSVP” with requests).
o Impact: Downtime.
Example: A library app risks SQL injection in “Search Book” if inputs aren’t sanitized.
Security Practices
Key practices to enhance security:
1. Input Validation:
o Check all inputs (e.g., “bookID is numeric”).
2. Authentication:
o Use strong passwords, multi-factor auth (e.g., “password + SMS”).
3. Authorization:
o Restrict access (e.g., “only admins add books”).
4. Encryption:
o Protect data (e.g., AES for user IDs).
5. Secure Coding:
o Follow guidelines (e.g., OWASP Top 10).
6. Testing:
o Penetration tests, vulnerability scans (e.g., “try hacking RSVP”).
7. Monitoring:
o Log suspicious activity (e.g., “10 failed logins”).

Tools for Software Security

• Static Analysis: SonarQube (code flaws).
• Dynamic Testing: Burp Suite (web vulnerabilities).
• Encryption: OpenSSL, bcrypt (passwords).
• Monitoring: Splunk, ELK Stack.
• Frameworks: OWASP guidelines.
Example: A library app uses OWASP to secure “Borrow Book.”

How to Implement Software Security

The process involves these steps:
1. Identify Assets:
o What to protect (e.g., “user data”).
2. Assess Threats:
o List risks (e.g., “SQL injection”).
3. Design Security:
o Plan controls (e.g., “sanitize inputs”).
4. Implement:
o Code securely (e.g., hash passwords).
5. Test:
o Verify (e.g., “can’t inject code”).
6. Monitor:
o Watch for breaches (e.g., “log failed attempts”).
7. Update:
o Fix vulnerabilities (e.g., “patch library”).

Example: Securing a Library App

• Threat: SQL injection in “Search Book.”
 • Unsecure Code:
python
CollapseWrapCopy
query = f"SELECT * FROM books WHERE title LIKE '%{user_input}%'"
• Secure Code:
python
CollapseWrapCopy
import sqlite3
conn = sqlite3.connect("library.db")
cursor = conn.cursor()
cursor.execute("SELECT * FROM books WHERE title LIKE ?", ('%' + user_input + '%',))
results = cursor.fetchall()
• Practice: Parameterized query prevents injection.
• Test: Try '; DROP TABLE books;'—fails safely.

Practical Example for BSIT Students

Imagine securing a campus event app:
• Asset: Student IDs in “RSVP Event.”
• Threat: Data exposure.
• Unsecure:
python
CollapseWrapCopy
class Event:
def register(self, studentID):
self.registrations.append(studentID) # Plain text
• Secure:
python
CollapseWrapCopy
import hashlib
class Event:
def register(self, studentID):
hashed_id = hashlib.sha256(studentID.encode()).hexdigest()
self.registrations.append(hashed_id)
• Test: Check IDs are hashed, not readable.
• Monitor: Log “too many RSVP attempts.”
Scenario: XSS risk in UI—add input sanitization.

Benefits of Software Security

• Safety: Protects users (e.g., “no data leaks”).
• Trust: Retains confidence (e.g., “app is secure”).
• Compliance: Meets standards (e.g., “GDPR-ready”).
Example: A game’s security stops “score hacks,” keeping players happy.

Real-World Example
 • Success: Google secures Android with encryption and updates.
• Failure: Equifax 2017 breach from unpatched software.

Key Takeaways
• Software security protects against threats like injection and XSS.
• It uses practices like encryption and validation.
• Examples like event apps and Google show its protective role.

Topic 49: Software Reengineering

The forty-ninth topic in the Software Engineering course introduces Software Reengineering, a process
focused on improving and modernizing existing software systems without necessarily building them from
scratch. Below, I’ll explain software reengineering in detail, including its definition, purpose, principles,
process, and examples tailored for BSIT students.

What is Software Reengineering?

Software reengineering is the examination, restructuring, and enhancement of an existing software
system to improve its quality, maintainability, performance, or adaptability while preserving its core
functionality. Ian Sommerville (Software Engineering, 10th Edition) defines reengineering as "the process
of restructuring and improving legacy software systems to make them more maintainable and adaptable
to new requirements."
Think of it like renovating an old house: you keep the foundation (core functionality), update the wiring
(code structure), and add modern features (new capabilities) instead of tearing it down and rebuilding.
Example: For a library app, reengineering might modernize an old “Borrow Book” system written in
COBOL to Python, improving readability and adding a web interface.

Purpose of Software Reengineering

Software reengineering serves several key purposes:
• Improve Maintainability: Makes code easier to update (e.g., “fix bugs faster”).
• Enhance Performance: Optimizes slow systems (e.g., “speed up search”).
• Adapt to Change: Updates for new tech (e.g., “mobile support”).
• Reduce Technical Debt: Cleans up messy code (e.g., “remove hacks”).
• Extend Lifespan: Avoids full replacement (e.g., “keep legacy alive”).
Example: A student portal’s old “View Grades” system is reengineered to use a modern database, cutting
load times.

Principles of Software Reengineering

Effective reengineering follows these principles:
1. Preserve Functionality: Core behavior stays intact (e.g., “Borrow still works”).
2. Incremental Approach: Change step-by-step (e.g., “refactor one module”).
3. Understand First: Analyze existing system before altering (e.g., “map old code”).
4. Test Thoroughly: Ensure no regressions (e.g., “old tests pass”).
5. Balance Cost: Weigh effort vs. benefits (e.g., “worth modernizing?”).
Example: A game’s “MovePlayer” is reengineered for speed, keeping movement logic the same.
Types of Software Reengineering
Reengineering activities vary by goal:
1. Code Restructuring:
o Reorganize code without changing behavior (e.g., “split big function”).
2. Refactoring:
o Improve code readability/maintainability (e.g., “rename variables”).
3. Reverse Engineering:
o Analyze code to understand it (e.g., “document legacy app”).
4. Forward Engineering:
o Rebuild with modern tech (e.g., “COBOL to Java”).
5. Data Reengineering:
o Update data structures (e.g., “flat file to SQL”).
Example: A library app’s “Search Book” is refactored for clarity, then forward-engineered to a web
service.

Software Reengineering Process

The process involves these steps:
1. Assessment:
o Evaluate system (e.g., “slow, outdated UI”).
2. Reverse Engineering:
o Extract design/info (e.g., “map Borrow logic”).
3. Planning:
o Define goals, scope (e.g., “modernize UI, keep logic”).
4. Restructuring/Refactoring:
o Clean code (e.g., “split Search into functions”).
5. Reimplementation:
o Update tech (e.g., “Python instead of C++”).
6. Testing:
o Verify functionality (e.g., “Search still finds books”).
7. Deployment:
o Roll out changes (e.g., “new app live”).

Example: Reengineering a Library App

• Old System: C-based, console app, slow “Borrow Book.”
• Assessment: Poorly structured, no database.
• Reverse Engineering: Document logic:
c
CollapseWrapCopy
int borrow(char* bookID) {
if (books[bookID].avail) {
books[bookID].avail = 0;
return 1;
}
return 0;
}
• Refactoring: Split into functions, improve names.
• Reimplementation:
python
CollapseWrapCopy
class Library:
def borrowBook(self, bookID):
if bookID in self.books and self.books[bookID].available:
self.books[bookID].available = False
return True
return False
• Testing: Old tests pass (e.g., “borrow succeeds”).
• Result: Faster, maintainable, database-ready.

Practical Example for BSIT Students

Imagine reengineering a campus event app:
• Old System: PHP, monolithic, slow “RSVP Event.”
• Assessment: Hard to update, no mobile support.
• Reverse Engineering: Map logic:
php
CollapseWrapCopy
function rsvp($eventID, $studentID) {
global $events;
if ($events[$eventID]['slots'] > 0) {
$events[$eventID]['slots']--;
return true;
}
return false;
}
• Refactoring: Break into classes:
python
CollapseWrapCopy
class Event:
def register(self, studentID):
if self.slots > 0:
self.slots -= 1
self.registrations.append(studentID)
return True
return False
• Reimplementation: Python + Flask for web/mobile.
• Testing: “RSVP works, slots decrease.”
• Result: Modular, mobile-ready.
Scenario: Add “Cancel RSVP”—easier with new structure.
Tools for Software Reengineering
• Reverse Engineering: Understand (code analysis), IDA Pro.
• Refactoring: PyCharm, Eclipse (auto-refactor).
• Testing: JUnit, pytest (regression tests).
• Version Control: Git (track changes).
Example: Event app uses PyCharm to refactor “RSVP.”

Benefits of Software Reengineering

• Maintainability: Easier updates (e.g., “add features”).
• Performance: Faster execution (e.g., “quick RSVP”).
• Cost Savings: Extends life vs. rewrite (e.g., “no new app”).
Example: A game’s “Shoot” is reengineered for speed, avoiding a full redo.

Real-World Example
• Success: IBM reengineered mainframe software for modern banking.
• Failure: The 2000s NHS IT ignored reengineering, scrapping a workable system.

Key Takeaways
• Reengineering improves legacy software without full replacement.
• It includes restructuring, refactoring, and reimplementation.
• Examples like event apps and IBM show its modernization role.

Topic 27: Domain Model: Identifying Business Classes

What is It?
A domain model is a conceptual representation of the key entities (business classes) in a problem
domain, focusing on real-world objects and their relationships, not software design. Identifying business
classes is the first step, finding nouns in requirements or use cases that represent significant entities. Ian
Sommerville (Software Engineering, 10th Edition) notes that domain modeling "helps understand the
problem domain by identifying key concepts and their interactions."
Example: For a library app, business classes might be “Book,” “User,” and “Loan.”
Purpose
• Understand the domain (e.g., “what’s a library?”).
• Define core entities for later design (e.g., “Book” becomes a class).
• Bridge requirements to software.
How to Identify Business Classes
1. Analyze Requirements:
o Extract nouns from use cases (e.g., “User borrows Book” → User, Book).
2. Filter:
o Keep significant entities (e.g., “Book”), discard vague ones (e.g., “System”).
3. Categorize:
o Tangible (e.g., “Book”), Roles (e.g., “User”), Events (e.g., “Loan”).
Example
• Use Case: “A User borrows a Book from the Library.”
• Classes: User, Book, Library, Loan (event of borrowing).
Topic 28: Domain Model Associations
What is It?
Domain model associations define the relationships between business classes, showing how they
interact in the problem domain. These are conceptual links, not implementation details, often
represented in UML with lines and multiplicity.
Example: In a library app, “User borrows Book” is a one-to-many association.
Purpose
• Clarify interactions (e.g., “Users have Loans”).
• Establish structure for design (e.g., “link User to Loan”).
• Guide navigation (e.g., “find User’s Books”).
How to Define Associations
1. Identify Relationships:
o From use cases (e.g., “User borrows Book”).
2. Name Them:
o Use verb phrases (e.g., “borrows,” “contains”).
3. Specify Multiplicity:
o 1-1, 1-*, -, etc. (e.g., “1 User borrows * Books”).
4. Draw UML:
o Lines between classes (e.g., User —borrows—> Book).
Example
• Classes: User, Book, Loan.
• Associations:
o “User borrows Book” (1 to *).
o “Loan involves Book” (1 to 1).
o “User has Loan” (1 to *).
UML:
text
CollapseWrapCopy
User ---1---->*--- Loan ---1---->1--- Book

Topic 29: Domain Model Attributes

What is It?
Domain model attributes are the properties or data elements of business classes that describe their
characteristics in the problem domain. They’re identified after classes and associations, focusing on
essential data.
Example: For a library app, “Book” has attributes like “title” and “ISBN.”
Purpose
• Detail classes (e.g., “what’s a Book?”).
• Support functionality (e.g., “search by title”).
• Prepare for implementation (e.g., “database fields”).
How to Identify Attributes
1. Analyze Requirements:
o Look for descriptive nouns (e.g., “Book has a title”).
 2. Keep Simple:
o Basic types (e.g., string, int), no complex objects.
3. Assign to Classes:
o Match to owning class (e.g., “title” to Book).
4. Add to UML:
o List under class name (e.g., “Book: -title: String”).
Example
• Classes: User, Book, Loan.
• Attributes:
o User: name (String), ID (String).
o Book: title (String), ISBN (String), available (Boolean).
o Loan: loanID (Int), date (Date).
UML:
text
CollapseWrapCopy
+---------+ +---------+ +---------+
| User | | Loan | | Book |
|---------|1 *|---------|1 1|---------|
| -name |<---->| -loanID |----->| -title |
| -ID | | -date | | -ISBN |
+---------+ +---------+ | -available |
+---------+

Updated Sequence Recap

• Topic 27: Domain Model: Identifying Business Classes (above)
• Topic 28: Domain Model Associations (above)
• Topic 29: Domain Model Attributes (above)
• Topic 30: Class-Based Modeling (previously covered)
• … (shifts continue)
• Topic 49: Software Reengineering (covered)
• Topic 52: Software Reuse (next, adjusted to 52)
Since you’ve requested “next” after catching the missed topics, we’ll now proceed to Topic 50 (now 53):
Software Reuse.

Topic 53: Software Reuse

What is Software Reuse?
Software reuse is the practice of using existing software components, code, or artifacts (e.g., libraries,
frameworks, patterns) in new projects to save time, reduce costs, and improve quality. Ian Sommerville
(Software Engineering, 10th Edition) defines it as "the process of using existing software assets in the
development of new systems rather than building everything from scratch."
Think of it like using LEGO bricks: instead of crafting each piece (code), you grab pre-made ones
(libraries) to build faster and stronger.
Example: A library app reuses a “database connector” library instead of writing one.
Purpose
 • Save Time: Faster development (e.g., “use existing login”).
• Reduce Costs: Less effort (e.g., “no new code”).
• Improve Quality: Leverages tested components (e.g., “bug-free library”).
• Standardize: Consistency across projects (e.g., “same UI kit”).
Types of Reuse
1. Code Reuse:
o Functions, classes (e.g., “reuse sort function”).
2. Component Reuse:
o Libraries, modules (e.g., “NumPy for math”).
3. Pattern Reuse:
o Design patterns (e.g., “Singleton for config”).
4. Framework Reuse:
o Full platforms (e.g., “Django for web”).
5. Product Line Reuse:
o Assets across similar apps (e.g., “library + bookstore”).
How to Implement Software Reuse
1. Identify Reusable Assets:
o Find existing code (e.g., “old login module”).
2. Evaluate Suitability:
o Check fit (e.g., “works with Python?”).
3. Adapt if Needed:
o Modify (e.g., “tweak UI component”).
4. Integrate:
o Add to project (e.g., “import library”).
5. Test:
o Verify (e.g., “login still secure”).
6. Document:
o Note usage (e.g., “uses Flask v2”).
Example: Reuse in a Library App
• Asset: Python’s sqlite3 library.
• Code:
python
CollapseWrapCopy
import sqlite3
class Library:
def __init__(self):
self.conn = sqlite3.connect("library.db")
def searchBook(self, title):
cursor = self.conn.cursor()
cursor.execute("SELECT title FROM books WHERE title LIKE ?", ('%' + title + '%',))
return cursor.fetchall()
• Result: Reuses sqlite3 for database access, saving custom DB code.
Practical Example for BSIT Students
Imagine an event app:
 • Asset: Flask framework.
• Code:
python
CollapseWrapCopy
from flask import Flask, jsonify
app = Flask(__name__)

events = [{"id": 1, "title": "Hackathon"}]

@app.route('/events', methods=['GET'])
def viewEvents():
return jsonify(events)
• Reuse: Flask handles web routing, avoiding custom server code.
• Test: “GET /events” returns list—works.
Benefits
• Efficiency: Faster builds (e.g., “web in hours”).
• Reliability: Proven components (e.g., “Flask is stable”).
• Focus: Work on unique features (e.g., “event logic”).
Real-World Example
• Success: Android reuses Java libraries for apps.
• Failure: Custom everything delayed early 2000s projects.
Key Takeaways
• Software reuse leverages existing assets.
• It includes code, components, and frameworks.
• Examples like event apps and Android show its efficiency role.

Topic 54: Emerging Trends in Software Engineering

The fifty-fourth topic in the Software Engineering course introduces Emerging Trends in Software
Engineering, focusing on the latest advancements, technologies, and practices shaping the future of
software development. Below, I’ll explain these trends in detail, including their definitions, significance,
examples, and relevance for BSIT students.

What are Emerging Trends in Software Engineering?

Emerging trends in software engineering are innovative technologies, methodologies, and paradigms
that are gaining traction and transforming how software is designed, developed, deployed, and
maintained. These trends reflect the industry’s response to evolving user needs, technological
breakthroughs, and market demands. Ian Sommerville (Software Engineering, 10th Edition) notes that
"software engineering continuously evolves to incorporate new tools and techniques that improve
productivity and system capabilities."
Think of it like fashion in tech: new styles (trends) emerge, blending old techniques (e.g., Agile) with
cutting-edge tools (e.g., AI) to create something fresh and functional (modern software).
Example: For a library app, trends like AI might suggest books, while cloud-native design ensures
scalability.

Purpose of Studying Emerging Trends

 • Stay Relevant: Prepares students for industry shifts (e.g., “learn AI now”).
• Boost Innovation: Inspires new solutions (e.g., “blockchain for loans”).
• Enhance Skills: Builds future-ready expertise (e.g., “master DevOps”).
• Meet Demands: Addresses user expectations (e.g., “faster, smarter apps”).

Key Emerging Trends

Here are some prominent trends as of March 6, 2025:
1. Artificial Intelligence (AI) and Machine Learning (ML) in Software:
o What: AI/ML automates tasks, predicts outcomes, and enhances apps.
o Example: Library app uses ML to recommend books based on borrowing history.
o Tools: TensorFlow, PyTorch.
o Impact: Smarter apps, less manual coding (e.g., “AI writes tests”).
2. Cloud-Native Development:
o What: Building apps for cloud environments using microservices, containers, and
orchestration.
o Example: Event app runs on AWS with Docker, scaling for 1,000 users.
o Tools: Kubernetes, Docker, AWS.
o Impact: Scalable, resilient systems (e.g., “no downtime”).
3. Low-Code/No-Code Platforms:
o What: Drag-and-drop tools for non-coders to build apps.
o Example: Student builds “RSVP Event” UI in Bubble without coding.
o Tools: OutSystems, Mendix, Bubble.
o Impact: Faster prototyping, broader participation (e.g., “anyone can contribute”).
4. DevSecOps (Security in DevOps):
o What: Integrates security into DevOps pipelines from the start.
o Example: Library app auto-scans “Borrow Book” for vulnerabilities.
o Tools: Snyk, OWASP ZAP.
o Impact: Secure-by-default software (e.g., “no leaks”).
5. Blockchain Beyond Crypto:
o What: Decentralized, secure data management for trust and transparency.
o Example: Library app tracks “Book Loans” on a blockchain ledger.
o Tools: Ethereum, Hyperledger.
o Impact: Tamper-proof records (e.g., “verify borrowing”).
6. Quantum Computing (Early Stage):
o What: Leverages quantum mechanics for ultra-fast computation.
o Example: Optimize “Search Book” across millions of records (future potential).
o Tools: Qiskit, Microsoft Q#.
o Impact: Solves complex problems (e.g., “faster algorithms”).
7. Serverless Architecture:
o What: Runs code without managing servers, auto-scaling on demand.
o Example: “RSVP Event” uses AWS Lambda, pays per use.
o Tools: AWS Lambda, Google Cloud Functions.
o Impact: Cost-efficient, low maintenance (e.g., “no server upkeep”).
8. Progressive Web Apps (PWAs):
 o What: Web apps with native-like features (offline, push notifications).
o Example: Library app works offline via PWA.
o Tools: React, Service Workers.
o Impact: Cross-platform reach (e.g., “web + mobile”).

How to Leverage These Trends

1. Learn Basics:
o Start with tools (e.g., “try Docker”).
2. Experiment:
o Build small projects (e.g., “AI chatbot”).
3. Integrate:
o Add to workflows (e.g., “DevSecOps in CI/CD”).
4. Stay Updated:
o Follow blogs, X posts (e.g., “quantum news”).
5. Collaborate:
o Join open-source (e.g., “PWA library”).

Example: Trends in a Library App

• AI/ML: Recommends “CS101” based on past loans.
python
CollapseWrapCopy
from sklearn.neighbors import NearestNeighbors
def recommend_book(user_history):
model = NearestNeighbors().fit(book_data)
suggestions = model.kneighbors(user_history)
return suggestions
• Cloud-Native: Runs on Kubernetes, scales for peak borrowing.
• DevSecOps: Scans code for SQL injection in “Search Book.”
• PWA: Offline access to “Borrow Book” status.

Practical Example for BSIT Students

Imagine an event app with trends:
• Serverless: “RSVP Event” on AWS Lambda:
python
CollapseWrapCopy
import json
def lambda_handler(event, context):
studentID = event['studentID']
if register(studentID):
return {'status': 'success'}
return {'status': 'full'}
• Low-Code: UI built in OutSystems, linked to Lambda.
• DevSecOps: GitHub Actions scans for vulnerabilities.
• Result: Fast, secure, student-built app in days.
Scenario: Add blockchain to log RSVPs—experiment with Hyperledger.

Benefits of Emerging Trends

• Innovation: New features (e.g., “AI suggestions”).
• Efficiency: Faster builds (e.g., “serverless”).
• Competitiveness: Stand out (e.g., “PWA skills”).
Example: A game uses cloud-native for “multiplayer,” beating lag.

Real-World Example
• Success: Netflix’s cloud-native, AI-driven recommendations.
• Future: Quantum computing trials at IBM (e.g., optimization).

Key Takeaways
• Emerging trends like AI, cloud-native, and DevSecOps shape software’s future.
• They offer speed, security, and innovation.
• Examples like event apps and Netflix show their transformative role.

Topic 33: Design Class Diagram

What is a Design Class Diagram?
A Design Class Diagram (DCD) is a UML diagram that refines the conceptual domain model into a
detailed blueprint for software implementation, specifying classes, their attributes, methods, and
relationships with implementation-level detail. It bridges analysis (domain model) and coding. Ian
Sommerville (Software Engineering, 10th Edition) notes that "design class diagrams provide a detailed
view of the software structure, ready for implementation."
Example: For a library app, the DCD details “Book” with methods like borrow().
Purpose
• Define software structure (e.g., “classes for Borrow”).
• Specify operations (e.g., “what Book does”).
• Guide coding (e.g., “attributes to variables”).
How to Create a Design Class Diagram
1. Start with Domain Model:
o Use business classes (e.g., User, Book, Loan).
2. Add Visibility:
o Public (+), private (-), protected (#) (e.g., -title).
3. Define Attributes:
o Type them (e.g., title: String).
4. Add Methods:
o Operations from use cases (e.g., +borrow(): Boolean).
5. Refine Associations:
o Navigation, roles (e.g., “User -> Loan”).
6. Draw UML:
o Boxes with sections (attributes, methods).
Example
• Domain Model: User, Book, Loan.
 • DCD:
text
CollapseWrapCopy
+---------+ +---------+ +---------+
| User | | Loan | | Book |
|---------|1 *|---------|1 1|---------|
| -name: String |<-->| -loanID: Int | -title: String |
| -ID: String | | -date: Date | -ISBN: String |
| +borrowBook() | | +create() | -available: Boolean |
+---------+ +---------+ | +borrow(): Boolean |
+---------+

Topic 34: Mapping Design to Code

What is Mapping Design to Code?
Mapping design to code is the process of translating a Design Class Diagram (or other design artifacts)
into executable source code, ensuring the software reflects the design’s structure and behavior. It’s the
handoff from design to implementation.
Example: “Book” class in the DCD becomes a Python class with borrow().
Purpose
• Implement design accurately (e.g., “match UML”).
• Ensure consistency (e.g., “code reflects intent”).
• Enable execution (e.g., “run the app”).
How to Map Design to Code
1. Define Classes:
o Create class skeletons (e.g., class Book).
2. Add Attributes:
o Map with types (e.g., title = "").
3. Implement Methods:
o Code operations (e.g., def borrow(self)).
4. Handle Associations:
o Use references (e.g., self.loans = []).
5. Set Visibility:
o Private with _ or __ (e.g., _title).
6. Test:
o Verify behavior (e.g., “borrow returns True”).
Example
• DCD:
text
CollapseWrapCopy
+---------+
| Book |
|---------|
| -title: String |
| -available: Boolean |
| +borrow(): Boolean |
+---------+
• Code:
python
CollapseWrapCopy
class Book:
def __init__(self, title):
self._title = title
self._available = True

def borrow(self):
if self._available:
self._available = False
return True
return False

Topic 57: Ethics in Software Engineering

What is Ethics in Software Engineering?
Ethics in software engineering involves applying moral principles to the development, deployment, and
use of software, ensuring it benefits society, avoids harm, and respects user rights. It addresses
dilemmas like privacy, fairness, and accountability. Ian Sommerville (Software Engineering, 10th Edition)
emphasizes that "software engineers have a responsibility to consider the ethical implications of their
work."
Example: A library app must protect user data, not sell it.
Purpose
• Protect users (e.g., “no privacy breaches”).
• Ensure fairness (e.g., “no bias in AI”).
• Build trust (e.g., “reliable software”).
• Meet legal standards (e.g., “GDPR compliance”).
Principles (ACM/IEEE Code of Ethics)
1. Public Interest: Prioritize societal good (e.g., “safe apps”).
2. Client and Employer: Balance loyalty with ethics (e.g., “report flaws”).
3. Product: Deliver quality (e.g., “test thoroughly”).
4. Judgment: Be honest, objective (e.g., “no fake deadlines”).
5. Profession: Uphold integrity (e.g., “credit others’ work”).
Ethical Issues
• Privacy: Collecting excess data (e.g., “track user location?”).
• Security: Ignoring vulnerabilities (e.g., “skip encryption?”).
• Bias: Unfair algorithms (e.g., “AI favors some users”).
• Transparency: Hiding limitations (e.g., “app risks unclear”).
Example: Library App
• Issue: “Sell borrowing history?”
• Ethical Choice: Don’t—protects privacy (Principle 1).
• Code: Encrypt data:
python
CollapseWrapCopy
import hashlib
def store_user(self, userID):
hashed_id = hashlib.sha256(userID.encode()).hexdigest()
self.users.append(hashed_id)
Practical Example for BSIT Students
• Scenario: Event app with “RSVP.”
• Issue: “Share student RSVPs publicly?”
• Ethical Choice: No—private by default, consent required.
• Code:
python
CollapseWrapCopy
class Event:
def register(self, studentID, consent=False):
if consent:
self.public_list.append(studentID)
else:
self.private_list.append(studentID)
• Reflection: “Fair, transparent—users control data.”
Benefits
• Trust: Users rely on ethical apps (e.g., “safe RSVP”).
• Reputation: Ethical devs stand out (e.g., “honest team”).
• Compliance: Avoids legal issues (e.g., “GDPR fine dodged”).
Real-World Example
• Success: Apple’s privacy focus (e.g., App Tracking Transparency).
• Failure: Facebook’s Cambridge Analytica breach (data misuse).
Key Takeaways
• Ethics ensures software benefits society responsibly.
• It addresses privacy, security, and fairness.
• Examples like event apps and Apple show its trust-building role.

Topic 58: Software Engineering for Mobile Applications

The fifty-eighth topic in the Software Engineering course introduces Software Engineering for Mobile
Applications, focusing on the unique principles, processes, and tools used to design, develop, and deploy
software for mobile devices like smartphones and tablets. Below, I’ll explain this topic in detail, including
its definition, purpose, challenges, practices, and examples tailored for BSIT students.

What is Software Engineering for Mobile Applications?

Software engineering for mobile applications is the application of software engineering principles to
create applications specifically for mobile platforms (e.g., iOS, Android), addressing their unique
constraints and opportunities, such as limited resources, diverse hardware, and user mobility. Ian
Sommerville (Software Engineering, 10th Edition) notes that "mobile software engineering adapts
traditional practices to the constraints and dynamic environments of mobile devices."
Think of it like designing a compact, efficient car: it needs to run well (perform), fit tight spaces (resource
limits), and adapt to varied roads (devices), all while keeping the driver (user) happy.
Example: A library app for mobile lets users “Borrow Book” on their phone, optimized for small screens
and offline use.

Purpose of Mobile Software Engineering

• User Accessibility: Delivers software anywhere (e.g., “RSVP on the go”).
• Optimize Performance: Fits mobile constraints (e.g., “fast on low RAM”).
• Enhance Experience: Leverages mobile features (e.g., “GPS for events”).
• Meet Market Demand: Targets mobile-first users (e.g., “students use phones”).

Characteristics of Mobile Applications

• Resource Constraints: Limited CPU, memory, battery (e.g., “lightweight code”).
• Diverse Platforms: iOS, Android differences (e.g., “adapt UI”).
• User Interface: Touch-based, small screens (e.g., “simple navigation”).
• Connectivity: Online/offline modes (e.g., “sync when connected”).
• Sensors: GPS, camera, accelerometer (e.g., “location-based features”).

Challenges in Mobile Software Engineering

1. Fragmentation:
o Many devices, OS versions (e.g., “Android 10 vs. 14”).
2. Performance:
o Slow on old hardware (e.g., “laggy RSVP”).
3. Battery Life:
o Drains fast (e.g., “GPS overuse”).
4. Security:
o Data on portable devices (e.g., “encrypt student IDs”).
5. Testing:
o Hard across devices (e.g., “iPhone vs. Samsung”).

Practices for Mobile Development

1. Cross-Platform Development:
o Use frameworks (e.g., Flutter, React Native) for iOS/Android.
2. Responsive Design:
o Adapt UI to screen sizes (e.g., “buttons fit 4-inch phones”).
3. Lightweight Code:
o Minimize resource use (e.g., “small APK”).
4. Offline Support:
o Cache data (e.g., “view events offline”).
5. Continuous Integration/Deployment (CI/CD):
o Automate builds/tests (e.g., “deploy via GitHub Actions”).
6. Security Measures:
o Encrypt data, secure APIs (e.g., “HTTPS only”).
7. Testing on Emulators/Devices:
 o Use tools (e.g., Android Emulator, Xcode Simulator).

Tools for Mobile Development

• Platforms: Android Studio (Android), Xcode (iOS).
• Frameworks: Flutter, React Native, Xamarin.
• Testing: Appium, Espresso, XCUITest.
• CI/CD: Jenkins, Fastlane.
• Cloud: Firebase, AWS Amplify.
Example: A library app uses Flutter for cross-platform “Borrow Book.”

Development Process
1. Requirements:
o Define mobile needs (e.g., “offline RSVP”).
2. Design:
o UI/UX for touch (e.g., “big buttons”).
3. Development:
o Code with framework (e.g., Flutter Dart).
4. Testing:
o Emulators + real devices (e.g., “test on Samsung”).
5. Deployment:
o App stores (e.g., Google Play, App Store).
6. Maintenance:
o Update for OS changes (e.g., “iOS 18 fix”).

Example: Library App for Mobile

• Feature: “Borrow Book” on Android/iOS.
• Code (Flutter):
dart
CollapseWrapCopy
class Book {
final String title;
bool available;

Book(this.title, this.available);

bool borrow() {
if (available) {
available = false;
return true;
}
return false;
}
}
class BorrowButton extends StatelessWidget {
final Book book;
BorrowButton(this.book);

@override
Widget build(BuildContext context) {
return ElevatedButton(
onPressed: () => book.borrow() ? print("Borrowed") : print("Unavailable"),
child: Text("Borrow"),
);
}
}
• Features: Offline caching, touch UI.
• Deploy: Google Play via CI/CD.

Practical Example for BSIT Students

Imagine an event app:
• Goal: “RSVP Event” on mobile.
• Code (React Native):
javascript
CollapseWrapCopy
import React, { useState } from 'react';
import { Button, Text, View } from 'react-native';

const Event = ({ title, capacity }) => {

const [slots, setSlots] = useState(capacity);

const register = () => {

if (slots > 0) {
setSlots(slots - 1);
alert("RSVP Successful");
} else {
alert("Event Full");
}
};

return (
<View>
<Text>{title} - Slots: {slots}</Text>
<Button title="RSVP" onPress={register} />
</View>
);
};
export default Event;
• Tools: React Native, Expo for testing.
• Test: Emulator (Pixel 6), real device (iPhone).
• Result: Cross-platform, lightweight RSVP.
Scenario: Add “location check-in” using GPS—update with sensor API.

Benefits
• Reach: Targets mobile users (e.g., “students on phones”).
• Experience: Leverages sensors (e.g., “scan QR for RSVP”).
• Speed: Frameworks accelerate dev (e.g., “Flutter cuts time”).
Example: A game’s mobile version uses accelerometer for “tilt controls.”

Real-World Example
• Success: WhatsApp’s cross-platform, lightweight design.
• Challenge: Early mobile apps struggled with fragmentation (e.g., 2000s Java ME).

Key Takeaways
• Mobile software engineering adapts to device constraints.
• It uses frameworks, CI/CD, and responsive design.
• Examples like event apps and WhatsApp show its mobile-first role.

Topic 59: Software Engineering for Web Applications

The fifty-ninth topic in the Software Engineering course introduces Software Engineering for Web
Applications, focusing on the principles, processes, and tools used to design, develop, and deploy
software applications that run on web browsers over the internet. Below, I’ll explain this topic in detail,
including its definition, purpose, challenges, practices, and examples tailored for BSIT students.

What is Software Engineering for Web Applications?

Software engineering for web applications is the application of software engineering practices to create
applications delivered via web browsers, leveraging client-server architectures, web protocols (e.g.,
HTTP), and technologies like HTML, CSS, and JavaScript. Ian Sommerville (Software Engineering, 10th
Edition) describes web application engineering as "the process of developing software systems that are
accessed through web browsers, often requiring distributed architectures and dynamic user interfaces."
Think of it like building a virtual storefront: it’s accessible anywhere (browser), looks good (UI), and
handles transactions (server logic) seamlessly for customers (users).
Example: A library web app lets users “Borrow Book” online, running on a browser with server-backed
data.

Purpose of Web Application Engineering

• Universal Access: Runs on any device with a browser (e.g., “RSVP from laptop”).
• Scalability: Supports many users (e.g., “1,000 students online”).
• Ease of Updates: Central deployment (e.g., “fix bugs once”).
• Rich Interaction: Dynamic UIs (e.g., “real-time search”).
Characteristics of Web Applications
• Client-Server Model: Browser (client) requests, server responds (e.g., “GET books”).
• Stateless Protocol: HTTP needs state management (e.g., “sessions”).
• Cross-Platform: Works on all OS (e.g., “Chrome on Windows/Mac”).
• Dynamic Content: Updates without reload (e.g., “AJAX for RSVP”).
• Distributed: Frontend, backend, database (e.g., “React + Node + MySQL”).

Challenges in Web Application Engineering

1. Browser Compatibility:
o Varies (e.g., “Chrome vs. Safari”).
2. Performance:
o Slow networks (e.g., “laggy search”).
3. Security:
o Exposed to attacks (e.g., “XSS, SQL injection”).
4. Scalability:
o High traffic (e.g., “handle 10,000 users”).
5. User Experience:
o Responsive design (e.g., “fit all screens”).

Practices for Web Development

1. Frontend Development:
o Use HTML/CSS/JS frameworks (e.g., React, Vue).
2. Backend Development:
o Server logic (e.g., Node.js, Django).
3. RESTful APIs:
o Connect client/server (e.g., “GET /events”).
4. Database Integration:
o Store data (e.g., MySQL, MongoDB).
5. Security Measures:
o HTTPS, input validation (e.g., “sanitize search”).
6. Continuous Deployment:
o Automate updates (e.g., “GitHub Actions”).
7. Testing:
o Unit, integration, browser tests (e.g., “Selenium”).

Tools for Web Development

• Frontend: React, Angular, Bootstrap.
• Backend: Node.js, Flask, Ruby on Rails.
• Database: PostgreSQL, Firebase.
• Testing: Jest, Mocha, Cypress.
• CI/CD: Jenkins, Vercel.
• Hosting: AWS, Heroku, Netlify.
Example: A library web app uses React (frontend), Flask (backend), and PostgreSQL.
Development Process
1. Requirements:
o Define features (e.g., “online RSVP”).
2. Design:
o UI mockups, API specs (e.g., “REST endpoints”).
3. Development:
o Frontend + backend (e.g., “React + Flask”).
4. Testing:
o Cross-browser, load tests (e.g., “Chrome + 100 users”).
5. Deployment:
o Cloud hosting (e.g., “Heroku”).
6. Maintenance:
o Monitor, update (e.g., “fix slow API”).

Example: Library Web App

• Feature: “Borrow Book” online.
• Frontend (React):
javascript
CollapseWrapCopy
import React, { useState } from 'react';

function BorrowButton({ bookId }) {

const [status, setStatus] = useState('Borrow');

const borrowBook = async () => {

const response = await fetch(`/api/borrow/${bookId}`, { method: 'POST' });
if (response.ok) setStatus('Borrowed');
};

return <button onClick={borrowBook}>{status}</button>;

}

export default BorrowButton;

• Backend (Flask):
python
CollapseWrapCopy
from flask import Flask, jsonify
app = Flask(__name__)

books = {"1": {"title": "CS101", "available": True}}

@app.route('/api/borrow/<book_id>', methods=['POST'])
def borrow_book(book_id):
if books.get(book_id, {}).get("available"):
 books[book_id]["available"] = False
return jsonify({"status": "success"})
return jsonify({"status": "unavailable"}), 400
• Deploy: Heroku, HTTPS enabled.

Practical Example for BSIT Students

Imagine an event web app:
• Goal: “RSVP Event” online.
• Code (Node.js + Express):
javascript
CollapseWrapCopy
const express = require('express');
const app = express();

let events = [{ id: 1, title: "Hackathon", slots: 10 }];

app.use(express.json());
app.get('/events', (req, res) => res.json(events));
app.post('/rsvp/:id', (req, res) => {
const event = events.find(e => e.id == req.params.id);
if (event && event.slots > 0) {
event.slots--;
res.json({ status: "success" });
} else {
res.status(400).json({ status: "full" });
}
});

app.listen(3000, () => console.log("Server running"));

• Frontend: Simple HTML/JS fetch to /rsvp.
• Test: Cypress for “RSVP works.”
• Result: Browser-based, scalable RSVP.
Scenario: Add “event filter”—update frontend dynamically.

Benefits
• Accessibility: No install needed (e.g., “open in Chrome”).
• Scalability: Cloud-ready (e.g., “handle campus-wide use”).
• Maintenance: Easy updates (e.g., “fix server-side”).
Example: A game’s web version runs on browser, no download required.

Real-World Example
• Success: Google Docs—web-based, real-time collaboration.
• Challenge: Early web apps (1990s) lacked interactivity.
Key Takeaways
• Web app engineering uses client-server and browser tech.
• It tackles compatibility, security, and UX.
• Examples like event apps and Google Docs show its reach.

Topic 60: Software Engineering Capstone Project

The sixtieth topic in the Software Engineering course introduces the Software Engineering Capstone
Project, a hands-on, integrative experience where students design, develop, and deliver a complete
software system, synthesizing concepts from the course. Below, I’ll explain this topic in detail, including
its definition, purpose, process, and examples tailored for BSIT students.

What is a Software Engineering Capstone Project?

A Software Engineering Capstone Project is a significant, team-based or individual project that requires
students to apply software engineering principles—requirements analysis, design, implementation,
testing, and deployment—to solve a real-world problem or build a functional system. Ian Sommerville
(Software Engineering, 10th Edition) highlights that "capstone projects simulate professional practice,
integrating technical and project management skills."
Think of it like a final exam with a twist: instead of answering questions, you build a working product
(e.g., an app) from scratch, showing you can “walk the talk” of software engineering.
Example: A library app capstone lets users “Borrow Book” online, built from concept to deployment.

Purpose of the Capstone Project

• Apply Knowledge: Use course concepts (e.g., “Agile + UML”).
• Develop Skills: Practice coding, teamwork, problem-solving (e.g., “fix bugs”).
• Simulate Industry: Mimic real-world dev (e.g., “meet deadlines”).
• Showcase Ability: Build portfolio (e.g., “show employers”).
• Solve Problems: Address needs (e.g., “help campus events”).

Characteristics of a Capstone Project

• End-to-End: Covers full lifecycle (requirements to delivery).
• Team-Oriented: Often collaborative (e.g., “3-5 students”).
• Realistic Scope: Feasible yet challenging (e.g., “app in 3 months”).
• Deliverable: Working software + documentation (e.g., “code + report”).
• Presentation: Demo and defend (e.g., “show to instructors”).

Capstone Project Process

1. Problem Identification:
o Choose a problem/domain (e.g., “event management”).
2. Requirements Analysis:
o Gather needs (e.g., “RSVP, view events”).
3. Design:
o Model system (e.g., UML diagrams).
4. Implementation:
o Code solution (e.g., “React + Flask”).
 5. Testing:
o Verify functionality (e.g., “unit tests pass”).
6. Deployment:
o Launch app (e.g., “host on Heroku”).
7. Documentation:
o Write report (e.g., “process, challenges”).
8. Presentation:
o Demo to peers/instructors (e.g., “show RSVP”).

Methodologies and Tools

• Methodologies: Agile (Scrum), Waterfall (if structured).
• Tools:
o Design: UML tools (e.g., StarUML).
o Coding: VS Code, Android Studio.
o Version Control: Git, GitHub.
o Testing: JUnit, Selenium.
o CI/CD: GitHub Actions, Jenkins.
o Hosting: AWS, Netlify.
Example: A capstone uses Scrum, GitHub, and AWS for a mobile app.

Example: Library App Capstone

• Problem: “Students need online book borrowing.”
• Requirements: “Search Book, Borrow Book, Return Book.”
• Design (DCD):
text
CollapseWrapCopy
+---------+ +---------+
| User |1 *| Book |
|---------|------|---------|
| -id: String | -title: String |
| +borrowBook() | -available: Boolean |
+---------+ | +borrow(): Boolean |
+---------+
• Implementation (Flask):
python
CollapseWrapCopy
from flask import Flask, jsonify
app = Flask(__name__)

books = {"1": {"title": "CS101", "available": True}}

@app.route('/borrow/<book_id>', methods=['POST'])
def borrow_book(book_id):
if books[book_id]["available"]:
 books[book_id]["available"] = False
return jsonify({"status": "success"})
return jsonify({"status": "unavailable"}), 400
• Testing: Unit test:
python
CollapseWrapCopy
def test_borrow_book():
assert borrow_book("1")["status"] == "success"
• Deploy: Heroku, demo shows “Borrow” working.

Practical Example for BSIT Students

Imagine a capstone: Campus Event App
• Team: 4 students (designer, 2 coders, tester).
• Problem: “Students miss events due to poor info.”
• Requirements: “View Events, RSVP, Notifications.”
• Design: UML class diagram:
text
CollapseWrapCopy
+---------+ +---------+
| Event |1 *| Student |
|---------|------|---------|
| -id: Int | -id: String |
| -title: String| +rsvpEvent() |
| -slots: Int | |
| +register() | |
+---------+ +---------+
• Implementation (React Native):
javascript
CollapseWrapCopy
import React, { useState } from 'react';
import { Button, Text } from 'react-native';

const Event = ({ id, title, slots }) => {

const [remaining, setRemaining] = useState(slots);

const register = () => {

if (remaining > 0) {
setRemaining(remaining - 1);
alert("RSVPed!");
} else {
alert("Full");
}
};
 return (
<>
<Text>{title} - {remaining} slots</Text>
<Button title="RSVP" onPress={register} />
</>
);
};

export default Event;

• Testing: Test on emulator, real device (e.g., “slots decrease”).
• Deploy: Expo hosting, GitHub for code.
• Presentation: Demo “RSVP,” explain Agile process.
Scenario: Add “push notifications”—integrate Firebase mid-project.

Challenges and Tips

• Challenges:
o Scope creep (e.g., “too many features”).
o Team conflicts (e.g., “who codes what?”).
o Time limits (e.g., “3 months tight”).
• Tips:
o Start small, iterate (e.g., “MVP first”).
o Use Agile (e.g., “weekly sprints”).
o Communicate (e.g., “daily stand-ups”).

Benefits
• Skills: Full-cycle experience (e.g., “design to deploy”).
• Portfolio: Tangible product (e.g., “show app”).
• Confidence: Real-world readiness (e.g., “I built this”).
Example: A game capstone with “Level 1” impresses recruiters.

Real-World Example
• Success: University teams build apps like “campus maps” for real use.
• Lesson: Scope management key (e.g., 2010s overambitious failures).

Key Takeaways
• Capstone projects integrate all SE concepts.
• They follow a lifecycle from problem to product.
• Examples like event apps show practical application.

Topic 61: Software Engineering in Industry

The sixty-first topic in the Software Engineering course introduces Software Engineering in Industry,
exploring how software engineering practices, tools, and methodologies are applied in professional
environments to deliver commercial or enterprise-grade software systems. Below, I’ll explain this topic in
detail, including its definition, purpose, key aspects, and examples tailored for BSIT students preparing
for the workforce.

What is Software Engineering in Industry?

Software engineering in industry refers to the disciplined application of software engineering principles
in real-world organizations—corporations, startups, or government entities—to develop, maintain, and
scale software products or services that meet business goals, customer needs, and operational demands.
Ian Sommerville (Software Engineering, 10th Edition) notes that "industrial software engineering
involves balancing technical rigor with practical constraints like budgets, deadlines, and stakeholder
expectations."
Think of it like moving from a school workshop to a factory: you use the same tools and skills (e.g.,
coding, testing), but now you’re building for real customers (users), under tighter schedules (deadlines),
and with a team of workers (colleagues).
Example: A library app in industry might be a commercial product like “OverDrive,” built for millions of
users with robust scalability and support.

Purpose of Software Engineering in Industry

• Deliver Business Value: Aligns software with goals (e.g., “increase sales”).
• Scale Efficiently: Handles large user bases (e.g., “1M borrows”).
• Ensure Reliability: Meets uptime, quality standards (e.g., “99.9% uptime”).
• Adapt to Market: Responds to competition, trends (e.g., “add AI features”).
• Prepare Students: Bridges academia to jobs (e.g., “work-ready skills”).

Key Aspects of Industry Software Engineering

1. Scale and Complexity:
o Larger systems, teams (e.g., “100 devs on one app”).
2. Stakeholder Management:
o Clients, managers, users (e.g., “meet client specs”).
3. Deadlines and Budgets:
o Time/cost constraints (e.g., “launch in 6 months”).
4. Regulatory Compliance:
o Laws, standards (e.g., “GDPR for user data”).
5. Maintenance and Support:
o Long-term updates (e.g., “fix bugs post-launch”).
6. Collaboration:
o Cross-functional teams (e.g., “devs + QA + ops”).

Industry Practices
1. Agile at Scale:
o Scrum, SAFe for large teams (e.g., “sprints across departments”).
2. DevOps Integration:
o CI/CD, monitoring (e.g., “deploy daily”).
3. Microservices Architecture:
o Modular, scalable (e.g., “separate RSVP service”).
 4. Quality Assurance (QA):
o Dedicated testing teams (e.g., “automated + manual”).
5. Technical Debt Management:
o Balance speed vs. cleanup (e.g., “refactor later”).
6. Customer Feedback Loops:
o Iterate based on use (e.g., “users want filters”).

Tools in Industry
• Project Management: Jira, Asana.
• Version Control: Git (GitHub Enterprise, GitLab).
• CI/CD: Jenkins, CircleCI.
• Cloud Platforms: AWS, Azure, Google Cloud.
• Monitoring: New Relic, Datadog.
• Collaboration: Slack, Microsoft Teams.
Example: An industry event app uses Jira for tasks, GitLab for code, and AWS for hosting.

How It Works in Industry

1. Initiation:
o Business case (e.g., “app to boost engagement”).
2. Planning:
o Scope, budget, timeline (e.g., “$50K, 6 months”).
3. Development:
o Agile sprints, microservices (e.g., “build RSVP”).
4. Testing:
o QA team, stress tests (e.g., “10K users”).
5. Deployment:
o Cloud, phased rollout (e.g., “beta to all”).
6. Support:
o Bug fixes, updates (e.g., “v1.1 with notifications”).

Example: Industry Library App

• Goal: Commercial app for libraries (e.g., “Libby”).
• Process:
o Planning: “Support 1M users, $100K budget.”
o Design: Microservices (e.g., “Search” + “Borrow”).
o Code (Node.js):
javascript
CollapseWrapCopy
const express = require('express');
const app = express();

let books = [{ id: 1, title: "CS101", available: true }];

app.get('/search', (req, res) => {

 const results = books.filter(b => b.title.includes(req.query.q));
res.json(results);
});

app.post('/borrow/:id', (req, res) => {

const book = books.find(b => b.id == req.params.id);
if (book && book.available) {
book.available = false;
res.json({ status: "success" });
} else {
res.status(400).json({ status: "unavailable" });
}
});

app.listen(3000);
• Deploy: AWS, monitored by Datadog.
• Result: Scales to millions, updated monthly.

Practical Example for BSIT Students

Imagine an industry-style event app:
• Scenario: Startup hires you for “EventLite.”
• Task: Build “RSVP” feature.
• Process:
o Sprint: 2 weeks, Jira ticket EL-101.
o Code (Django):
python
CollapseWrapCopy
from django.http import JsonResponse
from .models import Event

def rsvp_event(request, event_id):

event = Event.objects.get(id=event_id)
if event.slots > 0:
event.slots -= 1
event.save()
return JsonResponse({"status": "success"})
return JsonResponse({"status": "full"}, status=400)
• CI/CD: GitHub Actions builds, tests, deploys to Heroku.
• Monitor: Logs show “100 RSVPs, 0 errors.”
• Industry Twist: Client requests “analytics”—add in next sprint.
Scenario: Scale for 10K users—migrate to AWS ECS.

Challenges and Tips

• Challenges:
 o Tight deadlines (e.g., “launch soon”).
o Legacy code (e.g., “fix old bugs”).
o Team dynamics (e.g., “align with QA”).
• Tips:
o Learn tools (e.g., “master Git”).
o Communicate (e.g., “update manager”).
o Focus on MVP (e.g., “core features first”).

Benefits
• Experience: Real-world practice (e.g., “shipped a product”).
• Employability: Industry skills (e.g., “DevOps know-how”).
• Impact: Solves actual problems (e.g., “users benefit”).
Example: A game in industry scales to millions with microservices.

Real-World Example
• Success: Slack—Agile, DevOps, cloud-native success.
• Lesson: Poor planning sank 2000s NHS IT (over-budget, late).

Key Takeaways
• Industry SE balances tech with business needs.
• It uses Agile, DevOps, and scalable designs.
• Examples like event apps and Slack show its practical role.

Assignment 1: Domain Modeling and Design Class Diagram for a Student Portal
Related Topics: Topic 27 (Domain Model: Identifying Business Classes), Topic 28 (Domain Model
Associations), Topic 29 (Domain Model Attributes), Topic 33 (Design Class Diagram)
Objective
Understand object-oriented analysis and design by creating a domain model and refining it into a design
class diagram for a real-world system.
Task
Design a student portal system that allows students to view grades, register for courses, and check
schedules.
1. Domain Model:
o Identify at least 5 business classes (e.g., Student, Course).
o Define associations with multiplicity (e.g., “1 Student registers for * Courses”).
o List key attributes for each class (e.g., “Student: ID, name”).
2. Design Class Diagram:
o Refine the domain model into a DCD.
o Add visibility (e.g., -name: String), methods (e.g., +registerCourse(): Boolean), and
relationships.
3. Documentation:
o Write a 1-page explanation of your choices (e.g., “Why Course has slots?”).
Deliverables
• UML domain model diagram (hand-drawn or tool-based, e.g., StarUML).
 • UML design class diagram.
• 1-page report (PDF).
Evaluation Criteria
• Completeness: All required classes, associations, and attributes included (30%).
• Accuracy: Correct UML notation and logical relationships (30%).
• Clarity: Clear diagrams and well-justified explanations (20%).
• Creativity: Thoughtful features beyond basics (20%).
Suggested Tools
• StarUML, Lucidchart, or pencil/paper.

Assignment 2: Mapping Design to Code for an Event RSVP System

Related Topics: Topic 34 (Mapping Design to Code), Topic 58 (Software Engineering for Mobile
Applications)
Objective
Translate a design class diagram into executable code and adapt it for a mobile context.
Task
Using the provided DCD for an event RSVP system:
text
CollapseWrapCopy
+---------+ +---------+
| Event |1 *| Student |
|---------|------|---------|
| -id: Int | -id: String |
| -title: String| -name: String |
| -slots: Int | +rsvpEvent(e: Event): Boolean |
| +register(s: Student): Boolean |
+---------+ +---------+
1. Code Implementation:
o Write Python (or another language) classes for Event and Student.
o Implement methods with logic (e.g., register reduces slots if available).
2. Mobile Adaptation:
o Add a simple mobile-friendly UI (e.g., Flask web app or React Native component).
o Ensure it works offline (e.g., local storage or caching).
3. Testing:
o Write 2 unit tests (e.g., “register succeeds when slots > 0”).
Deliverables
• Source code files (e.g., event.py, app.py).
• Test file (e.g., test_event.py).
• Screenshot of mobile UI running (emulator or device).
Evaluation Criteria
• Functionality: Code matches DCD and works (40%).
• Mobile Readiness: UI and offline feature implemented (30%).
• Testing: Tests cover key cases (20%).
• Code Quality: Clean, commented code (10%).
Suggested Tools
• Python (Flask), React Native, VS Code, pytest.

Assignment 3: Agile Development Sprint for a Library App Feature

Related Topics: Topic 42 (Agile Software Development), Topic 43 (Scrum Framework)
Objective
Apply Agile and Scrum principles to develop a software feature collaboratively in a simulated sprint.
Task (Team of 3-5 Students)
Develop a “Return Book” feature for a library app in a 2-week sprint.
1. Sprint Planning:
o Create a product backlog (5+ user stories, e.g., “As a user, I want to return a book…”).
o Select 2-3 stories for the sprint backlog (assign story points, e.g., 3, 5).
2. Development:
o Code the feature (e.g., Python with Flask or JavaScript).
o Use Git for version control.
3. Daily Scrum:
o Hold 3 mock “daily stand-ups” (5-minute updates: “What did I do? What’s next?”).
o Document notes.
4. Sprint Review/Retrospective:
o Demo the feature.
o Write a 1-page reflection (e.g., “What went well? What to improve?”).
Deliverables
• Product and sprint backlog (table or Jira screenshot).
• Source code (GitHub repo link).
• Daily Scrum notes (text file).
• Demo video (2-3 minutes) + reflection (PDF).
Evaluation Criteria
• Agile Process: Backlog, stand-ups followed (30%).
• Feature Quality: “Return Book” works (30%).
• Teamwork: Evidence of collaboration (20%).
• Reflection: Insightful analysis (20%).
Suggested Tools
• GitHub, Trello/Jira, Flask/React, Zoom (for stand-ups).

Assignment 4: DevOps Pipeline for a Web-Based Event App

Related Topics: Topic 47 (DevOps Basics), Topic 59 (Software Engineering for Web Applications)
Objective
Implement a DevOps pipeline to automate the build, test, and deployment of a web application.
Task
Build a simple web-based event app with “View Events” functionality.
1. Development:
o Create a web app (e.g., Node.js + Express).
o Add a REST API endpoint (e.g., GET /events).
2. CI/CD Pipeline:
 o Set up GitHub Actions (or Jenkins) to:
▪ Build the app.
▪ Run unit tests (e.g., “events return correctly”).
▪ Deploy to a free host (e.g., Heroku, Netlify).
3. Monitoring:
o Add basic logging (e.g., “log API calls”).
o Simulate monitoring with a manual check (e.g., “response time < 1s”).
Deliverables
• Source code (GitHub repo with .github/workflows/ci.yml).
• Unit test file (e.g., test_events.js).
• Deployment URL (e.g., Heroku link).
• 1-page setup guide (PDF).
Evaluation Criteria
• Pipeline Success: Build, test, deploy work (40%).
• App Functionality: “View Events” runs (30%).
• Documentation: Clear guide (20%).
• Logging: Basic monitoring included (10%).
Suggested Tools
• Node.js, GitHub Actions, Heroku, Mocha (testing).

Assignment 5: Ethical Analysis and Security Enhancement for a Mobile App

Related Topics: Topic 48 (Software Security Basics), Topic 57 (Ethics in Software Engineering), Topic 58
(Software Engineering for Mobile Applications)
Objective
Analyze ethical implications and enhance security for a mobile application.
Task
Extend a mobile event app (e.g., from Assignment 2) with “RSVP Event.”
1. Ethical Analysis:
o Identify 2 ethical issues (e.g., “data privacy,” “accessibility”).
o Propose solutions (e.g., “encrypt IDs,” “add voice support”).
2. Security Enhancement:
o Add input validation (e.g., “prevent injection”).
o Encrypt sensitive data (e.g., “hash student IDs”).
3. Implementation:
o Update code with security fixes.
o Test for vulnerabilities (e.g., “try invalid input”).
4. Report:
o Write a 2-page analysis (ethical issues, security fixes, test results).
Deliverables
• Updated source code (GitHub link).
• Test cases (text file or script).
• 2-page report (PDF).
Evaluation Criteria
• Ethical Insight: Issues and solutions well-reasoned (30%).
 • Security Implementation: Fixes effective (30%).
• Testing: Vulnerabilities checked (20%).
• Report Clarity: Concise, detailed (20%).
Suggested Tools
• React Native/Flutter, Python (hashlib), OWASP ZAP (optional).

Assignment 6: Software Process Improvement Plan for a Game Development Team

Related Topics: Topic 45 (Software Process Improvement)
Objective
Apply software process improvement (SPI) techniques to analyze and enhance a development process.
Task
Imagine a game development team struggling with late bug detection and slow releases for a “Space
Shooter” game.
1. Assessment:
o Identify 3 process weaknesses (e.g., “no unit tests,” “manual builds”).
o Collect mock data (e.g., “5 bugs found post-release”).
2. Improvement Plan:
o Use PDCA (Plan-Do-Check-Act):
▪ Plan: Propose 2 changes (e.g., “add unit tests,” “automate builds”).
▪ Do: Outline implementation (e.g., “use pytest”).
▪ Check: Define metrics (e.g., “bugs reduced to 2”).
▪ Act: Standardize (e.g., “tests mandatory”).
3. Simulation:
o Write a sample unit test for a game function (e.g., shoot()).
4. Report:
o 2-page plan explaining the process and benefits.
Deliverables
• Mock data table (e.g., Excel/text).
• Sample test code (e.g., test_game.py).
• 2-page SPI plan (PDF).
Evaluation Criteria
• Analysis: Weaknesses accurately identified (30%).
• Plan Quality: PDCA applied logically (30%).
• Test Code: Functional and relevant (20%).
• Report: Clear, persuasive (20%).
Suggested Tools
• Python (pytest), MS Word/Google Docs.

Assignment 7: Lean Development of a Minimal Viable Product (MVP) for a To-Do App
Related Topics: Topic 46 (Lean Software Development)
Objective
Implement Lean principles to build an efficient, value-focused software product.
Task
Develop a simple web-based to-do app as an MVP.
 1. Value Identification:
o Define core value (e.g., “add and view tasks”).
o List 2 wastes to avoid (e.g., “fancy UI,” “unused reports”).
2. Development:
o Build a minimal app (e.g., Flask):
▪ Add task (POST).
▪ View tasks (GET).
o Keep it lightweight (e.g., no database, use memory).
3. Feedback Loop:
o Simulate user feedback (e.g., “needs delete”).
o Plan next iteration (e.g., “add DELETE endpoint”).
4. Documentation:
o 1-page explanation of Lean choices.
Deliverables
• Source code (GitHub link, e.g., app.py).
• 1-page Lean rationale (PDF).
• Screenshot of app running.
Evaluation Criteria
• Lean Application: Waste minimized, value maximized (30%).
• Functionality: Add/view works (30%).
• Feedback Plan: Realistic iteration (20%).
• Documentation: Clear justification (20%).
Suggested Tools
• Flask (Python), VS Code, browser.

Assignment 8: Software Reengineering of a Legacy Calculator App

Related Topics: Topic 49 (Software Reengineering)
Objective
Practice reengineering by modernizing an outdated software system.
Task
Reengineer a simple legacy calculator app written in Python.
1. Legacy Code (Provided):
python
CollapseWrapCopy
def calc(op, a, b):
if op == "add": return a + b
if op == "sub": return a - b
# No error handling, messy
print(calc("add", 5, 3))
2. Assessment:
o List 3 issues (e.g., “no structure,” “no validation”).
3. Reengineering:
o Refactor into a class (e.g., Calculator).
o Add error handling, methods (e.g., add(), subtract()).
 o Modernize (e.g., add a Flask API).
4. Testing:
o Write 2 unit tests (e.g., “add works”).
5. Report:
o 1-page summary of changes and benefits.
Deliverables
• Original + reengineered code (GitHub link).
• Test file (e.g., test_calc.py).
• 1-page report (PDF).
Evaluation Criteria
• Issue Identification: Accurate problems spotted (20%).
• Reengineering: Improved structure, functionality (40%).
• Testing: Tests cover key cases (20%).
• Report: Clear explanation (20%).
Suggested Tools
• Python, Flask, pytest.

Assignment 9: Software Reuse with a Third-Party Library for a Weather App

Related Topics: Topic 53 (Software Reuse)
Objective
Leverage existing software components to accelerate development and improve quality.
Task
Build a simple weather app using a third-party API/library.
1. Selection:
o Choose a free weather API (e.g., OpenWeatherMap).
o Register for an API key.
2. Development:
o Create a web app (e.g., Flask) to:
▪ Fetch current weather by city (e.g., “Manila”).
▪ Display temperature and condition.
o Reuse the API library (e.g., requests in Python).
3. Documentation:
o 1-page explanation of reuse benefits (e.g., “saved coding time”).
4. Testing:
o Verify with 2 cities (e.g., “Manila, Tokyo”).
Deliverables
• Source code (GitHub link, e.g., weather.py).
• 1-page reuse analysis (PDF).
• Screenshots of app output for 2 cities.
Evaluation Criteria
• API Integration: Weather data fetched correctly (40%).
• Reuse Justification: Benefits well-explained (30%).
• Functionality: Displays data clearly (20%).
• Presentation: Clean screenshots (10%).
Suggested Tools
• Flask, requests (Python), OpenWeatherMap API.

Assignment 10: Industry-Style Development and Deployment of a Chat App

Related Topics: Topic 61 (Software Engineering in Industry)
Objective
Simulate an industry workflow by building, deploying, and documenting a software product with
professional practices.
Task
Develop a basic real-time chat app as an industry junior developer.
1. Planning:
o Write a 1-page spec (e.g., “send/receive messages, 10 users”).
o Use Jira/Trello for 3 tasks (e.g., “setup server,” “code UI”).
2. Development:
o Build with Node.js + Socket.IO:
▪ Server broadcasts messages.
▪ Simple HTML/JS client.
3. Deployment:
o Host on a free platform (e.g., Render, Heroku).
o Use GitHub for version control.
4. Industry Practices:
o Write a README with setup instructions.
o Log commits (e.g., “feat: add send button”).
Deliverables
• Source code (GitHub repo link).
• 1-page spec (PDF).
• Trello/Jira screenshot of tasks.
• Deployment URL + README (in repo).
Evaluation Criteria
• Planning: Spec and tasks clear (20%).
• Functionality: Chat works in real-time (40%).
• Deployment: App live, accessible (20%).
• Professionalism: README, commits polished (20%).
Suggested Tools
• Node.js, Socket.IO, GitHub, Render/Heroku.

How These Assignments Enhance Understanding

1. Assignment 1: Reinforces OOAD by connecting domain concepts to design, a foundational SE
skill.
2. Assignment 2: Bridges design to implementation, emphasizing mobile constraints.
3. Assignment 3: Simulates Agile teamwork, a core industry practice.
4. Assignment 4: Introduces DevOps automation, critical for modern deployment.
5. Assignment 5: Combines ethics and security, fostering responsible engineering.
6. Assignment 6: Deepens SPI by applying a structured improvement cycle, mirroring industry
process optimization.
7. Assignment 7: Teaches Lean principles through minimalism and iteration, a practical efficiency
skill.
8. Assignment 8: Builds reengineering expertise, preparing students for legacy system work
common in industry.
9. Assignment 9: Reinforces reuse, a cost-saving and quality-enhancing practice in real projects.
10. Assignment 10: Simulates industry workflows, bridging academic learning to professional
expectations.

Below, I’ll briefly explain the examples I’ve used in the topics that involve "students," "events," or
related concepts (e.g., library apps, campus systems). These examples were chosen to be relatable
for BSIT students, reflecting scenarios they might encounter in academic or real-world settings. I’ll
reference the specific topics and assignments where they appear, focusing on their context and
purpose.

1. Student Portal System

• Topics Used In:
o Topic 27 (Domain Model: Identifying Business Classes), Topic 29 (Domain Model
Attributes), Topic 33 (Design Class Diagram), Topic 42 (Agile Software Development),
Topic 45 (Software Process Improvement).
o Assignment 1 (Domain Modeling and Design Class Diagram for a Student Portal).
• Example Description: A web or mobile system where students can view grades, register for
courses, and check schedules.
o Context: Represents a university system familiar to students, requiring features like
“Calculate GPA” or “View Grades.”
o Purpose: Illustrates object-oriented analysis (e.g., classes like Student, Course), design
(e.g., methods like registerCourse()), Agile iteration (e.g., delivering “Login” first), and SPI
(e.g., speeding up testing).
o Assignment Use: Students model and design this system, translating real-world needs
(e.g., grade access) into UML diagrams, reinforcing OOAD concepts.

2. Campus Event App

• Topics Used In:
o Topic 34 (Mapping Design to Code), Topic 40 (Risk Management), Topic 41 (Software
Metrics), Topic 43 (Scrum Framework), Topic 49 (Software Reengineering), Topic 53
(Software Reuse), Topic 58 (Software Engineering for Mobile Applications), Topic 60
(Capstone Project).
o Assignment 2 (Mapping Design to Code), Assignment 5 (Ethical Analysis and Security
Enhancement), Assignment 10 (Industry-Style Chat App indirectly relates via RSVP-like
functionality).
• Example Description: A mobile or web app for managing campus events, allowing students to
view events, RSVP, and get notifications.
 o Context: Mimics a student-oriented tool (e.g., “Hackathon RSVP”), with features like
“View Events” or “Cancel RSVP.”
o Purpose: Demonstrates coding from design (e.g., Event.register()), risk management
(e.g., “server downtime”), metrics (e.g., “cycle time”), Scrum (e.g., sprints for “RSVP”),
reengineering (e.g., modernizing old PHP), reuse (e.g., Flask), mobile dev (e.g., offline
support), and capstone scope (e.g., full app).
o Assignment Use: Students code, secure, and deploy this app, applying design-to-code
mapping, security (e.g., hashing IDs), and industry practices (e.g., CI/CD).

3. Library App
• Topics Used In:
o Topic 27 (Domain Model: Identifying Business Classes), Topic 28 (Domain Model
Associations), Topic 29 (Domain Model Attributes), Topic 33 (Design Class Diagram),
Topic 34 (Mapping Design to Code), Topic 40 (Risk Management), Topic 41 (Software
Metrics), Topic 42 (Agile Software Development), Topic 43 (Scrum Framework), Topic 47
(DevOps Basics), Topic 48 (Software Security Basics), Topic 49 (Software Reengineering),
Topic 58 (Mobile Apps), Topic 59 (Web Apps), Topic 61 (Industry).
o Assignment 3 (Agile Sprint), Assignment 8 (Reengineering).
• Example Description: A system (mobile, web, or desktop) where students/users borrow, return,
and search for books.
o Context: Simulates a campus or public library (e.g., “Borrow CS101”), with features like
“Search Book” or “Return Book.”
o Purpose: Shows domain modeling (e.g., User, Book, Loan), associations (e.g., “1 User
borrows * Books”), coding (e.g., borrowBook()), risk (e.g., “database crash”), metrics
(e.g., “bug density”), Agile/Scrum (e.g., sprint for “Return”), DevOps (e.g., CI/CD
pipeline), security (e.g., SQL injection fix), reengineering (e.g., C to Python), and industry
scale (e.g., “1M users”).
o Assignment Use: Students develop a feature iteratively (e.g., “Return Book” in Scrum)
and reengineer legacy code, applying process and modernization skills.

4. Event RSVP Functionality (Generalized)

• Topics Used In:
o Topic 34 (Mapping Design to Code), Topic 46 (Lean Software Development), Topic 47
(DevOps Basics), Topic 56 (Emerging Trends), Topic 58 (Mobile Apps), Topic 59 (Web
Apps).
o Assignment 4 (DevOps Pipeline).
• Example Description: A feature within apps (e.g., campus event or library) where students RSVP
to events like workshops or seminars.
o Context: A standalone or embedded function (e.g., “RSVP Hackathon”), often with slots
or capacity limits.
o Purpose: Illustrates coding (e.g., register()), Lean (e.g., minimal “RSVP” MVP), DevOps
(e.g., auto-deploy), trends (e.g., serverless), mobile (e.g., React Native UI), and web (e.g.,
REST API).
 o Assignment Use: Students build and deploy this feature with a pipeline, learning
automation and deployment in a web context.

5. Game Development Examples (e.g., Space Shooter)

• Topics Used In:
o Topic 41 (Software Metrics), Topic 42 (Agile), Topic 45 (Software Process Improvement),
Topic 58 (Mobile Apps), Topic 61 (Industry).
o Assignment 6 (SPI Plan).
• Example Description: A simple game (e.g., “Space Shooter”) where players move or shoot (e.g.,
“MovePlayer,” “Shoot”).
o Context: Represents a student project or industry product, with features like “Level 1” or
“Score.”
o Purpose: Shows metrics (e.g., “crash rate”), Agile (e.g., “Level 1 in Sprint 1”), SPI (e.g.,
“reduce bugs”), mobile (e.g., “tilt controls”), and industry (e.g., “scale multiplayer”).
o Assignment Use: Students analyze and improve a game dev process, applying SPI to a
creative, engaging system.

Why These Examples?

• Relatability: Students, events, and libraries are familiar to BSIT students, making abstract
concepts concrete (e.g., “I borrow books, so I get Loan class”).
• Flexibility: They adapt across topics—domain modeling (e.g., Student), coding (e.g., rsvpEvent()),
Agile (e.g., sprints), and industry (e.g., “scale to 1M”).
• Practicality: Mirror real systems (e.g., campus portals, OverDrive), preparing students for
academic or professional projects.
These examples evolve with the topics—starting as simple models (e.g., Topic 27), becoming coded
features (e.g., Topic 34), and scaling to industry-grade apps (e.g., Topic 61)—mirroring the SE
lifecycle. Let me know if you’d like deeper dives into any specific example!

Some Extra Topics

Topic: Software Requirements Engineering
(Proposed as Topic 10, fitting before design/modeling phases)
What is Software Requirements Engineering?
Software Requirements Engineering (RE) is the process of eliciting, analyzing, documenting, validating,
and managing the requirements for a software system. It defines what the system should do
(functionality) and how well it should perform (quality attributes). Ian Sommerville (Software
Engineering, 10th Edition) describes RE as "the process of establishing the services that the customer
requires from a system and the constraints under which it must operate."
Example: For a library app, RE identifies needs like “Users must borrow books” and constraints like
“System must handle 100 users concurrently.”
Purpose
• Clarify Needs: Ensures stakeholders agree on goals (e.g., “students need grade access”).
• Guide Development: Provides a blueprint (e.g., “RSVP feature required”).
• Avoid Missteps: Reduces rework (e.g., “catch ‘offline mode’ early”).
Key Activities
 1. Elicitation:
o Gather needs via interviews, surveys, observation (e.g., “students want event
notifications”).
2. Analysis:
o Resolve conflicts, prioritize (e.g., “search over analytics”).
3. Specification:
o Document in SRS (Software Requirements Specification) (e.g., “User shall search books
by title”).
4. Validation:
o Check completeness, feasibility (e.g., “can we encrypt data?”).
5. Management:
o Track changes (e.g., “add ‘return book’ later”).
Types of Requirements
• Functional: What it does (e.g., “Borrow Book”).
• Non-Functional: Quality constraints (e.g., “response time < 2s”).
• Domain: Context-specific (e.g., “library fines apply”).
Example: Campus Event App
• Elicitation: Interview students—“I want to RSVP and get reminders.”
• Analysis: Prioritize RSVP over reminders.
• Specification:
o Functional: “System shall allow RSVP to events.”
o Non-Functional: “System shall support 500 simultaneous users.”
• Validation: Stakeholders confirm via prototype review.
• Management: “Add reminders” logged for v2.
Techniques and Tools
• Techniques: Use cases, user stories, prototyping.
• Tools: Jira (track requirements), DOORS (formal SRS).
Notes
• Process: Iterative—refine as project evolves.
• Challenges: Ambiguity (e.g., “fast”?), changing needs.
• Student Relevance: Foundation for all later phases (e.g., domain model builds on this).

Topic: Software Design Principles

(Proposed as Topic 15, fitting after requirements and before detailed design)
What are Software Design Principles?
Software Design Principles are fundamental guidelines that help engineers create software systems that
are modular, maintainable, scalable, and robust. They focus on how to structure software to meet
requirements effectively, emphasizing qualities like flexibility and reusability. Ian Sommerville (Software
Engineering, 10th Edition) describes design principles as "rules and heuristics that guide the structuring
of software to improve its quality and longevity."
Example: For a library app, applying the “Single Responsibility Principle” ensures the Book class only
handles book data, not borrowing logic.
Purpose
• Improve Quality: Makes software easier to maintain (e.g., “fix bugs without breaking”).
 • Enhance Flexibility: Adapts to changes (e.g., “add mobile support”).
• Reduce Complexity: Simplifies understanding (e.g., “clear module roles”).
• Enable Reuse: Components work across projects (e.g., “reuse User class”).
Key Principles (SOLID + Others)
1. Single Responsibility Principle (SRP):
o A class should have one reason to change (e.g., Event manages event data, not RSVPs).
2. Open/Closed Principle (OCP):
o Open for extension, closed for modification (e.g., extend Payment with CreditCard
without altering it).
3. Liskov Substitution Principle (LSP):
o Subtypes must be substitutable for base types (e.g., StudentUser works where User
does).
4. Interface Segregation Principle (ISP):
o Clients shouldn’t depend on unneeded interfaces (e.g., Borrower interface excludes
admin methods).
5. Dependency Inversion Principle (DIP):
o Depend on abstractions, not concretions (e.g., Library uses Database interface, not
MySQL directly).
6. Other Principles:
o Modularity: Break into independent units (e.g., “UI vs. logic”).
o Encapsulation: Hide details (e.g., private _title in Book).
Example: Campus Event App
• SRP: Event class:
python
CollapseWrapCopy
class Event:
def __init__(self, title, slots):
self._title = title
self._slots = slots
# No RSVP logic here—separate class
• OCP: Add VIPEvent without changing Event:
python
CollapseWrapCopy
class VIPEvent(Event):
def __init__(self, title, slots, vip_pass):
super().__init__(title, slots)
self._vip_pass = vip_pass
• DIP: EventManager uses abstraction:
python
CollapseWrapCopy
class EventManager:
def __init__(self, storage): # Storage is abstract
self._storage = storage
def save(self, event):
 self._storage.save(event)
Application Process
1. Identify Components:
o Break system into parts (e.g., “User, Event”).
2. Apply Principles:
o Assign roles, abstract dependencies (e.g., “Event only holds data”).
3. Validate:
o Check flexibility (e.g., “can add new event type?”).
4. Refine:
o Adjust for clarity (e.g., “split big class”).
Notes
• Techniques: Use UML to visualize (e.g., class diagrams reflect SRP).
• Challenges: Over-engineering (e.g., “too many interfaces”).
• Student Relevance: Foundational for design (e.g., informs DCDs), widely used in industry (e.g.,
SOLID in frameworks).
Tools
• Design: StarUML, Visio.
• Coding: Python, Java (OOP languages).

Topic: Software Architecture

(Proposed as Topic 20, fitting after design principles and before detailed design)
What is Software Architecture?
Software Architecture is the high-level structure of a software system, defining its major components,
their relationships, and how they interact to meet requirements. It focuses on the “big picture” rather
than implementation details. Ian Sommerville (Software Engineering, 10th Edition) defines software
architecture as "the set of principal design decisions about the system, including its structure, behavior,
and interactions."
Example: For a library app, the architecture might include a web client, application server, and database,
connected via REST APIs.
Purpose
• Provide Structure: Organizes components (e.g., “separate UI from logic”).
• Ensure Qualities: Addresses scalability, performance (e.g., “handle 1,000 users”).
• Guide Development: Blueprint for teams (e.g., “build server first”).
• Facilitate Communication: Aligns stakeholders (e.g., “client sees flow”).
Key Concepts
1. Components:
o Major building blocks (e.g., “Database,” “API Server”).
2. Connectors:
o How components interact (e.g., “HTTP,” “message queues”).
3. Architectural Styles:
o Patterns like:
▪ Client-Server: Browser requests, server responds (e.g., web app).
▪ Layered: UI, logic, data layers (e.g., “MVC”).
▪ Microservices: Independent services (e.g., “RSVP service”).
 4. Views:
o Perspectives:
▪ Logical: Classes, modules (e.g., “User, Event”).
▪ Physical: Hardware deployment (e.g., “AWS server”).
▪ Process: Runtime behavior (e.g., “request flow”).
Example: Campus Event App
• Architecture: Client-Server with MVC.
o Client: Browser (React) for “View Events.”
o Server: Node.js API for “RSVP.”
o Database: MongoDB for event data.
• Diagram:
text
CollapseWrapCopy
[Browser] --> HTTP --> [API Server] --> [MongoDB]
(View) (Controller) (Model)
• Qualities: Scalable (server clusters), maintainable (separate layers).
Process
1. Define Requirements:
o Functional (e.g., “RSVP”), non-functional (e.g., “fast response”).
2. Choose Style:
o E.g., “Client-Server for web access.”
3. Design Components:
o Break into parts (e.g., “UI, backend”).
4. Specify Interactions:
o E.g., “REST API calls.”
5. Validate:
o Check against goals (e.g., “scales to 500 users?”).
Notes
• Techniques: Use ADL (e.g., UML) or boxes-and-arrows diagrams.
• Challenges: Over-complexity (e.g., “too many services”), trade-offs (e.g., “speed vs. cost”).
• Student Relevance: Critical for system design (e.g., capstone), industry standard (e.g., AWS
architectures).
Tools
• Design: Enterprise Architect, Draw.io.
• Implementation: Frameworks matching style (e.g., Spring for layered).

Topic: Software Project Management

(Proposed as Topic 50, fitting after quality assurance and before maintenance)
What is Software Project Management?
Software Project Management (SPM) is the process of planning, organizing, directing, and controlling
resources (people, time, budget) to achieve specific software development goals within constraints. It
ensures projects are completed on time, within scope, and on budget. Ian Sommerville (Software
Engineering, 10th Edition) defines SPM as "the activities involved in ensuring that software is delivered
according to plan, meeting stakeholder expectations."
Example: For a library app, SPM involves scheduling “Borrow Book” feature development, assigning
developers, and tracking progress to meet a semester deadline.
Purpose
• Coordinate Efforts: Aligns team (e.g., “devs + testers”).
• Meet Deadlines: Delivers on time (e.g., “launch by finals”).
• Control Costs: Stays within budget (e.g., “$5K limit”).
• Manage Risks: Mitigates issues (e.g., “server delay”).
• Ensure Success: Achieves goals (e.g., “usable app”).
Key Activities
1. Project Planning:
o Define scope, schedule, budget (e.g., “3 months, $10K”).
o Create Work Breakdown Structure (WBS) (e.g., “design, code, test”).
2. Resource Allocation:
o Assign tasks (e.g., “Alice codes UI”).
3. Scheduling:
o Use Gantt charts/PERT (e.g., “design: week 1-2”).
4. Risk Management:
o Identify, mitigate (e.g., “backup server”).
5. Monitoring and Control:
o Track progress (e.g., “50% done”), adjust (e.g., “add tester”).
6. Closure:
o Deliver, review (e.g., “demo, lessons learned”).
Key Concepts
• Scope: What’s included (e.g., “RSVP, no analytics”).
• Milestones: Key deliverables (e.g., “MVP by week 6”).
• Critical Path: Longest task sequence (e.g., “design → code → test”).
• Earned Value Management (EVM): Tracks cost/schedule performance.
Example: Campus Event App
• Plan:
o Scope: “View Events, RSVP.”
o Schedule: 8 weeks (2 weeks design, 4 weeks code, 2 weeks test).
o Budget: $2,000 (team hours, hosting).
• Tasks:
o Week 1: Design UI (Alice).
o Week 3-6: Code API (Bob).
o Week 7: Test (Charlie).
• Monitoring:
o Weekly status: “Coding 75% done, on track.”
• Risk: “Server crash” → mitigated with cloud backup.
Process
1. Initiate:
o Define goals (e.g., “event app for students”).
2. Plan:
o Detail tasks, timeline (e.g., “Gantt chart”).
 3. Execute:
o Assign, start work (e.g., “code RSVP”).
4. Monitor:
o Check progress (e.g., “Jira updates”).
5. Close:
o Deliver, evaluate (e.g., “user feedback”).
Notes
• Techniques: Waterfall (linear), Agile (iterative).
• Challenges: Scope creep (e.g., “add features”), resource shortages.
• Student Relevance: Essential for capstone, industry PM roles (e.g., Scrum Master).
Tools
• Planning: MS Project, Trello.
• Tracking: Jira, Asana.
• Charts: Excel, GanttProject.

Topic: Software Maintenance

(Proposed as Topic 55, fitting after project management and before advanced topics)
What is Software Maintenance?
Software Maintenance is the process of modifying and updating a software system after its initial
deployment to fix bugs, improve performance, adapt to changes, or add new features. It ensures the
software remains functional and relevant over time. Ian Sommerville (Software Engineering, 10th
Edition) defines maintenance as "the activities required to keep a software system operational and
responsive to user needs after delivery."
Example: For a library app, maintenance might involve fixing a “Borrow Book” bug or adding a “Reserve
Book” feature based on user feedback.
Purpose
• Fix Issues: Correct defects (e.g., “crash on search”).
• Enhance Functionality: Add features (e.g., “notifications”).
• Adapt to Change: Update for new OS (e.g., “iOS 18”).
• Improve Performance: Optimize (e.g., “faster load”).
• **Extend Lifespan:“ Keep software usable (e.g., “avoid obsolescence”).
Types of Maintenance
1. Corrective:
o Fix bugs (e.g., “RSVP fails for 0 slots”).
2. Adaptive:
o Adjust to environment (e.g., “support Android 14”).
3. Perfective:
o Add features, improve (e.g., “add event filters”).
4. Preventive:
o Avoid future issues (e.g., “refactor messy code”).
Example: Campus Event App
• Scenario: Post-launch issues reported.
• Maintenance:
o Corrective: Fix “slots not updating”:
python
CollapseWrapCopy
def rsvp_event(event_id):
event = db.get_event(event_id)
if event.slots > 0:
event.slots -= 1 # Bug: wasn’t saving
db.save(event) # Fixed
return True
return False
• Perfective: Add “Cancel RSVP”:
python
CollapseWrapCopy
def cancel_rsvp(event_id):
event = db.get_event(event_id)
event.slots += 1
db.save(event)
return True
• Adaptive: Update for new API version.
Process
1. Problem Identification:
o User reports, logs (e.g., “crash on RSVP”).
2. Analysis:
o Assess impact (e.g., “affects all users?”).
3. Design Changes:
o Plan fix/feature (e.g., “add cancel logic”).
4. Implementation:
o Code updates (e.g., “fix slots”).
5. Testing:
o Verify (e.g., “unit test cancel”).
6. Deployment:
o Release update (e.g., “v1.1”).
7. Documentation:
o Update records (e.g., “changelog”).
Notes
• Challenges: Legacy code (e.g., “no docs”), regression bugs (e.g., “fix breaks search”).
• Cost: Often >50% of lifecycle cost.
• Student Relevance: Prepares for real-world upkeep (e.g., capstone updates), industry norm.
Tools
• Bug Tracking: Jira, Bugzilla.
• Version Control: Git.
• Testing: Selenium, pytest.

Topic: Software Estimation

(Proposed as Topic 25, fitting after requirements/architecture and before detailed planning)
What is Software Estimation?
Software Estimation is the process of predicting the effort, time, and resources required to develop a
software system based on available information (e.g., requirements, scope). It supports planning and
budgeting decisions. Ian Sommerville (Software Engineering, 10th Edition) describes estimation as "a key
activity in project planning that involves forecasting the size, effort, and schedule of a software project,
despite inherent uncertainties."
Example: For a library app, estimation predicts “Borrow Book” feature takes 40 hours, 2 weeks, and 1
developer.
Purpose
• Plan Accurately: Set realistic schedules (e.g., “6 weeks for MVP”).
• Allocate Resources: Determine staff, budget (e.g., “2 devs, $5K”).
• Manage Expectations: Align stakeholders (e.g., “launch by May”).
• Control Risks: Anticipate overruns (e.g., “add buffer time”).
Key Techniques
1. Expert Judgment:
o Use experience (e.g., “past app took 50 hours”).
2. Analogy-Based:
o Compare to similar projects (e.g., “like last semester’s app”).
3. Function Point Analysis (FPA):
o Count features (e.g., inputs, outputs) to estimate size (e.g., “10 FPs = 100 hours”).
4. COCOMO (Constructive Cost Model):
o Formula-based (e.g., Effort = a * Size^b * Multipliers).
5. PERT (Program Evaluation and Review Technique):
o Use optimistic, pessimistic, likely estimates (e.g., “20, 60, 40 hours → 40 avg”).
Example: Campus Event App
• Requirements: “View Events, RSVP.”
• Estimation:
o Size: 50 LOC (Lines of Code) or 5 FPs (Function Points).
o Effort (COCOMO Basic): Effort = 2.4 * (5)^1.05 ≈ 13 person-hours.
o Time (PERT):
▪ Optimistic: 1 week, Pessimistic: 3 weeks, Likely: 2 weeks.
▪ Avg = (1 + 4*2 + 3) / 6 ≈ 2 weeks.
o Resources: 1 developer, $500 hosting.
• Outcome: “2 weeks, 13 hours, $500” plan.
Process
1. Gather Data:
o Use requirements (e.g., “3 features”).
2. Choose Method:
o E.g., “FPA for small app.”
3. Estimate Size:
o Measure (e.g., “50 LOC”).
4. Calculate Effort:
o Apply model (e.g., “13 hours”).
5. Determine Time:
 o Schedule (e.g., “2 weeks”).
6. Validate:
o Cross-check (e.g., “expert says 15 hours”).
Notes
• Units: Person-hours, days, LOC, FPs.
• Challenges: Uncertainty (e.g., “vague reqs”), over-optimism.
• Student Relevance: Key for capstone planning, industry budgeting (e.g., “how long for v1?”).
Tools
• Estimation: COCOMO calculators, MS Excel.
• Tracking: Jira (effort logs), Trello.