Software Engineering Concepts and Process Models
Introduction to Software Engineering and Software Fundamentals
Software is defined as the product developed and maintained by software professionals. It comprises three core components:
Programs or instructions that provide required functions, features, and performance when executed.
Data structures that allow programs to store and manipulate information.
Descriptive information or documentation that explains the operation and use of the programs.
Applications of Software Types:
System Software:
Description: Manages computer hardware and provides services to other programs.
Four Modern Examples: Android, Windows 11, Linux, macOS.
Application Software:
Description: Helps users perform specific personal or business tasks.
Four Modern Examples: Microsoft 365, Google Workspace, Adobe Photoshop, TallyPrime.
Engineering and Scientific Software:
Description: Supports calculations, simulations, modelling, and technical analysis.
Four Modern Examples: MATLAB, Simulink, AutoCAD, ANSYS.
Embedded Software:
Description: Operates inside devices or machines to control their functions.
Four Modern Examples: Smartwatch software, vehicle-control software, smart-TV firmware, medical-device software.
Product-Line Software:
Description: A standard software product developed for use by many customers.
Four Modern Examples: Microsoft Word, Microsoft Excel, Adobe Premiere Pro, QuickBooks.
Web Applications:
Description: Runs through a web browser and provides services over a network.
Four Modern Examples: Gmail, Google Maps, Amazon, Canva.
Artificial-Intelligence Software:
Description: Uses intelligent algorithms to perform tasks such as learning, reasoning, and recognition.
Four Modern Examples: ChatGPT, Google Gemini, Microsoft Copilot, GitHub Copilot.
Definitions of Software Engineering:
General Definition: Software engineering is the application of engineering principles, systematic processes, technical methods, and supporting tools to develop, operate, maintain, and improve high-quality software economically and efficiently.
IEEE Definition: According to IEEE, software engineering is the application of a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. It also includes the study of these approaches.
The Evolving Role and Dual Role of Software
The Evolving Role of Software:
Software as a product: Provides useful functions and information directly to users (e.g., word-processing software, accounting software, database systems, multimedia applications).
Software as a vehicle for delivering a product: Controls computer hardware, supports communication, and helps create other programs (e.g., operating systems, network software, compilers, development tools).
Software as an information transformer: Produces, manages, modifies, displays, and transmits information (e.g., banking systems, business-information systems, online services, communication applications).
Software embedded in modern products: Built into devices and systems (e.g., automobiles, medical equipment, mobile phones, industrial-control systems).
Software delivered as a service: Provided through networks and web browsers instead of only as an installed product (e.g., web applications, online banking, cloud-based business systems, Internet services).
Continuous maintenance and evolution: Must be corrected, adapted, and enhanced as user needs, technology, and business requirements change.
Dual Role of Software:
Software as a Product: Used directly by users to perform useful tasks, processing, managing, displaying, and transmitting information.
Examples: Microsoft Word for document creation, TallyPrime for accounting, Adobe Photoshop for image editing, WhatsApp for communication.
Software as a Vehicle for Delivering a Product: Acts as the means through which other products, services, or computing functions are delivered. Controls hardware, supports communication, and aids in program creation.
Examples: Windows operating system controls computer hardware, Android manages mobile devices, Web browsers deliver online services, Compilers and development tools help create new software.
The Changing Nature of Software
Network-Based Software:
Connects users, devices, and services through the Internet or other networks, allowing access from almost anywhere.
Examples: WhatsApp for messaging and calls, Gmail for email, Zoom for online meetings.
Embedded Software:
Installed inside electronic products to control their functions; interacted with indirectly in daily life.
Examples: Software in smart TVs, washing machines, microwave ovens, smartwatches, automobile braking systems.
Web-Based Software:
Runs through a browser without requiring full installation on the user's device, providing services over the Internet.
Examples: Amazon for online shopping, Google Docs for document creation, online banking portals, railway or airline booking websites.
Mobile Application Software:
Designed for smartphones and tablets to perform communication, payment, shopping, learning, and entertainment while travelling.
Examples: Google Pay for payments, Google Maps for navigation, Swiggy for food delivery, Instagram for social networking.
Cloud-Based Software:
Stores data and performs operations on remote servers, allowing file access across multiple devices.
Examples: Google Drive for file storage, Microsoft 365 for office work, Dropbox for file sharing, Canva for online design.
Intelligent Software:
Uses artificial-intelligence techniques to recognize patterns, answer questions, make recommendations, and support decision-making.
Examples: ChatGPT for answering questions, Google Assistant for voice commands, Netflix for content recommendations, Google Photos for face and image recognition.
Real-Time Software:
Responds immediately to events or inputs, critical where delayed responses affect safety, accuracy, or service quality.
Examples: Google Maps traffic updates, digital payment confirmation, vehicle-control systems, patient-monitoring software in hospitals.
Continuously Evolving Software:
Regularly updated to add features, correct errors, improve performance, and strengthen security throughout its lifecycle.
Examples: Android system updates, WhatsApp feature updates, banking-app security updates, Windows updates.
Software Myths
Software myths are incorrect beliefs or misleading assumptions regarding software development, management, and maintenance that cause unrealistic expectations, poor planning, and project failures.
Management Myths:
Myth 1: Existing standards and procedures are enough for successful software development.
Reality: Standards and guidelines may be outdated, incomplete, or not properly followed.
Example: A company cannot complete a new mobile application successfully by only following old documentation without adapting to current technologies.
Myth 2: Adding more programmers will help complete a delayed project faster.
Reality: Adding new team members to a late project increases delays because existing developers must spend time training them, and communication complexity increases.
Example: Adding new developers near the deadline of a software project may slow progress instead of speeding it up.
Myth 3: Outsourcing software development removes management responsibility.
Reality: The organization must still monitor progress, requirements, quality, and communication even when development is outsourced.
Example: A company hiring an external team to develop an online shopping application must still review and manage the project.
Customer Myths:
Myth 1: A general statement of objectives is enough to start development.
Reality: Clear requirements and continuous communication between customers and developers are necessary; unclear requirements lead to incorrect software.
Example: A customer stating "develop a banking app" is insufficient; details about security, features, users, and transactions are required.
Myth 2: Requirements changes are easy because software is flexible.
Reality: Changes become expensive and difficult when introduced after design, coding, or testing has started.
Example: Adding a new payment feature after completing an e-commerce application requires redesign, coding changes, and additional testing.
Practitioner (Developer) Myths:
Myth 1: Once the program runs, the work is finished.
Reality: Software development continues beyond coding to include testing, documentation, deployment, maintenance, and updates.
Example: A mobile application requires regular updates after its initial release.
Myth 2: Quality cannot be checked until the software is executed.
Reality: Quality activities such as reviews, inspections, and verification can identify problems before executing the software.
Example: Design reviews can detect errors before programmers start coding.
Myth 3: The only important product is the working program.
Reality: Important supporting products are required, such as requirements documents, design models, test plans, and user manuals.
Example: A hospital management system requires documentation for future maintenance and user training.
Myth 4: Software engineering creates unnecessary documentation and slows development.
Reality: Software engineering practices improve quality, reduce errors, make maintenance easier, and help teams manage software effectively.
Example: System documentation helps new developers maintain an existing application.
A Generic View of Process and Process Framework
Software Process Definition: A collection of activities, actions, and tasks performed to develop a software product systematically and efficiently.
Process Framework Definition: Represents the overall structure for software development, providing a common foundation adaptable to project size, complexity, and type.
Components of Framework Activities:
Software engineering actions
Task sets
Work products
Quality assurance points
Project milestones
Five Major Framework Activities:
Communication: Development team interacts with customers and stakeholders to understand requirements, objectives, and expectations.
Example: Collecting requirements for a Library Management System from librarians and users.
Planning: Defines project roadmap, including cost, time, resources, schedule, and risk management.
Example: Preparing a development plan for modules such as book management and user management.
Modelling: Focuses on analyzing requirements and designing the software structure before coding begins.
Example: Designing database tables, system architecture, and user interfaces for a software system.
Construction: Involves developing the software through coding and testing to create a working product.
Example: Writing code for book search, issue/return functions, and testing the application.
Deployment: Delivers completed software to users and collects feedback for future improvements.
Example: Installing a Library Management System and providing training to librarians.
Software Engineering Actions & Task Sets:
Software Engineering Actions: Major development activities within framework activities.
Modelling Activity contains: Analysis action, Design action.
Construction Activity contains: Coding action, Testing action.
Task Sets: Specific work required to complete an action, comprising:
Work Tasks: Specific activities performed by developers (e.g., writing code, preparing design documents).
Work Products: Outputs produced during development (e.g., requirement document, design model, source code, test reports).
Quality Assurance Points: Activities ensuring software quality (e.g., reviews, inspections, testing).
Project Milestones: Important checkpoints measuring project progress (e.g., requirement approval, design completion, software release).
Umbrella Activities in Software Process
Umbrella activities support the software development process across all framework activities (communication, planning, modelling, construction, deployment) to manage projects, improve quality, control changes, and ensure success.
The Eight Umbrella Activities:
Software Project Tracking and Control:
Description: Monitors project progress against the schedule and objectives.
Library Management System Example: Manager tracks whether book registration, student/member management, book issue and return, fine calculation, and report generation modules are completed according to plan.
Risk Management:
Description: Identifies potential risks and prepares solutions to reduce impact.
Library Management System Example: Risks include loss of book records, unauthorized access to member data, and server failure. Solutions include regular database backups, user authentication, and data security mechanisms.
Software Quality Assurance (SQA):
Description: Ensures software meets quality standards and functional requirements.
Library Management System Example: Testing verifies that correct books are issued, fine calculation is accurate, search functions work properly, and member information is stored correctly.
Technical Reviews:
Description: Evaluates work products (requirements, design documents, code) to catch errors early.
Library Management System Example: Developers examine database design for books/members, UI design, and issue/return code before delivery.
Measurement:
Description: Collects process and product data to improve performance and quality.
Library Management System Example: Team measures number of books stored, registered users, errors found during testing, and system response time during searches.
Software Configuration Management (SCM):
Description: Controls software changes and maintains system versions.
Library Management System Example: Records changes made, author of changes, and previous versions when adding online book reservation features.
Reusability Management:
Description: Promotes identification and reuse of software components.
Library Management System Example: Reuses login, search, database connection, and report generation modules in other academic management systems.
Work Product Preparation and Production:
Description: Prepares and maintains required documentation and outputs.
Library Management System Example: Prepares requirement specification documents, system design documents, database design, testing reports, and user manuals for librarians.
Software Engineering: A Layered Technology
Software engineering is structured in layers where each layer supports the one above it:
Quality Focus (Foundation Layer):
Description: Foundation of software engineering ensuring reliability, maintainability, efficiency, and user satisfaction.
Purpose: Produces defect-free software, improves performance, maintains customer satisfaction.
Example: Testing a Library Management System to ensure correct book issue, return, and fine calculation.
Process Layer:
Description: Provides the framework for managing development activities and defines their sequence (Communication, Planning, Modelling, Construction, Deployment).
Purpose: Organizes development work, controls progress, manages resources and risks.
Example: Following a software process to develop a Library Management System from requirement collection to deployment.
Methods Layer:
Description: Provides technical approaches for requirement analysis, design, coding, testing, and maintenance.
Includes: Requirement analysis methods, design techniques, programming methods, testing methods, maintenance methods.
Example: Designing database tables for books and members prior to coding.
Tools Layer:
Description: Provides automated or semi-automated support for development activities; integrated tools form a Computer-Aided Software Engineering (CASE) environment.
Includes: Design tools, testing tools, version control tools, development environments.
Example: Using Git for version control, Visual Studio Code for programming, and automated testing tools.
Capability Maturity Model Integration (CMMI)
Developed by the Software Engineering Institute (SEI) at Carnegie Mellon University, CMMI integrates best practices to define process improvement guidelines, establish consistent processes, and assess organizational maturity.
CMMI Staged Maturity Levels:
Level 1 – Initial:
Characteristics: Unpredictable, poorly controlled, ad hoc processes. Success depends on individual skills and efforts. No standard processes, reactive problem solving, limited planning and documentation.
Library Management System Example: System developed without planning, documentation, or testing procedures; success relies entirely on individual developers.
Level 2 – Managed:
Characteristics: Projects are planned, monitored, and controlled. Basic project management practices established; requirements managed; schedule and resources planned; practices repeatable.
Library Management System Example: Team prepares requirement documents, creates project schedule, tracks progress, and maintains testing records.
Level 3 – Defined:
Characteristics: Processes are well-documented, standardized, and followed across the organization. Standard procedures customized for project needs; guidelines maintained; training provided.
Library Management System Example: Organization follows standard processes for requirements, design, coding standards, testing, and documentation across all systems.
Level 4 – Quantitatively Managed:
Characteristics: Processes measured and controlled using data and metrics. Quantitative techniques predict and improve performance; quality, defects, cost, and schedules controlled.
Library Management System Example: Team measures system response time, defect counts, testing efficiency, and user satisfaction to improve quality.
Level 5 – Optimizing:
Characteristics: Focus on continuous process improvement through innovation, feedback, root cause analysis, and technology adoption.
Library Management System Example: System improved by introducing online book reservations, mobile access, AI recommendations, and automated notifications based on user feedback.
Benefits of CMMI:
Better project planning and tracking.
Fewer defects and improved software quality.
Enhanced customer satisfaction.
Reduced development costs and rework.
Stronger risk management.
Software Developalment Process Models: Prescriptive Process Models
Prescriptive process models prescribe a defined set of activities, actions, tasks, work products, and quality checks to provide a structured roadmap for planning, designing, coding, testing, and deploying software.
Waterfall Model:
Introduced by Dr. Winston W. Royce in in "Managing the Development of Large Software Systems".
Linear sequential model where each predefined phase must be completed and reviewed before moving to the next; output of one phase becomes input for the next.
Five Major Activities:
Communication: Gathers complete requirements, interacts with customers, defines project scope.l
Work Products: Sofware Requirement Specification (SRS) Document, Requirement list, User requirement document.
Planning: Estimates resources, time, cost, schedules, and risks.
Work Products: Project Plan, Development Schedule, Cost Estimation Report, Risk Management Plan.
Modelling: Converts requirements into software architecture, database structure, and UI design.
Work Products: Software Design Document (SDD), System Architecture Diagram, Database Design Diagram (ER Diagram), User Interface Design.
Construction: Translates designs into code and conducts unit/integration testing and debugging.
Work Products: Source Code, Executable Software, Test Cases, Test Reports, Debugging Reports.
Deployment: Installs software, trains users, operates system, collects feedback, performs maintenance.
Work Products: Deployed Software System, User Manual, Training Documents, Maintenance Reports, Updated Software Versions.
Advantages:
Simple and easy to understand.
Easy project management via clear deliverables per phase.
Clear documentation produced at every phase.
Well-defined milestones act as checkpoints.
Suitable for stable requirements.
Better quality control through scheduled reviews.
Easy cost and time estimation.
Prototype Model:
Definition of Prototype: An early sample, rough working model, or release built to test concepts before developing the final version.
Definition of Prototype Model: SDLC model where a working prototype is built quickly, evaluated by users, and iteratively refined until the final system is developed. Ideal for unclear requirements.
Seven Steps:
Requirements Gathering and Analysis: Collect basic requirements and objectives.
Quick Design: Focuses on major visible aspects like input/output and UI layouts.
Build Prototype: Develop simplified working model.
Customer Evaluation of Prototype: Customer tests model and gives feedback.
Prototype Refinement: Developers update features, fix issues, and refine prototype iteratively.
Final System Development: Full coding, detailed design, system testing, and documentation.
Testing and Maintenance: Thorough testing, deployment, and ongoing bug fixes/updates.
Advantages:
Early working model for user evaluation.
Clarifies requirements through practical feedback.
Reduces risk of unclear requirements.
Improves developer-customer communication.
Increases customer involvement and satisfaction.
Limitations:
Can be time-consuming and costly.
Developers may compromise final system quality for prototype speed.
Frequent change requests delay completion.
Prototype cost is wasted if discarded.
Requires continuous customer participation.
Incomplete documentation from frequent changes.
Hard to accommodate all change requests.
Spiral Model:
Proposed by Barry Boehm in as an evolutionary, risk-driven process model combining Waterfall and Prototyping features.
Progresses through repeated cycles (spirals/iterations), each producing an improved product version with a primary focus on risk identification and reduction.
Four Phases per Spiral:
Objectives Determination: Identifies iteration goals, analyzes requirements, determines alternative approaches and constraints.
Output: Requirement specification and project objectives.
Risk Analysis and Resolution: Evaluates technical/project risks and creates mitigation strategies or prototypes.
Output: Risk analysis report and risk mitigation plan.
Specific Risk Examples & Solutions:
Data loss risk: Implement database backup and recovery mechanisms.
Security risk: Provide user authentication and access control.
Performance risk: Use efficient database design for faster searching.
Develop Next Version of Product: Architecture design, coding, integration, testing, and debugging.
Output: Working software version.
Customer Evaluation: Customer reviews software, provides feedback, and plans the next iteration.
Output: Customer feedback and plan for the next iteration.
Advantages: Strong risk management, handles changing requirements, continuous customer feedback, suitable for large/complex projects.
Limitations: Expensive and time-consuming, requires risk analysis expertise, complex to manage, unsuitable for small/low-risk projects.
Library Management System Spiral Steps:
Spiral 1 (Basic Prototype): Objectives = basic requirements (books, members, search); Risk = database selection/storage; Development = login, book entry, search modules; Evaluation = librarian reviews prototype.
Spiral 2 (Core System): Objectives = book issue/return, member management; Risk = data accuracy and security; Development = issue/return module, transaction records; Evaluation = user testing and feedback.
Spiral 3 (Enhancement): Objectives = fine calculation, reports; Risk = performance and security; Development = fine calculation, notifications, reports; Evaluation = librarian evaluates features.
Spiral 4 (Final Product): Objectives = finalize deployment requirements; Risk = deployment/maintenance; Development = testing, installation, system release; Evaluation = user approval of final system.
Incremental Development Model
Software is divided into time-boxed increments. Each increment is a complete development cycle delivering a working, functional software version with a specific feature set.
Five Activities Performed in Each Increment:
Analysis: Identifies requirements, collects user needs, prioritizes functional/non-functional features for the current time-box.
Design: Converts requirements into architecture, database structure, module design, and UI layouts.
Coding: Writes source code, develops modules, integrates with prior increments, and performs code reviews.
Testing: Performs unit and integration testing, verifies features, and fixes defects.
Deployment: Installs software release, delivers increment to users, trains users, collects feedback.
Library Management System Increments:
Increment 1 (Basic System):
Analysis: Login, book registration, book search.
Design: Basic database and user interface design.
Coding: Login, book entry, and search modules.
Testing: Test login and book functions.
Deployment: Release basic system.
Increment 2 (Core Functions):
Analysis: Member registration, book issue and return, transaction records.
Design: Design member and transaction modules.
Coding: Develop member management and issue/return modules.
Testing: Test member and issue/return functions.
Deployment: Release updated system.
Increment 3 (Advanced Features):
Analysis: Fine calculation, reports, notifications.
Design: Design advanced modules.
Coding: Develop fine calculation, report, and notification features.
Testing: Test advanced features.
Deployment: Release enhanced system.
Increment 4 (Final System):
Analysis: Online reservation, barcode support, mobile access.
Design: Design final integrated system.
Coding: Develop and optimize complete system.
Testing: Perform final system testing.
Deployment: Deploy complete Library Management System.
Concurrent Development Model
Also called the Concurrent Engineering Model. Allows multiple software development activities (Analysis, Design, Coding, Testing, Deployment) to be performed simultaneously across different teams.
Activities Performed:
Analysis: Examines requirements and produces the SRS document.
Design: Converts SRS into technical blueprints (architecture, database, interfaces).
Coding: Translates design into executable code with unit testing.
Testing: Verifies functionality, security, and performance; corrects defects.
Deployment: Configures environment, migrates data, trains users, installs system.
States of an Activity:
Activities transition through dynamic states showing current progress, supporting tracking, managing changes, and coordinating concurrent work.
Importance of Activity States ( reasons):
Shows Status
Project Monitoring
Problem Identification
Team Coordination
Change Management
Concurrent Execution
Project Visibility
Decision Making
Advantages:
Reduced overall development time.
Better resource utilization across multiple teams.
Easy change management without project shutdown.
Early problem detection.
Improved project monitoring via activity states.
Supports large, complex projects.
Improved cross-team communication.
High flexibility.
Disadvantages:
Complex management overhead.
Requires highly skilled managers.
Communication challenges and conflicts.
Higher coordination costs (frequent reviews/meetings).
Activity dependency issues causing delays.
Difficult tracking across multiple states.
Overly complex for small projects.
Demands continuous collaboration.
Component-Based Development Model
Also known as Component-Based Software Engineering (CBSE). Develops applications by selecting, adapting, and integrating pre-existing, reusable software components.
Software Component Definition: An independent, reusable, replaceable software unit performing a specific function and communicating through well-defined interfaces.
Objectives: Reduce development time and cost, improve reliability, promote reuse, increase productivity.
Nine Process Activities:
Requirements Analysis: Determines system requirements and potential for reusing components.
Architectural Design: Defines overall system structure, interface protocols, and communication mechanisms to support component integration.
Component Identification: Searches component libraries, open-source repositories, commercial vendors, third-party services, and past projects.
Component Qualification: Evaluates components for functionality, reliability, performance, security, compatibility, cost, and vendor support.
Component Adaptation: Modifies components to fit system needs via three techniques:
White-Box Adaptation: Source code is accessible and directly modified.
Grey-Box Adaptation: Internal behavior modified via configuration, inheritance, or extension mechanisms.
Black-Box Adaptation: Source code unavailable; adapted externally using wrappers, connectors, or interfaces.
Component Composition: Assembles components while ensuring compatible interfaces, matching data formats, and correct control flows.
Integration and Testing: Integrates components and runs interface, integration, system, performance, security, and regression tests.
System Deployment: Installs system, configures servers/databases, migrates data, connects external services, and trains users.
Maintenance and Component Updating: Updates or replaces components due to security flaws, technology updates, vendor discontinuation, or performance issues.
Advantages:
Reduced development time.
Lower development costs.
Improved software reliability (reused code is pre-tested).
Increased developer productivity.
Easy component-level maintenance.
Enhanced overall software quality.
Rapid application delivery.
Disadvantages:
Suitable components may be unavailable.
Incompatible interfaces from different vendors.
Lack of source code access.
Security vulnerabilities in third-party software.
Vendor lock-in/dependency.
Licensing constraints.
High integration complexity.
Component updates may break backwards compatibility.
Agile Development and Agile Models
Founded in February by software professionals in Snowbird, Utah, USA, who authored the Agile Manifesto.
Focuses on iterative delivery in short cycles (sprints), customer collaboration, rapid adaptation to changes, and functional software.
Four Values of the Agile Manifesto:
Individuals and interactions over processes and tools: Emphasizes team communication and collaboration.
Working software over comprehensive documentation: Prioritizes delivery of functional code.
Customer collaboration over contract negotiation: Engages customers continuously throughout development.
Responding to change over following a plan: Adapts readily to changing requirements.
Twelve Principles of the Agile Manifesto:
Customer Satisfaction Through Early and Continuous Delivery.
Welcome Changing Requirements (even late in development).
Frequent Delivery of Working Software (shorter time scales).
Business and Developers Work Together daily.
Build Projects Around Motivated Individuals (provide environment and trust).
Face-to-Face Communication is the most effective method.
Working Software is the Primary Measure of Progress.
Maintain a Sustainable Development Pace indefinitely.
Continuous Attention to Technical Excellence and Good Design.
Simplicity is Essential (maximizing the amount of work not done).
Self-Organizing Teams Produce Best Solutions.
Regular Reflection and Continuous Improvement (process tuning).
Ten Types of Agile Models:
Extreme Programming (XP): Focuses on technical excellence, pair programming, TDD, and frequent releases.
Scrum: Iterative framework utilizing short Sprints, Product/Sprint Backlogs, and daily meetings.
Adaptive Software Development (ASD): Uses Speculate, Collaborate, and Learn phases for dynamic projects.
Dynamic Systems Development Method (DSDM): Focuses on rapid delivery within fixed time/cost constraints.
Feature Driven Development (FDD): Client-valued feature-centric incremental approach.
Crystal Methods: Family of adaptable, communication-centric methodologies scaled to project size.
Lean Software Development: Eliminates waste, optimizes efficiency, and maximizes customer value.
Kanban: Visual workflow management focused on continuous flow and Work-In-Progress (WIP) limits.
Agile Unified Process (AUP): Lightweight Agile variant of the Unified Process.
Scaled Agile Framework (SAFe): Scales Agile principles across large enterprises.
Extreme Programming (XP)
Created by Kent Beck to deliver frequent releases, improve quality, and respond rapidly to changing requirements.
Five Core Values of XP:
Simplicity: Breaks complex processes into small, manageable steps.
Communication: Continuous collaboration between developers and customers.
Feedback: Frequent working demonstrations yield rapid user feedback.
Respect: Mutual respect and support among team members.
Courage: Honest feedback, estimating, and willingness to adapt/refactor.
XP Methodology Process:
User Stories: Short, plain-language descriptions of user needs written on index cards by customers (e.g., "As a visitor, I want to login, in order to access the website.").
Release Planning: Estimates story delivery times (in weeks), schedules releases, and prioritizes user stories.
Iteration: Short execution cycles (few weeks) prioritizing high-risk, high-value stories first.
Key XP Practices:
Pair Programming: Two developers work at one workstation; one writes code while the other reviews.
Test-Driven Development (TDD): Automated unit tests are written before functional code.
Refactoring: Cleaning and restructuring code without altering external behavior.
Simple Design: Implementing minimal design necessary for current tasks.
Continuous Integration: Merging code daily/frequently to spot integration errors early.
Acceptance Testing: Written by business analysts/testers to validate user story conditions.
Example Scenario ("As a visitor, I want to login, in order to access the website."):
Condition 1: Given a visitor, when login with an existing account -> Expected Result: User can access the website.
Condition 2: Given a visitor, when login with an undefined account -> Expected Result: User cannot access the website.
Small Releases: Releases every weeks delivering fully tested, functional, production-ready software.
Applicability of XP:
Frequently changing requirements.
Active, available customer participation.
Small, co-located development teams.
Skilled, disciplined developers.
Advantages: Frequent working releases, high code quality, responsive to change, strong customer involvement, early bug detection.
Limitations: Requires intense customer presence, hard to scale to large/distributed teams, relies heavily on high developer skill, minimal documentation.
Scrum Model
An iterative Agile framework dividing software development into short cycles called Sprints (lasting weeks).
Scrum Process Stages:
Product Backlog: Prioritized list of all product features maintained by the Product Owner (e.g., User login, Book search, Book issue/return, Fine calculation).
Sprint Planning: Team selects top backlog items for the sprint and defines a Sprint Goal.
Sprint Backlog: Selected features broken down into specific developer tasks (e.g., Design UI, create tables, write login code, test authentication).
Sprint Execution: Development, testing, and component integration during the sprint cycle.
Daily Scrum Meeting: -minute daily standup answering: What was done yesterday? What will be done today? What blockers exist?
Sprint Review: Demonstrating working software increment to stakeholders and gathering feedback at the end of the sprint.
Potentially Shippable Increment: Functional, tested code produced at sprint end (e.g., Sprint 1 = Login + Search; Sprint 2 = Issue/Return; Sprint 3 = Fine Calculation).
Sprint Retrospective: Team reviews internal process, discussing what went well, problems faced, and continuous improvements for the next sprint.
Scrum Roles:
Product Owner: Manages product backlog, defines priorities, represents business/customer interests.
Scrum Master: Facilitates Scrum processes, clears impediments, enforces practices.
Development Team: Cross-functional, self-organizing team that designs, builds, and tests software increments.
Core Principles: Transparency, Inspection, Adaptation.
Kanban Model
An Agile workflow management method based on continuous flow, visual tracking, and Work-In-Progress (WIP) limits rather than fixed-length sprints.
Kanban Board Flow Stages:
Backlog -> To Do -> In Progress -> Testing -> Done -> Delivered Software
Process Activities:
Backlog: Prioritized repository of all pending features/stories.
To Do: Selected high-priority tasks ready for immediate development.
In Progress: Active development stage. Strictly managed using Work-In-Progress (WIP) limits to prevent multitasking overload.
Testing: Functional verification and bug fixing of completed code.
Done: Verified tasks meeting definition of done.
Delivered Software: Features deployed into production.
Key Practices:
Visualize Work (Kanban board).
Limit Work in Progress (WIP limits).
Manage Flow.
Make Policies Explicit.
Continuous Improvement.
Library Management System Kanban Example:
Backlog: Member registration, book issue, fine calculation.
To Do: Book issue module selected.
In Progress: Coding book issue logic.
Testing: Testing issue and return functionality.
Done: Feature completed successfully.
Delivered: Released to library users.
Advantages: Easy visual monitoring, continuous delivery, high flexibility for changing priorities, improves efficiency, reduces bottlenecks.
Limitations: Unsuitable without disciplined team management, lack of fixed milestones complicates long-term estimation, requires supplementary tools for massive projects.