210160116104 7th IT – B2

A Laboratory Manual for

SOFTWARE PROJECT
MANAGEMENT
(3171609)
B.E. Semester VII
(Department of Information Technology)

Directorate of Technical Education,

Gandhinagar, Gujarat.

1|Pa ge
210160116104 7th IT – B2

Government Engineering College, Modasa

Certificate

This is to certify that Mr.Divykumar R. Mishra Enrollment No. 210160116104

of B.E.Semester 7th Information Technology of this Institute (GTU Code: 017)
has satisfactorily completed the Practical / Tutorial work for the subject
(3171609) for the academic year 2024.

Place: Government Engineering College, Modasa

Date:

Prof. Nainesh Nagekar Prof. H. R. Patel

Subject Faculty Head of the Department

2|Pa ge
210160116104 7th IT – B2

Preface

Main motto of any laboratory/practical/field work is for enhancing required skills as well as creating
ability amongst students to solve real time problem by developing relevant competencies in psychomotor
domain. By keeping in view, GTU has designed competency focused outcome-based curriculum for
engineering degree programs where sufficient weightage is given to practical work. It shows importance
of enhancement of skills amongst the students and it pays attention to utilize every second of time allotted
for practical amongst students, instructors and faculty members to achieve relevant outcomes by
performing the experiments rather than having merely study type experiments. It is must for effective
implementation of 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 method in the classroom. Accordingly, this lab manual is designed to focus on the
industry defined relevant outcomes, rather than old practice of conducting practical to prove concept and
theory.

By using this lab manual students can go through the relevant theory and procedure in advance before the
actual performance which creates an interest and students can have basic idea prior to 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 that how students will be assessed by providing rubrics.

Software Engineering is an application of systematic, defined and measurable approach begins with
requirement specification and progresses with planning, modelling, testing and concluded with
deployment. It is a layered paradigm which comprises of process, 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. The quality product motivates
the firmness, commodity and delight.

Utmost care has been taken while preparing this lab manual however always there is chances of
improvement. Therefore, we welcome constructive suggestions for improvement and removal of errors if
any.

3|Pa ge
210160116104 7th IT – B2

1.1 Practical – Course Outcome matrix

Course Outcomes (COs):

CO1 Describe and determine the purpose and importance of a software project and project
management practices.

CO2 Compare project approaches for given software project and identify risk factors.

CO3 Estimate and evaluate project cost and schedules and determine risk management approaches.
CO4 Define and evaluate quality assurance measures.
CO5 Implement a project to manage project schedule, expenses and resources with the application of
suitable project management tools.

Sr. Objective(s) of Experiment CO C C C CO

No. 1 O O O 5
2 3 4
1. Write a short note on Software Projects Vs other
types of Projects. √
2. Prepare Functional and non-functional requirements of
your term project. √
3. Estimate the term project cost using COCOMO. √

4. Prepare project plan using CPM for you term project. √

5. Report term projects progress using Earned √

Value Analysis (EVA) report.

6. Identify the objects for SCM in term project. √

7. Identify and elaborate in detail – Quality Assurance √

Activities needed for term project.

8. Write a project closure analysis report for term √

project.

9. Implementation / Prototype of term project. √

10. Presentation and Viva of term project. √

4|Pa ge
210160116104 7th IT – B2

(Progressive Assessment Sheet)

Date Date Ass Sign.

Re
Sr. Objective(s) of Experiment Page of of ess of
me m
No. No.
perfo submi nt Teache a
rm ss r with r
anc ion Mar date k
e ks s

Write a short note on Software Projects Vs

1 other types of Projects.

Prepare Functional and

2
non- functional requirements of your term
project.

Estimate the term project cost using COCOMO.

3

Prepare project plan using CPM for you

4 term project.

Report term projects progress using Earned

5 Value Analysis (EVA) report.

Identify the objects for SCM in term project.

6

Identify and elaborate in detail – Quality

7 Assurance Activities needed for term project.

Write a project closure analysis report for

8 term project.

Implementation / Prototype of term project.

9

Presentation and Viva of term project.

10

Total

5|Pa ge
210160116104 7th IT – B2

GUJARAT TECHNOLOGICAL UNIVERSITY, AHMEDABAD,

COURSE CURRICULUM
COURSE TITLE: Software Project Management (Code: 3171609)
Degree Program in which this course is Semester in which
offered offered

Information Technology 7thSemester

1. PREREQUISITE
Fundamentals of Software Engineering
2. RATIONALE
Today’s world is a digital world driven by software of varying sizes and complexity.
Understandably, the effectiveness and efficiency of the work done nowadays primarily depends
on the quality of the software(s) being employed. The quality of the software relies on the way
it is managed during its development as well as maintenance.
3. COURSE OUTCOMES
1. Describe and determine the purpose and importance of a software project and project
management practices.
2. Compare project approaches for given software project and identify risk factors.
3. Estimate and evaluate project cost and schedules and determine risk management
approaches.
4. Define and evaluate quality assurance measures.
5. Implement a project to manage project schedule, expenses and resources with the
application of suitable project management tools.

4. TEACHING AND EXAMINATION SCHEME

6|Pa ge
210160116104 7th IT – B2

5. SUGGESTED LEARNING RESOURCES A. LIST OF BOOKS

1) Bob Hughes and Mike Cotterell, “Software Project Management”, Tata McGraw Hill, 4th
edition, 2006
2) Walker Royce, “Software Project Management”, Pearson Education, 2005
3) Kieron Conway, “Software Project Management”, Dreamtech Press, 2001
4) S. A. Kelkar, “Software Project Management”, PHI Publication, 15th edition, 2013.
5) Roger S. Pressman, “Software Engineering – A Practitioner’s approach”, Tata McGraw Hill,
2009
6) Ramesh, “Managing Global software Projects”, Tata McGraw Hill, 2001
7) Shailesh Mehta, "Project Management and Tools & Technologies – An overview", SPD,
2017

B. LIST OF SOFTWARE / LEARNING WEBSITES

• www.onesmartclick.com/engsineering/software-engineering.html
• www.sei.cmu.edus
• https://www.edx.org/school/uc-berkeleyx
• https://devops.com/most-popular-open-source-devops-tools/
• https://www.guru99.com/devops-tutorial.html

7|Pa ge
210160116104 7th IT – B2

5.1 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. Prepare SRS for given software project

2. Compare SDLC models for the given project
3. Estimate project cost and prepare project schedule
4. Evaluate risk management approaches suitable for the project
5. Design test suite to ensure software quality

5.2 Guidelines for Faculty members

6. Teacher should provide the guideline with demonstration of practical to the students
with all features.
7. Teacher shall explain basic concepts/theory related to the experiment to the students
before starting of each practical
8. Involve all the students in the performance of each experiment.
9. The 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.
10. Teachers should give the opportunity to students for hands-on experience after the
demonstration.
11. 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.
12. Give practical assignments and assess the performance of students based on task
assigned to check whether it is as per the instructions or not.
13. The teacher is expected to refer to the complete curriculum of the course and follow
the guidelines for implementation.

8|Pa ge
210160116104 7th IT – B2

5.3 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 a record of all observations.
3. Students shall develop maintenance skills as expected by industries.
4. Students shall attempt to develop related hand-on skills and build confidence.
5. Students shall develop the habits of evolving more ideas, innovations, skills etc. apart
from those included in the scope of manual.
6. Students shall refer to technical magazines and data books.
7. Student should develop a habit of submitting the experimentation work as per the
schedule and s/he should be well prepared for the same.

5.4 General Guidelines for Software Engineering Laboratory Work

8. A student must perform all the practical as described in the practical list.
9. For performing the practical list, students can be able to work individually or make a
team of maximum 3 students’ group.
10. For making the group, students must take care that all the students of group must be
from the same batch.
11. After establishing the team, every team will have to identify the problem area /
definition for performing the laboratory work.
12. Every team must approve their problem definition to respective faculty members
within 15 days (about 2 weeks) of the beginning of the semester.
13. Once the problem definition is approved by the faculty member, every team must
perform all the practical tasks based on their respective problem definition.

9|Pa ge
210160116104 7th IT – B2

Practical – 1

Aim: Write a short note on Software Projects Vs other types of Projects.

Theory:

Difference between Software Project and Other type of Project:

Aspect Software Projects Other Types of Projects

Low visibility during early stages. High visibility throughout the

Progress is often intangible project.
Visibility until late in the project. Progress is often physical and
observable.
- High complexity due to abstract
nature, evolving technologies, and - Complexity is usually more
Complexity potential for unforeseen technical predictable and tied to physical or
issues. mechanical factors.
- Struggles with conformity due to
diverse, evolving requirements and
- Conformity is more stable, with
Conformity the need to adhere to multiple
projects following well-defined
standards
standards and regulations.
and protocols.
High flexibility in design and
implementation. - Limited flexibility; changes can be
Software can be easily modified, costly, time-consuming, or
Flexibility
updated, or scaled even after impossible once the project is
deployment. underway or completed.
- Requirements are generally well-
- Requirements are often dynamic defined and stable, with fewer
Requirements and can change frequently during the changes during the project
project. lifecycle.
Requires specialized tools for coding, - Tools and techniques vary
testing, debugging, and version depending on the project type, e.g.,
control. construction may use CAD software,
Tools and
Agile, Scrum, and DevOps are Gantt charts, and
Techniques traditional project management.
common methodologies.
Iterative development is common (e.g., - Iteration is less common; projects
Agile). often follow a linear or waterfall
Frequent revisions and updates are approach with minimal revisions
Iteration
expected. once the project begins.

10 | P a g e
210160116104 7th IT – B2

Often includes specialized roles such

as developers, testers, and DevOps
- Team roles are more traditional
Team Structure engineers.
and defined by project type (e.g.,
Collaboration across diverse teams
architects, engineers, laborers in
(e.g., UI/UX, backend, frontend).
construction).

QA involves rigorous testing, including

unit, integration, system, and - QA is based on compliance with
acceptance testing. standards, inspections, and
Quality Assurance
Continuous integration and performance testing, often at
deployment are key practices. specific milestones.
- High involvement from stakeholders - Stakeholder involvement is often
throughout the project due to the concentrated during planning and
Stakeholder iterative nature and changing key milestones, with less frequent
Involvement requirements. engagement
during execution.
- Delivery is often phased, with - Delivery is typically a single, final
multiple releases or updates handover with fewer follow-
Delivery
over time (e.g., versioning). up phases.
High risk due to uncertainty in - Risks are generally more
requirements, technology, and market predictable and tied to physical
conditions. factors, with risk management
Risk Management
Risk management is continuous and planned early and adjustments
adaptive. made as needed.
- Cost estimation is more challenging - Cost estimation is generally more
due to potential changes in scope and accurate, based on established
Cost Estimation technology requirements. practices and material costs.

Rubric wise marks obtained:

Sr. Needs
No. Criteria Improvement Acceptable Good Very Good Total

[1-4] [5-6] [7-8] [9-10]

1 Content Incomplete Basic Appropriate Appropriate
contents. compariso comparison is comparison with
n
is shown presented. example is
shown.

Signature of Faculty:

11 | P a g e
210160116104 7th IT – B2

Practical – 2

Aim: Prepare Functional and non-functional requirements of term project.

Theory:
Requirements analysis is a very critical process that enables the success of a system or
software project to be assessed. Requirements are generally split into two types: Functional
and Nonfunctional requirements.

Functional Requirements: These are the requirements that the end user specifically
demands as basic facilities that the system should offer. All these functionalities need to be
incorporated into the system as a part of the contract. These are represented or stated in the
form of input to be given to the system, the operation performed, and the output expected.
They are basically the requirements stated by the user which one can see directly in the final
product, unlike the non-functional requirements.

Non-functional requirements: These are basically the quality constraints that the system
must satisfy according to the project contract. The priority or extent to which these factors are
implemented varies from one project to another. They are also called non-behavioral
requirements.

They basically deal with issues like:

• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility

12 | P a g e
210160116104 7th IT – B2
Following are the differences between Functional and Non-Functional Requirements

Functional Requirements Non-Functional Requirements

A functional requirement defines a system or its A non-functional requirement defines the
component. quality attribute of a software system.
It specifies “What should the software It places constraints on “How should the
system does?” software system fulfills the functional
requirements?”
Functional requirement is specified by User. Non-functional requirements are specified by
technical peoples e.g. Architect, Technical
leaders and software developers.
It is mandatory. It is not mandatory.
It is captured in a use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system.

Helps you verify the functionality of the software. Helps you to verify the performance of the
software.

Functional Testing like System, Integration, End Non-Functional Testing like Performance, Stress,
to End, API testing, etc. are done. Usability, Security testing, etc. are done.

Usually easy to define. Usually more difficult to define.

Example Example
Authentication of user whenever he/she logs into Emails should be sent with a latency of no
the system. greater than 12 hours from such an activity.
System shutdown in case of a cyberattack. The processing of each request should be done
within 10 seconds
A Verification email is sent to the user whenever
he/she registers for the first time on some The site should load in 3 seconds when the
software system. number of simultaneous users is > 10000

13 | P a g e
210160116104 7th IT – B2

Functional Requirements:
(R.1): User Registration and Authentication

Description Cloud forcasting users must be able to create accounts using either a valid email address
or social media authentication. The registration process should be secure, ensuring user
data protection and safeguarding access to the platform. Authentication is critical to
maintainingthe integrity of the platform by ensuring that only authorized users can access
the application's features.

R.1.1: User Registration

Input Users must provide a valid email address or select an option for social media authentication
(such as Google, Facebook, or Twitter).
Output The system sends a registration confirmation email or provides a success message after
social media authentication.

Processing The system verifies the email address by sending a confirmation link to the user's email or
authenticates the social media credentials. Upon successful verification, the system creates a
user account in the database, storing necessary information like email, username, and
authentication token.

R.1.2: User Authentication

Input Users enter their login credentials (email and password) or use social media authentication to
log in.

Output Users gain access to their account if the credentials are valid or receive an error message if
authentication fails.

Processing The system validates the login credentials against the stored data. If the credentials are
correct, the system generates a session token and grants access to the user's account. For
social media authentication, the system verifies the social media token with the respective
provider.

(R.2): Waste Reporting

Description Users should be able to report waste incidents by capturing images, providing details, and
tagging the location. The platform must validate and securely store these reports, making
them available for local authorities to access and manage.

R.2.1: Submit Waste Report

Input Users provide a description of the waste incident, select the waste type, tag the location using
GPS, and optionally attach multimedia files (photos/videos).

Output The system acknowledges receipt of the waste report and provides a unique reference number
for tracking.
Processing The system validates the input data, ensuring that required fields are completed. It then stores
the report securely in the database, linking it to the user account and relevant local authority
based on the location.

R.2.2: Report Validation

Input The system checks the completeness and accuracy of the waste report details.

Output The report is marked as valid or flagged for user review if any required information is missing

14 | P a g e
210160116104 7th IT – B2
(R.1): User Registration and Authentication

or appears incorrect.

Processing The system runs validation checks on the report data, such as verifying location accuracy and
checking for potential spam reports. If validation fails, the system prompts the user to correct
the details before final submission.

