GANPAT UNIVERSITY

U. V. PATEL COLLEGE OF ENGINEERING

LAB MANUAL
2CEIT502: Software Engineering

Computer Engineering/ Information

Technology/ Computer Engineering with
Artificial Intelligence

A.Y. 2023-2024
 GANPAT UNIVERSITY
U.V. PATEL COLLEGE OF ENGINEERING
B. Tech Semester VII
Computer Engineering/ Information Technology
2CEIT502: Software Engineering
List of Experiments
Tools – Star UML –Word processing software like MS-Word, Open office etc.

Sr. Experiments CO
No Mapping

1 To study various Software development life cycle (SDLC) models prepare a report of their analysis 1
with answering given questions.

2 To prepare a problem statement and Requirement Elicitation techniques. 3

3 To create a static view (structure diagrams) of a software design on chosen definition. 2

4 To create a dynamic view (behavioural diagrams) of a software design on chosen definition. 2

5 Identify the design principle that is being violated in relation to the given scenario. 3

6 To study about various Project Management Software (tools) available in the market. 4

7 Prepare Software requirement specification (SRS) document. 3

8 To study about Structure System analysis and Design method (SSADM). 2

9 To learn estimating techniques to estimate project parameters on a given case study using SE Vlabs 4
tool.

10 To prepare the test suite for a given case study on SE Vlab tool. 5

Course Outcomes:
CO1 Able to gain knowledge of different software development lifecycle models and able to apply it

CO2 Acquire knowledge of different analysis models and build according to software needs.

CO3 Gain the understanding of different approaches of requirement gathering, analysis, and documentation.

CO4 Get to know different coding and testing standards and methods to be used in industry for software projects

Mapping of CO and PO:

COs PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 PSO1 PSO2 PS03
CO1 3 2 3 3 3 0 0 0 3 2 3 0 2 2 0
CO2 3 3 3 2 2 0 0 0 3 2 2 1 3 2 0
CO3 3 2 3 3 3 1 0 0 2 3 3 2 3 3 1
CO4 3 2 2 2 1 1 0 0 3 1 2 1 1 1 0
 Prof. Ravi Raval
Assistant Professor,
CE Dept.

Practical-1
Aim: To study various Software development life cycle (SDLC) models
prepare a report of their analysis with answering given questions.

Task-1: Watch these videos on Youtube first:

What is SDLC? (4:54) https://www.youtube.com/watch?v=4xCldpbDZ10
Waterfall model: (6:08) https://www.youtube.com/watch?v=Y_A0E1ToC_I

Task-2 : Attempt the questions given below:

1. Write one example of a software project that would be amenable to the classical
waterfall model.
A software project that could be well-suited for the classical waterfall model is the
development of a standalone desktop application for a specific, well-defined task. Here's
an example:
Project: Inventory Management System
Imagine a scenario where a small business owner wants to automate their inventory
management process. They want a software solution that allows them to track product
stock levels, generate reports, and manage orders.
In this scenario, the classical waterfall model is appropriate because the project
requirements are well-defined and unlikely to change significantly during development.
The business owner has a clear understanding of what they need, and the focus is on
delivering a stable and reliable desktop application without the need for frequent
iterations or changes in requirements.

2. What is the difference between incremental process model and evolutionary process
model?
Incremental and evolutionary process models are both iterative approaches to software
development, but they differ in how they handle the development process and the scope
of changes made in each iteration. Here are the key differences between these two
models:

Incremental Process Model:

i) Phased Development: In the incremental model, the project is divided into distinct
phases or increments. Each increment represents a portion of the complete
system's functionality.
 ii) Sequential Phases: The increments are developed one after the other, and each
increment builds upon the functionality of the previous ones. It follows a linear or
sequential progression.
iii) Partial Functionality: Each increment typically delivers a subset of the system's
features, but it's a working and potentially usable version of the software.
iv) Early Deliveries: The incremental model allows for early delivery of parts of the
software, which can be beneficial for stakeholders who want to start using certain
features sooner.
v) Requirements Stability: This model assumes that the project's requirements are
reasonably stable, with minimal changes expected between increments. Changes
are usually accommodated in subsequent increments.
vi) Rigidity: It can be less flexible when dealing with changes that affect the core
architecture, as major modifications may require reworking multiple increments.

Evolutionary Process Model:

i) Continuous Evolution: In the evolutionary model, the software evolves

continuously and iteratively throughout the development process.

ii) Parallel Development: Unlike the sequential nature of the incremental model,
evolutionary development often involves parallel development of different parts
or features of the software.

iii) Exploration and Experimentation: This model is particularly useful when the
project requirements are not well-defined or are expected to change frequently. It
allows for exploration, experimentation, and adaptation based on user feedback.

iv) Minimal Viable Product (MVP): Evolutionary models often emphasize the
creation of a Minimal Viable Product (MVP) early in the process, which is a basic
version of the software with essential features to gather user feedback and validate
concepts.

v) Flexibility: The evolutionary model is highly adaptable to changing requirements

and emerging insights. It embraces change and welcomes adjustments throughout
the development lifecycle.

vi) Continuous User Involvement: Users are actively involved throughout the
development process, providing feedback and shaping the software's evolution.

In summary, the incremental model follows a more structured, phased approach with
stable requirements and sequential increments, whereas the evolutionary model is more
flexible, adaptive, and responsive to changing requirements, often involving parallel
development and continuous user involvement. The choice between these models
depends on the project's nature, requirements, and the level of uncertainty and volatility in
the project environment.
3. Which model is more suitable for your capstone project-1? Why?
(Assumption: Blood Bank Management System)
The choice between the incremental and evolutionary models for your Blood Bank
Management System project would depend on several factors, including the project's
specific requirements, the level of uncertainty, and the needs of the stakeholders. Here's
an evaluation of both models in the context of a Blood Bank Management System:

Incremental Model for Blood Bank Management System:

 The incremental model could be suitable for your Blood Bank Management System
project under certain conditions:
i) Stable and Well-Defined Requirements: If your project has well-defined and
relatively stable requirements, meaning that you have a clear understanding of
what features and functionalities the blood bank system needs, then the
incremental model can work well. This model is ideal when you can divide the
system into distinct phases or increments, such as donor management, inventory
tracking, and blood distribution, and you don't anticipate significant changes to
these requirements during development.
ii) Phased Rollout: If you want to deliver the system to users incrementally, allowing
them to start using certain features early on while others are under development,
the incremental model is a good fit. This can be beneficial for getting user
feedback and improving the system over time.

iii) Limited Resources or Time Constraints: If you have resource or time constraints
and need to prioritize the development of critical functionalities first, the
incremental approach allows you to focus on building and delivering the most
important features first.

Evolutionary Model for Blood Bank Management System:

The evolutionary model might be more suitable if your project exhibits the following
characteristics:
i) Uncertain or Evolving Requirements: If the requirements for your Blood Bank
Management System are not well-defined or are expected to evolve significantly
during development, the evolutionary model can be advantageous. It allows for
continuous adaptation and refinement as you gain a better understanding of user
needs and regulatory requirements.
ii) User Involvement and Feedback: If you want to actively involve blood bank staff
and other stakeholders throughout the development process, gathering their
feedback and making continuous improvements based on their insights, the
evolutionary model supports this approach.
iii) Risk Mitigation: If there are high risks associated with the project, such as
regulatory compliance challenges or complex integrations with other systems, the
evolutionary model provides the flexibility to address these risks iteratively.

In conclusion, both models can be adapted to suit your Blood Bank Management System
project, but the choice depends on the nature of your requirements and the level of
flexibility and adaptability you need. If your requirements are stable and you want to
deliver the system in phases, the incremental model can work. However, if your
requirements are uncertain, and you want to continuously evolve the system based on user
feedback, the evolutionary model might be more appropriate. Consider the specific needs
and constraints of your project when making this decision.
4. State the parameters to choose suitable life cycle model for any system.
i) Project Requirements and Stability: The stability of project requirements: Are the
requirements well-defined and stable, or are they likely to change frequently?
Clarity of objectives: How clear are the project objectives, and is there a solid
understanding of what the system should accomplish?
ii) Project Size and Complexity: Project size: Is it a small, medium, or large-scale
project in terms of scope, budget, and resources?
Complexity: Does the project involve complex technologies, intricate integrations,
or regulatory compliance requirements?
iii) Project Timeline and Deadlines: Time constraints: Are there specific deadlines or
time-to-market pressures that must be met?
 Project duration: How long is the project expected to last, and is it a short-term or
long-term endeavor?
iv) Budget and Resource Availability: Budget constraints: What financial resources
are available for the project?
Resource availability: What is the availability of skilled team members, tools, and
infrastructure?
v) Risk Tolerance: Risk assessment: What are the project's inherent risks, and how
tolerant is the organization to project risks?
Risk mitigation: Does the project require a model that allows for early
identification and mitigation of risks?
vi) User Involvement and Feedback: Stakeholder involvement: How actively do
stakeholders, including end-users, want to participate in the development process?
Feedback loops: Is there a need for continuous feedback and refinement based on
user input?
vii) Regulatory and Compliance Requirements: Industry-specific regulations: Does the
project need to adhere to specific regulatory standards or compliance
requirements?
viii) Flexibility and Adaptability: Change management: How open is the project to
accommodate changes in requirements or technology advancements?
Iterative development: Does the project benefit from an iterative approach that
allows for frequent adjustments?
ix) Quality and Testing:Quality assurance: How critical is the quality of the final
product, and what level of testing and validation is required?
x) Client or Stakeholder Expectations: Client preferences: What are the expectations
and preferences of the client or primary stakeholders?
Client involvement: Does the client have a specific model preference or industry-
standard preference?
xi) Previous Project Experience:Team expertise: What is the team's experience and
proficiency with different life cycle models?
Lessons learned: Are there lessons from previous projects that can influence the
choice of model?
xii) Technology and Tools: Available tools and technologies: What development tools
and technologies are available or preferred for the project?
xiii) Documentation and Deliverables:Documentation requirements: What level of
documentation is expected for the project, and how does it align with the chosen
model?

5. Which life cycle model is/are widely used in software industry nowadays?
Agile Model
It's important to note that the software industry is dynamic, and the popularity of life
cycle models can change over time. Furthermore, the choice of model often depends on
the nature of the project, the organization's culture, and the specific requirements of the
stakeholders.

To determine the most suitable life cycle model for a particular project, it's advisable to
conduct a thorough assessment of project requirements, constraints, and objectives, and
then select the model or combination of models that best align with those factors.
Additionally, it's a good practice to stay up-to-date with industry trends and adapt to new
methodologies as they emerge.

6. Give the comparison of all life cycle models based upon characteristics of different SDLC
models, fill the details with following options:

Sr. Model / Feature Waterfall Prototype Spiral Iterative or

No model Model Model Incremental Model
1 Unclear User requirements Poor Good Excellent Good
2 Unfamiliar technology Poor Excellent Excellent Good
3 Complex System Good Excellent Excellent Good
4 Short-time schedule Poor Good Poor Excellent
5 Strong project management Excellent Excellent Excellent Excellent
6 Cost limitation Poor Poor Poor Excellent
7 Documentation Excellent Good Good Excellent
8 Component reusability Excellent Poor Poor Excellent

Practical-2
Aim: Implement back propagation from scratch and show the performance on any
dataset.
Code:

//Font: Times New Roman, Size:12

Output: