What is Software Engineering?

Justify Software is Engineered but

01 S-23/3M
not Manufactured

Software Engineering is the systematic and disciplined approach to designing, developing,

testing, and maintaining software applications, essentially applying engineering principles to the
creation of software, which is why it's considered "engineered" rather than "manufactured"
because software is not a physical product that can be built on an assembly line like a car, but is
instead constructed through a series of logical steps and design decisions, allowing for flexibility
and continuous modification throughout its lifecycle.
Key points explaining why software is engineered, not manufactured:
∙ Intangible nature:
Unlike physical products, software is intangible and exists only as code, making it impossible to
"manufacture" in the traditional sense where you physically assemble components.
∙ Iterative development:
Software engineering often uses iterative development methodologies, where designs are
continuously refined and improved throughout the development process, unlike a manufacturing
process with fixed production steps.
∙ Flexibility and modification:
Software can be easily modified and updated after deployment, whereas changing a
manufactured product usually requires significant rework.
∙ Design-centric focus:
The primary focus in software development is on design and problem-solving, rather than solely
on production and assembly, which is a key element of manufacturing.
In summary, the term "engineering" is used to emphasize the systematic and methodical
approach taken to build software, considering complex requirements, potential issues, and
ongoing maintenance, which is fundamentally different from the more standardized and
repetitive process of manufacturing physical goods

02 What is Process? Discuss the process framework activities. S-23/4M

 S-23/7
03
M

S-22/4
08 Discuss merits and demerits of Waterfall model.
M

W-22/
11 Explain the different phases of Waterfall model.
3M
Advantages of the SDLC Waterfall Model
The classical waterfall model is an idealistic model for software development. It is very simple,
so it can be considered the basis for other software development life cycle models. Below are
some of the major advantages of this SDLC model.
∙ Easy to Understand: The Classical Waterfall Model is very simple and easy to
understand.
∙ Individual Processing: Phases in the Classical Waterfall model are processed one at a
time.
∙ Properly Defined: In the classical waterfall model, each stage in the model is clearly
defined.
∙ Clear Milestones: The classical Waterfall model has very clear and well-understood
milestones.
∙ Properly Documented: Processes, actions, and results are very well documented.
∙ Reinforces Good Habits: The Classical Waterfall Model reinforces good habits like
define-before-design and design-before-code.
∙ Working: Classical Waterfall Model works well for smaller projects and projects where
requirements are well understood.
Disadvantages of the SDLC Waterfall Model
The Classical Waterfall Model suffers from various shortcomings we can’t use it in real projects,
but we use other software development lifecycle models which are based on the classical
waterfall model. Below are some major drawbacks of this model.
∙ No Feedback Path: In the classical waterfall model evolution of software from one
phase to another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phase. Therefore, it does not incorporate any mechanism for error
correction.
∙ Difficult to accommodate Change Requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
the customer’s requirements keep on changing with time. It is difficult to accommodate
any change requests after the requirements specification phase is complete.
∙ No Overlapping of Phases: This model recommends that a new phase can start only
after the completion of the previous phase. But in real projects, this can’t be maintained.
To increase efficiency and reduce cost, phases may overlap.
∙ Limited Flexibility: The Waterfall Model is a rigid and linear approach to software
development, which means that it is not well-suited for projects with changing or
uncertain requirements. Once a phase has been completed, it is difficult to make changes
or go back to a previous phase.
∙ Limited Stakeholder Involvement: The Waterfall Model is a structured and sequential
approach, which means that stakeholders are typically involved in the early phases of the
 project (requirements gathering and analysis) but may not be involved in the later
phases (implementation, testing, and deployment).
∙ Late Defect Detection: In the Waterfall Model, testing is typically done toward the end
of the development process. This means that defects may not be discovered until late in
the development process, which can be expensive and time-consuming to fix.
∙ Lengthy Development Cycle: The Waterfall Model can result in a lengthy development
cycle, as each phase must be completed before moving on to the next. This can result in
delays and increased costs if requirements change or new issues arise.
Discuss Incremental process model with its diagram and compare it
06 W-23/7M
with Waterfall model.

S. No. Waterfall Model Incremental Model

Need for Detailed Documentation The need for Detailed Documentation

Documentation in the waterfall model is in the incremental model is Necessary
Necessary. but not too much.
 In the waterfall model, early stage In an incremental model, early-stage
Planning
planning is necessary. planning is also necessary.