(R.3): Local Authority Interaction

Description Local authorities must be able to access and manage waste reports submitted by users. The
system should allow authorities to update the status of reports and communicate progress
with users through notifications.

R.3.1: Access and Manage Waste Reports

Input Local authorities log in to their accounts and view the list of reported waste incidents in their
jurisdiction.

Output. Authorities can view detailed reports, update the status (e.g., in-progress, completed), and
assign cleanup teams.

Processing The system provides authorities with a dashboard displaying reports, allowing them to filter
by status, date, or location. Upon status update, the system sends notifications to the
respective users.

R.3.2: Incident Status Updates

Input Authorities update the status of a waste report after taking action.
Output Users receive notifications about the status of their reports, along with any relevant details
(e.g., cleanup scheduled, incident resolved).
Processing The system records the status update in the database and triggers a notification to the user,
ensuring they are informed about the progress.
(R.4): User Notifications
Description Cloud forcasting should provide real-time notifications to users about the status of their waste
reports,new features, or important announcements. Notifications must be delivered promptly
and reliably.
R.4.1: Notification Generation
Input Trigger events such as status updates, new messages from authorities, or app announcements.
Output Notifications are generated and prepared for delivery to the user.
Processing The system listens for trigger events and creates corresponding notifications, which
are queued for delivery via in-app messages, push notifications, or emails.
R.4.2: Notification Delivery
Input System-generated notifications.
Output: Users receive notifications in real-time via their preferred method (push notifications, email,
in-app).
Processing: The system delivers notifications to the intended recipients using the appropriate channels,
ensuring that users are informed of any updates related to their reports or account.
(R.5): User Feedback and Rating

15 | P a g e
210160116104 7th IT – B2
(R.1): User Registration and Authentication
Description Cloud forcasting should allow users to provide feedback and rate the service provided by
localauthorities after the resolution of their waste reports. This feedback is essential for
maintaining service quality and improving the platform.
R.5.1: Feedback Submission
Input Users provide a rating (e.g., star rating) and optional written feedback after a waste report is
resolved.
Output The feedback is stored in the system and associated with the corresponding report and local
authority.
Processing The system prompts users to submit feedback after the incident is marked as resolved.
Feedback is stored in the database and may be used for performance reviews or displayed in
authority dashboards.
R.5.2: Feedback Analysis
Input Stored user feedback and ratings.
Output: Aggregated feedback reports are generated for analysis by local authorities and
administrators.

Processing The system analyzes feedback data to identify trends, common issues, and areas for
improvement. Summary reports are generated and made available to the relevant
stakeholders.
(R.6): Data Privacy and Security
Description Cloud forcasting must implement robust data privacy measures to protect user
information and interactions. The platform must comply with relevant data protection
laws and industrystandards to ensure the security and confidentiality of user data.
R.6.1: Data Encryption
Input User data, including personal information, waste report details, and interactions.
Output Data is securely encrypted during transmission and storage.
Processing The system employs advanced encryption techniques (e.g., AES-256) to protect data at rest
and in transit. Secure communication protocols (e.g., HTTPS, SSL/TLS) are used for all data
exchanges.
R.6.2: Compliance with Regulations
Input Applicable data protection regulations (e.g., GDPR, CCPA).
Output The system is compliant with the required data protection laws and regulations.
Processing The system undergoes regular audits to ensure compliance with relevant regulations. It
includes mechanisms for data access requests, user consent management, and breach
notifications.
(R.7): Accessibility and Compatibility
Description Cloud forcasting must be accessible to users with disabilities and compatible with a wide
range of devices, browsers, and operating systems. The platform should adhere to web
accessibilitystandards to ensure inclusivity.
R.7.1: Accessibility Standards
Input Accessibility standards and guidelines (e.g., WCAG 2.1).
Output The platform complies with web accessibility standards, providing equal access to all users.

16 | P a g e
210160116104 7th IT – B2
(R.1): User Registration and Authentication
Processing The system incorporates accessibility features such as screen reader support, keyboard
navigation, and alternative text for images. Regular testing ensures compliance with
accessibility standards.
R.7.2: Compatibility Testing
Input Various devices, browsers, and operating systems.
Output The platform is verified for compatibility across a broad range of environments.
Processing The system undergoes rigorous testing on different devices (e.g., smartphones, tablets),
browsers (e.g., Chrome, Firefox, Safari), and operating systems (e.g., Android, iOS).
Compatibility issues are identified and resolved to ensure a seamless user experience.
(R.8): User Profile Management
Description Cloud forcasting allows users to create, view, and manage their profiles. Users can update
their personal information, set preferences, and manage their interaction with the platform.
This feature ensures that users have control over their data and can tailor their experience to
meettheir needs.
R.8.1: Profile Creation and Initialization
Input Users provide personal information, such as their name, email, contact number, profile
picture, and preferred language.
Output A user profile is created, and the information is stored securely in the system.
Processing The system prompts new users to complete their profile upon registration. It validates the
provided information and stores it in the database. Users can also upload a profile picture,
which is processed and stored in a secure, optimized format.
R.8.2: View Profile
Input User requests to view their profile details.
Output The system displays the user's profile information, including personal details, account
settings, and activity history.
Processing The system retrieves the user's profile data from the database and presents it in a user-friendly
interface. The profile page includes sections for personal information, past waste reports,
feedback submitted, and notification preferences.
R.8.3: Edit Profile
Input User selects the option to edit their profile and provides updated information (e.g., change of
address, new profile picture, update contact details).
Output The profile is updated, and the changes are saved in the system.
Processing The system allows users to edit their profile information at any time. Upon submission of the
updated details, the system validates the input and updates the stored data. The system also
ensures that changes are reflected across all related components, such as user notifications
and waste report submissions.
R.8.4: Manage Preferences
Input Users set or update their preferences, such as notification settings, preferred waste categories
for reporting, or language settings.
Output The system saves the user's preferences and applies them to future interactions.
Processing The system provides an interface for users to manage their preferences, which are stored in
the database. These preferences influence how the user interacts with the platform, such as the
types of notifications they receive or the default language for the interface.

