ACKNOWLEDGEMENT

It is indeed a great pleasure to express our thanks and gratitude to all those who helped us during this
project. This project has given us a nice opportunity to think, implement and interact with various
aspects of the Software Development Life Cycle. We would like to acknowledge all the people who
have helped us at one stage or another by providing the much needed support, encouragement and
groundwork to complete our project during the specific schedule.
We express a deep sense of gratitude towards our guide GuideName towards their innovative
ideas and earnest effort to make our project a success. It is their sincerity that prompted us throughout
the project to do hard work using the industry adopted technologies. Our commitment to the
application is a result of patience, hard work and dedication as inspired by them.
Furthermore, this project has given us very good practical knowledge and we learnt a lot and
got good training to use my knowledge and expertise for very practical use in the industry and society.
We am very thankful to all those who have directly or indirectly helped me towards completion of the
project.

With Sincere Regards,

INTERSHIP EFFORT ESTIMATION

The estimation of various project parameters is a basic project planning activity. The important project
parameters that are estimated include: project size, effort required to develop the software, project
duration and cos. The estimates not only help in quoting the project cost to the customer, but also
prove in resource planning and scheduling.

There are three board categories of estimation techniques:

 Empirical estimation techniques
 Heuristic techniques
 Analytical estimation techniques

COCOMO (Constructive Cost estimation Model) – Heuristic techniques

It can be classified into three categories

 Organic
 Semidetached
 Embedded

Using Semidetached Intermediate COCOMO Model

Software project estimation in today’s era may result in companies profit and loss, thus a small error in
estimating have very large impact on project and company itself. But then too it’s also true that
estimation can never be exact particularly in software we have many variables – human, technical,
environmental, political etc.

The cost estimation model is concerned with the representation of the process to be estimated. Before
project cost estimation project scope, modules and delay estimation must be done. Here we have user
COCOMO – Cost Constructive Model for the estimation of the project cost. COCOMO is the
hierarchy of cost estimation models those ranges from very large complex project to in house
development by inexperienced developers. Among the range of the COCOMO models we have used
the semidetached intermediate model of it.

Reasons of selecting semidetached Intermediate model

 It provides the flexibility in estimation according to the problem on hand.
 It considers all around cost drivers that affect the project cost.
 The development team in case of project includes mixture of experienced and less experienced
team Reg-User.
 It is not only assumes factors such as effort and development time to find product size but also
consider other factors taken into account using a set of 15 cost driver based on various attributes of
software development.
The cost drivers are classified into following items:
 Product
 Computer
 Personnel
 Development environment

The Intermediate COCOMO models with their co-efficient are given below

Project Effort T Dev.

Organic 2.4 (KLOC) 1.05 2.5 (Effort) 0.38
Semidetached 3.0 (KLOC) 1.12 3.0 (Effort) 0.35
Embedded 3.6 (KLOC) 1.20 3.0 (Effort) 0.32

The Equations for the Intermediate model of the COCOMO is given below
Efforts = 2.4(KLOC) * Total effort multiplier
T DEV (Time for Development) = 2.5(Efforts) * Total effort multipliers

COST ANALYSIS

Total cost of the project including resources and labors. Labor cost should be broken down into the
areas of design, analysis, prototype construction, software development, hardware-software
integration, testing, design modifications and documentation. A cost analysis is NOT a tabulation of
your expenditure
Group Dependencies

Some dependencies are described as follows:

1. User has sufficient privileges to access internet.

2. Server is running smoothly.
3. Database transactions are giving expected results.
4. Database transactions are secure and reliable.
5. User is aware about the languages and usage.
6. Python Django and supported IDE to be installed.
7. SQLite Database understanding and support must be there.

Gantt Chart

PERT Chart
 Prepare project Analysis of project
proposal

1 Jan 2 15Jan 16Jan 2 31Jan

‘22 wks ‘22 ‘22 wks ‘22
START
1 Jan 2022

Created design
Understand basic fun- fundamentals
-ctionality of Python
1 Feb 10 10Feb
1 Jan 4 31Jan ‘22 days ‘22
‘22 wks ‘22

Created backup and Created groups and Created Front End and Created main UI, created
restore functionality connect them to database combined to database tables for contacts

16 Apr 2 31Apr 1 Apr 2 15Apr 1 Mar 4 31Mar 11Feb 18 28Feb

‘22 wks ‘22 ‘22 wks ‘22 ‘22 wks ‘22 ‘22 days ‘22

Documentation of the
project FINISH
25 Apr 2022
1 Apr 4 25Apr
‘22 wks ‘22

Requirement of New System

The new system is managed by the Python Django, which are user friendly windows for every user and for maintaining
the database MySQL is used.
The new system is highly secured, because for login the system it requires the username and password which is different
for each department therefore providing each department a different view of the customer information.
It provides wide range of certain criteria in each window the client is working for better and quicker solution.
It maintains report for all criteria and transactions.
Manages member information separately for all exercise and employee information separately for considering the
requirements of centre.
Stores information about regular products.
This system can run on any windows operating system.

o Home
o About Us
o Online Courses
o Camps
o Teacher Training Courses
o Gallery
 o Centres
o Articles
o Shop
o Donate/Charity
o Books/Publications

Feasibility Study

The feasibility of software can be tested in for dimensions:

1. Technology- Is a project technically feasible? As in our case that is quiz we have many
examples of the same, so no technical infeasibility are there.
2. Finance- Is it financially feasible? Does it have too much cost of development?
3. Time- Will it takes too much time to complete? We have planned each phases and it
seems to be in controlled and within time so no extra time cost will be added.
4. Resources- Do we have sufficient resource to succeed?

Technical Feasibility

Technical analysis evaluates technical merits of the system at the same time collects additional
information about performance, reliability, maintainability and productivity. The technical feasibility
means that the project can be done with the current equipment, existing software technology and the
current knowledge. The present system is technically feasible as it developed on Python Django. These
are currently used for development which altogether makes our system technically feasible. All the
resources needed for the development as well as the maintenance is easily available on internet like
Python 3 and Django.

Time Schedule Feasibility

The project has simple working and the basic requirement can be satisfied within the allotted time
period. So, the project is feasible and can be completed before the deadline.

Operational Feasibility

Operation feasibility deals with the acceptance of the users and their willingness to use the system. The
Yoga Hut application is helpful in the current situation. There is never been a decrease in demand of
books so it will be great for all users.

Implementation Feasibility

Implementation feasibility is concerned with specifying external resources and software that will
successfully satisfy the requirements. This system is built in Python Technology as an web application.
As many android applications are available for different use so system is feasible for implementing.

Features of New System

  Knowledge of yoga and its culture in one click.
 Best Place to explore all yoga information and Trainer connects.
 Best Books and publications to find at one place.
 Can shop yoga accessories and its collections.
 The system is to provide facility to connect for train the trainer model.
 The system provides authentic features for yoga academy and training programs, camps and
shops.
 It provides wide range of certain criteria in each window the client is working for better and quicker
solution.
 It maintains report for all criteria and transactions.
 Manages member information separately for all exercise and employee information separately for
considering the requirements of centre.
 Stores information about regular products.

Module Descriptions

Login Form – the login form will be used by the administrator, Trainer, yoga centre instructors and
Reg-User of the yoga centre to access their respective accounts.

Administrator can:
 Manage user accounts (CRUD – create, update, and delete)
 Manage reg. user type (CRUD – create, update, and delete)
 Manage member information (CRUD – create, update, and delete), approve and disapprove the
application
 Manage yoga centre instructor information (CRUD – create, update, and delete), activate and
deactivate the account
 Manage promotional material (upload banners and videos for promotion and advertisement
purposes)
 Manage yoga and yoga plan information (CRUD – create, update, and delete)
 Manage payment (accept and void payments)
 Perform database and system maintenance

