SOFTWARE ENGINEERING (3161605)

A Laboratory Manual for

SOFTWARE ENGINEERING
(3161605)

B.E. Semester 6 (Information Technology)

Directorate of Technical Education,

Gandhinagar, Gujarat.
SOFTWARE ENGINEERING (3161605)

Government Engineering College, Bhavnagar

Certificate

This is to certify that Mr. Shah Trush Sunilkumar Enrollment No.

210430116124 of B.E. Semester 6th Information Technology of this Institute
(GTU Code:43) has satisfactorily completed the Practical / Tutorial work for
the subject Software Engineering (3161605) for the academic year 2023-24.

Place:

Date:

Name and Sign of Faculty member

Head of the Department

 Preface

The main motto of any laboratory/practical/field work is to enhance required skills and create ability
amongst students to solve real-time problems by developing relevant competencies in the
psychomotor domain. By keeping this in view, GTU has designed a competency-focused outcome-
based curriculum for engineering degree programs where sufficient weightage is given to practical
work. It shows the importance of enhancement of skills amongst the students, and it pays attention to
utilizing every second of time allotted for practical amongst students, instructors, and faculty members
to achieve relevant outcomes by performing the experiments rather than merely study-type
experiments. It is a must for the effective implementation of a competency-focused outcome-based
curriculum that every practical is keenly designed to serve as a tool to develop and enhance relevant
competency required by the various industry among every student. These psychomotor skills are very
difficult to develop through traditional chalk-and-board content delivery methods in the classroom.
Accordingly, this lab manual is designed to focus on industry-defined relevant outcomes rather than
the old practice of conducting practical to prove concepts and theories.

By using this lab manual, students can go through the relevant theory and procedure in advance before
the actual performance, which creates interest, and students can have a basic idea prior to the
performance. This, in turn, enhances pre-determined outcomes amongst students. Each experiment in
this manual begins with competency, industry-relevant skills, course outcomes as well as practical
outcomes (objectives). The students will also achieve safety and necessary precautions to be taken
while performing practical.

This manual also provides guidelines to faculty members to facilitate student-centric lab activities
through each experiment by arranging and managing necessary resources in order that the students
follow the procedures with required safety and necessary precautions to achieve the outcomes. It also
gives an idea of how students will be assessed by providing rubrics.

Software Engineering is an application of a systematic, defined, and measurable approach that begins
with requirement specification and progresses with planning, modeling, and testing, and concludes
with deployment. It is a layered paradigm that comprises processes, methods, and tools with the
bedrock of quality focus. The Software Engineering approach's main purpose is committed to
developing the software products within the stipulated time and budget with more quality. Quality
product motivates firmness, commodity, and delight.

Utmost care has been taken while preparing this lab manual; however, there is always a chance of
improvement. Therefore, we welcome constructive suggestions for improvement and removal of
errors, if any.
Software Engineering (3161605) No: 210430116124

Practical – Course Outcome matrix

Course Outcomes (COs):

CO-1: Prepare SRS (Software Requirement Specification) document and SPMP (Software
Project Management Plan) document.
CO-2: Apply the concept of Functional Oriented and Object-Oriented Approaches for Software
Design. CO-3. Recognize how to ensure the quality of software products, different quality standards,
and software review techniques.
CO-4. Apply various testing techniques and test plans
in. CO-5. Able to understand modern Agile
Development
Sr.
Objective(s) of Experiment CO1 CO2 CO3 CO4 CO5
No.
Study of various type of Software Process models with
comparison and find out which process model will be
1. √
appropriate for your selected Project.

Discuss the Project Management: Project Planning and

2. √ √
Project Scheduling about your Project.
Prepare the Software Requirement Specification (SRS)
3. √ √
document for selected project.
4. Draw the Data Flow Diagram for your selected Project. √ √

Draw the Entity-Relationship Diagram for your selected

5. √ √
Project
Draw Use case Diagram for your selected Project.
6. √ √
Solve the problem by applying basic COCOMO model.
7. √ √

8. Modeling UML Class Diagrams and Sequence diagrams √ √

Design the various test cases to perform the testing of the
9. √ √
system and also perform the various type of testing.
Study of any two Open-source tools in DevOps for
Infrastructure Automation, Configuration Management
10. √
Deployment Automation, Performance Management, Log
Management Monitoring.
Software Engineering (3161605) No: 210430116124

Industry Relevant Skills

The following industry relevant competency is expected to be developed in the student by

undertaking the practical work of this laboratory.

1. Apply knowledge of Process Models for the development of software.

2. Understand the concept of Software requirement Specification (SRS) document for project
development.

Guidelines for Faculty members

1. Teacher should provide the guideline with demonstration of practical to the students with
all features.
2. Teacher shall explain basic concepts/theory related to the experiment to the students before
starting of each practical
3. Involve all the students in performance of each experiment.
4. Teacher is expected to share the skills and competencies to be developed in the students
and ensure that the respective skills and competencies are developed in the students after
the completion of the experimentation.
5. Teachers should give opportunity to students for hands-on experience after the
demonstration.
6. Teacher may provide additional knowledge and skills to the students even though not
covered in the manual but are expected from the students by concerned industry.
7. Give practical assignment and assess the performance of students based on task assigned to
check whether it is as per the instructions or not.
8. Teacher is expected to refer complete curriculum of the course and follow the guidelines
for implementation.

Instructions for Students

1. Students are expected to carefully listen to all the theory classes delivered by the faculty
members and understand the COs, content of the course, teaching and examination scheme, skill
set to be developed etc.
2. Students shall organize the work in the group and make record of all observations.
3. Students shall develop maintenance skill as expected by industries.
4. Student shall attempt to develop related hand-on skills and build confidence.
5. Student shall develop the habits of evolving more ideas, innovations, skills etc. apart from those
Software Engineering (3161605) No: 210430116124

included in scope of manual.

6. Student shall refer technical magazines and data books.
7. Student should develop a habit of submitting the experimentation work as per the schedule and
she/he should be well prepared for the same.

General Guidelines for Software Engineering Laboratory Work

1. Student has to perform all the practical as described in the practical list.

2. For performing the practical list, student can able to work individually or work in a team as per
subject teacher guidelines.
3. After establishing the team, every team will have to identify the problem area / definition for
performing the laboratory work.
4. Every team has to approve their problem definition to respective faculty member within 15 days
of the beginning of the semester.
5. Once the problem definition is approved by the faculty member, every team has to perform all
the practical based on their respective problem definition.
Software Engineering (3161605) No: 210430116124

Index
(Progressive Assessment
Sheet)

Sr. Objective(s) of Experiment Page Date of Date of Assessment Sign. of Remarks

No. No. perfor submiss Marks Teacher
mance ion with
date
1 Study of various type of Software Process
models with comparison and find out which
process model will be appropriate for your
selected Project.
2 Discuss the Project Management: Project
Planning and Project Scheduling about your
Project.
3 Prepare the Software Requirement
Specification (SRS) document for selected
project.
4 Draw the Data Flow Diagram for your selected
Project.
5 Draw the Entity-Relationship Diagram for your
selected Project
6 Draw Usecase Diagram for your selected
Project.
7 Solve the problem by applying basic
COCOMO model.
8 Modeling UML Class Diagrams and
Sequence diagrams
9. Design the various test cases to perform the
testing of the system and also perform the
various type of testing.
10. Study of any two Open-source tools in
DevOps for Infrastructure Automation,
Configuration Management, Deployment
Automation, Performance Management, Log
Management Monitoring.
Total
Software Engineering (3161605) No: 210430116124

Practical – 1
AIM: Study of various type of Software Process models with comparison and find out which process
model will be appropriate for your selected Project.

Objectives: To learn different process models and identify suitable model for the project development.

 Theory:
A software process is defined as a collection of work activities, actions, and tasks that are
performed when some work product is to be created.

List of Different Process Models

 Waterfall model.
 V model.
 Incremental model.
 RAD model.
 Agile model.
 Iterative model.
 Spiral model.
 Prototype model.

Waterfall Model:
 The Waterfall model is a traditional and linear approach to software development that follows a
sequential and phased structure. It is one of the earliest models used in the field of software
engineering. The process is named "waterfall" because it resembles a waterfall where progress
flows in one direction—downwards through phases like Conception, Initiation, Analysis, Design,
Construction, Testing, Maintenance, and Deployment.
 Here are the main phases of the Waterfall model:

Requirements: In this phase, the requirements for the software project are gathered and
documented. This involves understanding the needs of the end-users and defining the system's
functionality.

Design: Once the requirements are clear, the system architecture and design are created. This
includes high-level design and low-level design, specifying how the system will be built.
Software Engineering (3161605) No: 210430116124

Implementation: The actual coding or programming of the software takes place in this phase.
The design is translated into a programming language, and the system is built according to the
specifications.

Testing: After the implementation, the software undergoes testing to identify and fix any defects
or issues. This phase ensures that the software meets the specified requirements and functions as
intended.

Deployment: Once the software has been thoroughly tested and approved, it is deployed or
released to the end-users or customers.

Maintenance: The final phase involves maintaining and supporting the software. This may
include addressing any issues that arise in the live environment, making updates, and providing
ongoing support.

Figure 1: waterfall model

Software Engineering (3161605) No: 210430116124

Advantages:

1. Uses clear structure

When compared with other methodologies, Waterfall focuses most on a clear, defined set of steps.
Its structure is simple—each project goes through these steps:

 Requirement gathering and documentation

 System design
 Implementation
 Testing
 Delivery/deployment
 Maintenance

2. Determines the end goal early

One of the defining steps of Waterfall is committing to an end product, goal, or deliverable at the
beginning, and teams should avoid deviating from that commitment. For small projects where
goals are clear, the Waterfall model is good for making your team aware of the overall goal from
the start, with less potential for getting lost in the details as the project moves forward.

Unlike Scrum, which divides projects up into individual sprints, Waterfall is good for keeping the
focus on the end goal at all times. If your team has a concrete goal with a clear end date, Waterfall
will eliminate the risk of getting bogged down as you work toward that goal.

3. Transfers information well

Waterfall’s approach is highly methodical, so it should come as no surprise that the methodology
emphasizes a clean transfer of information at each step. When applied in a software setting, every
new step involves a new group of people, and though that might not be the case at your company,
you still should aim to document information throughout a project’s lifecycle. Whether you’re
passing projects off at each step or experience unexpected personnel changes, Waterfall prioritizes
accessible information so new additions to the team can get up to speed quickly if needed.
Software Engineering (3161605) No: 210430116124

Disadvantages:

1. Makes changes difficult

One of the drawbacks of waterfall model is also one of its advantages: Waterfall is based entirely
on following a set of steps that keep teams always moving forward. The methodology, in its
traditional form, leaves almost no room for unexpected changes or revisions. So, if your team has
loyally followed the steps of Waterfall nearly to the end of the project but then faces an unplanned
roadblock that necessitates a change in scope or goals, pivoting won’t be easy. You’ll have put a
considerable amount of work into a project under very specific, rigid assumptions. A sudden
change to the parameters of the project could render much of the work you’ve carried out up to
that point useless, which can throw off the entire timeline.

2. Excludes the client and/or end user

