Marka University

Unit1: Introduction to software engineering:

 Software is a set of instructions used to get inputs and process them to produce the desired output.
 It also includes a set of documents, such as the software manual, Source Code, Executables, Design
Documents, Operations, and System Manuals and Installation and Implementation Manuals.
Software Engineering
A few important definitions given by several authors and institutions are as follows:
Definition:
Software Engineering is the application of a systematic, disciplined, scientific approach to the
development, operation and maintenance of software.
OR
Software Engineering is a discipline whose aim is the production of fault free software that
satisfies the user’s needs and that is delivered on time and within budget.
Goals of Software Engineering:
The primary goals of Software Engineering is
1. To improve the quality, reliability of software.
2. To increase productivity.
3. To increase the job satisfaction of software engineers, etc.
PROGRAMS VERSUS SOFTWARE PRODUCTS
Programs
 A program is a combination of source code and object code.
 A program is a subset of software and it becomes software only if
documentation and operating procedure manuals are prepared.
 Program = Source Code + Object Code
Software Products
 A software product consists not only of the program code but also
of all the associated documents, such as the requirements
specification documents, the design documents, the test
documents, and the operating procedures, user manuals and
operational manuals, etc.
 Software = Program + Documentation + Operating Procedures
Programs versus Software Products
The various differences between a program product and a software product are given in Table.
S.
No.
Programs vs Software Products
1. Programs are developed by individuals
for their personal use.
# A software product is usually developed by a group of
engineers working as a team.
2 Usually small in size
#Usually large in size
3 Single user
#Large number of users
4 Single developer
#Team of developers
5 Lack proper documentation
#Good documentation support
6 Adhoc development
#Systematic development
7 Lack of user interface
#Good user interface
8 Have limited functionality
#Exhibit more functionality

What is SDLC?
SDLC (Software Development Life Cycle) is a structured process used to develop software.
It helps developers build software systematically, efficiently, and with minimal errors.

Think of it like building a house: you first plan, then design, then construct, and finally
maintain it. Software development works the same way.

Why SDLC is Important

1. Ensures software meets user needs.
2. Reduces project cost and time.
3. Improves software quality.
4. Provides a clear roadmap for developers.
5. Helps manage risk and changes during development.

Phases of SDLC

1. Requirement Analysis

• Goal: Understand what the users need from the software.

• Activities:
o Talk to users and stakeholders.
o Gather functional and non-functional requirements.
• Outcome: A requirement specification document (SRS).

Example: For a banking app, users may want to check balance, transfer money, and get
notifications.

2. Feasibility Study

• Goal: Check if the project is possible and worth doing.

• Types of feasibility:
o Technical: Can we build it with current technology?
o Economic: Is it affordable?
o Operational: Will it work in real life?
o Legal: Are there any legal issues?
• Outcome: A feasibility report (Yes/No + recommendations).
Example: Can we make a secure mobile banking app with our current team and budget?

3. System Design

• Goal: Plan how the system will work.

• Activities:
o Create architecture diagrams.
o Design database, user interface, and system flow.
• Outcome: Design document that developers follow.

Example: Designing screens for login, fund transfer, and notifications in the banking app.

4. Implementation / Coding

• Goal: Write the actual software code.

• Activities:
o Developers write code according to design.
o Use programming languages and tools.
• Outcome: Working software modules.

Example: Writing code in Java or Python to handle login, transactions, and notifications.

5. Testing

• Goal: Ensure the software works correctly and is bug-free.

• Types of testing:
o Unit testing – test individual modules.
o Integration testing – test combined modules.
o System testing – test the whole system.
o User acceptance testing (UAT) – final approval from users.
• Outcome: A tested, reliable software ready for deployment.

6. Deployment

• Goal: Release the software to users.

 • Activities:
o Install software on user systems.
o Train users if necessary.
• Outcome: Users start using the software.

Example: Launch the banking app on Google Play Store or App Store.

7. Maintenance

• Goal: Keep software updated and error-free after release.

• Activities:
o Fix bugs.
o Add new features.
o Improve performance.
• Outcome: Long-term support and software updates.

Example: Adding a new feature like biometric login or updating security protocols in the
banking app.

Key Points to Remember

• SDLC is step-by-step: You cannot skip steps.
• It ensures quality, efficiency, and user satisfaction.
• Phases may overlap in modern models like Agile.
• SOFTWARE-DEVELOPMENT LIFE-CYCLE
• – The software-development life-cycle is used to help the development of a large software product
• in a systematic, well-defined, and cost-effective way.
• – It goes through a series of phases from start to end. This process is called the Software-
• Development Life-Cycle.
• – The software development life-cycle consists of several phases.
• – These are:
• o Feasibility study
• o Project analysis (Requirements analysis and specification)
• o System design (Design)
• o Coding
• o Testing
• o Implementation
• o Maintenance
• Software Development Life Cycle Models
• – A software life cycle model (also called process model) is a descriptive and diagrammatic
• representation of the software life cycle.
• Need for a software life cycle Model:
• – The development team must identify a suitable life cycle model to develop a project..
– Without using of a particular life cycle model the development of a software product may lead to
 • project failure.
• Different software life cycle models:
• – Various kinds of process models:
•  Classical Waterfall model
•  Iterative Waterfall model
•  Prototyping model
•  Incremental model
•  Spiral model

Classical Waterfall Model

The Waterfall Model is the earliest and simplest model of the Software Development Life
Cycle (SDLC).

• It is called “waterfall” because the development flows downward step by step, just
like water falling down from a cliff.
• Each phase must be completed fully before the next one starts (no going back).
• It works well when requirements are clear, fixed, and well-understood.

Phases of the Classical Waterfall Model

1.

Requirement Analysis

• Gather all requirements from the client or end-users.

• Requirements are documented in a Software Requirement Specification (SRS).
• Example: If you are building a library system, you record: book borrowing rules,
membership system, late fees, etc.

Output: SRS Document.

2. System Design
 • Plan the architecture of the system.
• Decide hardware & software needs, database design, user interfaces, and system flow.
• Example: Decide tables for storing books, member details, transactions, etc.

Output: System Design Document.

3.

Implementation (Coding)

• Developers write the actual program code based on the design.

• The system is usually built in modules (small parts) and then combined.
• Example: Write code for “Add Book”, “Issue Book”, “Return Book” functions.

Output: Source Code.

4.

Integration and Testing

• Individual modules are integrated into a full system.

• Test the system for errors (bugs), performance, and correctness.
• Example: Check if the system correctly deducts a book when borrowed.

Output: Tested Software Product.

5.

Deployment (Installation)

• The finished software is delivered to the client.

• Installed in the real environment and made ready for use.
• Example: The library system is installed on the library’s computers.

Output: Working Software in the client’s environment.

6.

Maintenance

• After deployment, software may need updates, bug fixes, or new features.
• Example: Later, the library wants an online portal for users to check available books
→ this is done in maintenance.

Output: Updated and maintained software.

Advantages of Waterfall Model

• Simple and easy to understand.
• Well-structured with clear steps.
• Good for small projects with fixed requirements.

Disadvantages of Waterfall Model

• Rigid: cannot go back to a previous phase.
• Not suitable for projects with changing requirements.
• Testing comes late → problems are found late.

Summary in one line:

The Classical Waterfall Model is a step-by-step software development approach where each
phase flows into the next, suitable only for projects with stable and clear requirements.

Iterative Waterfall Model

What it is:
• The Iterative Waterfall Model is a modified version of the Classical Waterfall Model.
• Unlike the Classical Waterfall, where you can’t go back, the Iterative Waterfall allows
limited feedback loops.
 • This means if an error is found in one phase, you can go back to the previous phase to
fix it (but not too far back).
• It adds flexibility while still keeping a structured approach.

Phases of the Iterative Waterfall Model

1.

Requirement Analysis

• Collect requirements from users.

• Write the Software Requirement Specification (SRS).
• If problems are found later (like missing requirements), you can return to this phase
from the next stage.

2.

System Design

• Translate requirements into architecture and system design.

• Plan database, user interface, and system flow.
• If errors are found during coding or testing, you can loop back here to correct the
design.

3.

Implementation (Coding)

• Write the actual code.

• Each module is developed separately.
• If coding problems occur, developers can return to design phase for corrections.

4.

Testing

• Test individual modules and the integrated system.

• If bugs are found, the team can go back to coding phase to fix them.
 • This iterative feedback ensures higher quality than the classical waterfall.

5.

Deployment

• The software is delivered to the client after testing.

• If problems occur after deployment, updates or patches may be made.

6.

Maintenance

• Regular updates, bug fixes, and improvements after deployment.

Key Feature:
Feedback Loop
• Classical Waterfall: No going back.
• Iterative Waterfall: Allows going back to one previous phase if needed.
• Example:
o If a bug is found during testing → go back to coding.
o If a design mistake is discovered during coding → go back to design.

Advantages of Iterative Waterfall

1. Errors are found earlier compared to classical waterfall.
2. Provides flexibility through limited backtracking.
3. More reliable and realistic for real-world projects.
4. Easy to understand and manage.

Disadvantages of Iterative Waterfall

1. Still not very flexible (you can only go one step back).
2. Not suitable for projects with very frequent changes.
3. Still late involvement of users compared to Agile/Prototype.
 Real Example

Imagine building an Online Shopping System:

• During testing, you find that the “Add to Cart” feature doesn’t work correctly.
• Instead of restarting the whole project, you just go back to the coding phase → fix the
bug → test again.
• If the error was in system design (like database design wrong), you go back to the
design phase, fix it, then code again.

Summary in One Line:

The Iterative Waterfall Model improves the Classical Waterfall by allowing feedback loops
(backtracking to previous phases), making it more practical and less rigid.

Prototyping Model

What it is:
• The Prototyping Model is a software development approach where a prototype (early
working version) of the software is built, tested, and improved based on user
feedback.
• Instead of freezing requirements first (like in Waterfall), this model lets users see and
interact with a working system early.
• The prototype is not the final system – it’s a toy implementation used to refine
requirements and design.

Phases of the Prototyping Model

1.

Requirement Gathering and Analysis

• Collect basic requirements from the customer (not detailed).

 • Example: The client wants an online banking app with login, account balance check,
and transfer options.
• Only the main features are identified at this stage.

2.

Quick Design

• Create a rough design for the system.

• Focus only on the most important parts (like the user interface screens).
• Example: Draw mockups of login page, account summary page, transfer form.

3.

Build Prototype

• Develop a simple, working prototype (a small version of the system).

• Doesn’t need full functionality – just the core features.
• Example: Create a clickable demo showing how a user logs in and checks balance.

4.

Customer Evaluation

• Show the prototype to the end-users/customers.

• Collect feedback: what they like, what they want to change, what’s missing.
• Example: The customer may say “Add a transaction history page” or “Change the
design of the transfer form.”

5.

Refinement (Iterative Process)

• Based on feedback, update the prototype.

• This cycle (Prototype → Feedback → Refinement) is repeated until the customer is
satisfied.

6.
Product Engineering (Final System Development)

• Once requirements are clear, the final system is built using traditional SDLC steps
(design, coding, testing).
• Unlike the prototype, the final product has full functionality, performance, and
security.

7.

Deployment & Maintenance

• Deliver the final system to the customer.

• Maintain it with bug fixes, updates, and improvements.

Advantages of Prototyping Model

1. User involvement is high – customers see the system early.
2. Helps in better requirement understanding.
3. Reduces risk of failure – users can correct misunderstandings early.
4. Faster detection of missing or confusing features.
5. Builds customer confidence.

Disadvantages of Prototyping Model

1. Can be time-consuming if too many iterations are needed.
2. Users may think the prototype is the final system.
3. Prototype code may be low quality and sometimes reused incorrectly.
4. Not suitable for very large, complex projects where requirements must be clear from
the start.

Real Example

Imagine building a Hospital Management System:

• You quickly build a prototype showing how patients register, doctors check
appointments, and billing works.
• Doctors say: “We also need a prescription printing feature.”
 • Patients say: “We need SMS reminders for appointments.”
• You update the prototype until everyone is satisfied.
• Then you build the final system with all required features.

Summary in One Line:

The Prototyping Model builds a working prototype early, gets user feedback, and refines it
until requirements are clear, then develops the final system.

Incremental Model

What it is:
• The Incremental Model is a software development approach where the system is built
piece by piece (in increments).
• Instead of delivering the whole software at once, development is done in small
modules, each of which adds functionality.
• After each increment, the customer gets a working version of the software.

Phases of the Incremental Model

1.

Requirement Analysis

• Gather requirements and divide them into increments (smaller parts).

• Example: If building an E-learning System, requirements may be divided as:
o Increment 1 → User Registration & Login
o Increment 2 → Course Browsing
o Increment 3 → Video Lessons
o Increment 4 → Online Quizzes & Certificates

2.

System Design

• High-level design is created for the overall system.

 • Each increment has a detailed design for its functionality.

3.

Implementation (Coding)

• Develop the first increment (core/basic features).

• Deliver it to the customer for use.
• Next, add more increments step by step.

4.

Testing

• Each increment is tested separately.

• After integration, the entire system is tested again.

5.

Deployment

• Each increment is delivered to the customer once it is tested and approved.

• Users can start using the system early even before the final version is complete.

6.

Maintenance

• Fix bugs, update features, and improve performance after deployment.

Example Workflow

Let’s say we are building an Online Shopping System:

• Increment 1: User Login & Registration

• Increment 2: Product Catalog & Search
 • Increment 3: Shopping Cart
• Increment 4: Payment Gateway & Invoice

After Increment 1 is delivered, users can already log in and register.

After Increment 2, they can browse products.

After Increment 3, they can add to cart.

After Increment 4, they can make payments.

At each step, the system grows in functionality.

Advantages of Incremental Model

1. Early delivery – customer gets a working system quickly.
2. Risk is reduced – issues are found earlier.
3. Easier to test and debug small increments.
4. Users give feedback after each increment, improving the product.
5. Flexible – changes can be added in future increments.

Disadvantages of Incremental Model

1. Requires good planning and design (to divide system properly).
2. More time and cost compared to simpler models.
3. Integration of increments can be challenging.
4. Not suitable for very small projects (overkill).

Real-Life Example

Imagine building a Mobile Banking App:

• First release: Login + Check Balance.

• Second release: Money Transfer.
• Third release: Bill Payments.
 • Fourth release: Loan Applications & Credit Card Services.

Customers don’t need to wait for the whole system; they start using features from the
very first release.

Summary in One Line:

The Incremental Model delivers the software step by step in small increments, allowing early
use, feedback, and reduced risk.

Spiral Model

What it is:

The Spiral Model is a risk-driven software development model.

It combines Iterative Development (repeating cycles) and Prototyping (early models) with
strong focus on risk analysis.
Development happens in spirals (cycles), and in each spiral, the project goes through four
main phases.

Think of it like a spiral (coil): with each loop, the project gets closer to the final system,
while risks are continuously identified and handled.

Phases of the Spiral Model (in each cycle)

Every spiral (iteration) has 4 quadrants/phases:

1.

Planning (Determine Objectives)

Identify objectives, requirements, and constraints for this cycle.

Example: For an Online Shopping System, in the first cycle → only focus on Login +
Product Search.
2.

Risk Analysis

Identify possible risks (technical issues, cost overruns, unclear requirements).

Analyze alternatives and find ways to reduce risks.

Example: Risk → Payment Gateway may fail.

Solution: Prototype different gateways (PayPal, Stripe) and choose the best.

3.
Engineering (Development & Testing)

Build a prototype or a partial version of the system.

Test it and deliver it for feedback.

Example: Develop the Login + Product Search features and test them.

4.

Evaluation (Customer Review)

Show the prototype or increment to the customer.

Get feedback and refine requirements for the next spiral.

Example: Customer may say, “Add filtering in product search.”

After evaluation, the next spiral begins → adding more features, reducing new risks, and
repeating the process.

Example Workflow (Online Shopping System)

Spiral 1: Login + Product Search

Spiral 2: Shopping Cart + Checkout

Spiral 3: Payment Gateway + Order Tracking

Spiral 4: Review System + Recommendation Engine

Each spiral:
Plans objectives →

Analyzes risks →

Builds & tests →

Gets customer feedback.

Advantages of Spiral Model

Risk management is built-in (best for high-risk projects).

Customer feedback at every stage → ensures requirements are correct.

Development is incremental, so users see progress early.

Suitable for large, complex projects.

Flexible – changes can be handled in later spirals.

Disadvantages of Spiral Model

Expensive (due to risk analysis and multiple cycles).

Requires highly skilled team (especially in risk analysis).

Can take longer than other models.

Not suitable for small, low-budget projects.

Real-Life Example

Imagine developing an Air Traffic Control System (where safety is critical):

Spiral 1 → Prototype for tracking flights.

Spiral 2 → Add communication with pilots.

Spiral 3 → Add weather tracking.

Spiral 4 → Integrate all with full safety checks.

Risk analysis ensures that failures don’t occur in a critical system.

Summary in One Line:

The Spiral Model develops software in cycles (spirals), focusing on risk analysis,
prototyping, and customer feedback, making it ideal for large, high-risk projects.