Trainer can:
 Encode member information
 Encode yoga and yoga plan information
 Accept payment

Yoga centre Instructor can:

 View yoga plan and schedules
Reg-User can:
 Apply for a yoga and yoga plan
 View schedule of activities
Justification:

 Python Django is best open source programming language to develop web

application (back end) for small and large enterprise with portable implementation.
 MySQL is also best open source database engine to work.
 Combination of both will give great web application as output.

Implementation

Implementation Environment

 Our project is suitable to all type of users like single and multi-users.
 Multi users are allowed to operate the website at the same time.
 We provide the interface which is user friendly.
 We have GUI (graphical user interface) by which all type of users can easily access the
application.
 One user at a time and also multi users can access the website at the same time and use all the
services.
 If we don’t provide the GUI in the website then user won’t like our website.
 For better performance and reliability, we have to include GUI in the website
 So, for the more security and performance we have to use the GUI.

Security Features User authentication:

 Identification and authentication are used to establish a user's identity.
 Each user is required to log in to the system.

Password Protection:
 Every user who is to be allowed to access the portal is given his own username and password
and given his own access rights so that only authorized and authenticated users can access the
project.

Confidentiality:
 We provide confidentiality to all the users.
 In that one user cannot access the data of the other users.
  For that we provide one key to each user to secure its data.

Scalability:

 We provide the scalable website to make sure that every user can access the website in a proper
order.

 User likes those type of website which are in one particular order that user cannot wait for the
usage of the services.

Coding Standards

 Every company follows a different coding standard based on their best practices.

 Coding standard is required because there may be many developers working on different
modules so if they will start inventing their own standards then source will become very
unmanageable and it will become difficult to maintain that source code in future.

 Here are several reasons why to use coding specifications:

Your peer programmers have to understand the code you produce.

A coding standard acts as the blueprint for all the team to decipher the code.
Simplicity and clarity achieved by consistent coding saves you from common mistakes.
If you revise your code after some time then it becomes easy to understand code.
 Implementation GUI of Visual Studio Code.

Coding Standards

Naming Convention

 Use meaningful names

 Function and variable names in snake_case

 Classname in PascalCase

 Constants snake_case capitalized

Indentation/Space

 Use 4 spaces for indentation(Python 3 disallows mixing the use of tabs and spaces for indentation)

 Separate top level function and classes with two blank lines

 Separate method definition inside class by one line

 Maximum length of line should be less than 80 characters

 There should be no trailing white spaces

Imports

 Import from Python standard library(1st)

 Import from core Django(2nd)

 Import from 3rd party vendor(3rd)

 Import from Django Apps(4th)(Current Project)

 Avoid import *

Migrations

 Do not modify the files created by makemigration command(do not add custom sql command)

 Place custom sql command if needed in a separate file and do not mix it with the auto generated
files from makemigration command

 Forward and backward migration work only on auto generated files by makemigration command

 Not all migration can be reversed

 Add — database=<dbConfigName> always in your migration

Forward Migration

 python manage.py migrate appname 0002 — settings=project.settings.<Env> —

database=<dbConfigName>

 python manage.py migrate appname 0003 — settings=project.settings.<Env> —

database=<dbConfigName>

 Suppose it added all the migration 0001.py , 0002.py , 0003.py , 0004.py

Backward Migration

(Remove New migrations -0002.py , 0003.py , 0004.py)

 python manage.py migrate appname 0001 — settings=project.settings.<Env> —

database=<dbConfigName>
Response Status

 Response message with status codes