Another limitation of the Waterfall model is that as an internal process, the Waterfall methodology
focuses very little on the end user or client involved with a project. Its main purpose has always
been to help internal teams move more efficiently through the phases of a project, which can work
well for the software world. However, if you work in an industry other than software, clients often
want to be involved during a project, adding opinions and clarifying what they want as the project
moves forward.

3. Delays testing until after completion

Testing is one of the biggest downsides of the using the traditional Waterfall approach. Saving the
testing phase until the last half of a project is risky, but Waterfall insists that teams wait until step
four out of six to test their products. Outside of the software industry, the testing phase could mean
showing a new website design to a client, A/B testing content, or taking any number of steps to
gain empirical data on the viability of the project. At this point, the project has likely taken
considerable time to complete, so large revisions could cause significant delays.

V Model:
 V-Model also referred to as the Verification and Validation Model. In this, each phase of SDLC
must complete before the next phase starts. It follows a sequential design process same as the
waterfall model. Testing of the device is planned in parallel with a corresponding stage of
development.
Software Engineering (3161605) No: 210430116124

Figure 2: v model

Verification: It involves a static analysis method (review) done without executing code. It is the
process of evaluation of the product development process to find whether specified requirements
meet.

Validation: It involves dynamic analysis method (functional, non-functional), testing is done by

executing code. Validation is the process to classify the software after the completion of the
development process to determine whether the software meets the customer expectations and
requirements.

Advantage:

 Easy to Understand.
 Testing Methods like planning, test designing happens well before coding.
 This saves a lot of time. Hence a higher chance of success over the waterfall model.
 Avoids the downward flow of the defects.
 Works well for small plans where requirements are easily understood.
Disadvantage:

 Very rigid and least flexible.

 Not a good for a complex project.

Software Engineering (3161605) No: 210430116124

 Software is developed during the implementation stage, so no early prototypes of the software are
produced.

 If any changes happen in the midway, then the test documents along with the required documents,
has to be updated.

Incremental Model:
 Incremental Model is a process of software development where requirements divided into multiple
standalone modules of the software development cycle. In this model, each module goes through
the requirements, design, implementation and testing phases. Every subsequent release of the
module adds function to the previous release. The process continues until the complete system
achieved.

Figure 3: incremental model

The various phases of incremental model are as follows:

Software Engineering (3161605) No: 210430116124

Requirement analysis: In the first phase of the incremental model, the product analysis expertise
identifies the requirements. And the system functional requirements are understood by the
requirement analysis team. To develop the software under the incremental model, this phase
performs a crucial role.

Design & Development: In this phase of the Incremental model of SDLC, the design of the
system functionality and the development method are finished with success. When software
develops new practicality, the incremental model uses style and development phase.

Testing: In the incremental model, the testing phase checks the performance of each existing
function as well as additional functionality. In the testing phase, the various methods are used to test
the behavior of each task.

Implementation: Implementation phase enables the coding phase of the development system. It
involves the final coding that design in the designing and development phase and tests the
functionality in the testing phase. After completion of this phase, the number of the product working
is enhanced and upgraded up to the final system product.

Advantages:

 Errors are easy to be recognized.

 Easier to test and debug

 More flexible.

 Simple to manage risk because it handled during its iteration.

 The Client gets important functionality early.

Disadvantage
 Need for good planning

 Total Cost is high.

 Well defined module interfaces are needed.

Software Engineering (3161605) No: 210430116124

RAD Model:
 RAD is a linear sequential software development process model that emphasizes a concise
development cycle using an element-based construction approach. If the requirements are well
understood and described, and the project scope is a constraint, the RAD process enables a
development team to create a fully functional system within a concise time period.

Figure 4: RAD model

The various phases of RAD are as follows:

Business Modelling: The information flow among business functions is defined by answering
questions like what data drives the business process, what data is generated, who generates it,
where does the information go, who process it and so on.

Data Modelling: The data collected from business modeling is refined into a set of data objects
(entities) that are needed to support the business. The attributes (character of each entity) are
identified, and the relation between these data objects (entities) is defined.

Process Modelling: The information object defined in the data modeling phase are transformed
to achieve the data flow necessary to implement a business function. Processing descriptions are
created for adding, modifying, deleting, or retrieving a data object.

Application Generation: Automated tools are used to facilitate construction of the software;
even they use the 4th GL techniques.
Software Engineering (3161605) No: 210430116124

Testing & Turnover: Many of the programming components have already been tested since
RAD emphasis reuse. This reduces the overall testing time. But the new part must be tested, and
all interfaces must be fully exercised.

Advantages:

 This model is flexible for change.

 In this model, changes are adoptable.

 Each phase in RAD brings highest priority functionality to the customer.

 It reduced development time.

 It increases the reusability of features.

Disadvantage:
 It required highly skilled designers.

 All application is not compatible with RAD.

 For smaller projects, we cannot use the RAD model.

 On the high technical risk, it's not suitable.

 Required user involvement

Agile model:
 The meaning of Agile is swift or versatile. "Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into smaller
iterations, or parts do not directly involve long term planning. The project scope and requirements
are laid down at the beginning of the development process. Plans regarding the number of
iterations, the duration and the scope of each iteration are clearly defined in advance.
Software Engineering (3161605) No: 210430116124

Figure 5: Agile model

Following are the phases in the Agile model are as follows:

Requirements gathering: In this phase, you must define the requirements. You should explain
business opportunities and plan the time and effort needed to build the project. Based on this
information, you can evaluate technical and economic feasibility.

Design the requirements: When you have identified the project, work with stakeholders to define
requirements. You can use the user flow diagram or the high-level UML diagram to show the work of
new features and show how it will apply to your existing system.

Construction/ iteration: When the team defines the requirements, the work begins. Designers and
developers start working on their project, which aims to deploy a working product. The product will
undergo various stages of improvement, so it includes simple, minimal functionality.

Testing: In this phase, the Quality Assurance team examines the product's performance and looks for
the bug.

Deployment: In this phase, the team issues a product for the user's work environment.

Feedback: After releasing the product, the last step is feedback. In this, the team receives feedback
about the product and works through the feedback.
Software Engineering (3161605) No: 210430116124

Advantages:

 Frequent Delivery

 Face-to-Face Communication with clients.

 Efficient design and fulfils the business requirement.

 Anytime changes are acceptable.

 It reduces total development time.

Disadvantage:

 Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.

 Due to the lack of proper documentation, once the project completes and the developers allotted to
another project, maintenance of the finished project can become a difficulty.

Iterative model:
 In this Model, you can start with some of the software specifications and develop the first version
of the software. After the first version if there is a need to change the software, then a new version
of the software is created with a new iteration. Every release of the Iterative Model finishes in an
exact and fixed period that is called iteration.

 The Iterative Model allows the accessing earlier phases, in which the variations made respectively.
The final output of the project renewed at the end of the Software Development Life Cycle
(SDLC) process.
Software Engineering (3161605) No: 210430116124

Figure 6:iterative model

The various phases of Iterative model are as follows:

Requirement gathering & analysis: In this phase, requirements are gathered from customers
and check by an analyst whether requirements will fulfil or not. Analyst checks that need will
achieve within budget or not. After all of this, the software team skips to the next phase.

Design: In the design phase, team design the software by the different diagrams like Data Flow
diagram, activity diagram, class diagram, state transition diagram, etc.

Implementation: In the implementation, requirements are written in the coding language and
transformed into computer programmes which are called Software.

Testing: After completing the coding phase, software testing starts using different test methods.
There are many test methods, but the most common are white box, black box, and grey box test
methods.

Deployment: After completing all the phases, software is deployed to its work environment.

Review: In this phase, after the product deployment, review phase is performed to check the
behaviour and validity of the developed product. And if there are any error found then the process
starts again from the requirement gathering.

Maintenance: In the maintenance phase, after deployment of the software in the working
environment there may be some bugs, some errors or new updates are required. Maintenance
involves debugging and new addition options.
Software Engineering (3161605) No: 210430116124

Advantages:

 Testing and debugging during smaller iteration is easy.

 A Parallel development can plan.

 It is easily acceptable to ever-changing needs of the project.

 Risks are identified and resolved during iteration.

 Limited time spent on documentation and extra time on designing.

Disadvantage:

 It is not suitable for smaller projects.

 More Resources may be required.

 Design can be changed again and again because of imperfect requirements.

 Requirement changes can cause over budget.

 Project completion date not confirmed because of changing requirements.

Spiral model
 The spiral model, initially proposed by Boehm, is an evolutionary software process model that
couples the iterative feature of prototyping with the controlled and systematic aspects of the linear
sequential model. It implements the potential for rapid development of new versions of the
software. Using the spiral model, the software is developed in a series of incremental releases.
During the early iterations, the additional release may be a paper model or prototype. During later
iterations, more and more complete versions of the engineered system are produced.
Software Engineering (3161605) No: 210430116124

Figure 7: Spiral model

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle, the
various alternatives that are possible for achieving the targets, and the constraints that exists.

Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located on the
risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve uncertainties and
risks. This process may include activities such as benchmarking, simulation, and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether to
continue with a further period of the spiral. If it is determined to keep, plans are drawn up for the next
step of the project.

Advantages:

 High amount of risk analysis

 Useful for large and mission-critical projects.

Disadvantage:

 Can be a costly model to use.

 Risk analysis needed highly particular expertise

Software Engineering (3161605) No: 210430116124

 Doesn't work well for smaller projects.

Prototype model:
 The prototype model requires that before carrying out the development of actual software, a
working prototype of the system should be built. A prototype is a toy implementation of the
system. A prototype usually turns out to be a very crude version of the actual system, possible
exhibiting limited functional capabilities, low reliability, and inefficient performance as compared
to actual software. In many instances, the client only has a general view of what is expected from
the software product. In such a scenario where there is an absence of detailed information
regarding the input to the system, the processing needs, and the output requirement, the
prototyping model may be employed.

Figure 8: Prototype model

Steps of Prototype Model:

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product
Software Engineering (3161605) No: 210430116124

Advantages:

 Reduce the risk of incorrect user requirement

 Good where requirement is changing/uncommitted

 Regular visible process aids management

 Support early product marketing

 Reduce Maintenance cost.

 Errors can be detected much earlier as the system is made side by side.

Disadvantages:

 An unstable/badly implemented prototype often becomes the final product.

 Require extensive customer collaboration

 Costs customer money.

 Needs committed customer.

 Difficult to finish if customer withdraw

 May be too customer specific, no broad market

 Difficult to know how long the project will last.

 Easy to fall back into the code and fix without proper requirement analysis, design, customer
evaluation, and feedback.

 Prototyping tools are expensive.

 Special tools & techniques are required to build a prototype.

 It is a time-consuming process
Software Engineering (3161605) No: 210430116124

Quiz:

1. Compare waterfall model and incremental

model. Ans:

Aspect Waterfall Model Incremental Model

Development
Sequential and linear Iterative and incremental
process
Distinct phases (requirements, Divided into small,
Phases
design, etc.) manageable increments

Flexibility to More flexible, changes can be easily

Less flexible
changes incorporated
Higher risk, especially with unclear
Risk management Lower risk due to iterative nature
requirements
Earlier delivery of
Delivery time Longer delivery time
partial functionality
Client Continuous involvement with
Mainly at the beginning and end
involvement early increments

Testing At the end of the development cycle At the end of each increment

