Lecture No.

3
Principles of Software Engineering
by
Kalimullah Khan
Assistant Professor
• Lecture Outlines
• Software Development Life Cycle
• Different Phases of SDLC
• Selecting SDLC for a project
• Process Models
• Selection criteria of process model for a project
• The Build and Fix Process Model
• Advantages and disadvantages of build and fix model
• When to use build and fix model
Software development life cycle (SDLC)
• The SDLC is a structured approach to software development that outlines the phases and activities
involved in creating and maintaining software systems.
• It serves as a guideline to manage the entire process from initial concept through to deployment
and maintenance.
• The Software Development Life Cycle (SDLC) is a systematic process used to develop software
applications.
• It consists of a series of phases, each with specific activities, that guide the development process
from initial conception to final delivery and maintenance.
• The SDLC ensures that the software
• meets user requirements,
• is delivered on time,
• and is of high quality.
 Different Phases of SDLC
• Pressman outlines several key phases in the SDLC, which are typically followed in a sequential or
iterative manner:

Planning

• Objective: Define the scope, objectives, and feasibility of the project.

• Activities: Project initiation, requirement gathering, risk assessment, and project planning.
• Deliverables: Project plan, feasibility report, and initial requirements document.
Analysis
• Objective: Understand and document what the software must do.
• Activities: Requirements elicitation, analysis, and specification.
• Deliverables: Requirements specification document, use cases, and user stories.

Design
• Objective: Define how the software will be built.
• Activities: Architectural design, detailed design, and design validation.
• Deliverables: Design documents, architecture diagrams, and detailed design specifications.
Implementation (Coding)
• Objective: Develop the software according to the design specifications.
• Activities: Coding, unit testing, and integration.
• Deliverables: Source code, compiled code, and unit test results.

Testing
• Objective: Ensure the software meets the specified requirements and is free of defects.
• Activities: System testing, acceptance testing, and regression testing.
• Deliverables: Test plans, test cases, test reports, and defect logs.
Deployment
• Objective: Deliver the software to users and ensure it is operational in the target environment.
• Activities: Installation, configuration, training, and user support.
• Deliverables: Deployed software, installation guides, and training materials.

Maintenance
• Objective: Provide ongoing support and enhancements after the software is deployed.
• Activities: Bug fixing, updates, and performance improvements.
• Deliverables: Updated software, maintenance logs, and enhancement reports.
Process Models
1. Waterfall Model
• The Waterfall model is a linear and sequential approach where each phase of the SDLC must be
completed before the next phase begins. It includes phases like requirements, design,
implementation, testing, deployment, and maintenance.
Characteristics:
• Sequential: Each phase is completed in a strict order.
• Documentation-Heavy: Detailed documentation is produced at each phase.
• Inflexible: Changes are difficult to incorporate once a phase is completed.
• Best For: Projects with well-defined requirements that are unlikely to change.
Water Fall Model Example: Creating a Recipe Book App
Description: Develop a mobile app to store and organize recipes.
Processes:
Requirements: Gather requirements (e.g., features like recipe input, search, and category
organization).
Design: Design the app layout and database schema.
Implementation: Code the app based on the design.
Testing: Test the app to ensure all features work as intended.
Deployment: Release the app to users.
Maintenance: Fix any issues that arise after launch.
Why Waterfall Fits: The project has clear, fixed requirements, and each phase follows a sequential
order. Changes are minimal, and the linear approach suits the straightforward nature of the app.
2. Agile Model
• Description: The Agile model emphasizes iterative development, where the software is developed
in small, manageable increments called sprints. Each sprint produces a potentially shippable
product increment.
• Typically lasting 1 to 4 weeks. During a sprint, a team works on a set of tasks or user stories to
produce a specific deliverable.
Characteristics:
• Iterative: Development is carried out in repeated cycles (Sprints).
• Flexible: Requirements can evolve based on feedback.
• Collaborative: Frequent communication with stakeholders and users.
• Best For: Projects with evolving requirements and the need for frequent feedback.
Example Agile Model: Building a Personal Finance Tracker
Description: Develop a personal finance app with budgeting and expense tracking features.
Processes:
Sprint 1: Develop basic budgeting features and release to a small group of users.
Sprint 2: Collect feedback and add expense tracking features.
Sprint 3: Incorporate additional user requests and improve the user interface.
Why Agile Fits: The app benefits from iterative development, allowing for frequent updates and
adjustments based on user feedback. Agile’s flexibility helps accommodate changes and new feature
requests.
3. Spiral Model
• Description: The Spiral Model, developed by Barry Boehm.
• The Spiral model combines iterative development with systematic risk assessment. It involves
repeated cycles (or spirals) of planning, risk analysis, engineering, and evaluation.