17 | P a g e
210160116104 7th IT – B2

2. Non-functional Requirements:
Non-functional attributes, also known as non-functional requirements, describe the qualities and
characteristics that our project " Cloud forcasting " should possess to meet user expectations.
Here are some non-functional attributes to consider:
1. Usability:
Intuitive Interface: The user interface of Cloud forcasting should be clean, simple, and
intuitive, allowing users to navigate the app with ease. Users should be able to report waste
incidents, communicate with local authorities, and receive notifications without confusion or
difficulty. Icons and prompts should be clear and self-explanatory, minimizing the learning
curve for new users.
Accessibility: Ensure that the app is accessible to all users, including those with disabilities.
This includes support for screen readers, color contrast adjustments, and alternative text for
images. Compliance with WCAG (Web Content Accessibility Guidelines) standards should be
maintained.
User Feedback: Provide immediate feedback to users for actions taken, such as successful
submission of reports or updates on incident status, ensuring that users are aware of the results
of their interactions with the app.
2. Performance:
Response Time: The app should respond to user actions, such as submitting waste reports or
loading profile information, within 2 seconds. This includes the time taken to capture and
upload images, which should not exceed 5 seconds.
Real-time Updates: Notifications about incident status updates should be delivered to users
within 2 seconds of the update occurring. The app should support real-time updates, ensuring
that users receive the latest information without delay.
Efficient Resource Usage: Optimize the app to use device resources (such as battery, memory,
and processing power) efficiently, ensuring that it does not slow down the device or drain its
battery excessively.
3. Security:
Data Protection: Implement robust data security measures, including end-to-end encryption of
user data during transmission and storage. Sensitive information, such as user credentials and
location data, should be securely encrypted.
Authentication and Authorization: Ensure that user authentication processes are secure,
requiring strong passwords and supporting multi-factor authentication (MFA). Access to
sensitive features, such as local authority management tools, should be restricted to authorized
personnel only.
Regular Security Audits: Conduct regular security audits and vulnerability assessments to
identify and address potential threats. This includes testing for common vulnerabilities, such as
SQL injection, cross-site scripting (XSS), and data leakage.
Privacy Compliance: Ensure compliance with data protection regulations, such as GDPR or
CCPA, to safeguard user privacy. Users should be informed about data collection practices, and
they should have the option to manage their data, including deleting their accounts if desired.

18 | P a g e
210160116104 7th IT – B2

4. Reliability:
High Availability: The Cloud forcasting platform should maintain an uptime of at least 99.9%,
allowing for minimal scheduled maintenance. Users should be able to access the app whenever
needed, without encountering downtime.
Redundancy and Failover: Implement redundancy and failover mechanisms to minimize
downtime in the event of server failures or other technical issues. This includes having backup
servers and data replication in place to ensure continuous availability.
Data Integrity: Ensure that all data submitted by users, including waste reports and profile
updates, is accurately stored and retrievable. Implement data validation checks to prevent
corruption or loss of data during transmission or storage.
5. Compatibility:
Cross-platform Support: Ensure that Cloud forcasting is compatible with various devices,
including desktops, tablets, and smartphones. The app should function seamlessly on
different screensizes and resolutions.
Browser Compatibility: Test and optimize the app for compatibility with a wide range of web
browsers, including both older and newer versions of popular browsers like Chrome, Firefox,
Safari, and Edge.
Operating System Compatibility: Cloud forcasting should support multiple operating systems,
including Android (version 7.0 and above) and iOS (version 11 and above). Regular updates
should be provided to maintain compatibility with new OS releases.
6. Scalability:
Handle Growing User Base: Design the platform to be scalable, capable of handling an
increasing number of users without performance degradation. This includes optimizing database
queries, load balancing, and using scalable cloud infrastructure.

Flexible Infrastructure: Use cloud-based solutions that can scale up or down based on
demand, ensuring that the app can handle sudden spikes in usage, such as during environmental
campaigns or disaster events.

Data Storage: Ensure that the app's data storage solutions can scale to accommodate an
increasing volume of user data, such as images and reports, without impacting performance or
response times.

These non-functional attributes are critical to delivering a high-quality and user-centric platform
that meets performance expectations while providing a secure and accessible experience for
users.