2. State weather the following statements are true or false. Justify your answer.
a) Software development organizations which follow the iterative waterfall model for
product development provide maximum customer satisfaction.
b) The loops for spiral model are fixed.

Ans:

a) Software development organizations which follow the iterative waterfall model

for product development provide maximum customer satisfaction.

 False: The iterative waterfall model is still a sequential and phased approach like the traditional
waterfall model. While it allows for some degree of iteration, it might not provide the maximum
customer satisfaction as it can be less adaptive to changing requirements during the development
process. Other iterative and incremental models like Agile or Scrum are often considered more
customer-centric due to their flexibility, continuous feedback loops, and early delivery of
functional increments.
 Software Engineering (3161605) No: 210430116124

b) The loops for the spiral model are fixed.

 False: The Spiral model is characterized by loops or cycles, each representing a phase in the
software development process (e.g., planning, risk analysis, engineering, testing). However, the
number of loops is not fixed; it depends on the project's specific needs and complexities. The
model is inherently flexible, allowing for multiple iterations of the spiral to address evolving
requirements, incorporate feedback, and manage risks. The number of loops can vary based on
the project's unique circumstances.

Difference between all process models:

Model Description Strengths Weaknesses Best suited for

Sequential Well-defined Inflexible, high Stable requirements,
phases process, clear upfront cost, well- understood
(requirements, documentation difficult to projects
Waterfall design, change
implementation,
testing,
deployment)
Sequential, with Focus on Moderate Requirements are
testing phases Quality flexibility to Well-Defined
V Model corresponding to Assurance change
development
phases
Delivers Early delivery of Can lead to Complex projects
software in small functionality, feature creep, with well-defined
Increment increments manageable potential rework features, phased
al chunks of work deliveries

Iterative with Fast feedback, Incomplete New concepts,

rapid prototyping low upfront cost, functionality, gathering user
RAD early validation potential for feedback, exploring
of concepts scope creep technical feasibility
Iterative and Flexible, Requires strong Complex projects
incremental, adaptable to team with evolving
Agile short feedback changing communication, requirements,
loops, close requirements, potential for uncertain
collaboration fast feedback scope creep environments
Repeated cycles Flexibility, Can be complex Projects with
of design, adaptability to to manage, evolving
development, changing requires strong requirements, need
Iterative testing, requirements, team for early feedback,
refinement early feedback communication uncertainty about
technical feasibility
Iterative with Proactive risk Complex, High-risk projects,
Spiral
 Software Engineering (3161605) No: 210430116124

risk management mitigation, requires projects with

focus adaptability to experienced evolving
changing needs, team, potentially requirements,
well- defined slower complex systems
process development
Develops rapid, Early feedback, Incomplete New concepts,
working models low upfront cost, functionality, gathering user
validates can lead to scope feedback, exploring
Prototype concepts quickly creep, not technical feasibility,
suitable for final validating
product requirements

Best suited model for our project:

Prototype model

 Prototyping allows you to quickly test and validate design ideas, concepts, and features before
investing significant time and resources into full-scale development.

 By creating a prototype, you can gather feedback from stakeholders and end-users early in the
process, helping to ensure that your final product meets their needs and expectations.

 By applying Prototype model into our project, it can offer several benefits

– Identification of Design Flaws: Prototyping enables you to identify and address design
flaws, usability issues, and functionality gaps early in the development process. By testing
the prototype with real users, you can uncover any areas of confusion or frustration and
make necessary adjustments to improve the user experience.

– Reduced Development Costs: By identifying and addressing issues early in the process,
prototyping can help reduce the overall development costs. Fixing problems during the
design phase is typically less expensive than making changes during development or after
the product has been released.

– Faster Time-to-Market: Prototyping enables you to accelerate the development process and
bring your product to market faster. By quickly iterating on design ideas and features, you
can streamline the development cycle and reduce time spent on rework or revisions.

– Enhanced Stakeholder Communication: Prototypes serve as effective communication tools

for conveying design concepts and ideas to stakeholders, clients, and development teams.
Visual prototypes help stakeholders visualize the final product and provide valuable
feedback that can inform subsequent iterations.
Software Engineering (3161605) No: 210430116124

– The Prototype model promotes an iterative approach to development, allowing you to

refine and improve the prototype based on feedback and testing results. Each iteration
builds upon the previous one, incorporating lessons learned and moving closer to the final
product

 In summary, applying the Prototype model to our project can help us validate ideas, identify
design flaws, iterate quickly, reduce costs, accelerate time-to-market, enhance
communication, and mitigate risks.

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

2. Roger S. Pressman, Software Engineering- A practitioner’s Approach, McGraw-Hill
International Editions

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty:
Software Engineering (3161605) No: 210430116124

Practical – 2
AIM: Discuss the Project Management: Project Planning and Project Scheduling about your Project.

Objectives:

1. To represent the plan to deliver the project scope over time.

Theory:
Planning details for a portfolio-related website like "Personal Portfolio Website" can
encompass various aspects of its development and operation. Here are some key plan details:

1. Content Planning:
 Plan the content structure of the website. This typically includes sections such as:
 About Me/Bio: A brief introduction about yourself, your background, and your
expertise.
 Portfolio: Showcase your work, projects, case studies, or accomplishments. Include
descriptions, images, and links where applicable.
 Resume/CV: Provide a downloadable or accessible version of your resume or CV.
 Services (if applicable): Outline the services you offer, along with pricing or package
details.
 Testimonials: Include testimonials or reviews from past clients or employers.
 Contact: Provide contact information or a contact form for inquiries or collaborations.
 Blog (optional): If you plan to share insights, tutorials, or industry-related content,
consider including a blog section.

2. Design and User Experience (UX):

 Determine the design aesthetic and user experience you want to achieve. Consider factors like:
 Visual appeal: Choose a visually appealing design that aligns with your personal brand.
 Navigation: Ensure easy navigation throughout the website, with clear menus and links.
 Responsiveness: Optimize the website for various devices and screen sizes, including
desktops, tablets, and smartphones.
 Accessibility: Ensure that the website is accessible to users with disabilities, adhering to
accessibility standards (e.g., WCAG).

3. Technology Stack:
 Choose the appropriate technology stack for building the website. Consider factors such as:
 Content Management System (CMS): Decide whether to use a CMS like WordPress,
Joomla, or a static site generator like Jekyll or Hugo.
 Frontend Framework: Select a frontend framework for designing the user interface (e.g.,
React, Vue.js).
 Hosting: Choose a reliable hosting provider that meets your requirements for
performance, security, and scalability.
 Domain Name: Register a domain name that reflects your personal brand or business.
Software Engineering (3161605) No: 210430116124

4. SEO and Marketing Strategy:

 Develop a strategy for search engine optimization (SEO) to improve the visibility of
your website in search engine results.
 Implement SEO best practices, including keyword research, meta tags optimization,
image optimization, and content optimization.
 Plan marketing initiatives to promote your portfolio website, such as social media
marketing, email newsletters, and networking events.
Software Engineering (3161605) No: 210430116124

Quiz:

1) Explain project scheduling process.

Ans:
Project scheduling is the process of creating a timeline or roadmap that outlines the sequence of
tasks and activities needed to complete a project within a specified timeframe. It involves
breaking down the project into smaller, manageable tasks, estimating the time required for each
task, determining their dependencies, and arranging them in a logical order to achieve the
project's objectives efficiently. Here are steps to the project scheduling process:

 Define the Project Scope

 Identify Activities
 Sequence Activities
 Estimate Duration
 Develop the Schedule
 Allocate the Resources
 Optimize the Schedule
 Finalize the Schedule
 Monitor and Control
 Update the Schedule

2) Explain Software metrics used for software cost estimation

Ans:
Software metrics play a crucial role in estimating the cost of software development projects.
These metrics provide quantitative measures of various aspects of the software development
process, allowing project managers to make informed decisions and accurately estimate the
resources required for a project. Here are some commonly used software metrics for software
cost estimation:

 Lines of Code (LOC): Measures the size of the codebase, providing a rough estimate of
development effort.

 Function Points (FP): Standardized measure based on system functionality, aiding in

estimating development effort and duration.

 Cyclomatic Complexity: Measures code complexity, helping to identify areas that may
require more effort for testing and maintenance.

 Effort Estimation: Predicts human effort needed for development, relying on historical data
or estimation models like COCOMO.

 Cost Estimation: Quantifies financial resources required for development and maintenance,
aiding in budget allocation.

 Schedule Estimation: Predicts project completion time, based on historical data, team
experience, and productivity rates.

 Defect Density: Measures defects relative to software size, assisting in assessing and
Software Engineering (3161605) No: 210430116124

improving software quality.

 Productivity Metrics: Track efficiency of development process, aiding in identifying areas

for improvement and estimating future productivity levels.

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

2. Roger S. Pressman, Software Engineering- A practitioner’s Approach, McGraw-Hill
International Editions

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Software Engineering (3161605) No: 210430116124

Practical – 3
AIM: Prepare the Software Requirement Specification (SRS) document for selected project.

Objectives:

1. Learn how to provide a detailed overview of our software product, its parameters and goals.

2. Describes the project's target audience and its user interface, hardware and software requirements.

Theory:

A software requirements specification (SRS) is a document that is created when a detailed description of
all aspects of the software to be built must be specified before the project is to commence. It is important
to note that a formal SRS is not always written. In fact, there are many instances in which effort
expended on an SRS might be better spent in other software engineering activities. However, when
software is to be developed by a third party, when a lack of specification would create severe business
issues, or when a system is extremely complex or business critical, an SRS may be justified.

IEEE Template for SRS

Software Engineering (3161605) No: 210430116124

Software Requirements Specification

For Personal Portfolio Website
Version 1.0 approved

Prepared by
210430116123
210430116124

Shantilal Shah Engineering College, Bhavnagar

03-19-2024
Software Engineering (3161605) No: 210430116124

Table of Contents
Table of Contents 34
Revision History 34
1. Introduction 35
1.1 Purpose 35
1.2 Document Conventions 35
1.3 Intended Audience and Reading Suggestions 35
1.4 Product Scope 35
1.5 References 35
2. Overall Description 36
2.1 Product Perspective 36
2.2 Product Functions 36
2.3 User Classes and Characteristics 36
2.4 Operating Environment 36
2.5 Design and Implementation Constraints 36
2.6 User Documentation 36
2.7 Assumptions and Dependencies 37
3. External Interface Requirements 37
3.1 User Interfaces 37
3.2 Hardware Interfaces 37
3.3 Software Interfaces 37
3.4 Communications Interfaces 37
4. System Features 37
4.1 System Feature 1 37
4.2 System Feature 2 (and so on) 38
5. Other Nonfunctional Requirements 38
5.1 Performance Requirements 38
5.2 Safety Requirements 38
5.3 Security Requirements 38
5.4 Software Quality Attributes 38
5.5 Business Rules 38
6. Other Requirements 39
Appendix A: Glossary 39
Appendix B: Analysis Models 39
Appendix C: To Be Determined List 41

Revision History
Name Date Reason For Changes Version
Software Engineering (3161605) No: 210430116124

1. INTRODUCTION

