PROJECT ASSISTANT

A Project Report Submitted in the

Partial Fulfillment of the Requirements
for the Award of the Degree of

BACHELOR OF TECHNOLOGY

IN

Information Technology

Submitted by

ALAMPALLY SREEJA 19881A1202

K.KEERTHAN REDDY 19881A1223

SUPERVISOR
E.Ravi Kumar
Assistant professor

Department of Information Technology

 Department of Information Technology

CERTIFICATE

This is to certify that the project titled PROJECT ASSISTANT is carried

out by

ALAMPALLY SREEJA 19881A1202

K.KEERTHAN REDDY 19881A1223

in partial fulfillment of the requirements for the award of the degree of

Bachelor of Technology in Information Technology during the year 2021-

22.

Signature of the Supervisor Signature of the HOD

E.Ravi Kumar DR.MUNISHEKAR VELPURU
Assistant professor HEAD OF THE DEPARTMENT,IT

Kacharam (V), Shamshabad (M), Ranga Reddy (Dist.)–501218, Hyderabad, T.S.

Ph: 08413-253335, 253201, Fax: 08413-253482, www.vardhaman.org
 Acknowledgement

The satisfaction that accompanies the successful completion of the task

would be put incomplete without the mention of the people who made it
possible, whose constant guidance and encouragement crown all the efforts
with success.

We wish to express our deep sense of gratitude to E.Ravi Kumar, Assis-

tant professor and Project Supervisor, Department of Information Technology,
Vardhaman College of Engineering, for his able guidance and useful sugges-
tions, which helped us in completing the project in time.

We are particularly thankful to DR.MUNISHEKAR VELPURU, the

Head of the Department, Department of Information Technology, his guidance,
intense support and encouragement, which helped us to mould our project
into a successful one.

We show gratitude to our honorable Principal Dr. J.V.R. Ravindra, for

providing all facilities and support.

We avail this opportunity to express our deep sense of gratitude and heart-
ful thanks to Dr. Teegala Vijender Reddy, Chairman and Sri Teegala
Upender Reddy, Secretary of VCE, for providing a congenial atmosphere to
complete this project successfully.

We also thank all the staff members of Electronics and Communication

Engineering department for their valuable support and generous advice. Finally
thanks to all our friends and family members for their continuous support and
enthusiastic help.

ALAMPALLY SREEJA
K.KEERTHAN REDDY

i
 Abstract

Understanding the market need for a product or service is a crucial as-

pect of a business plan.With the excitement of a new business idea, it can
be tempting to launch without much forward-thinking. Yet with a lack of
planning businesses can run out of cash and can’t even prepare or pay for
vital activities such as marketing or dealing with suppliers.So, we have come
up with an idea to provide proper guidance and to develop the project in
an organized way so that it could be helpful for the clients.The client has to
provide all the necessary details of the project on our website such as problem
statement, the domain of the project, under which organization it is going to
be implemented, under which sector(public/private) it falls, and some personal
details of the client for further communications.After the client provides the
information, we will verify and respond to the clients by providing the client
login. We provide instructions for the particular project of the client.The
client can address the queries at any time on the website.

ii
 Table of Contents

Title Page No.

Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
CHAPTER 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
CHAPTER 2 Literature Survey . . . . . . . . . . . . . . . . . . . . . 2
2.1 Existing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Limitations of Existing Systems . . . . . . . . . . . . . . . . . . . 2
2.3 Proposed method and Advantages . . . . . . . . . . . . . . . . . . 2
2.4 Advantages of proposed methodology . . . . . . . . . . . . . . . . 3
CHAPTER 3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Non-functionalonal requirements . . . . . . . . . . . . . . . . . . . 4
3.3 Computational requirements . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1 Software requirements . . . . . . . . . . . . . . . . . . . . . 5
3.3.2 Hardware requirements . . . . . . . . . . . . . . . . . . . . . 5
3.3.3 Software Development Life Cycle . . . . . . . . . . . . . . . 5
CHAPTER 4 DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Software Architecture . . . . . . . . . . . . . . . . . . . . . 7
4.1.2 Technical Architecture . . . . . . . . . . . . . . . . . . . . . 7
4.2 Uml diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
CHAPTER 5 IMPLEMENTATION . . . . . . . . . . . . . . . . . . 11
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Method of Implementation . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Output Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

iii
CHAPTER 6 TESTING RESULTS . . . . . . . . . . . . . . . . . . 18
6.1 Overview of testing . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Dimensions of testing . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3 Testcases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
CHAPTER 7 Conclusions and Future Scope . . . . . . . . . . . . . 20
REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
List of Tables

v
 List of Figures

3.1 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 SDLC Implementation . . . . . . . . . . . . . . . . . . . . . . . . 6

4.1 Software Architechture . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.2 Technical Architechture . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 usecase diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.1 process of implementation . . . . . . . . . . . . . . . . . . . . . . . 11

5.2 implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4 Client Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5 Client login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6 Instructions to client . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.7 database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.1 testcases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

vi
 Abbreviations

Abbreviation Description

VCE Vardhaman College of Engineering

SDLC Software Development Life Cycle

UML Unified Modeling language

 CHAPTER 1

Introduction

1.1 Introduction
A start-up is generally a young business which just begins to develop.These
companies are generally meant for innovation of the existing ideas in order
to offer product or service that is not availableanywhere in market or which
are available in an inferior manner.The main essence of start-ups has to do
more with high ambition,innovative ness, scalability and growth.At first these
companies has incur lot of expenses in the form of business modelling, testing
and marketing their concept. Since, these companies are very small and
initially operated and financed eitherby an individual or by partners together
thereby the companies face many challenges with limited resources availing
with ample opportunities.[1]

1.2 Problem Definition

We have come up with an idea to provide proper guidance and to develop
the project in an organized way so that it could be helpful for the clients.The
client has to provide all the necessary details of the project on our website such
as problem statement, the domain of the project, under which organization
it is going to be implemented, under which sector(public/private) it falls,
and some personal details of the client for further communications.After the
client provides the information, we will verify and respond to the clients by
providing the client login. We provide instructions for the particular project
of the client.The client can address the queries at any time on the website.

1
 CHAPTER 2

Literature Survey

2.1 Existing System

Understanding the market need for a product orservice is a crucial aspect
of a business plan.
With the excitement of a new business idea, it can be tempting to launch
without much forward thinking. Yet with a lack of planning businesses can
run out of cash and can’t even prepare or pay for vital activities such as
marketing or dealing with suppliers.
At first these companies has incur lot of expenses in the form of business
modelling, testing and marketing their concept. Since, these companies are
very small and initially operated and financed either by an individual or by
partners together thereby the companies face many challenges with limited
resources availing with ample opportunities.

2.2 Limitations of Existing Systems

• Risk of Failure

• Team conflicts

• Lack of Resources

• Lack of proper Guidance

• Lack of Knowledge

2.3 Proposed method and Advantages

We develop a website that consists of form, client login,etc. The client
has to provide all the necessary details of the project on our website such

2
as problem statement, the domain of the project, under which organization
it is going to be implemented,under which sector(public/private) it falls, and
some personal details of the client for further communications.After the client
provides the information, we will verify and respond to the clients by providing
the client login. The client can address queries at any time on the website.

2.4 Advantages of proposed methodology

• We offer our services in a more efficient, cost-effective, and competitive
manner.

• We make them aware of their limitations and tend to focus on their core
strengths. This causes them to partner with other small organizations.

• Customers often benefit from a superior value proposition

• We make them know all the tools present in the market

• We provide advantages and disadvantages of tools so that they can

choose best tool.

• We provide communication to freelancer

• The query of our clients will be resolved by freelancer

• We help our clients to make projects in effective

Department of Information Technololgy 3

 CHAPTER 3

Analysis

3.1 Functional requirements

Modules:

1. Client:The Client is the main entity in our proposed framework. The

patient has the following main tasks:

• View the instructions.

• The client can clarify their queries.

2. Freelancers: These are individuals who provide instructions for all kinds
of projects in an organized manner.They should complete the following
tasks:

• They give replies to the queries.

3. Admin:Admin is responsible for the following functions:

• Authenticate all participants who interact with the system.

• Generate keys for clients and freelancers.

3.2 Non-functionalonal requirements

• Portability

• Reliability

• Usability

• Performance

• Security

4
 • Privacy

• Scalability

3.3 Computational requirements

3.3.1 Software requirements