19 | P a g e
210160116104 7th IT – B2

Rubric wise marks obtained:

Sr. Needs
No. Criteria Improvement Acceptable Good Very Good Total
[5-6] [7-8] [9-10]
[1-4] Either of Listed all the Listed all the
1 Content Incomplete functional or functional and functional and non-
contents. non-functional non- functional functional
requirement is requirements. requirements with
missing or elaboration.
incomplete.

Signature of Faculty:

20 | P a g e
210160116104 7th IT – B2

Practical – 3
Aim: Estimate your term project cost using COCOMO.

Theory:
COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e. number of Lines of

Code. It is a procedural cost estimate model for software projects and is often used as a process of
reliably predicting the various parameters associated with making a project such as size, effort, cost,
time, and quality. It was proposed by Barry Boehm in 1981 and is based on the study of 63 projects,
which makes it one of the best documented models. The key parameters which define the quality of
any software products, which are also an outcome of the COCOMO are primarily Effort & Schedule:

● Effort: Amount of labor that will be required to complete a task. It is measured in person
months units.
● Schedule: Simply means the amount of time required for the completion of the job, which is, of
course, proportional to the effort put in. It is measured in the units of time such as weeks, and
months.

Different models of COCOMO have been proposed to predict the cost estimation at different levels,
based on the amount of accuracy and correctness required. All of these models can be applied to a
variety of projects, whose characteristics determine the value of the constant to be used in subsequent
calculations. These characteristics pertaining to different system types are mentioned below. Boehm’s
definition of organic, semidetached, and embedded systems:

1. Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also the
team members have a nominal experience regarding the problem.

2. Semi-detached – A software project is said to be a Semi-detached type if the vital

characteristics such as team size, experience, and knowledge of the various programming
environment lie in between that of organic and Embedded. The projects classified as Semi
Detached are comparatively less familiar and difficult to develop compared to the organic ones
and require more experience and better guidance and creativity. Eg: Compilers or different
Embedded Systems can be considered Semi-Detached types.

3. Embedded – A software project requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size than

21 | P a g e
210160116104 7th IT – B2

the other two models and also the developers need to be sufficiently experienced and creative to
develop such complex models.

● Basic COCOMO Model

● Intermediate COCOMO Model
● Detailed COCOMO Model

4. Basic Model –
Effort = a(KLOC)b
Time = c(Effort)d

Person Required = Effort/Time

The above formula is used for the cost estimation of for the basic COCOMO model, and also is used in
the subsequent models. The constant values a,b,c, and d for the Basic Model for the different categories
of the system:

Software Projects a b c d

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

The effort is measured in Person-Months and as evident from the formula is dependent on Kilo-Lines
of code. The development time is measured in months. These formulas are used as such in the Basic
Model calculations, as not much consideration of different factors such as reliability, and expertise is
taken into account, henceforth the estimate is rough. Below is the C++ program for Basic COCOMO.

22 | P a g e
210160116104 7th IT – B2

5. Intermediate Model –

The basic COCOMO model assumes that the effort is only a function of the number of lines of code
and some constants evaluated according to the different software systems. However, in reality, no
system’s effort and schedule can be solely calculated on the basis of Lines of Code. For that, various
other factors such as reliability, experience, and Capability. These factors are known as Cost Drivers
and the Intermediate Model utilizes 15 such drivers for cost estimation. Classification of Cost Drivers
and their Attributes:

(I) Product attributes –

Required software reliability extent

Size of the application database

The complexity of the product

Run-time performance constraints

Memory constraints

The volatility of the virtual machine environment

Required turnabout time

Analyst capability

Software engineering capability

Applications experience

Virtual machine experience

Programming language experience

Use of software tools

Application of software engineering methods

Required development schedule

23 | P a g e
210160116104 7th IT – B2

6. Detailed Model –

Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of
the cost driver’s impact on each step of the software engineering process. The detailed model uses
different effort multipliers for each cost driver attribute. In detailed COCOMO, the whole software is
divided into different modules and then we apply COCOMO in different modules to estimate effort and
then sum the effort. The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model

Advantages of the COCOMO model:

Provides a systematic way to estimate the cost and effort of a software project.

Can be used to estimate the cost and effort of a software project at different stages of the development
process.
Helps in identifying the factors that have the greatest impact on the cost and effort of a software
project.

Can be used to evaluate the feasibility of a software project by estimating the cost and effort required to
complete it.

Disadvantages of the COCOMO model:

Assumes that the size of the software is the main factor that determines the cost and effort of a software
project, which may not always be the case.

Does not take into account the specific characteristics of the development team, which can have a
significant impact on the cost and effort of a software project.

Does not provide a precise estimate of the cost and effort of a software project, as it is based on
assumptions and averages.

24 | P a g e
210160116104 7th IT – B2

Cost Estimation For Cloud forcasting using COCOMO:

Estimate the effort and duration of the Cloud Forcasting project using the COCOMO (Constructive
Cost Model) model. COCOMO considers various factors, including project size, complexity,
developmentenvironment, and team experience to estimate effort and duration.

1. Determine the Development Mode

● Given the details of Cloud forcasting , let's assume it's a "Semi-detached" type, as it likely
involvessome level of complexity but not the highest, like an embedded system.

2. Estimate the Project Size (KLOC)

● The first step in COCOMO is to estimate the size of the project in terms of KLOC (thousands
of lines of code). If you have an estimate for the total lines of code for the Cloud forcasting
project, you can provide that. For this example, let's assume the project is estimated to be 2.5
KLOC.

3. COCOMO Model Basic Estimation Table

Effort (E): E = 3.0 × (2.5)1.12 ≈ 8.44 person-months
Development Time (D): D = 2.5 × (8.44)0.35 ≈ 4.54 months

Average Staff Size: Average Staff Size = E / D ≈ 1.86 persons

Cost per Person-Month: $4000 (assumed constant)

Total Cost: Total Cost = E × Cost per Person-Month ≈ 8.44 × 4000 = $33,760

Parameter Value
Project Type Semi-Detached
Estimated KLOC (K) 2.5
Effort (E) 8.44 person-months
Development Time (D) 4.54 months
Average Staff Size 1.86 persons
Cost per Person-Month $4000
Total Cost $33,760

25 | P a g e
210160116104 7th IT – B2

4. Effort and Time Distribution Table

Phase Percentage of Effort Effort (person-months) Development Time

(months)
Requirements Analysis 20% 1.69 0.91
Design 30% 2.53 1.36
Coding & Unit Testing 20% 1.69 0.91
Integration & Testing 30% 2.53 1.36
Total 100% 8.44 4.54

6. Effort Distribution by Activity Table

Activity Effort Percentage Effort (person-months) Cost

Planning & Requirements 6% 0.51 $2,430
Product Design 10% 0.84 $5,520
Detailed Design 15% 1.27 $3,810
Coding 34% 2.87 $9,586
Testing 19% 1.60 $5,800
Quality Assurance 10% 0.84 $3,914
Documentation 6% 0.51 $2,700
Total 100% 8.44 $33,760

Summary:

● Total Effort: 8.44 person-months

● Total Development Time: 4.54 months
● Total Cost: $33,760

26 | P a g e
210160116104 7th IT – B2

Rubric wise marks obtained:

Sr. Criteria Needs Acceptable Good Very Good Total
No. Improvement
Analysis [1] [2-3] [4-5] [6-7]
No basis for Poorly Fairly Clearly
1 KLOC understands understands understand
estimation. KLOC KLOC KLOC estimation
estimation. estimation. and factors
affecting KLOC
estimation.

Formula/ [1] [2] [3]

Calculatio Correct Correct Correct
2 n application of application of application of
formula and formula and formula and
calculation. calculation with calculation with
detailed steps. detailed steps for
all
types.

Signature of Faculty:

27 | P a g e
210160116104 7th IT – B2

Practical – 8

Aim: Write a project closure analysis report for term project.

Theory:

What to include in a project closure report?

In addition to learning about the success or failure of the assignment, every project closure
checklist should include all legal and logistical steps needed to tie up any loose ends. Which
means no project closure checklist would be complete without:

The original project requirements from all stakeholders, including timeline and budget Proof

that each requirement was met using data from a project management software

Payment due upon services rendered of any outstanding and related supplier, partner, or vendor
invoices

A holistic performance review for all major sections of the project

An organized folder that includes all related project files and communications to be kept as part
of your archive

Lessons learned and client feedback, and where managing client relations can be improved

Confirmation that the client has received all of their deliverables

The release or transfer of any remaining project resources

Properly offboarding any one-time partners or freelancers brought on for this specific project

28 | P a g e
210160116104 7th IT – B2

Project Closure Report

Project Name: Cloud forcasting

Department: IT

Focus Area: Weather detector and show on display

Product/Process: Web Application For Weather detector.

Prepared By:

Document Owner(s) Project/Organization Role

Divykumar Mishra Project Manager

Project Closure Report Version Control:

Version Date Author Change Description

1.0 14/08/2024 Divykumar Mishra Initial Draft
1.1 17/08/2024 Divykumar Mishra Incorporated Feedback and Revisions
2.0 20/08/2024 Divykumar Mishra Final Version

29 | P a g e
210160116104 7th IT – B2

TABLE OF CONTENTS

1 Project Closure Report Purpose .....................................................................1

2 Project Closure Report Goals......................................................................... 1
3 Project Closure Report Summary ..................................................................1
3.1 Project Background Overview ................................................................... 1
3.2 Project Highlights and Best Practices ........................................................ 1
3.3 Project Closure Synopsis ........................................................................... 1
4 PROJECT METRICS PERFORMANCE 1
4.1 Goals and Objectives Performance 2
4.2 Success Criteria Performance 2
4.3 Milestone and Deliverables Performance 2
4.4 Schedule Performance 2
4.5 Budget Performance 2
4.6 Metrics Performance Recommendations 2
5 PROJECT CLOSURE TASKS 3
5.1 Resource Management 3
5.2 Issue Management 3
5.3 Risk Management 3
5.4 Quality Management 3
5.5 Communication Management 3
5.6 Customer Expectation Management 3
5.7 Asset Management 3
5.8 Lessons Learned 3
5.9 Post project Tasks 4
5.10 Project Closure Recommendations 4
6 PROJECT CLOSURE REPORT APPROVALS 5
7 APPENDICES 5
7.1 Project Closure Report Sections Omitted 5

30 | P a g e
210160116104 7th IT – B2

1. PROJECT CLOSURE REPORT PURPOSE

Project Closure Report Purpose
This report aims to document the final status, deliverables, and outcomes of the Cloud Forcasting
project. It ensures that all project activities are completed, and resources are released. It also
captures lessons learned and provides recommendations for future projects.

2. PROJECT CLOSURE REPORT GOALS

Project Closure Report Goals
● To evaluate the performance of the project against initial goals and objectives.
● To ensure all project deliverables are completed and meet quality standards.
● To document lessons learned and make recommendations for future projects.
● To formally close the project and release all resources.

3. PROJECT CLOSURE REPORT SUMMARY

3.1 Project Background Overview
Project Background Overview
Cloud Forcasting was initiated to provide a platform for citizens to report waste incidents and
engage withlocal authorities to maintain environmental cleanliness. The application was
designed for both Android and iOS platforms with key features such as waste reporting, user
notifications, and interaction with authorities.

3.2 Project Highlights and Best Practices

Project Highlights and Best Practices
● Successful Integration: The app successfully integrated with local government systems for
real-time updates.
● User Engagement: High user engagement with a 70% weekly active user rate.
● Security: Strong security measures were implemented to protect user data.

3.3 Project Closure Synopsis

Project Closure Synopsis
The project met its key objectives within the scheduled timeline and budget. However, certain
features like advanced analytics and user forums were deferred for future development. Overall, the
project was deemed successful based on the user feedback and project metrics.

31 | P a g e
210160116104 7th IT – B2

4. PROJECT METRICS PERFORMANCE

4.1 Goals and Objectives Performance

Goals and Objectives Performance
The primary goal of providing a user-friendly platform for waste management was achieved with
positive feedback from users and authorities.

4.2 Success Criteria Performance

Success Criteria Performance

The success criteria included user adoption, system reliability, and security compliance, all of which
were met

4.3 Milestone and Deliverables Performance

Milestone and Deliverables Performance
All major milestones, including app development, testing, and deployment, were completed as
scheduled.

4.4 Schedule Performance

Schedule Performance
The project was completed on time with a slight delay in the final testing phase, which was promptly
managed.

4.5 Budget Performance

Budget Performance
The project was completed within budget, with a contingency fund that remained unused.

4.6 Metrics Performance Recommendations

Metrics Performance Recommendations

● Enhance future projects with more frequent user testing phases.
● Allocate more resources to the initial design phase to avoid redesigns.

32 | P a g e
210160116104 7th IT – B2

5. PROJECT CLOSURE TASKS

5.1 Resource Management
Resource Management
All project resources, including personnel and equipment, have been reallocated or returned.

5.2 Issue Management

Issue Management
All outstanding issues have been resolved, and a final issue log has been archived.

5.3 Risk Management

Risk Management
Risk assessments were conducted throughout the project, and all identified risks were mitigated.

5.4 Quality Management

Quality Management
Quality checks were performed at each phase of the project, and the final product meets all required
standards.

5.5 Communication Management

Communication Management
Regular communication with stakeholders ensured that the project stayed on track.

5.6 Customer Expectation Management

Customer Expectation Management

Customer expectations were managed through regular updates and feedback sessions.

5.7 Asset Management

Asset Management
All project assets, including documentation and code, have been archived for future reference.

5.8 Lessons Learned

Lessons Learned
● Importance of early user involvement to avoid redesigns.
● Need for better risk management strategies during the testing phase.

33 | P a g e
210160116104 7th IT – B2

5.9 Post project Tasks

Post-project Tasks
● Transfer of maintenance responsibilities to the operations team.
● Final report submission to stakeholders.

5.10 Project Closure Recommendations

Project Closure Recommendations

● Consider implementing deferred features in a future phase.
● Conduct a follow-up survey with users six months post-launch.

34 | P a g e
210160116104 7th IT – B2

6. Project Closure Report Approvals

Prepared By: Cloud Forcasting

(Project Manager)

Approved By: Prof. Nainesh Nagekar

(Faculty Professor)

Approval Date:

7. Appendices

7.1 Project Closure Report Sections Omitted

● Section 6: Post-Implementation Review (Omitted due to ongoing post-implementation

activities)
● Section 8: Detailed Financial Analysis (Omitted as financials were covered in
summary form under Budget Performance)

35 | P a g e
210160116104 7th IT – B2

Sr. Needs
Criteria Improvement Acceptable Good Very Good Total
No.

Analysis [1] [2-3] [4-5] [6-8]

Poorly Fairly Clearly Clearly
understands the understands understands understands
the the the

project status. project status. project status project status

based based
1 on individual on individual
modules. modules can
validate against
the
requirements.

Documenta [0] Poor [1] [2]

tion
documentation Fairly Presented the
2 presented the analysis in
analysis and technical words.
status.

Signature of Faculty:

36 | P a g e