1.1 Purpose
A portfolio website is a digital platform designed to showcase an individual's or a company's
work, achievements, skills, and capabilities. It serves as a comprehensive presentation of past
projects, creative endeavors, professional accomplishments, and relevant experiences. The primary
purpose of a portfolio website is to provide a centralized location where potential clients,
employers, collaborators, or other stakeholders can explore and evaluate the creator's expertise,
style, and suitability for specific opportunities.

1.2 Document Conventions

In a portfolio website, document conventions ensure consistency and clarity in design and
organization. These conventions include a clear navigation menu for easy access, consistent
header and footer layouts, uniform typography and color schemes, standardized image formatting,
structured content with headings and paragraphs, and cohesive styling of interactive elements.
Adhering to these conventions creates a professional and user-friendly experience, enhancing
readability, navigation, and overall presentation of the portfolio's content.

1.3 Intended Audience and Reading Suggestions

The intended audience for a personal portfolio website includes potential clients, employers,
collaborators, and peers seeking to evaluate the creator's skills and suitability for projects or
opportunities. Reading suggestions tailored for this audience might include detailed project case
studies, client testimonials, a comprehensive About Me section highlighting skills and
experiences, and a portfolio showcasing diverse examples of work. Additionally, including a blog
or resources section with industry insights, tips, and thought leadership can engage and inform
visitors. Overall, the website should provide compelling content and showcase the creator's
expertise, professionalism, and personality effectively.

1.4 Product Scope

The product scope for a personal portfolio website includes creating a digital platform to showcase
the creator's skills, projects, achievements, and experiences. It should feature a user-friendly
interface, responsive design, comprehensive portfolio sections, an About Me page, contact
information, and potentially a blog or resources section for additional engagement.

1.5 References
Build a Portfolio Without Professional Experience Today (rumie.org)
How to create a portfolio (w3schools.com)
50 Best Portfolio Website Templates 2024 - Colorlib
Software Engineering (3161605) No: 210430116124

2. Overall Description

2.1 Product Perspective

The product perspective for a portfolio website involves considering it as a standalone digital
platform that showcases the creator's work and skills. It should be user-focused, emphasizing ease
of navigation, clear presentation of content, and seamless integration of multimedia elements to
effectively communicate the creator's expertise and style.

2.2 Product Functions

The product functions for a portfolio website include showcasing the creator's work through
multimedia elements such as images, videos, and case studies. It allows visitors to navigate
through different sections, view project details, read testimonials, contact the creator, and
potentially engage with additional content like a blog or resources section.

2.3 User Classes and Characteristics

User classes for a portfolio website include potential clients, employers, collaborators, and peers.
Characteristics may vary, but users generally seek to evaluate the creator's skills, expertise, and
suitability for projects or opportunities. They may have diverse backgrounds, interests, and levels
of familiarity with the creator's industry or field.

2.4 Operating Environment

The operating environment for a portfolio website encompasses various web browsers, devices,
and internet connectivity levels. It should be compatible with popular browsers like Chrome,
Firefox, and Safari, accessible on desktops, laptops, tablets, and mobile devices, and optimized for
different screen sizes and resolutions.

2.5 Design and Implementation Constraints

Design and implementation constraints for a portfolio website may include adherence to web
standards and accessibility guidelines, limitations of chosen website-building platforms or
frameworks, compatibility with older browsers, and considerations for hosting and bandwidth
restrictions. Additionally, budgetary constraints and time limitations may impact design choices
and feature implementation.

2.6 User Documentation

User documentation for a portfolio website may include a user guide or FAQ section explaining
how to navigate the site, view projects, contact the creator, and access additional resources. It may
also provide troubleshooting tips, browser compatibility information, and instructions for using
interactive features.
Software Engineering (3161605) No: 210430116124

2.7 Assumptions and Dependencies

Assumptions for a portfolio website may include reliable internet access for visitors, adherence to
web standards by browsers, and basic familiarity with website navigation. Dependencies may
include third-party services for hosting, domain registration, or analytics, as well as updates to
browser or device software impacting website performance.

3. External Interface Requirements

3.1 User Interfaces

User interfaces for a portfolio website comprise intuitive navigation menus, clear call-to-action
buttons, and visually appealing layouts. They facilitate easy access to portfolio sections, project
details, and contact information. Responsive design ensures seamless viewing across devices, while
interactive elements engage users and enhance the browsing experience.

3.2 Hardware Interfaces

Hardware interfaces for a portfolio website involve compatibility with various devices such as
desktop computers, laptops, tablets, and smartphones. The website should adapt to different screen
sizes and resolutions, ensuring optimal viewing and functionality across different hardware
configurations without requiring specific hardware components or connections.

3.3 Software Interfaces

Software interfaces for a portfolio website include compatibility with web browsers such as
Chrome, Firefox, Safari, and Edge. The website should also be compatible with different operating
systems like Windows, macOS, iOS, and Android. Additionally, integration with content
management systems or e-commerce platforms may be necessary for website management and
functionality.

3.4 Communications Interfaces

Communications interfaces for a portfolio website involve forms or contact sections enabling
visitors to reach out to the creator. These interfaces may include contact forms, email addresses, and
social media links, facilitating communication between visitors and the creator for inquiries,
collaborations, or networking opportunities.

4. System Features

4.1 System Feature 1

System Feature 1 for a portfolio website could be a "Project Showcase" section where the creator
displays their work with detailed descriptions, images, and possibly videos. This feature allows
visitors to explore the creator's portfolio, view their skills and expertise, and gain insight into their
style and capabilities.
Software Engineering (3161605) No: 210430116124

4.2 System Feature 2 (and so on)

System Feature 2 for a portfolio website might be a "Testimonials" section, showcasing feedback
and endorsements from previous clients or collaborators. This feature enhances credibility and
trustworthiness, providing validation of the creator's skills and professionalism to potential clients
or employers.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

Performance requirements for a portfolio website include fast loading times to ensure optimal user
experience, with pages loading within a few seconds. It should also handle concurrent user
interactions efficiently, maintain uptime reliability of at least 99%, and be scalable to accommodate
increasing traffic and content updates without degradation in performance.

5.2 Safety Requirements

Safety requirements for a portfolio website involve implementing secure connections (HTTPS),
safeguarding user data with encryption and data protection measures, and regularly updating
software to mitigate security vulnerabilities. Additionally, measures should be in place to prevent
unauthorized access, spam, and malicious attacks, ensuring the safety and integrity of the website
and its users.

5.3 Security Requirements

Security requirements for a portfolio website include robust user authentication mechanisms, secure
storage of sensitive information, and protection against common web threats such as SQL injection,
cross-site scripting (XSS), and distributed denial-of-service (DDoS) attacks. Regular security audits
and updates should be conducted to ensure ongoing protection against emerging threats.

5.4 Software Quality Attributes

Software quality attributes for a portfolio website include usability, ensuring an intuitive interface
and seamless navigation. Additionally, reliability ensures consistent performance and minimal
downtime. Accessibility ensures the website is usable by individuals with disabilities. Finally,
maintainability ensures ease of updating and modifying the website to accommodate changes and
improvements over time.

5.5 Business Rules

Business rules for a portfolio website may include pricing policies, terms of service, and copyright
regulations governing the use of content. Additionally, rules for handling client inquiries, project
inquiries, and collaborations may be defined to streamline communication and ensure adherence to
professional standards and legal requirements.
Software Engineering (3161605) No: 210430116124

6. Other Requirements
Other requirements for a portfolio website may include compliance with data protection
regulations such as GDPR, ensuring user consent for data collection and processing. Additionally,
the website should adhere to industry standards for web design and accessibility, providing an
inclusive experience for all visitors, regardless of their abilities.

Appendix A: Glossary
1. Portfolio: A collection of work samples, projects, or achievements displayed to showcase skills,
expertise, and experience.
2. Homepage: The main landing page of a website, often containing an overview or introduction to
the individual and their work.
3. About Me: A section of the website dedicated to providing information about the individual,
including their background, skills, interests, and experiences.
4. Projects: A section showcasing the individual's past work or projects, including descriptions,
images, and links to further details.
5. Resume/CV: A digital version of the individual's resume or curriculum vitae, highlighting their
education, work experience, skills, and achievements.
6. Contact: A section or page with contact information, such as email address, phone number, and
possibly a contact form, allowing visitors to reach out to the individual.
7. Skills: A list or section detailing the skills and expertise possessed by the individual, often
categorized or ranked based on proficiency.
8. Testimonials: Quotes or feedback from clients, colleagues, or employers endorsing the
individual's skills, work ethic, or character.
9. Blog: An optional section where the individual can share thoughts, insights, or updates related to
their work, industry trends, or personal experiences.
10. Responsive Design: Design approach ensuring the website functions and looks good across
various devices and screen sizes, including desktops, tablets, and smartphones.
11. Navigation: The menu or system of links that allows visitors to navigate through different sections
or pages of the website.

Appendix B: Analysis Models

An analysis model for evaluating a personal portfolio website:
1. Purpose: Determine the primary objective of the website, whether it's to showcase work, attract
clients or employers, or simply provide information about the individual.
2. Target Audience: Identify the intended audience for the website, such as potential clients,
employers, collaborators, or peers in the industry.
3. Content: Evaluate the quality, relevance, and organization of the content on the website,
including portfolio items, about me section, resume/CV, blog posts (if any), and contact
information.
4. Design and User Experience (UX):
 Visual Design: Assess the aesthetics, consistency, and appeal of the website's design.
Software Engineering (3161605) No: 210430116124

 Navigation: Evaluate the ease of navigation and intuitiveness of the website's structure and
menu system.
 Responsiveness: Check if the website is optimized for various devices and screen sizes,
providing a seamless user experience.
 Accessibility: Ensure that the website is accessible to users with disabilities, adhering to
WCAG (Web Content Accessibility Guidelines) standards.
 Interactivity: Assess the level of interactivity and engagement offered by the website, such
as animations, hover effects, and interactive elements.
5. Functionality:
 Contact Form: Check the functionality and ease of use of the contact form (if applicable).
 Social Media Integration: Evaluate integration with social media platforms for easy
sharing and networking.
 Portfolio Filtering/Sorting: If applicable, assess the ability to filter or sort portfolio items
based on categories, tags, or other criteria.
 Search Functionality: Evaluate the presence and effectiveness of a search feature,
especially for websites with a large amount of content.
 Performance: Assess the speed and loading times of the website, optimizing for fast
performance.
6. SEO (Search Engine Optimization):
Meta Tags: Evaluate the presence and optimization of meta tags, including title tags, meta
descriptions, and keywords.
 Content Quality: Assess the quality, relevance, and uniqueness of the content for search
engine ranking.
 Backlinks: Check for the presence of backlinks from reputable websites to improve search
engine visibility.
 Site Structure: Evaluate the website's structure and hierarchy for optimal crawling and
indexing by search engines.
7. Analytics and Tracking:
 Google Analytics: Assess the integration of Google Analytics or other analytics tools for
tracking website traffic, user behavior, and conversions.
 Conversion Tracking: Evaluate the setup of goals and conversion tracking to measure the
effectiveness of the website in achieving its objectives.
8. Security:
 SSL Certificate: Ensure the presence of an SSL certificate for secure communication
between the website and its visitors.
 Data Privacy: Evaluate compliance with data privacy regulations, such as GDPR (General
Data Protection Regulation), especially if collecting personal information through contact
forms or analytics.
9. Maintenance and Updates:
 Content Updates: Consider the ease of updating and adding new content to the website,