Operating System:Windows 10
Database Server : SQL YOG(MYSQL)
Server : Apache Tomcat 8
Platform : Java
Technology : php
Client Side Technology : HTML,CSS,Java Script
IDE : Eclipse

3.3.2 Hardware requirements

Processor:Intel core I7
RAM:4GB
Hard Disk:500 GB

3.3.3 Software Development Life Cycle

Software Development Life Cycle, SDLC for short, is a well-defined, struc-
tured sequence of stages in software engineering to develop the intended
software product. Software Development Paradigm: The software development
paradigm helps developer to select a strategy to develop the software. A
software development paradigm has its own set of tools, methods and proce-
dures, which are expressed clearly and defines software development life cycle.
A software development paradigms or process models are defined as follows:
Spiral Model: Spiral model is a combination of both, iterative model and
one of the SDLC model. It can be seen as if you choose one SDLC model
and combine it with cyclic process (iterative model).

Department of Information Technololgy 5

 Figure 3.1: Spiral Model

This model considers risk, which often goes un-noticed by most other
models. The model starts with determining objectives and constraints of the
software at the start of one iteration. Next phase is of prototyping the
software. This includes risk analysis. Then one standard SDLC model is used
to build the software. In the fourth phase of the plan of next iteration is
prepare.
SDLC Implementation: SDLC provides a series of steps to be followed to
design and develop a software product efficiently. SDLC framework includes
the following steps:

Figure 3.2: SDLC Implementation

Department of Information Technololgy 6

 CHAPTER 4

DESIGN

4.1 Architectures

4.1.1 Software Architecture

Figure 4.1: Software Architechture

4.1.2 Technical Architecture

Figure 4.2: Technical Architechture

7
4.2 Uml diagrams
UML Design
Unified Modeling Language (UML) is a general purpose modeling language.
The main aim of UML is to define a standard way to visualize the way a
system has been designed. It is quite similar to blueprints used in other fields
of engineering. UML is not a programming language; it is rather a visual
language. We use UML diagrams to portray the behavior and structure of
a system, UML helps software engineers, businessmen and system architects
with modeling, design and analysis. The Object Management Group (OMG)
adopted Unified Modeling Language as a standard in 1997. It’s been managed
by OMG ever since. International Organization for Standardization (ISO)
published UML as an approved standard in 2005. UML has been revised over
the years and is reviewed periodically.
Do we really need UML?

• Complex applications need collaboration and planning from multiple

teams and hence require a clear and concise way to communicate amongst
them.

• Businessmen do not understand code. So UML becomes essential to com-

municate with non programmer’s essential requirements, functionalities
and processes of the system.

• A lot of time is saved down the line when teams are able to visualize
processes, user interactions and static structure of the system.

• UML is linked with object oriented design and analysis. UML makes the
use of elements and forms associations between them to form diagrams.
Diagrams in UML can be broadly classified as:

The Primary goals in the design of the UML are as follows:

• Provide users a ready-to-use, expressive visual modeling Language so

that they can develop and exchange meaningful models.

Department of Information Technololgy 8

 • Provide extendibility and specialization mechanisms to extend the core
concepts.

• Provide a formal basis for understanding the modeling language.

• Encourage the growth of OO tools market

• Support higher level development concepts such as collaborations, frame-

works, patterns and components.

• Integrate best practices.

Types of UML Diagrams:

Structural Diagrams: Capture static aspects or structure of a system.
Structural Diagrams include: Component Diagrams, Object Diagrams, Class
Diagrams and Deployment Diagrams.
Behavior Diagrams: Capture dynamic aspects or behavior of the system.
Behavior diagrams include: Use Case Diagrams, State Diagrams, Activity
Diagrams and Interaction Diagrams.
USE CASE DIAGRAM:
A use case diagram in the Unified Modeling Language (UML) is a type
of behavioral diagram defined by and created from a Use-case analysis. Its
purpose is to present a graphical overview of the functionality provided by
a system in terms of actors, their goals (represented as use cases), and any
dependencies between those use cases. The main purpose of a use case diagram
is to show what system functions are performed for which actor. Roles of the
actors in the system can be depicted.[2]

Department of Information Technololgy 9

 Figure 4.3: usecase diagram

Department of Information Technololgy 10

 CHAPTER 5