Characteristics:
• Iterative: Repeated cycles of development with regular revisions.
• Risk-Focused: Emphasizes risk analysis and management.
• Flexible: Can accommodate changes and evolving requirements.
• Best For: Large, complex projects with high risks.
Example of Spiral Model: Airline Reservation System

Description: Developing a comprehensive airline reservation system that includes booking, ticketing,
seat selection, and customer support.

Why Spiral Fits: The system is complex and involves significant risk due to its scale and the need for
integration with various external systems (e.g., payment gateways, global distribution systems). The
Spiral model’s focus on risk analysis and iterative development helps manage these complexities and
uncertainties.
4. Incremental Model
• Description: The Incremental model divides the project into smaller, manageable parts or
increments. Each increment is developed and delivered separately, adding functionality
progressively.

Characteristics:
• Phased Delivery: Parts of the system are delivered incrementally.
• Feedback-Driven: Each increment can be adjusted based on user feedback.
• Manageable: Smaller, incremental releases reduce complexity.
• Best For: Projects where partial functionality can be delivered early and additional features added
over time.
Example of Incremental Model: E-commerce Website

• Description: Building an e-commerce platform with core features such as product listings, shopping
cart, and checkout process.

• Why Incremental Fits: The website can be developed in increments, starting with basic
functionality (e.g., product catalog and shopping cart) and adding additional features (e.g., user
accounts, reviews, and recommendations) over time.
• This approach allows for partial deployment and user feedback, helping prioritize features and
manage the development process more effectively.
Selection criteria of process model for a project
Selection Criteria for a Process Model involve evaluating various project management
methodologies or models to determine the most suitable one for a specific project.
The choice depends on various factors, including project size, complexity, goals, and the nature of
the work.
Here’s a breakdown of the criteria and an example to illustrate the selection process.

Key Selection Criteria for a Process Model

Project Requirements:
Complexity: Projects with complex and evolving requirements may benefit from agile
methodologies, whereas projects with well-defined and stable requirements might suit traditional
models like Waterfall.
Scope: The clarity and stability of project scope can influence the choice. Well-defined projects may
use Waterfall, while projects with evolving scope might use Agile.
• Project Size:
• Small Projects: Agile methodologies like Scrum or Kanban can be effective for smaller projects due
to their flexibility and iterative nature.
• Large Projects: Larger projects with multiple teams and interdependencies may require more
structured approaches like Waterfall or the V-Model.

• Stakeholder Involvement:
• Frequent Feedback: Agile models are suitable if frequent feedback from stakeholders is required
throughout the project lifecycle.
• Limited Interaction: Traditional models might be more appropriate if stakeholder involvement is
limited to specific phases.
• Time Constraints:
• Tight Deadlines: Agile methods can help with tight deadlines by delivering incremental
improvements quickly.
• Long-Term Projects: For projects with extended timelines, models like Waterfall might be used,
focusing on a structured approach with detailed planning.

• Risk Management:
• High Risk: Agile methodologies allow for continuous risk management and adjustments throughout
the project, making them suitable for high-risk projects.
• Low Risk: For projects with well-understood risks and low uncertainty, a more linear approach like
Waterfall can be sufficient.
• Team Experience:

• Experienced Teams: Teams familiar with Agile practices might prefer Scrum or Kanban.
• Less Experience: Teams less familiar with Agile methodologies might opt for more traditional
models until they gain the necessary expertise.
• Example: Selecting a Process Model
• Scenario:
• A company is developing a new e-commerce website. The project has a clear initial scope but may
involve frequent updates based on user feedback and market changes.

• Project Details:
• Complexity: Medium
• Size: Medium to Large
• Stakeholder Involvement: High
• Time Constraints: Moderate deadlines with periodic releases
• Risk: Medium, with potential for changing requirements
• Team Experience: Mixed experience with Agile methodologies
• Process Models Considered:
• Waterfall Model:
• Pros: Well-structured, suitable for projects with clear and stable requirements.
• Cons: Less flexibility to accommodate changes once the project is underway.
• Agile Model (Scrum):
• Pros: Highly flexible, allows for iterative development and frequent stakeholder feedback.
• Cons: Requires ongoing stakeholder involvement and can be challenging to manage without
experience.
• Kanban:
• Pros: Provides continuous delivery and flexibility in managing work.
• Cons: May lack the structured approach needed for coordinating larger teams.
• Decision:
• Given the project’s requirements for frequent updates based on user feedback, the potential for
evolving requirements, and the need for moderate deadlines with periodic releases, Scrum is
chosen as the most suitable process model.
• Justification for Scrum:
• Flexibility: Scrum’s iterative approach allows for regular updates and adjustments based on
stakeholder feedback and changing requirements.
• Stakeholder Involvement: Scrum encourages frequent interaction with stakeholders through
regular sprint reviews, ensuring the project aligns with user needs.
• Risk Management: Scrum’s iterative nature helps manage risks by delivering incremental
improvements and incorporating feedback early and often.
• Team Adaptation: The team, while having mixed experience, can leverage Scrum’s structure and
guidance to enhance their agile practices and improve over time.
• Implementation:

• Sprint Planning: Define a product backlog and plan sprints focusing on features and updates that
are critical for the e-commerce website.
• Daily Scrum: Hold daily stand-up meetings to track progress and address any obstacles.
• Sprint Reviews: Conduct reviews at the end of each sprint to demonstrate progress and gather
feedback from stakeholders.
• Sprint Retrospectives: Regularly review the process to identify areas for improvement and adapt
practices accordingly.
The Build and Fix Process Model
• The Build and Fix model is a simple and straightforward approach where software is built quickly to
meet immediate needs, and then improved or "fixed" iteratively based on user feedback and
emerging issues.
• There is no formal planning, design, or structured development process; instead, the focus is on
quickly creating a working version of the software and then making modifications as needed.
Key Characteristics:
Rapid Development: The focus is on quickly building a functional version of the software.
Ad-hoc Improvements: Changes and improvements are made on the fly based on feedback and
observed issues.
Minimal Documentation: There is little to no formal documentation or planning at the beginning.
Reactive Changes: Modifications are made reactively as problems or new requirements arise, rather
than proactively through a structured process.
Process Steps:
Build: Create an initial version of the software to meet the basic needs.
Release: Deploy the initial version to users or stakeholders.
Fix: Address issues, bugs, and new requirements as they arise, making changes to the software.
Repeat: Continue to make incremental changes and improvements, releasing updated versions as
needed.
Example Project: A simple internal tool for tracking employee work hours.

Initial Build: Develop a basic tool with minimal features for logging hours.
Release: Deploy the tool to employees for use.
Fix: Based on feedback, fix bugs (e.g., incorrect hour calculations), add new features (e.g., reporting),
and make improvements (e.g., user interface changes).
Repeat: Continue to update the tool with fixes and additional features as needed.
Advantages and Disadvantages of Build and Fix Model:
Pros:
Quick to Implement: Can rapidly deliver a working product.
Flexibility: Easy to adapt and make changes based on immediate needs and feedback.
Low Initial Investment: Requires minimal upfront planning and documentation.
Cons:
Lack of Structure: Can lead to poorly organized code and insufficient design.
Unpredictable Quality: Continuous changes can introduce new bugs or create unstable software.
Limited Scalability: Not well-suited for large or complex projects due to the lack of formal planning
and design.
When to use build and fix model
The Build and Fix model is suitable for:

Small, Simple Projects: Where the scope and complexity are limited, and risks are low.
Prototyping: To quickly develop a proof of concept or prototype.
Short-Term Needs: When a rapid turnaround is required and formal processes would slow down
development.
Exploratory Development: For projects with evolving requirements or experimental goals.
Minimal Documentation: Where extensive planning and documentation are not critical.
Rapid Iteration: When immediate feedback and quick adjustments are essential.
Thank You