such as portfolio items or blog posts.

 Software Updates: Evaluate the maintenance plan for keeping the website's software,
Software Engineering (3161605) No: 210430116124

plugins, and themes up to date to ensure security and compatibility.

10.Feedback and Improvement:

 User Feedback: Gather feedback from users, peers, or mentors to identify areas for
improvement in design, content, or functionality.
 Testing: Conduct usability testing and A/B testing to identify any usability issues and
optimize user experience.

Appendix C: To Be Determined List

 Client Testimonials Section: Create a dedicated section for displaying testimonials from
satisfied clients or collaborators, showcasing positive feedback and endorsements.
 Case Studies: Develop in-depth case studies for select portfolio projects, providing
detailed insights into the process, challenges, solutions, and outcomes of each project.
 Expanded Blog Section: Expand the blog section to include more frequent and diverse
content, such as industry insights, project updates, tutorials, or personal reflections on
relevant topics.
 Multimedia Content: Incorporate multimedia content like videos, animations, or
interactive demos to enhance the visual appeal and engagement of the website.
 Language Localization: Implement language localization features to provide content in
multiple languages, catering to a broader international audience.
 Advanced Search Functionality: Enhance the search functionality to allow visitors to
search for specific content within the portfolio, such as projects by industry, technology
stack, or client name.

Quiz:

1. Which are properties of good SRS?

Ans:
 Clear and Concise: The SRS should be easy to understand, avoiding ambiguity and
unnecessary complexity.
 Complete: It should address all requirements and functionalities expected from the software.
 Consistent: Information and requirements should be coherent and not contradict each other.
 Verifiable: Requirements should be testable, allowing for verification of software
functionality.
 Traceable: Each requirement should be uniquely identifiable and traceable back to its
source.
 Feasible: Requirements should be realistic and achievable within project constraints.
 Prioritized: Requirements should be ranked by importance, aiding in resource allocation and
decision-making.
 Modifiable: The SRS should be flexible and adaptable to accommodate changes throughout
the software development lifecycle.
Software Engineering (3161605) No: 210430116124

2. What is functional and non-functional requirement?

Ans:
 Functional Requirements: These define specific functions or features that the software
system must perform, such as calculations, data processing, or user interactions. They
describe what the system should do.
 Non-functional Requirements: These specify the quality attributes and constraints of the
system, such as performance, security, reliability, usability, and scalability. They describe
how the system should behave or perform, rather than what it should do.

Suggested Reference:
1. Ian Sommerville, Software engineering, Pearson education Asia
2. Roger S. Pressman, Software Engineering- A practitioner’s Approach, McGraw-Hill
International Editions

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Software Engineering (3161605) No: 210430116124

Practical – 4
AIM: Draw the Data Flow Diagram for your selected Project.

 Objectives:
To learn flow-oriented model through data flow diagrams.

 Theory:
The DFD takes an input-process-output view of a system. That is, data objects flow into the
software, are transformed by processing elements, and resultant data objects flow out of the
software. The data flow diagram enables you to develop models of the information domain and
functional domain.

Term Notation Remarks

External
Name of the external entity is written inside the rectangle
entity

Process Name of the process is written inside the circle

A left-right open rectangle is denoted as data store; name of the data

Data store
store is written inside the shape

Data flow Data flow is represented by a directed arc with its data name
Software Engineering (3161605) No: 210430116124

Explanation of Symbols used in DFD

 Process: Processes are represented by circle. The name of the process is written into the circle.
The name of the process is usually given in such a way that represents the functionality of the
process. More detailed functionalities can be shown in the next Level if it is required. Usually it
is better to keep the number of processes less than 7. If we see that the number of processes
becomes more than 7 then we should combine some the processes to a single one to reduce the
number of processes and further decompose it to the next level .
 External entity: External entities are only appeared in context diagram. External entities are
represented by a rectangle and the name of the external entity is written into the shape. These
send data to be processed and again receive the processed data.
 Data store: Data stares are represented by a left-right open rectangle. Name of the data store is
written in between two horizontal lines of the open rectangle. Data stores are used as repositories
from which data can be flown in or flown out to or from a process.
 Data flow: Data flows are shown as a directed edge between two components of a Data Flow
Diagram. Data can flow from external entity to process, data store to process, in between two
processes and vice-versa.

 Background / Preparation:

Levels of DFD

DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be created. Levels of DFD
are as follows:

 0-level DFD: The primary external entities (boxes) produce information for use by the system
and consume information generated by the system
 1-level DFD: It represents the main functions of the system and how they interact with each
other.
 2-level DFD: It represents the processes within each function of the system and how they
interact with each other.

 Tools / Material Needed:

o Hardware:
o Software:
Software Engineering (3161605) No: 210430116124

0 Level of DFD: zero-level Data Flow Diagram (DFD) for a personal portfolio website:

Personal portfolio Website

Display
Portfolio

Visitor (user)

1 Level of DFD: One-level Data Flow Diagram (DFD) for a personal portfolio website:

Personal portfolio Website

/*Display
Portfolio*/

Visitor (user)
 Software Engineering (3161605) No: 210430116124

/*Request
Portfolio
Data*/

Server
(Backend)

/*Retrieve
Portfolio
Data*/

Database
(Projects, Contact Info, etc….)

2 Level of DFD: Two-level Data Flow Diagram (DFD) for a personal portfolio website:

Personal portfolio Website

/*Display
Portfolio*/

Visitor (user)
Software Engineering (3161605) No: 210430116124

/*Request
Portfolio
Data*/

Server
(Backend)

/*Retrieve
Portfolio
Data*/

Database
(Projects, Contact Info, etc….)

/*Display
Portfolio
Data*/

Visitor
(user)

Quiz:
1. In a data flow diagram, does an arrow represent a flow of control or something else?
Ans:
In a Data Flow Diagram (DFD), an arrow represents the flow of data between different
components of the system, rather than the flow of control. Arrows indicate the direction in which
data moves within the system, showing how data is passed from one component (such as a
process, external entity, or data store) to another.
Software Engineering (3161605) No: 210430116124

2. What is “information flow continuity” and how is it applied as a data flow diagram is refined?
Ans:
"information flow continuity" ensures that the flow of data remains consistent and unbroken as a
Data Flow Diagram (DFD) is refined. It means that data elements identified at higher levels of
abstraction are consistently represented and maintained at lower levels of detail. This principle
ensures consistency, traceability, and integration of data flows throughout the DFD refinement
process.

3. What are the advantages of DFD?

Ans:
The advantages of Data Flow Diagrams (DFDs) include:
 Clarity and simplicity in visualizing data flow.
 Structured analysis by breaking down complex systems.
 Effective communication of system requirements.
 Identification of problems and inefficiencies.
 Scalability for modeling systems of varying complexity.
 Documentation of system architecture and behavior.
 Facilitation of requirements analysis and prioritization.

Suggested Reference:

1. Roger S. Pressman, Software Engineering- A practitioner’s Approach, McGraw-Hill

International Editions

2. Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to
all questions

Signature of the Faculty

Software Engineering (3161605) No: 210430116124

Practical – 5
AIM: Draw the Entity-Relationship Diagram for your selected Project.

 Objectives:
1. Identify entity sets, their attributes, and various relationships
2. Represent the data model through ER diagram

 Theory:
Entity-Relationship model is used to represent a logical design of a database to be created. In ER
model, real world objects (or concepts) are abstracted as entities, and different possible
associations among them are modeled as relationships.

For example, student and school -- they are two entities. Students study in school. So, these two
entities are associated with a relationship "Studies in".

As another example, consider a system where some job runs every night, which updates the
database. Here, job and database could be two entities. They are associated with the
relationship "Updates".

Entity Set and Relationship Set

An entity set is a collection of all similar entities. For example, "Student" is an entity set that
abstracts all students. Ram, John are specific entities belonging to this set. Similarly, a
"Relationship" set is a set of similar relationships.

Attributes of Entity
Attributes are the characteristics describing any entity belonging to an entity set. Any entity in a set
can be described by zero or more attributes.
For example, any student has got a name, age, an address. At any given time a student can study
only at one school. In the school he would have a roll number, and of course a grade in which he
studies. These data are the attributes of the entity set Student.

Keys
One or more attribute(s) of an entity set can be used to define the following keys:

Super key: One or more attributes, which when taken together, helps to uniquely identify an
entity in an entity set. For example, a school can have any number of students. However, if we
know grade and roll number, then we can uniquely identify a student in that school.
Software Engineering (3161605) No: 210430116124

Candidate key: It is a minimal subset of a super key. In other words, a super key might contain
extraneous attributes, which do not help in identifying an object uniquely. When such
attributes are removed, the key formed so is called a candidate key.
Primary key: A database might have more than one candidate key. Any candidate key chosen for a
particular implementation of the database is called a primary key.
Prime attribute: Any attribute taking part in a super key
Weak Entity
An entity set is said to be weak if it is dependent upon another entity set. A weak entity can't be
uniquely identified only by it's attributes. In other words, it doesn't have a super key.

For example, consider a company that allows employees to have travel allowance for their
immediate family. So, here we have two entity sets: employee and family, related by "Can claim
for". However, family doesn't have a super key. Existence of a family is entirely dependent on the
concerned employee. So, it is meaningful only with reference to employee.

Entity Generalization and Specialization

Once we have identified the entity sets, we might find some similarities among them. For example,
multiple person interacts with a banking system. Most of them are customers, and rest employees or
other service providers. Here, customers, employees are persons, but with certain specializations.
Or in other way, person is the generalized form of customer and employee entity sets.

ER model uses the "ISA" hierarchy to depict specialization (and thus, generalization).

Mapping Cardinalities
One of the main tasks of ER modeling is to associate different entity sets. Let's consider two entity
sets E1 and E2 associated by a relationship set R. Based on the number of entities in E1 and E2 are
associated with, we can have the following four type of mappings:

One to one: An entity in E1 is related to at most a single entity in E2, and vice versa
One to many: An entity in E1 could be related to zero or more entities in E2. Any entity in E2 could
be related to at most a single entity in E1.
Many to one: Zero or more number of entities in E1 could be associated to a single entity in E2.
However, an entity in E2 could be related to at most one entity in E1.
Many to many: Any number of entities could be related to any number of entities in E2, including
zero, and vice versa.
ER Diagram
From a given problem statement we identify the possible entity sets, their attributes, and
relationships among different entity sets. Once we have these information, we represent them
pictorially, called an entity-relationship (ER) diagram.
 Software Engineering (3161605) No: 210430116124

ER Diagram of Personal Portfolio Website:

Internships Projects
Address
Name

1 M
User Has Portfolio
Email_id

User_id
Mobile
Experience Education
Software Engineering (3161605) No: 210430116124

Quiz:

1. what is weak entity set?

Ans:
A weak entity set is an entity set that cannot be uniquely identified by its own attributes alone and
depends on another entity set, called the identifying entity set, for its primary key. Weak entities have
a partial key and exist in a one-to-many relationship with the identifying entity set.

2. what is mapping cardinality?

Ans:
Mapping cardinality describes the relationship between entities in an Entity-Relationship (ER) model.
It specifies how many entities from one entity set can be associated with how many entities from
another entity set. In short, it defines the "one-to-one," "one-to-many," "many-to-one," and "many-to-
many" relationships between entities.

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Software Engineering (3161605) No: 210430116124