IMPLEMENTATION

5.1 Introduction
We now know what the problem is Startups have been using tools appro-
priate for executing a known business. But startups are all about unknowns.
To find the path to build a winning startup, entrepreneurs must try a new
way:
Winners throw out the traditional product management and introduction
processes they learned at existing companies. Instead, they combine agile
engineering and Customer Development to iteratively build, test and search
for a business model, turning unknowns into knowns.

Figure 5.1: process of implementation

Winners also recognize their startup ”vision” as a series of untested hy-

potheses in need of ”customer proof.” They relentlessly test for insights, and
they course correct in days or weeks, not months or years, to preserve cash
and eliminate time wasted on building features and products that customers
don’t want.
Winners recognize their startup is a series of untested hypotheses.
Losers blindly execute a rigid product management and introduction.
methodology. They assume thahe founder’s vision drives the business strategy
and product development plans and that all they need to do is to raise funds
for execution.
Founders, not employees, must search for a business model. The best way
to search is for the founders themselves to get out of the building to gain

11
a deep, personal, firsthand understanding of their potential customers’ needs
before locking into a specific path and precise product specs. That’s the
difference between winners and losers. It’s also the Customer Development
process detailed in this book.

5.2 Method of Implementation

At first glance, the new-product introduction model outlined in the diagram
at right appears to be helpful and benign. It illustrates the process of getting a
new product into the hands of waiting customers. A new product moves from
development to customer testing (alpha/beta test), and using feedback from
this initial testing, the product engineers fix technical errors in the product
until the product launch date and first customer ship.
The new-product introduction model is a good fit for an existing company
where the customers are known, the product features can be specified upfront,
the market is well-defined, and the basis of competition is understood.
As for startups, a scant few fit these criteria. Few even know who
their customers are. Yet many persist in using the new-product introduction
model not only to manage product development but as a roadmap for finding
customers and setting the timing for the startup’s sales, launch, and revenue
plans. Investors use the new product introduction diagram to set and plan
to fund. All parties involved in the startup use a roadmap leading toward a
very different location, yet they’re surprised to end up lost.

Figure 5.2: implementation

Concept and Seed Stage

At the concept and seed stage, founders capture their passion and vision
for the company, sometimes on the back of a napkin, and turn them into
a set of key ideas, which becomes the outline for the business plan. Next,
issues surrounding the product are defined. What is the product or service

Department of Information Technololgy 12

concept? What are the product features and benefits? Can it be built? Is
further technical research needed? Who will the customers be, and where will
they be found? Statistical and market research and a few customer nterviews
fuel the evaluation and business plan.
This step also brings forth the first guess at how the product will ultimately
reach the customer, including discussions of competitive differences, distribution
channels, and costs. An initial positioning chart explains the company and
its benefits to venture capitalists or corporate higher-ups. The business plan
now gets market size, competitive and financial sections, with an appendix
containing Excel spreadsheets forecasting revenue and expenses. Creative
writing, passion, and shoe leather combine in the concept and seed phase in
hopes of convincing an investor to fund the company or the new division.
Product Development
In stage two, product development, everyone stops talking and starts
working. The respective departments go to their figurative corners as the
company begins to specialize by function. Marketing refines the size of the
market defined in the business plan and begins to target the first customers. In
a well-organized startup (one with a fondness for the process), the marketing
folk might even run a focus group or two on the market they think they’re
in and work with Product Management on a market requirements document
(MRD) for engineering to specify the product’s final features and functions.
Marketing starts to build a sales demo, writes sales materials (websites,
presentations, datasheets), and hires a PR agency. In this stage, or by alpha
test, the company traditionally hires a VP of Sales.
Meanwhile, Engineering focuses on specifying and then building the product.
The simple box labeled ”Product Development” typically expands into a
”waterfall” or ”spiral” or incremental process of interlacing steps, all focused
on minimizing the development risk of a defined feature set (Figure 1.2). This
process starts with the founder’s vision, which may be expanded into an MRD
(and a product requirements document), and expands further into detailed
engineering
Alpha/Beta Test
In stage three, the alpha/beta test, Engineering continues building along

Department of Information Technololgy 13

with the classic waterfall development model, working toward the first customer
ship date. And, by beta test time, working with a small group of outside
users to test the product and ensure that it works as specified. Marketing
develops a complete marketing communications plan, sets up the corporate
website, provides Sales often causes huge engineering waste, with hundreds of
hours of work tossed aside, or tons of code cut and dropped to the floor,
when customers say the new features aren’t ones they care about. Ironically,
startups were often crippled by the very methodology they traditionally used
to build new products.
Focus on Launch Date
The traditional product introduction model focuses engineering, sales and
marketing on the all-important, immovable launch date. Marketing tries to
pick an ”event” (trade show, conference, blog, etc.) where they can ”launch”
the product. Executives look at that date and the calendar, working backward
to ignite fireworks on the day the product is launched. Neither management
nor investors tolerate ”wrong turns” that result in delays. In fact, traditional
engineering schedules have test cycles with the names alpha, beta, and release
but rarely allow time to improve the product. They’re still geared to putting
out the original product with minimal bugs, though.
The product launch and first customer ship dates are merely the dates when
a product development team thinks the product’s first release is ”finished.”
It doesn’t mean the company understands its customers or how to market or
sell to them, yet in almost every startup, ready or not, departmental clocks
are set irrevocably to ”first customer ship.” Even worse, a startup’s investors
are managing their financial expectations by this date as well. The chorus
of investor voices says, ”Why, of course that’s what you do. Getting the
product to market is what sales and marketing people do in startups. That’s
how a startup makes money.” This is deadly advice. Ignore it. Focusing only
on launch results in a ”fire, ready, aim” strategy that ignores the customer
discovery process -a fundamental and generally fatal error. Obviously, every
startup or company wants to get a product to market and sell it, but that
can’t be done until the company understands who it’s selling to and why

Department of Information Technololgy 14

they’ll buy. The forced march ignores the iterative loo that says, ”If our
assumptions are wrong, maybe we need to try something different.” It shuts
off the ”build, test and learn” flow and assumes

5.3 Output Screens

Figure 5.3: Home Page

Department of Information Technololgy 15

 Figure 5.4: Client Request

Figure 5.5: Client login

Department of Information Technololgy 16

 Figure 5.6: Instructions to client

Figure 5.7: database

Department of Information Technololgy 17

 CHAPTER 6

TESTING RESULTS

6.1 Overview of testing

Testing:
An estimate says that 50 percent of whole software development process
should be tested. Errors may ruin the software from critical level to its
own removal. Software testing is done while coding by the developers and
thorough testing is conducted by testing experts at various levels of code
such as module testing, program testing, product testing, in-house testing and
testing the product at user’s end. Early discovery of errors and their remedy
is the key to reliable software.

6.2 Dimensions of testing

Unit testing:
Unit testing involves the design of test cases that validate that the internal
program logic is functioning properly, and that program inputs produce valid
outputs. All decision branches and internal code flow should be validated. It
is the testing of individual software units of the application .it is done after
the completion of an individual unit before integration. This is a structural
testing, that relies on knowledge of its construction and is invasive. Unit tests
perform basic tests at component level and test a specific business process,
application, and/or system configuration. Unit tests ensure that each unique
path of a business process performs accurately to the documented specifications
and contains clearly defined inputs and expected results.

18
6.3 Testcases

Figure 6.1: testcases

Department of Information Technololgy 19

 CHAPTER 7

Conclusions and Future Scope

Hence, We developed a website that consists of form, client login,etc. The

client has to provide all the necessary details of the project on our website such
as problem statement, the domain of the project, under which organization it
is going to be implemented, under which sector(public/private) it falls, and
some personal details of the client for further communications.
After the client provides the information, we will verify and respond to
the clients by providing the client login. The client can address the queries
at any time on the website.we can extend this project by providing complete
help to the clients from beginning to the end of the project.

20
 REFERENCES

[1] Akitsu Oe and Hitoshi Mitsuhashi. “Founders’ experiences for startups’

fast break-even”. In: Journal of Business Research 66.11 (2013), pp. 2193–
2201.
[2] David Faitelson and Shmuel Tyszberowicz. “UML diagram refinement
(focusing on class-and use case diagrams)”. In: 2017 IEEE/ACM 39th
International Conference on Software Engineering (ICSE). IEEE. 2017,
pp. 735–745.

21