There is a high amount of risk in There is a low amount of risk in the

Risk
the waterfall model. incremental model.

There is a long waiting time for There is a short waiting time for
Waiting Time for
running software in the waterfall running software in the incremental
Running Software
model. model.

Handling Large The waterfall model can’t handle The incremental model also can’t
Projects large projects. handle large projects.

Flexibility to change in the Flexibility to change in incremental

Flexibility to Change
waterfall model is Difficult. model is Easy.

The cost of the Waterfall model is The cost of the incremental model is
Cost
Low. also Low.

Testing is done in the waterfall Testing is done in the incremental

Testing model after the completion of the model after every iteration of the
coding phase. phase.

Returning to the previous

Returning to Returning to the previous stage/phase
stage/phase in the waterfall model
Previous Phases in the incremental model is possible.
is not possible.

In the waterfall model, a large In an incremental model large team is

Team Size
team is required. not required.

In the waterfall model overlapping In incremental model overlapping of

Phases Overlapping
of phases is not possible. phases is possible.
 There is only one cycle in the Multiple development cycles take place
Development Cycles
waterfall model. in the incremental model.

Customer The customer is involved only at In incremental model, customer

Involvement the beginning of development. involvement is intermediate.

Linear with iterative framework type is

Framework Type The linear framework type is used.
used.

The customer has more control over

The customer is having least
Customer Control the administrator in comparison to the
control over the administrator.
waterfall model.

Reusability Reusability is the least possible. Reusability is possible to some extent.

12 Explain steps involved during the prototyping W-22/4M

Explain the process model which is used in situations where the user
10 W-22/3M
Requirements are not well understood.
 03 Explain Spiral Process Model and states its advantages and disadvantages. S-23/7M

What is the importance of Process Model in development of

09 S-22/7M
Software System? Discuss Spiral Model in detail.

-Agile,Scrum, XP, DSDM,CRC

02 Define agile process .Give any two agile principles. S-22/3M

08 Explain Agile model. W-22/4M

The Agile process is a project management framework that involves breaking a project down
into phases and focusing on collaboration and improvement. It's an iterative approach that
prioritizes quick delivery, adapting to change, and collaboration over following a set plan

What is Agile Model?

The Agile Model was primarily designed to help a project adapt quickly to change requests. So,
the main aim of the Agile model is to facilitate quick project completion. To accomplish this
task, agility is required. Agility is achieved by fitting the process to the project and removing
activities that may not be essential for a specific project. Also, anything that is a waste of time
and effort is avoided. The Agile Model refers to a group of development processes. These
processes share some basic characteristics but do have certain subtle differences among
themselves.
Agile SDLC Models/Methods
Given below are some Agile SDLC Models:
∙ Crystal Agile methodology: The Crystal Agile Software Development
Methodology places a strong emphasis on fostering effective communication and
collaboration among team members, as well as taking into account the human elements
that are crucial for a successful development process. This methodology is particularly
beneficial for projects with a high degree of uncertainty, where requirements tend to
change frequently.
∙ Dynamic Systems Development Method (DSDM): DSDSM methodology is tailored
for projects with moderate to high uncertainty where requirements are prone to change
frequently. Its clear-cut roles and responsibilities focus on delivering working software in
short time frames. Governance practices set it apart and make it an effective approach for
teams and projects.
∙ Feature-driven development (FDD): FDD approach is implemented by utilizing a
series of techniques, like creating feature lists, conducting model evaluations, and
implementing a design-by-feature method, to meet its goal. This methodology is
 particularly effective in ensuring that the end product is delivered on time and that it
aligns with the requirements of the customer.
∙ Scrum: Scrum methodology serves as a framework for tackling complex projects and
ensuring their successful completion. It is led by a Scrum Master, who oversees the
process, and a Product Owner, who establishes the priorities. The Development Team,
accountable for delivering the software, is another key player.
∙ Extreme Programming (XP): Extreme Programming uses specific practices like pair
programming, continuous integration, and test-driven development to achieve these
goals. Extreme programming is ideal for projects that have high levels of uncertainty and
require frequent changes, as it allows for quick adaptation to new requirements and
feedback.
∙ Lean Development: Lean Development is rooted in the principles of lean manufacturing
and aims to streamline the process by identifying and removing unnecessary steps and
activities. This is achieved through practices such as continuous improvement, visual
management, and value stream mapping, which helps in identifying areas of
improvement and implementing changes accordingly.
∙ Unified Process: Unified Process is a methodology that can be tailored to the specific
needs of any given project. It combines elements of both waterfall and Agile
methodologies, allowing for an iterative and incremental approach to development. This
means that the UP is characterized by a series of iterations, each of which results in a
working product increment, allowing for continuous improvement and the delivery of
value to the customer.
04 Explain Extreme Programming (XP) in detail. S-22/7M
05 Draw the extreme programming process W-22/4M
 Write a short note on Dynamic Systems Development Method
06 W-23/4M
(DSDM) in detail.
03 Explain Scrum with its advantages and disadvantages. S-22/7M
 Write a note on CRC Modeling. Draw and discuss CRC for the
07 W-23/7M
“Email System User”.
Metrices(size,object,function),Project Scheduling Process, COCOMO, RMMM, four P’s,
Discuss the differences Size Oriented Metrix and Object Oriented
01 S-23/7M
Metrix.
W-23/7
05 Explain Function oriented metrics with suitable example.
M
 Enlist and Explain Requirement Engineering Tasks in detail.
S-23/7M
02 Or
S-22/4M
What are the tasks performed in requirement engineering?
Define requirement engineering. Write functional and non
03 W-23/4M
functional requirement for hotel management system.
07 Briefly Explain: Requirement Elicitation and Validation. W-22/4M
How the activity diagrams are useful in eliciting the requirements of
04 S-22 /4M
software system?
Functional and Non-Functional Requirements for a Hotel Management System:
Functional Requirements:
These are the specific functionalities that the system must perform. They define what the system
should do.
1. Room Booking and Reservation:
○ The system should allow users to search for available rooms, check rates, and
make reservations.
○ Customers can cancel or modify their reservations.
2. Check-In and Check-Out:
○ The system should manage guest check-ins and check-outs, updating room
availability accordingly.
3. Room Service Ordering:
 ○ Guests should be able to order room service through the system.
4. Payment Processing:
○ The system should process payments through various methods (credit card, debit
card, cash, etc.) during booking and check-out.
5. Customer Management:
○ The system should store customer information (name, contact details, booking
history) for future bookings and services.
6. Employee Management:
○ The system should allow the hotel management to manage employee information,
roles, and schedules.
7. Inventory Management:
○ The system should track inventory items such as room supplies, food and
beverages, etc., ensuring availability for guest use.
8. Billing and Invoice Generation:
○ Automatically generate and print bills or invoices for customers based on their use
of hotel services.
Non-Functional Requirements:
These define how the system performs its functions and focus on the system's quality attributes.
1. Performance:
○ The system should handle up to 500 concurrent users without performance
degradation.
○ Response time for room booking should not exceed 3 seconds.
2. Scalability:
○ The system should be scalable to accommodate more hotels or branches in the
future.
3. Security:
○ Customer data must be encrypted to protect sensitive information such as
payment details.
○ Only authorized personnel should be able to access the employee and financial
management modules.
4. Usability:
○ The system should have an intuitive user interface that is easy for both hotel staff
and guests to use with minimal training.
5. Availability:
○ The system should have 99.9% uptime to ensure continuous availability for online
booking.
6. Data Backup and Recovery:
○ The system should have daily backups of all critical data and a recovery
mechanism in case of data loss or corruption.
 7. Compliance:
○ The system should comply with local data protection laws, such as GDPR, for
handling customer data.
8. Maintainability:
○ The system should be designed in a modular fashion to allow easy updates, bug
fixes, and enhancements without major disruptions.
These requirements guide the development and testing phases of the hotel management system to
ensure it fulfills both the functional needs and non-functional expectations of the stakeholders.

Activity diagrams are useful in eliciting software system requirements by visually representing
the flow of activities within a system, allowing analysts to identify key processes, decision
points, and potential issues within a workflow, thus helping to capture detailed functional
requirements and ensure all necessary steps are considered during the design phase.
Key benefits of using activity diagrams for requirement elicitation:
 ∙ Visual Representation:
Activity diagrams provide a clear, graphical representation of a system's workflow, making it
easier for stakeholders (including non-technical users) to understand the system's behaviour and
identify potential gaps in requirements.
∙ Identifying Use Cases:
By mapping out the steps in a specific user scenario, activity diagrams can be used to identify
and document different use cases for the system, helping to capture diverse user needs.
∙ Detailed Process Breakdown:
Activity diagrams can break down complex processes into smaller, manageable steps, allowing
for a more thorough analysis of the system's functionality and potential edge cases.
∙ Decision Points and Conditions:
The ability to incorporate decision nodes and guard conditions within activity diagrams helps to
model complex logic and identify situations where the system needs to make choices based on
specific criteria.
∙ Parallelism and Concurrency:
Activity diagrams can depict parallel activities and synchronization points, which is useful for
modelling systems with concurrent processes.
∙ Collaboration and Communication:
By providing a shared visual representation of the system's workflow, activity diagrams facilitate
communication and collaboration between stakeholders, developers, and users, ensuring
everyone is on the same page regarding system requirements
Define feasibility study. Enlist and explain the contents to be
05 W-22/4M
included in the feasibility study report.
A feasibility study is a comprehensive evaluation that assesses the practicality of a proposed
project or business idea, analysing various factors like financial viability, technical requirements,
legal constraints, and market demand to determine whether the project is likely to succeed and if
it's worth pursuing.
Key components of a feasibility study report:
∙ Executive Summary:
A concise overview of the project, including its objectives, key findings, recommendations, and
overall feasibility assessment.
∙ Project Description:
 ○ Problem Statement: Clearly defines the issue or need the project aims to address.
○ Project Goals and Objectives: Specific, measurable targets the project intends to
achieve.
○ Product/Service Description: Detailed explanation of the proposed product or
service, including its features and benefits.
∙ Market Analysis:
○ Market Size and Growth Potential: Analysis of the target market size,
demographics, and potential growth rate.
○ Competition Assessment: Identification and evaluation of existing competitors,
their strengths and weaknesses.
○ Market Penetration Strategy: Plan for how the project will capture market share.
∙ Technical Feasibility:
○ Technology Assessment: Evaluation of available technology to implement the
project, including its limitations and compatibility.
○ System Requirements: Detailed list of hardware, software, and infrastructure
needed.
○ Development Process: Outline of the project development phases and timelines.
∙ Economic Feasibility:
○ Cost Analysis: Detailed breakdown of project costs, including development,
operational, and maintenance expenses.
○ Revenue Projections: Estimated revenue generation based on market penetration
and pricing strategy.
○ Return on Investment (ROI): Analysis of the expected financial return compared
to the initial investment.
∙ Financial Feasibility:
○ Funding Sources: Identification of potential funding options like loans, equity
investments, or grants.
○ Financial Projections: Projected cash flow statements, income statements, and
balance sheets.
○ Break-Even Analysis: Calculation of the sales volume required to cover project
costs.
∙ Legal and Regulatory Feasibility:
○ Permits and Licenses: Identification of necessary permits and licenses to operate
the project.
○ Compliance Requirements: Assessment of relevant legal and regulatory
frameworks that may impact the project.
∙ Management Feasibility:
○ Organizational Structure: Outline of the project team roles and responsibilities.
○ Project Management Plan: Description of project management methodologies and
processes.
 ○ Stakeholder Analysis: Identification of key stakeholders and their potential impact
on the project.
∙ Risk Assessment:
○ Potential Risks: Identification of potential risks associated with the project.
○ Mitigation Strategies: Proposed actions to address and minimize identified risks.

Important Considerations:
∙ Data Accuracy: Ensure the feasibility study relies on reliable and up-to-date data sources.
∙ Objectivity: Maintain a neutral perspective when evaluating project viability.
∙ Clear Communication: Present the findings of the study in a clear and concise manner,
including recommendations and next steps.
06 Define Generalization. Explain with example W-22/3M
Generalization in software engineering is the process of grouping entities into broader categories
based on common attributes, behavior, or both. This process helps to reduce the complexity of
models and redundancy in specifications.
Here are some examples of generalization in software engineering:
∙ Creating a superclass
Generalization can be used to create a superclass that has common properties and methods
shared by multiple subclasses. For example, a "Car" entity can be the child entity, and "Sedan,"
"SUV," and "Truck" can be the generalized parent entities.
∙ Identifying commonalities
Generalization can be used to identify commonalities among a set of entities. For example, all
graphical user interface windows have a title.
∙ Applying a general function
Generalization can be used to apply a general function to other use cases. For example, a general
function filter can be applied to keep only positive numbers from a list.

List the characteristics of a good quality SRS.

S-23/3M
01 Or
S-22/3M
What are the characteristics of good SRS document?

- Correct
- Unambiguous
- Complete
- Modifiable
- Traceable
- Verifiable
- Consistent