Practical – 6
AIM: Draw Usecase Diagram for your selected Project .

 Objectives:
1. To write different scenarios of the system’s execution.
2. To explore various UML use case diagram components to draw USECASE diagram.

 Theory:
o A use case diagram is used to represent the dynamic behavior of a system. It encapsulates
the system's functionality by incorporating use cases, actors, and their relationships. It
models the tasks, services, and functions required by a system/subsystem of an
application. It depicts the high-level functionality of a system and also tells how the user
handles a system.
o Purpose of Use Case Diagrams
 The main purpose of a use case diagram is to portray the dynamic aspect of a
system. It accumulates the system's requirement, which includes both internal as
well as external influences. It invokes persons, use cases, and several things that
invoke the actors and elements accountable for the implementation of use case
diagrams. It represents how an entity from the external environment can interact
with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.
o In a use-case diagram, an actor is a user of the system (i.e. Something external to the
system; can be human or non-human) acting in a particular role.
o A use-case is a task which the actor needs to perform with the help of the system,
e.g., find details of a book or print a copy of a receipt in a bookshop.
o We can draw a box (with a label) around a set of use cases to denote the system
boundary, as on the previous slide (“library system”).

Inheritance can be used between actors to show that all use cases of one actor are
available to the other:
If several use cases include, as part of their functionality, another use case, we have a
special way to show this in a use-case diagram with an <<include>> relation.
Software Engineering (3161605) No: 210430116124

If a use-case has two or more significantly different outcomes, we can show this by
extending the use case to a main use case and one or more subsidiary cases.

 Background / Preparation:
How to draw a Use Case diagram?
It is essential to analyze the whole system before starting with drawing a use case diagram, and
then the system's functionalities are found. And once every single functionality is identified, they
are then transformed into the use cases to be used in the use case diagram.
After that, we will enlist the actors that will interact with the system. The actors are the person or
a thing that invokes the functionality of a system. It may be a system or a private entity, such that
it requires an entity to be pertinent to the functionalities of the system to which it is going to
interact.
Once both the actors and use cases are enlisted, the relation between the actor and use case/
system is inspected. It identifies the no of times an actor communicates with the system.
Basically, an actor can interact multiple times with a use case or system at a particular instance
of time.
Following are some rules that must be followed while drawing a use case diagram:
1. A pertinent and meaningful name should be assigned to the actor or a use case of a
system.
2. The communication of an actor with a use case must be defined in an understandable
way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of
interactions between the use case and actors.
The purposes of use case diagrams can be as follows:

 Used to gather requirements of a system.

 Used to get an outside view of a system.
 Identify external and internal factors influencing the system.
 Show the interacting among the requirements are actors.
Scenarios
• Scenarios are real-life examples of how a system can be used.
• They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;
 Software Engineering (3161605) No: 210430116124

A description of the state when the scenario finishes.

 Tools / Material Needed:
 Hardware
 Web Server
 Database Server
 Load Balancer
 Firewall
 Router
 Client Devices

 Software
 User Interface
 Authentication System
 Search Engine
 Order Management System
 Payment Gateway
 Content Management System
 Notification System
 Analytics System

 Procedure / Steps:
o Developing Use Cases:
o Step One – Define the set of actors that will be involved in the story
 Actors are people, devices, or other systems that use the system or product within
the context of the function and behavior that is to be described
 Actors are anything that communicate with the system or product and that are
external to the system itself
o Step Two – Develop use cases, where each one answers a set of questions

USECASE Diagram for Personal Portfolio Website

Personal Portfolio
Website

//Manages
Software Engineering (3161605) No: 210430116124

User

//Registers, Logs in

Visitor

//Views

Portfolio Page

Quiz:

1. What are the four main components of a use case diagram?

Ans:
The four main components of a use case diagram are:
 Actors: External entities interacting with the system.
 Use Cases: Specific functionalities or tasks the system performs.
 Relationships: Connections between actors and use cases.
 System Boundary: Defines the scope of the system.

2. List relationship used in use case.

Ans:
Here are the main types of relationships used in a use case diagram:
 Association: Describes a relationship between an actor and a use case. It indicates that the
actor interacts with the system to perform the use case.
 Generalization: Represents an "is-a" relationship between actors or between use cases. It
signifies that one actor or use case is a specialized version of another.
Software Engineering (3161605) No: 210430116124

 Include: Indicates that one use case includes another use case. It represents a relationship
where the behaviour of one-use case is always included in the behaviour of another use
case.
 Extend: Indicates that one use case extends another use case. It represents a relationship
where the behaviour of one-use case can be optionally extended by another use case under
certain conditions.

3. What Tests Can Help Find Useful Use Cases?

Ans:
To find useful use cases:
 Ensure they address specific stakeholder needs.
 Verify they cover all essential functionalities.
 Assess their technical feasibility.
 Evaluate their potential impact on the system and stakeholders.
 Prioritize high-value use cases.
 Ensure consistency with other requirements.
 Validate with stakeholders or end-users through user acceptance testing.

Suggested Reference:

1. Roger S. Pressman, Software Engineering- A practitioner’s Approach, McGraw-Hill

International Editions
2. Booch, G. et al. The Unified Modeling Language User Guide. Chapters 15, 18, 27.
Addison-Wesley.
3. Jacobson, I. et al. Object-Oriented Software Engineering: A Use-Case Driven Approach.
Addison-Wesley.
4. Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modelling Language.
Chapter 5. Addison Wesley.

References used by the students:

Rubric wise marks obtained:

Software Engineering (3161605) No: 210430116124

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Software Engineering (3161605) No: 210430116124

Practical – 7
AIM: Solve the problem by applying basic COCOMO model.

 Objectives:
1. Categorize projects using COCOMO, and estimate effort and development time
required for a project.

 Theory

A software project is not just about writing a few hundred lines of source code to achieve a
particular objective. The scope of a software project is comparatively quite large, and such
a project could take several years to complete. However, the phrase "quite large" could
only give some (possibly vague) qualitative information. As in any other science and
engineering discipline, one would be interested to measure how complex a project is. One
of the major activities of the project planning phase, therefore, is to estimate various project
parameters in order to take proper decisions. Some important project parameters that are
estimated include:

Project size: What would be the size of the code written say, in number of lines, files,
modules?
Cost: How much would it cost to develop a software? A software may be just pieces of
code, but one has to pay to the managers, developers, and other project personnel.
Duration: How long would it be before the software is delivered to the clients?
Effort: How much effort from the team members would be required to create the
software?
In this experiment we will focus on two methods for estimating project metrics:
COCOMO

COCOMO (Constructive Cost Model) was proposed by Boehm. According to him, there
could be three categories of software projects: organic, semidetached, and embedded. The
classification is done considering the characteristics of the software, the development team
and environment. These product classes typically correspond to application, utility and
system programs, respectively. Data processing programs could be considered as
application programs. Compilers, linkers, are examples of utility programs. Operating
systems, real-time system programs are examples of system programs. One could easily
apprehend that it would take much more time and effort to develop an OS than an
attendance management system.

The concept of organic, semidetached, and embedded systems is described below.

 Software Engineering (3161605) No: 210430116124

Organic: A development project is said to be of organic type, if The project deals with
developing a well understood application The development team is small The team
members have prior experience in working with similar types of projects
Semidetached: A development project can be categorized as semidetached type, if
The team consists of some experienced as well as inexperienced staff Team members may
have some experience on the type of system to be developed.
Embedded: Embedded type of development project is those, which Aims to develop a
software strongly related to machine hardware team size is usually large.
Boehm suggested that estimation of project parameters should be done through three
stages: Basic COCOMO, Intermediate COCOMO, and Complete COCOMO.

Basic COCOMO Model

The basic COCOMO model helps to obtain a rough estimate of the project parameters. It
estimates effort and time required for development in the following way:
Effort = a * (KDSI)b PM Tdev
= 2.5 * (Effort)c Months

where

 KDSI is the estimated size of the software expressed in Kilo Delivered Source
Instructions
 a, b, c are constants determined by the category of software project
 Effort denotes the total effort required for the software development, expressed in
person months (PMs)
 Tdev denotes the estimated time required to develop the software (expressed in
months)
The value of the constants a, b, c are given below:

Software project a b c
Organic 2.4 1.05 0.38
Semi-detached 3.0 1.12 0.35
Embedded 3.6 1.20 0.32

Basic COCOMO model for Personal Portfolio Website

COCOMO (Constructive Cost Model) is a well-known software cost estimation model developed
by Barry Boehm. It estimates the effort and cost required for software development based on
various factors. For a personal portfolio website, which is typically a small-scale project, we can
use the Basic COCOMO model, which estimates effort in person-months (PM).

The Basic COCOMO model uses the following equation to estimate effort (E) in person-months:

[ E = a * (KLOC)^b ]

Where:
Software Engineering (3161605) No: 210430116124

- ( a ) and ( b ) are constants determined by the type of project.

- ( KLOC ) is the estimated size of the software in thousands of lines of code.

For a personal portfolio website, we can assume a small size, typically in the range of a few kilo
lines of code (KLOC). Let's assume ( KLOC = 5 ) for our example.

The constants ( a ) and ( b ) for the Basic COCOMO model are as follows:

- ( a = 2.4 ) for small projects

- ( b = 1.05 ) for small projects

Substituting these values into the equation, we get:

[ E = 2.4 * (5)^{1.05} ]

Calculating this 

Software project a b c e(Effort) d(Months)

Organic 2.4 1.05 0.38 13.0056 5.40
Semi-detached 3.0 1.12 0.35 18.1957 6.90
Embedded 3.6 1.20 0.32 24.8351 6.99

Quiz:

1. Assume that the size of an organic type software product has been estimated to be 32,000 lines of
source code. Assume that the average salary of software engineers be Rs. 15,000/- per month. Determine
the effort required to develop the software product and the nominal development time.
Ans:
To determine the effort required to develop the software product and the nominal development time
using the Basic COCOMO model, we follow these steps:

1. Estimate Size: Given that the size of the software product is 32,000 lines of source code
(KLOC).

2. Apply Effort Equation: The effort estimation equation for Basic COCOMO is:

[ E = a * (KLOC)^b ]

Where:
- ( E ) = Effort in person-months (PM)
- ( a ) and ( b ) are constants determined by the type of project.

3. Select Constants: For organic type software projects, typical values for ( a ) and ( b ) are:
- ( a = 2.4 )
Software Engineering (3161605) No: 210430116124

- ( b = 1.05 )

4. Calculate Effort: Substitute the values into the effort equation:

[ E = 2.4 * (32)^{1.05} ]

[ E approx 2.4 * 32^{1.05} ]

[ E approx 2.4 * 10.491 ]
[ E approx 25.178 ]

So, the estimated effort required to develop the software product is approximately 25.178
person-months.

5. Calculate Nominal Development Time: The nominal development time is calculated using the
formula:

T = frac{E}{D} ]

Where:
- ( T ) = Development time in months
- ( E ) = Effort in person-months
- ( D ) = Number of developers working on the project

Assuming one developer:

[ T = frac{25.178}{1} ]
[ T approx 25.178 ]

So, the nominal development time is approximately 25.178 months.