{
‘status’:’success|error’,
‘data’:{
'result':{} || [] , ''
}, #one level
‘meta’:{} #any meta information that you want to pass
}

 200 OK — Success — GET/PUT — return resource/status message

 201 Created — Success — POST — provide status message or return newly created object

 204 No Content — Success — DELETE

 304 Unchanged — Redirect — ALL — Indicates no changes since last request

 400 Bad Request — Failure — GET/PUT/POST — invalid request, return error messages

 401 Unauthorized — Failure — ALL — missing credentials/Authentication required

 403 Forbidden — Failure — ALL — restricted content

 404 Not Found — Failure — Resource not found

 405 Method Not Allowed Failure — Failure — ALL — An invalid HTTP method was attempted

App Structure
project/
gitignore
README.md
docs/
requirements/
local.txt
 qa.txt
prod.txt
base.txt
project/
settings/
base.py //copy of original settings.py
qa.py
local.py
prod.py
urls.py
wsgi.py
settings_default.py //renamed settings->settings_default
app1/
app2/
v1/
api.py // entry point , not much logic
service.py // all business logic
util.py // any helper
test/
migrations/
admin.py
models.py
apps.py
urls.py
views.py
utils/
service/
helper/

Tools/Extra

 Code Quality — flake8

 Environment Manager — venv

 Documentation — Swagger

 Testing — pytest

 IDE — sublime,vim,pycharm

 Debug — pdb
References

 https://www.python.org/dev/peps/pep-0008/

 https://google.github.io/styleguide/pyguide.html

 https://www.chromium.org/chromium-os/python-style-guidelines

 http://doc.pytest.org/en/latest/

Testing

The Test Plan document on the other hand, is derived from the YogaTraining Description, Software
Requirement Specification, or Use Case Documents.
The Test Plan document is usually prepared by the Test Lead or Test Manager and the focus of the
document is to describe what to test, how to test, when to test and who will do what test.

It is not uncommon to have one Master Test Plan which is a common document for the test phases and
each test phase has their own Test Plan documents. There is much debate, as to whether the Test Plan
document should also be a static document like the Test Strategy document mentioned above or should
it be updated every often to reflect changes according to the direction of the project and activities. Our
own personal view is that when a testing phase starts and the Test Manager is “controlling” the
activities, the test plan should be updated to reflect any deviation from the original plan. After all,
Planning and Control are continuous activities in the formal test process.

Components of the Test Plan document

 Test Plan id
 Introduction
 Test items
 Features to be tested
 Features not to be tested
 Test techniques
 Testing tasks
 Suspension criteria
 Features pass or fail criteria
 Test environment (Entry criteria, Exit criteria)
 Test deliverables
 Trainer/ YogaMember and training needs
 Responsibilities
 Schedule
This is a standard approach to prepare test plan and test strategy documents, but things can vary
company-to-company.

General Test Cases

 YogaTraining Book Flow – Test cases
 User(YogaMember) Registration – Test cases
 Trainer – YogaTraining creation Test cases
General Test Cases
1. Verify that user is able to navigate through all the YogaTrainings across different categories
2. Verify that all the links and banners are redirecting to correct YogaTraining/category pages and
none of the links are broken
3. Verify that the company logo is clearly visible
4. Verify that all the text – YogaTraining, category name, price and YogaTraining description are
clearly visible
5. Verify that all the images – YogaTraining and banner are clearly visible
6. Verify that category pages have relevant YogaTraining listed specific to the category
7. Verify that correct count of total YogaTrainings are listed on the category pages
8. Search – Verify that on searching all the YogaTraining satisfying the search criteria are visible
on the search result page
9. Search – Verify the more relevant YogaTraining for the search term are displayed on the top
for a particular search term
10. Search – Verify that count of YogaTrainings is correctly displayed on the search result page for
a particular search term
11. Filtering – Verify that filtering functionality correctly filters YogaTraining based on the filter
applied
12. Filtering – Verify that filtering works correctly on category pages
13. Filtering – Verify that filtering works correctly on the search result page
14. Filtering – Verify that correct count of total YogaTrainings is displayed after a filter is applied
15. Sorting – Verify that all the sort options work correctly – correctly sort the YogaTrainings
based on the sort option chosen
16. Sorting – Verify that sorting works correctly on the category pages
17. Sorting – Verify that sorting works correctly on the search result page
18. Sorting – Verify that sorting works correctly on the pages containing filtered result, after
applying filters
19. Sorting – Verify that YogaTraining count remains intact irrespective of sorting option applied

Test Cases of Yoga Hut

Test Engineer: Name of the person who is testing the module.
01-04-2022
Date:
User authentication
Purpose:
Test User Name and Password (Kuldeep, Kuldeep007)
Data:
· Enter User Name
Steps:
· Enter Password
 · Click Login
Pass
Status:
Table: Login
 
Test Engineer: Name of the person who is testing the module.
01-04-2022
Date:
Purpose: Add new Trainer
PreReq: Admin logged in
Test Data: User Name and Password(Kuldeep, Kuldeep007)
· Enter User Name
· Enter Password
Steps:
· Enter new Record
Status: Pass
Table: Add Trainer
 
Test Engineer: Name of the person who is testing the module.
Date: 01-04-2022
Purpose: View Members
PreReq: Admin logged in
Test Data: User Name and Password(Kuldeep, Kuldeep007)
· Enter User Name
Steps:
· Enter Password
· Click view users

Status: Pass
Table: View Members
 
Test Engineer: Name of the person who is testing the module.
Date: 01-04-2022
Purpose: Delete Member
Pre Req: Admin logged in
Test Data: User Name and Password(Kuldeep, Kuldeep007)
· Enter User Name
· Enter Password
·  Click on view users
Steps:
· Click on delete
Status: Pass
Table: Delete Members
 
Test Engineer: Name of the person who is testing the module.
Date: 01-04-2022
Purpose: View Messages
Pre Req: Admin logged in
Test Data: User Name and Password(Kuldeep, Kuldeep007)
· Enter User Name
Steps:
· Enter Password
Click on Message Box to view message
Status: Pass
Table: View Messages
 
Test Engineer: Name of the person who is testing the module.
Date: 01-04-2022
Purpose: Delete Messages
Pre Req: Admin logged in
Test Data: User Name and Password(Kuldeep, Kuldeep007)
· Enter User Name
· Enter Password
·  Click on the message box
Steps:
· Click on delete
Status: Pass
Table: Delete Message

TEST CASES

Test Case Documents

Designing good test cases is a complex art. The complexity comes from three sources:
Test cases help us discover information. Different types of tests are more effective for different
classes of information.
Test cases can be "good" in a variety of ways. No test case will be good in all of them.
People tend to create test cases according to certain testing styles, such as domain testing or
risk-based testing. Good domain tests are different from good risk-based tests.
The test cases will have a generic format as below.

Test case ID - The test case id must be unique across the application
Test case description - The test case description must be very brief.
Test prerequisite - The test pre-requisite clearly describes what should be present in the system,
before the test can be executes.
Test Inputs - The test input is nothing but the test data that is prepared to be fed to the system.
Test steps - The test steps are the step-by-step instructions on how to carry out the test.
Expected Results - The expected results are the ones that say what the system must give as output or
how the system must react based on the test steps.
Actual Results – The actual results are the ones that say outputs of the action for the given inputs or
how the system reacts for the given inputs.
Pass/Fail - If the Expected and Actual results are same then test is Pass otherwise Fail.
The test cases are classified into positive and negative test cases. Positive test cases are designed to
prove that the system accepts the valid inputs and then process them correctly. Suitable techniques to
design the positive test cases are Specification derived tests, Equivalence partitioning and State-
transition testing. The negative test cases are designed to prove that the system rejects invalid inputs
and does not process them.
Suitable techniques to design the negative test cases are Error guessing, Boundary value analysis,
internal boundary value testing and State-transition testing. The test cases details must be very clearly
specified, so that a new person can go through the test cases step and step and is able to execute it. The
test cases will be explained with specific examples in the following section.
For example consider online shopping application. At the user interface level the client request the web
server to display the YogaTraining details by giving email id and Username. The web server processes
the request and will give the response. For this application we will design the unit, Integration and
system test cases.

Unit Test Cases

These are very specific to a particular unit. The basic functionality of the unit is to be understood based
on the requirements and the design documents. Generally, Design document will provide a lot of
information about the functionality of a unit. The Design document has to be referred before UTC is
written, because it provides the actual functionality of how the system must behave, for given inputs.
For example, in the YogaTraining customization and shopping application, if the user enters valid
Email id and Username values, let us assume that Design document says, that the system must display
a YogaTraining details and should insert the Email id and Username in database table. If user enters
invalid values the system will display appropriate error message and will not store it in database.

Integration Test Cases

Before designing the integration test cases the testers should go through the Integration test plan. It
will give complete idea of how to write integration test cases. The main aim of integration test cases is
that it tests the multiple modules together. By executing these test cases the user can find out the errors
in the interfaces between the Modules.
For example, in YogaTraining customization and shopping, there will be Catalog and Administration
module. In catalog section the customer can track the list of YogaTrainings and can Book the
YogaTrainings online. In administration module the admin can enter the YogaTraining name and
information related.

System test cases

The system test cases meant to test the system as per the requirements; end-to end. This is basically to
make sure that the application works as per SRS. In system test cases, (generally in system testing
itself), the testers are supposed to act as an end user. So, system test cases normally do concentrate on
the functionality of the system, inputs are fed through the system and each and every check is
performed using the system itself. Normally, the verifications done by checking the database tables
directly or running programs manually are not encouraged in the system test.
The system test must focus on functional groups, rather than identifying the program units. When it
comes to system testing, it is assume that the interfaces between the modules are working fine.
Ideally the test cases are nothing but a union of the functionalities tested in the unit testing and the
integration testing. Instead of testing the system inputs outputs through database or external programs,
everything is tested through the system itself.
For example, YogaTraining customization and shopping application, the catalog and administration
screens would have been independently unit tested and the test results would be verified through the
database. In system testing, the tester will mimic as an end user and hence checks the application
through its output

Conclusion and Discussion

CONCLUSION

We have enjoyed a lot in our project “Yoga Hut” and special thanks to our internal guide
GuideName who had helped us a lot in our project analysis. The YogaHut is highly secured, because
for login the system it requires the username and password which is different for each department
therefore providing each department a different view of the customer information. It provides wide
range of certain criteria in each window the client is working for better and quicker solution. It
maintains report for all criteria and transactions. Manages member information separately for all
exercise and employee information separately for considering the requirements of centre Stores
information about regular products

DISCUSSION

Self-Analysis of Project Viabilities

According to me, this projected is completed with the primary functionalities as specified earlier but
then again there is lot more than this which can be done. The project is well capable to handle the
given job for some particular task but not all of them. So then it is a challenge to further develop it in
to well fledge web application as it was challenge to develop up to this very stage.

Problems Encountered and Possible Solutions

There are so many problem encountered during this project.
 The problem to maintain threshold.
 The problem to maintain back end service.

Summary of Project Work

It is a great achievement to successfully complete the project. The prior knowledge of software
engineering has helped immensely in overcoming the various roadblocks. We have done work with
pre-planned scheduling related with time constraints and result oriented progress in project
development.

References and Bibliography:

A.1Abbreviations
 HTTP : Hyper Text Transfer Protocol
 URL :Uniform Resource Locator
A.2Bibliography

1) Online tutorials for Python Django.

2) Online tutorials for converting attachment to byte array and store attachment to the
database and how to send attachment via web service.
3) Getting online information on different Exceptions and syntaxes.

A.3Referred websites:
 www.w3schools.com
 www.tutorialspoint.com

 https://www.tutorialspoint.com/django/index.htm

 https://www.edureka.co/blog/django-tutorial/