This estimation provides a rough estimate of the effort and time required to develop the software
product based on its size and type. Actual effort and time may vary depending on factors such as project
complexity, team experience, and development methodology.

Suggested Reference:

1) Roger S. Pressman, Software Engineering- A practitioner’s Approach, McGraw-Hill

International Editions
Software Engineering (3161605) No: 210430116124

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty:
Software Engineering (3161605) No: 210430116124

Practical – 8
AIM: Modeling UML Class Diagrams and Sequence diagrams.

Objectives:

1. Graphically represent a class, and associations among different classes

2. Identify the logical sequence of activities undergoing in a system, and represent them pictorially

 Theory:
Class diagram
It is a graphical representation for describing a system in context of its static construction[1].

Elements in class diagram

Class diagram contains the system classes with its data members, operations and relationships
between classes.
Class
A set of objects containing similar data members and member functions is described by a class. In
UML syntax, class is identified by solid outline rectangle with three compartments which
contain

Class name
A class is uniquely identified in a system by its name. A textual string [2]is taken as class name. It
lies in the first compartment in class rectangle.

Attributes
Property shared by all instances of a class. It lies in the second compartment in class rectangle.

Operations
An execution of an action can be performed for any object of a class. It lies in the last compartment
in class rectangle.

Example

To build a structural model for an Educational Organization, ‘Course’ can be treated as a class which
contains attributes ‘courseName’ & ‘courseID’ with the operations ‘addCourse()’ &
‘removeCourse()’ allowed to be performed for any object to that class.
Software Engineering (3161605) No: 210430116124

Generalization/Specialization
It describes how one class is derived from another class. Derived class inherits the properties of its
parent class.

Geometric_Shapes is the class that describes how many sides a particular shape has. Triangle,
Quadrilateral and Pentagon are the classes that inherit the property of the Geometric_Shapes class.
So the relations among these classes are generalization. Now Equilateral_Triangle,
Isosceles_Triangle and Scalene_Triangle, all these three classes inherit the properties of Triangle
class as each one of them has three sides. So, these are specialization of Triangle class.

Relationships
Existing relationships in a system describe legitimate connections between the classes in that
system.

Association
It is an instance level relationship[i] that allows exchanging messages among the objects of both
ends of association. A simple straight line connecting two class boxes represent an association.
Software Engineering (3161605) No: 210430116124

We can give a name to association and also at the both end we may indicate role names and
multiplicity of the adjacent classes. Association may be unit-directional.

Example

In structure model for a system of an organization an employee (instance of ‘Employee’ class) is

always assigned to a particular department (instance of ‘Department’ class) and the association
can be shown by a line connecting the respective classes.

Aggregation
It is a special form of association which describes a part-whole[i] relationship between a pair of
classes. It means, in a relationship, when a class holds some instances of related class, then that
relationship can be designed as an aggregation.

Example

For a supermarket in a city, each branch runs some of the departments they have. So, the relation
among the classes ‘Branch’ and ‘Department’ can be designed as an aggregation. In UML, it can
be shown as in the fig. below

Composition [i]
It is a strong from of aggregation which describes that whole is completely owns its part. Life
cycle of the part depends on the whole.

Example
Software Engineering (3161605) No: 210430116124

Let consider a shopping mall has several branches in different locations in a city. The existence
of branches completely depends on the shopping mall as if it is not exist any branch of it will no
longer exists in the city. This relation can be described as composition and can be shown as
below

 Multiplicity
It describes how many numbers of instances of one class is related to the number of instances
of another class in an association.
Notation for different types of multiplicity:

o Sequence diagram:

The sequence diagram represents the flow of messages in the system and is also
termed as an event diagram. It helps in envisioning several dynamic scenarios. It
portrays the communication between any two lifelines as a time-ordered sequence
of events, such that these lifelines took part at the run time. In UML, the lifeline is
represented by a vertical bar, whereas the message flow is represented by a
vertical dotted line that extends across the bottom of the page. It incorporates the
iterations as well as branching.
o Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.
Software Engineering (3161605) No: 210430116124

o Notations of a Sequence Diagram

Lifeline

An individual participant in the sequence diagram is represented by a lifeline. It is

positioned at the top of the diagram.

Actor

A role played by an entity that interacts with the subject is called as an actor. It is out of
the scope of the system. It represents the role, which involves human users and external
hardware or subjects. An actor may or may not represent a physical entity, but it purely
depicts the role of an entity. Several distinct roles can be played by an actor or vice versa.

Activation

It is represented by a thin rectangle on the lifeline. It describes that time period in which
an operation is performed by an element, such that the top and the bottom of the rectangle
is associated with the initiation and the completion time, each respectively.
Software Engineering (3161605) No: 210430116124

Messages

The messages depict the interaction between the objects and are represented by arrows.
They are in the sequential order on the lifeline. The core of the sequence diagram is
formed by messages and lifelines.

Following are types of messages enlisted below:

 Call Message: It defines a particular communication between the lifelines of an

interaction, which represents that the target lifeline has invoked an operation.

Return Message: It defines a particular communication between the lifelines of

interaction that represent the flow of information from the receiver of the corresponding
caller message.

Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.
Software Engineering (3161605) No: 210430116124

Recursive Message: A self message sent for recursive purpose is called a recursive
message. In other words, it can be said that the recursive message is a special case of the
self message as it represents the recursive calls.

Create Message: It describes a communication, particularly between the lifelines of an

interaction describing that the target (lifeline) has been instantiated.

Destroy Message: It describes a communication, particularly between the lifelines of an

interaction that depicts a request to destroy the lifecycle of the target.
Software Engineering (3161605) No: 210430116124

Duration Message: It describes a communication particularly between the lifelines of an

interaction, which portrays the time passage of the message while modeling a system.

UML Class Diagram for Personal Portfolio Website:

In a personal portfolio website, some of the main classes might include:
1. User: Represents users of the website.
Attributes: UserID, Username, Email, Password
2. Portfolio: Represents portfolios created by users.
Attributes: PortfolioID, UserID, Title, Description
3. Project: Represents projects within portfolios.
Attributes: ProjectID, PortfolioID, Title, Description, Link

User Portfolio

User_id PortfolioId
Username User_id
Email Title
Password Description

Project Project

ProjectId ProjectId
PortfolioId PortfolioId
Title Title
Description Description
Link Link
 Software Engineering (3161605) No: 210430116124

Sequence Diagram for Personal Portfolio Website:

The sequence diagram represents interactions between objects over time. Here's an example of a
sequence diagram for a user creating a portfolio and adding a project to it:

CreatePortfolio()
Portfolio Controller
User Website

CreatePortfolio()

CreateProject() CreateProject()
Project Portfolio Controller
Portfolio

Quiz:

1) In a sequence diagram, what does a box depict? What does a dashed line depict? What does a
arrow between boxes depict?
Ans:
In a sequence diagram:
 Box: A box represents an object or actor within the system. It typically contains the name of
the object or actor, representing the role it plays in the sequence of interactions.

 Dashed Line: A dashed line represents a message or communication between objects or

actors in the system. It depicts the flow of information or invocation of a method between
objects during the sequence of interactions.

 Arrow Between Boxes: An arrow between boxes depicts the direction of the message flow.
It indicates which object or actor is sending the message and which object or actor is
receiving the message in the sequence of interactions. The arrowhead points from the sender
to the receiver of the message.

2) What does a X over a lifeline indicate?

Ans:
In a sequence diagram, placing an "X" over a lifeline typically indicates the termination or
destruction of the object or actor represented by that lifeline. This symbol signifies the end of the
object's or actor's existence or participation in the sequence of interactions depicted in the diagram.
It is used to denote when an object or actor is no longer available or active in the system.
Software Engineering (3161605) No: 210430116124

Suggested Reference:

1) Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.

2) Pankaj Jalote, Software Engineering – A Precise Approach Wiley

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty:
Software Engineering (3161605) No: 210430116124

Practical – 9
AIM: Design the various test cases to perform the testing of the system and also perform the various
type of testing
Objectives: To explore and learn about different testing techniques and use them.

 Theory:
o Software Testing is evaluation of the software against requirements gathered from users
and system specifications. Testing is conducted at the phase level in software
development life cycle or at module level in program code. Software testing comprises of
Validation and Verification.

o Software Validation
 Validation is process of examining whether or not the software satisfies the user
requirements. It is carried out at the end of the SDLC. If the software matches
requirements for which it was made, it is validated.

o Validation ensures the product under development is as per the user

requirements.
o Validation answers the question – "Are we developing the product which
attempts all that user needs from this software ?".
o Validation emphasizes on user requirements.
o Software Verification
 Verification is the process of confirming if the software is meeting the business
requirements, and is developed adhering to the proper specifications and
methodologies.

 Verification ensures the product being developed is according to design

specifications.
 Verification answers the question– "Are we developing this product by firmly
following all design specifications ?"
 Verifications concentrates on the design and system specifications.

o Target of the test are -

 Errors - These are actual coding mistakes made by developers. In addition, there is a
difference in output of software and desired output, is considered as an error.
Software Engineering (3161605) No: 210430116124

 Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an
error which can cause system to fail.
 Failure - failure is said to be the inability of the system to perform the desired task.
Failure occurs when fault exists in the system.

o Testing Levels
 Testing itself may be defined at various levels of SDLC. The testing process
runs parallel to software development. Before jumping on the next stage, a
stage is tested, validated and verified.
 Testing separately is done just to make sure that there are no hidden bugs or
issues left in the software. Software is tested on various levels -
o Unit Testing

While coding, the programmer performs some tests on that unit of program to
know if it is error free. Testing is performed under white-box testing approach. Unit
testing helps developers decide that individual units of the program are working as
per requirement and are error free.

o Integration Testing

Even if the units of software are working fine individually, there is a need to find
out if the units if integrated together would also work without errors. For example,
argument passing and data updation etc.

o System Testing
The software is compiled as product and then it is tested as a whole.

 Background / Preparation:
o Test management tool
o Test management tools are used to keep track of all the testing activity, fast data
analysis, manage manual and automation test cases, various environments, and
plan and maintain manual testing as well.
o Test management tools are used to keep track of all the testing activity, fast data analysis,
manage manual and automation test cases, various environments, and plan and maintain
manual testing as well.
o The test management tool is connected with the automation software. These types of
tools had various strategies for testing and multiple sets of features. Some of the test
management tools had capabilities to design the test case with the help of requirements.
Software Engineering (3161605) No: 210430116124

o It is best for test managing, scheduling, defect logging, tracking, and analysis.
o Some of the most commonly used test management tools are as follows:
o Quality center
o RTH
o Testpad
o Test Monitor
o PractiTest

 Tools / Material Needed:

o Hardware:
o Software:

o Test Cases:
 The test case is defined as a group of conditions under which a tester determines
whether a software application is working as per the customer's requirements or
not. Test case designing includes preconditions, case name, input conditions, and
expected result. A test case is a first level action and derived from test scenarios.

o Test case template

o The primary purpose of writing a test case is to achieve the efficiency of the
application.

Test Actual
Test Expected
case Test Steps Result Pass/Fail
Scenario Results
ID s

Goto Register page and enter user

details such as – Successful
As
1 User Registration Username, registration, user Pass
Expected
Email, account created
Password etc.
Successful login,
As
2 User Login Valid username and password user redirected to Pass
Expected
their dashboard.
User should not
If NOT Valid username and be redirected to As
2(1) User Login Fail
password their respective Expected
dashboard.
Enter Portfolio details such as-
Portfolio created As
3 Portfolio Creation Title, Pass
successfully expected
Description etc.
4 Project Addition Enter project details such as – Project added to As Pass
Title, the portfolio expected
 Software Engineering (3161605) No: 210430116124

Description,
successfully.
Link
Provide invalid input during Clear error As
registration/login messages, expected
5 Error Handling Pass
appropriate
feedback.
Example
Expected
Test Actual
Test Results
Case Test Steps Result Pass/Fail
Scenario
ID s

User should
Check
1. Go to Login into As
Customer
TU01 site http://demo.guru99.c om application Expecte Pass
Login with
d
valid Data 2. Enter UserId

3. Enter Password
4. Click Submit

TU02 Check Customer 1. Go to User should As Pass

Login with not Login Expected
site http://demo.guru99.c om
invalid Data into
2. Enter UserId
application
3. Enter Password
4. Click Submit

Quiz:

1 What elements of the WebApp can be “unit tested”? What types of tests must be conducted only
after the WebApp elements are integrated?
Ans:
Elements that can be unit tested:
 Individual Functions or Methods
 Components
 Backend APIs
 Data Models
 Utility Functions
Tests conducted only after integration:
 Integration Testing
 End-to-End Testing
 System Testing
 User Acceptance Testing (UAT)
 Performance Testing
Software Engineering (3161605) No: 210430116124

 Security Testing

2 What is white box testing? What is the different coverage based testing strategies.
Ans:
White box testing examines the internal structure of software, targeting internal logic and
code paths. Coverage-based testing strategies ensure thorough testing by assessing different
aspects of code execution. Statement coverage verifies that each code statement is executed at
least once, while branch coverage assesses all possible decision outcomes. Path coverage tests
every possible route through the code, ensuring all sequences of statements are executed.
Condition coverage examines logical conditions, ensuring both true and false outcomes are
tested. Multiple condition coverage assesses compound conditions, and function coverage
tests all functions or methods. These strategies collectively validate the correctness and
reliability of the software.

3 What is black box testing?

Ans:
Black box testing is a software testing technique that focuses on examining the functionality
of a system without knowledge of its internal code structure. Testers interact with the system's
external interfaces, inputs, and outputs to validate its behavior against specified requirements.
This method treats the system as a "black box," where testers have no visibility into its
internal workings. Black box testing ensures that the system performs as expected from a
user's perspective, identifying discrepancies between actual and desired behavior. It covers
various testing types, including functional, non-functional, and regression testing, providing
comprehensive validation of the software's functionality and usability.

Suggested Reference:
1 Software Testing: A Craftsman's Approach, by Paul C. Jorgensen, Third Edition
2 Software Engineering by Rajib Mall, PHI 2014

References used by the students:

Rubric wise marks obtained:

 Software Engineering (3161605) No: 210430116124

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to
all questions

Signature of Faculty:
Software Engineering (3161605) No: 210430116124

Practical – 10

AIM: Study of Open-source tools in DevOps for Infrastructure Automation, Configuration

Management, Deployment Automation, Performance Management, Log Management.
Monitoring

 Objectives: to learn how DevOps tools works.

 Theory:

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s
ability to deliver applications and services at high velocity: evolving and improving products at a faster
pace than organizations using traditional software development and infrastructure management
processes. This speed enables organizations to better serve their customers and compete more effectively
in the market.

How DevOps Works

Under a DevOps model, development and operations teams are no longer “siloed.” Sometimes, these
two teams are merged into a single team where the engineers work across the entire application
lifecycle, from development and test to deployment to operations, and develop a range of skills not
limited to a single function.

In some DevOps models, quality assurance and security teams may also become more tightly integrated
with development and operations and throughout the application lifecycle. When security is the focus of
everyone on a DevOps team, this is sometimes referred to as DevSecOps.

These teams use practices to automate processes that historically have been manual and slow. They use
a technology stack and tooling which help them operate and evolve applications quickly and reliably.
These tools also help engineers independently accomplish tasks (for example, deploying code or
provisioning infrastructure) that normally would have required help from other teams, and this further
increases a team’s velocity.
Software Engineering (3161605) No: 210430116124

Why DevOps Matters

Software and the Internet have transformed the world and its industries, from shopping to entertainment
to banking. Software no longer merely supports a business; rather it becomes an integral component of
every part of a business. Companies interact with their customers through software delivered as online
services or applications and on all sorts of devices. They also use software to increase operational
efficiencies by transforming every part of the value chain, such as logistics, communications, and
operations. In a similar way that physical goods companies transformed how they design, build, and
deliver products using industrial automation throughout the 20th century, companies in today’s world
must transform how they build and deliver software.

DevOps Practices

Continuous Integration
Continuous integration is a software development practice where developers regularly merge their code
changes into a central repository, after which automated builds and tests are run. The key goals of
continuous integration are to find and address bugs quicker, improve software quality, and reduce the
time it takes to validate and release new software updates.

Continuous Delivery
Continuous delivery is a software development practice where code changes are automatically built,
tested, and prepared for a release to production. It expands upon continuous integration by deploying all
code changes to a testing environment and/or a production environment after the build stage. When
continuous delivery is implemented properly, developers will always have a deployment-ready build
artifact that has passed through a standardized test process.

Microservices
The microservices architecture is a design approach to build a single application as a set of small
services. Each service runs in its own process and communicates with other services through a well-
defined interface using a lightweight mechanism, typically an HTTP-based application programming
interface (API). Microservices are built around business capabilities; each service is scoped to a single
purpose. You can use different frameworks or programming languages to write microservices and
deploy them independently, as a single service, or as a group of services.

Infrastructure as Code
Infrastructure as code is a practice in which infrastructure is provisioned and managed using code and
software development techniques, such as version control and continuous integration. The cloud’s API-
Software Engineering (3161605) No: 210430116124

driven model enables developers and system administrators to interact with infrastructure
programmatically, and at scale, instead of needing to manually set up and configure resources. Thus,
engineers can interface with infrastructure using code-based tools and treat infrastructure in a manner
similar to how they treat application code. Because they are defined by code, infrastructure and servers
can quickly be deployed using standardized patterns, updated with the latest patches and versions, or
duplicated in repeatable ways.

Configuration Management
Developers and system administrators use code to automate operating system and host configuration,
operational tasks, and more. The use of code makes configuration changes repeatable and standardized.
It frees developers and systems administrators from manually configuring operating systems, system
applications, or server software.

Policy as Code
With infrastructure and its configuration codified with the cloud, organizations can monitor and enforce
compliance dynamically and at scale. Infrastructure that is described by code can thus be tracked,
validated, and reconfigured in an automated way. This makes it easier for organizations to govern
changes over resources and ensure that security measures are properly enforced in a distributed manner
(e.g. information security or compliance with PCI-DSS or HIPAA). This allows teams within an
organization to move at higher velocity since non-compliant resources can be automatically flagged for
further investigation or even automatically brought back into compliance.

Monitoring and Logging

Organizations monitor metrics and logs to see how application and infrastructure performance impacts
the experience of their product’s end user. By capturing, categorizing, and then analyzing data and logs
generated by applications and infrastructure, organizations understand how changes or updates impact
users, shedding insights into the root causes of problems or unexpected changes. Active monitoring
becomes increasingly important as services must be available 24/7 and as application and infrastructure
update frequency increases. Creating alerts or performing real-time analysis of this data also helps
organizations more proactively monitor their services.

Communication and Collaboration

Increased communication and collaboration in an organization is one of the key cultural aspects of
DevOps. The use of DevOps tooling and automation of the software delivery process establishes
collaboration by physically bringing together the workflows and responsibilities of development and
operations. Building on top of that, these teams set strong cultural norms around information sharing and
facilitating communication through the use of chat applications, issue or project tracking systems, and
wikis. This helps speed up communication across developers, operations, and even other teams like
marketing or sales, allowing all parts of the organization to align more closely on goals and projects.
Software Engineering (3161605) No: 210430116124

DevOps Tools
The DevOps model relies on effective tooling to help teams rapidly and reliably deploy and
innovate for their customers. These tools automate manual tasks, help teams manage complex
environments at scale, and keep engineers in control of the high velocity that is enabled by
DevOps. AWS provides services that are designed for DevOps and that are built first for use with
the AWS cloud. These services help you use the DevOps practices described above.

Quiz:
1 What are the challenges with DevOps implementation?
Ans:
The challenges of DevOps implementation include:

 Cultural resistance
 Toolchain complexity
 Skill gaps
 Legacy system integration
 Security concerns
 Compliance requirements
 Communication and collaboration issues
 Scalability challenges
 Measuring success effectively
 Continuous improvement culture adoption.

2 What is DevOps? How it works? What are the DevOps principles & best practices?
Ans:
DevOps is a collaborative approach that combines development (Dev) and operations (Ops) to
streamline software delivery. It works through automation, continuous integration/deployment,
infrastructure as code, and a culture of collaboration and continuous improvement.

Key principles and best practices include automation, infrastructure as code, microservices
architecture, CI/CD pipelines, monitoring, collaborative culture, feedback loops, and security
integration. These practices aim to enhance speed, quality, and efficiency in software development
and delivery.

3 Explain 7Cs of DevOps lifecycle.

Ans:
The 7Cs of the DevOps lifecycle represent a set of guiding principles that help organizations
implement and manage their DevOps practices effectively. Each "C" stands for a key aspect of the
DevOps journey:

1. Continuous Business Planning: This involves aligning the development and operations
teams with the overall business objectives. It emphasizes the need for continuous planning and
adaptation to changing business requirements throughout the software delivery process.
Software Engineering (3161605) No: 210430116124

2. Collaborative Development: Encourages close collaboration between developers, operations

teams, and other stakeholders involved in the software development process. Collaboration
ensures that everyone works towards common goals, shares knowledge, and contributes to the
success of the project.

3. Continuous Testing: Shifts testing left in the development process, integrating testing
activities early and often. This ensures that defects are identified and addressed early, reducing
the risk of costly issues later in the development lifecycle.

4. Continuous Integration: Involves the frequent integration of code changes into a shared
repository, where automated tests are run to validate the changes. Continuous integration helps
detect integration issues early and ensures that the codebase remains in a deployable state at all
times.

5. Continuous Deployment: Automates the deployment of code changes to production or

production-like environments after successful testing. Continuous deployment enables rapid
and reliable delivery of new features and fixes to end-users.

6. Continuous Monitoring: Involves monitoring the performance, availability, and security of

applications and infrastructure in real-time. Continuous monitoring provides valuable insights
into system health, enabling proactive issue detection and resolution.

7. Continuous Feedback & Optimization: Establishes feedback loops throughout the DevOps
lifecycle to gather insights from users, testing, monitoring, and other sources. Continuous
feedback helps identify areas for improvement and informs iterative optimization efforts.

Suggested Reference:

1 Deepak Gaikwad, Viral Thakkar, DevOps Tools from Practitioner’s ViewPoint, Wiley.
2 The DevOps Handbook - Gene Kim et. al.
References used by the students:
 Software Engineering (3161605) No: 210430116124

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty: