Sepfinal1 Odt

SOFTWARE ENGINEERING LABORATORY 18MCA39
Garments management
MCA-VTU DSCE Page 1 of 136

1. EXECUTIVE SUMMARY
The project is designed for garments to maintain the database of service provided to
customer and details of stock of product. They were maintaining the bills, stocks, customer
details in the form of paper document.
Here we are providing the application in the form of software so that they can
maintain the database of purchase, stocks, customer details in the application we
provided so that it becomes easy to access the details of transactions as the owner needs.
1.1.Issue.
Depend on website text and images — We cannot physically see or touch the
merchandise, so it can be difficult to determine things like quality and fit.
Security concerns — It can be difficult to tell if the website is secure. If the site is
not secure or is fraudulent—we can potentially open ourselves up to identity theft.
Privacy concerns — If a site doesn’t have a comprehensive privacy policy, it is

impossible for us to know who has access to our information, and whether our
information is protected or shared with third parties. Information sharing could lead
to spam, or even identity theft.
1.2.Anticipated Outcomes
24-hour-shopping — On the Internet stores never close so we can shop when it’s
convenient for us and browse as long as we like. Save time — It helps in save our
time in driving across town, searching for parking, or standing in line to pay for our
purchases. Shop from the comfort of your home — We can shop while relaxing on
our couch, even when the weather or traffic is bad. And we don’t have to worry about
crowds of people at the mall. Comparison shop — It’s easy to do comparison
shopping online and learn from product reviews written by other shoppers. More
variety — We can see an endless variety of products and services available online.
The items we find on just a few websites can far outnumber what is available in local
stores. we can even shop globally without leaving our home.
1.3.Recommendation
Online shopping becomes relevant in the last decade. The kind of business online
retailer are doing is proof enough that they are providing some benefits to customer
which offline shopping does not give to the customer. The approach described herein
allows us to meet our corporate objectives of continuously improving efficiency,

reducing costs, and capitalizing on technology. The recommended Mix-cart will

methodically migrate the data and functions of our current mainframe system to our
new web-based platform in order to preserve data integrity and it allows the
customers to be familiar with their products. The web-based platform is compatible
with all other current IT systems and will improve the efficiency and accuracy of
delivering the products to . Some of the ways that this technology will achieve its
desired results are:
 User will be able to enter and give their feedback at any time from any location
instead of phoning their data to their developer for entry into the mainframe
system
 Feedback and that data will be immediately accessible for error control and
feedback purposes which will reduce the need for good and quality products in
this website positions to gather, analyze and compile data
 User will have the ability to register for website which reduces the problem to
developer and users
1.4.Justification
 This system provides a brand new application which makes communication in daily
life easy.
 The system provides facilities of SMS, email, notifications, to-do-list, and various
other features which give the user a user friendly interactive communication. The
system provides high security, data storage. Theft of information and misusage of
user’s account is not possible.
 This creates a feeling of secured and safe communication in the users mind.
2. BUSINESS CASE ANALYSIS TEAM
The following individuals comprise the business case analysis team. They are responsible
for the analysis and creation of the Mix-cart Project.
Role Description Name/Title
Technology Support Provides all technology support VP Information Technology

for the project
Process Improvement Advises team on process Process Team Lead

improvement techniques
Project Manager Manages the business case and Project Manager

project team
Software Support Provides all software support for Software Group Lead
the project

3. PROBLEM DEFINITION
3.1.Problem Statement.
Since its inception, We Consulting has relied upon a mainframe system to manage
online ordering and other product details, payment details. As the online ordering
grows, so does the burden placed upon admin to effectively manage the web site
administration at acceptable levels. In the we Consulting has and take help of friends
to help manage and run the day to day web site operations. They do nothing to
improve the management of the web site administration. Additionally, friends must
currently call their other friends to enter their work hours and raise any concerns
regarding payroll and administrative tasks. This places a large burden on admin who
much products these requirements with their day to day new products.
Reporting is another problem area associated with the legacy mainframe system. All
weekly and monthly financial reports or feedback must be generated manually which
allows for a high probability of error and require significant amounts of time. These
manual tasks further add to the burden and expense of the web site or Mix-cart.
3.2.Organizational Impact
The following provides a high-level explanation of how the organization, tools,

processes, and roles and responsibilities will be affected as a result of the Mix-cart
Project implementation:
Tools: the existing legacy administration platform will be phased out completely as
the garments managemnt Project is stood up and becomes operational. This will
require training buyers on the Mix-Cart tools and their use in support of other
organizational tools.
Processes: with the Mix-cart Project comes more efficient and streamlined
administrative and payroll processes. This improved efficiency will lessen the
burden on admin and provide autonomy to buyers in managing their administrative
and payroll tasks and actions.
Roles and Responsibilities: in addition to the Mix-cart Project allowing greater

autonomy to buyers and fewer burdens on admin, the manpower required to
appropriately staff human resources and payroll departments will be reduced. While
we greatly value our buyers, The new platform will be managed by the IT group and
we do not anticipate any changes to IT staffing requirements.

Hardware/Software: in addition to the software and licensing for the project, We

Consulting will be required to purchase additional servers to accommodate the
platform and its anticipated growth for the next 10 years.
3.3.Technology Migration
In order to effectively migrate existing data from our legacy platform to the new
Web-based platform, a phased approach has been developed which will result in
minimal/no disruption to day to day operations, administration, and payroll activities.
The following is a high-level overview of the phased approach:
Phase I: Hardware/Software will be purchased and the Mix-cart system will be

created in the web-based environment and tested by the IT development group.
Phase II: IT group will stand up a temporary legacy platform in the technology lab
to be used for day to day operations for payroll and administration activities. This
will be used as a backup system and also to archive all data from the web site
mainframe.
Phase III: The web-based platform will be populated with all current payroll and
administrative data. This must be done in conjunction with the end of a pay cycle.
Phase IV: All buyers will receive training on the new web-based platform.
Phase V: The web-based platform will go live and the legacy mainframe system will
be archived and stood down.
4. PROJECT OVERVIEW
This Project overview provides detail for how this project will address we Consulting
garments problem. The overview consists of a project description, goals and objectives
for the Mix-cart Project, project performance criteria, project assumptions, constraints,
and major milestones. As the project is approved and moves forward, each of these
components will be expanded to include a greater level of detail in working toward the
project plan.
4.1.Project Description
Online clothes shopping system In today’s busy world, people don’t have time for
their personal needs. And the technology is so fast that anyone can do anything by

just sitting in a room. The internet is the way that helps a person in all aspects. If
someone wish to buy and view things, he can buy online with the help of internet.
Today there are very least organizations which are manual.

Everything is going to be computerized and online whether it is banking, advertising
or shopping. We are trying to help people to make their life easier by proving online
clothes shopping. In this we have introduced many modules like admin module and
customer module. The customers have to register for any enquiry related to clothes.
The unregistered person can’t access this application. The registered customer can
view details of clothes and he can buy of his choice and need. He has to pay the price
of cloth. The admin module contains the access of admin on the application. The
admin can change everything in the application. He has the ability to add, delete,
update any information regarding the clothes. The project’s home page includes the
registration link. The registered users can login to their account for their queries or
buy new clothes. And the unregistered users have first to register. The registration
can be done by following the sign up link.
4.2.Goals and Objectives
The Mix-cart Project directly supports several of the corporate goals and objectives.
The following table lists the business goals and objectives the Mix-cart Project
supports and how it supports them:
Business Goal/Objective Description

Timely and accurate Delivery of products to ordered customer is accurate and
reporting it saves the time of user.
This is a web based application which helps people to
User friendly find and buy latest things with different functionalities on
internet. It is useful in the way that it makes an easier way
to buy things online.
Reduce overhead costs User can get amazing discounts and cash backs.
4.3.Project Performance
Prototyping, in some form or another, should be used all the time. However,
prototyping is most beneficial in systems that will have many interactions with the
users. It has been found that prototyping is very effective in the analysis and design
of on-line systems, especially for transaction processing, where the use of screen
dialogs is much more in evidence. The greater the interaction between the computer
and the user, the greater the benefit is that can be obtained from building a quick
system and letting the user play with it.Systems with little user interaction, such
as batch processing or systems that mostly do calculations, benefit little from

prototyping. Sometimes, the coding needed to perform the system functions may be
too intensive and the potential gains that prototyping could provide are too small.
4.4.Project Assumptions
E- Commerce is the next logical step for Indian merchants. With the growth of mobile
phones and increased issuing and use of debit and credit cards, mobile commerce will
deliver strong growth over the coming years. Mobile technology gives us the edge over
our competitors. First Data’s mobile commerce solutions can help businesses meet the
growing demands of the mobile and social media revolution. Social media networks
such as Face book are likely to increasingly become channels for sales and consumer
engagement. First Data already offers a loyalty solution for the Face book social media
network as well as mobile payments opportunities using our Trusted Service Manager
(TSM) service, which powers part of the Google Wallet which has made headlines
recently. With Google Wallet, millions of consumers will no longer need to carry their
leather wallets. This mobile application securely stores credit cards, offers, gift cards
and more on their mobile phone. This virtual wallet is changing the face of commerce
by enabling customers to simply make “tap and go” payments with their mobile
devices, while increasing loyalty at merchant locations. New and exciting developments
in India will enable our merchants to attract new tech savvy customers who are ready to
use their mobile devices for secure online transactions.
4.5.Project Constraints
.
Mandated constraints. Some online shopping websites and recommender systems
provide outcomes based on their alternatives. However, their prices do not always match a
clients budget. When a client is interested in purchasing a new product, he or she may
access the internet to find it. Nevertheless, some online shopping websites and
recommender systems may not offer clients and consumers the products that meet their
preferences. Clients and consumers may become upset or dissatisfied, especially if the
system is not easy to use. Clients and consumers do not want to face difficulties when
purchasing a product or waste time searching through websites. Even the options some
websites offer do not necessarily match client or consumer preferences or requirements.
4.6.Major Project Milestones
The following are the major project milestones identified at this time. As the project
planning moves forward and the schedule is developed, the milestones and their
target completion dates will be modified, adjusted, and finalized as necessary to
establish the baseline schedule.

Milestones/Deliverables Target Date

Project Charter 01/03/2018
Project Plan Review and Completion 03/04/2018
Project Kickoff 03/04/2018
Phase I Complete 04/05/2018
Phase II Complete 06/05/2018
Phase III Complete 08/05/2018
Phase IV Complete 10/06/2018
Phase V Complete 12/07/2018
Closeout/Project Completion 12/07/2018
5. STRATEGIC ALIGNMENT
The Project is in direct support for online shopping. By directly supporting these strategic
plans, this project will improve our business and help move the customers shopping into
next level
Plan Goals/Objectives Relationship to Project
Strategic Plan for Improve record This project will allow for real-time
Information keeping and information and increased information
Management information accuracy
management
A complete and
efficient web
application which New technology will allow many payroll
Strategic Plan for can provide the and administrative functions to be
application management online shopping automated reducing the levels of staff
experience is the required to manage these systems
basic objective of
the project.
6. COST BENEFIT ANALYSIS.
Costs should include direct and indirect costs, intangible costs, opportunity costs, and the
cost of potential risks. Benefits should include all direct and indirect revenues and
intangible benefits, such as increased production from improved employee safety and
morale, or increased sales from customer goodwill.

The final step is to compare the results of the aggregate costs and
benefits quantitatively to determine if the benefits outweigh the costs. If so, then the
rational decision is to go forward with the project. If not, the business should review of
the project to see if it can make adjustments to either increase benefits or decrease costs to
make the project viable. Otherwise, the company may abandon the project.
7. ALTERNATIVES ANALYSIS
The following alternative options have been considered to address the business problem.
These alternatives were not selected for a number of reasons which are also explained
below.
Action Description First year costs

Type (- indicates
Action
anticipated
savings)
Purchase Web-based
Cost Initial investment for WP Project 40,000.00
product and licenses
Cost for IT group to install new
Software installation and
Cost software and for the training 10,000.00
training
group to train all employees
An immediate reduction in
Reduce HR and payroll overhead equal to the annual
Savings -8,395.00
staff by 5 employees salary of 3 HR specialists and 2
payroll analysts.
18 regional managers currently
Managers no longer average 16 hours per week non-
required to work non- billable time. It is anticipated
Savings -4,744.00
billable payroll and that this number will be reduced
administrative tasks to no more than 2 hours per
week.
Less frequent use of IT resources
System maintenance
working on non-value added
required every 6 months Savings -4,200
tasks results in approximately
instead of monthly
4200 savings per year.

Action Description First year costs

Type (- indicates
Action
anticipated
savings)
Savings in cost to out-process
exiting employee and recruit,
Reduce employee
Savings hire, and train new employees is -5,000
turnover by 10%
approximately 5,000 in the first
year.
Net First Year Savings 27,361.00
8. APPROVALS
The signatures of the people below indicate an understanding in the purpose and content
of this document by those signing it. By signing this document you indicate that you
approve of the proposed project outlined in this business case and that the next steps may
be taken to create a formal project in accordance with the details outlined herein.
Approver Title Signature Date

Name
Prof.Rakshita Project guide

1.2 FEASIBILITY STUDY

1. EXECUTIVE SUMMARY
.
This feasibility study of Online Shopping: The proposed system for the above discussed
existing system easily provides a solution to the biggest problem of going global and still
not opening the stores in all parts of the world with the local product through the site’s
website. Maintenance and addition of further features are also cost effective in terms of
the profits obtained. In addition the site also provides several features for the
administrators and for the Newsletters of the new products.
2. DESCRIPTION OF PRODUCTS AND SERVICES
The growing use of Internet in India provides a developing prospect for online shopping. If E-marketers
know the factors affecting online Indian behavior, and the relationships between these factors and the type
of online buyers, then they can further develop their marketing strategies to convert potential customers
into active ones, while retaining existing online customers .This project is a part of study, and focuses on
factors which online Indian buyers keep in mind while shopping online. This research found that
information, perceived usefulness, ease of use; perceived enjoyment and security/privacy are the five
dominant factors which influence consumer perceptions of Online purchasing. Consumer behavior is
said to be an applied discipline as some decisions are significantly affected by their behavior or expected
actions. The two perspectives that seek application of its knowledge are micro and societal
perspectives. The online purchasing behavior of online shoppers and factor influencing online
shopping behavior and its future perspective. Internet is changing the way consumers shop and buy goods
and services, and has rapidly evolved into a global phenomenon. Many companies have started using the
Internet with the aim of cutting marketing costs, thereby reducing the price of their products ahead in
highly competitive markets .and services in order to stay.
3. TECHNOLOGY CONSIDERATIONS
Upgraded technological capability will be required for mix-cart to move toward offering
an on-line marketplace from which customers may purchase our products. Customers
demand a simple and easy way by which to conduct on-line transactions and it is
imperative that all transactions are conducted in a secure manner. While Mix- cart
maintains a web site with product lists and descriptions, it does allow for purchasing to
be done on-line. This functionality must be integrated with our current web site to allow
for secure purchases to be made. Additionally, new on-line marketing functionality must
be considered in order to target existing and potential customers through methods such as
e-mailing lists, promotional advertisements, and loyalty discounts.
While Mix- cart maintains a small information technology (IT) group, the expertise does
not currently exist internally to design, build, and implement the sort of extensive on-line
platform required for this effort. Therefore, the recommendation is to contract this work
out to an Internet marketplace provider who can work with Mix- cart to meet its needs
within the determined time frame and budget. It should be noted that while Mix- cart

does not have this expertise internally, the technology exists and is in use throughout the
marketplace which lowers the risk of this concept considerably.
4. PRODUCT/SERVICE MARKETPLACE
The on-line marketplace for chocolates and confections has been thriving for many years.
In 2018 on-line chocolate sales accounted for approximately $20 million or 20% of total
chocolate sales worldwide. While online shopping are available in almost every store,
our primary marketplace consists of specialty Mix-cart. All of Mix-cart current major
competitors already have an established on-line presence of at least 3-5 years. The top 3
competitors are currently: Mix-cart, Worldwide . A large majority of Mix-cart customer
base are returning customers and referrals from existing customers. By providing a more
convenient means of purchasing our products on-line it is expected that we will retain
these customers while conducting an on-line marketing campaign for new customers as
well.
5. MARKETING STRATEGY
In order to be successful, Mix- cart must differentiate itself from competitors in order to
appeal to customers in the on-line marketplace. To do this, Mix- cart will utilize its
practice of personalizing its product packaging which it currently offers in-store
customers. Current competitors do not currently provide any personalization of
packaging. Customers will have the ability to personalize messages on or inside of
product packaging, request specific color-based themes, or tailor packaging for special
occasions or events.
Will implement a customer e mailing list in order to send product promotions, sales
advertisements, and other special offerings to customers who register. Additionally, ABC
will offer referral incentives to customers who refer our products to friends and family in
order to provide additional incentives. Mix- cart will also maintain a customer database
in order to determine its target customer groups and geographical regions. Mix- cart will
research marketing intelligence providers to determine the benefits and costs of
purchasing customer information for bulk email campaigns as well. Another important
consideration of Mix-cart's on-line marketing strategy is cost. Electronic marketing
communication costs are very small in comparison to direct mail marketing which Mix-
cart currently utilizes. However, we expect the additional revenue from on-line sales to
greatly outweigh these additional electronic marketing costs.

6. ORGANIZATION AND STAFFING
The Mix-cart on-line sales campaign is not anticipated to significantly affect the
organizational structure of the company. There are, however, several staffing additions
required to successfully implement the on-line sales campaign.
Staffing Position #1: On-line Ideator– this full time position will lead sales staff in
identifying sales opportunities and converting these opportunities to actual sales. This
person will report to Mix-cart’s Director of Sales and will work in Mix-cart headquarters.
Staffing Position #2: On-line Customer service executive officer– Customer feedback
refers to the opinions customers share with you about your product, service, and/or the
overall experience they’re having with your business.
7. SCHEDULE
The Mix-cart on-line sales campaign is expected to take six months from project approval
to launch of the e-commerce platform. Many of the foundations for this platform, such as
high-speed internet and web server capability, are already available. The following is a
high level schedule of some significant milestones for this initiative:
Jan 6, 2018: Initiate Project
February 20, 2018: Project kickoff meeting
March 7, 2018: Complete on-line sales site design
April 25, 2018: Complete testing of on-line sales site
may 15, 2018: Complete beta testing trials of on-line sales site
July 21, 2018: Go live with site launch
Upon approval of this project a detailed schedule will be created by the assigned project
team to include all tasks and deliverables.
8. FINANCIAL PROJECTIONS
The financial projections for the addition of an on-line sales platform for Mix-cart are
highlighted in the table below. These figures account for projected on-line sales,

additional staffing requirements, shipping, material, and insurance costs, contract support
for IT and training needs, and web server and hosting costs.
The assumptions for these projections are as follows:
 In store sales projections remain unchanged

 All milestones are performed in accordance with the schedule
 All transactions are closed yearly with no carry-over to subsequent years
9. FINDINGS AND RECOMMENDATIONS
Based on the information presented in this feasibility study, it is recommended that Mix-
cart approves the on-line sales initiative and begins project initiation. The findings of this
feasibility study show that this initiative will be highly beneficial to the organization and
has a high probability of success. Key findings are as follows:
Technology:
 Will utilize existing technology which lowers project risk

 E commerce infrastructure will be contracted out to vendor which allows ABC to
share risk
 Once in place this technology is simple to operate and maintain for a relatively low
cost

Marketing:
 This initiative will allow Mix-cart to reach large number of target groups
electronically at a low cost
 ABC can expand customer base beyond geographic areas where stores are
currently located
 The marketplace for on-line chocolate and confection sales is in a steady state of
growth
 ABC is able to differentiate itself from its competitors and will utilize incentive
programs to target new consumers
Organizational:
9. Minimal increases to staffing are required with no changes to organizational

structure
10. No new facilities or capital investments are required
Financial:
 Breakeven point occurs early in the second year of operation

 Five year projections show on-line sales accounting for 25% of total sales
 Mix-cart will be in position to capture greater market share by maintaining both
an in-store and on-line presence

PROJECT TEAM DESCRIPTION

PROJECT:
PREPARED BY: <ABHILASH S B, ABHISHEK M L>
PROJECT PERIODS (weeks, months, etc.)
(Shade in periods of staff/volunteer availability)
Week 1 2 3 4 5 6 7 8 9 1 11 1 1 14 15
0 2 3
Initial study
Software
installation
Database
creation
Design
Coding
Testing
Reporting
Outstanding staff/volunteer issues:
Next steps:
DATE: <04, APRIL, 2017>

Resource Plan©
For intra college information communication system
Document Control
Document Information
© Information
Document Id 5258
Document Owner Abhishek M L
Issue Date 10-04-2018
Last Saved Date 29-05-2018
File Name Business case
Document History
Version Issue Date Changes

[1.0] 07-03-2018 Page 12
Document Approvals
Role Name Signature Date ©
Project Review Group

ghhjviji Abhilash S Bale 03003-03-2018
Project Manager.
030Prof.Rakshitha 03003-03-2018
Communications Manager
(if applicable) 030Dr.Samitha 03003-03-2018
Project Office Manager

(if applicable) 030Dr.Suma 03003-03-2018

Template Guide
What is a Resource Plan?
A Resource Plan identifies the physical resources required to complete the project. A typical
Resource Plan includes:
 A list of the types of resources (labour, equipment and materials) required

 A schedule outlining when each of the resources is required to be utilized
 An assignment of each resource to a set of activities to be completed.
To create a Resource Plan, the following steps are undertaken:
 List the general types of resources to be utilized on the project

 Identify the number of resources and purpose of each type of resource
 Identify when the resources are required by completing a ‘Resource Schedule’ table
 Allocate the resources to project activities by completing a ‘Resource Usage’ table. ©
When to use a Resource Plan
A Resource Plan is typically developed towards the end of the Project Planning phase, after
the Work Breakdown Structure (WBS) has been identified. Although summarized resource
information may be described within the communication system, Feasibility Study, Terms of
Reference or Project Plan, a detailed Resource Plan cannot be created until every activity and
task within the Project Plan has been identified.
Following the completion of the Resource Plan, it will be possible to finalize the
communication between client and admin of the project will have been identified. ©
How to use this template
This document provides a guide on the topics usually included in a Resource Plan. Sections
may be added, removed or redefined.. Example tables, diagrams and charts have been added
(where suitable) to provide further guidance on how to complete each relevant section.
1. Resource Listing
This section identifies the types and numbers of resources required to complete the project. A
‘resource’ is typically defined as the labour, equipment and materials used to complete the
activities in the Project.

1.1 Labour
List all of the roles, responsibilities and skill-sets required by completing the following table:
Role No. Responsibilities© Skill-Set Start End Date

Date
Project 1 Deliver the approved solution which meets Time 01-01- 30-05-2018
Manager the requirements of the user. Management 2018
Quality
Management
People
Management
Project lead 2 Day to day running of development effort. People 01-01- 30-05-2018
Management 2018
Team 3 The priority is to carry out the tasks Time 01-01- 30-05-2018
member assigned. Management 2018
Note:
 All roles within the project should be listed here
 The No. represents the number of full-time equivalent people required for the role
 Only a summary of the Responsibilities and Skill-Sets is required.
 The Start-Date and End-Date outline the timeframes for which the role is required. ©
1.2 Equipment
List all of the items of equipment required to undertake the project, including computers, building
facilities and vehicles. Each item of equipment should be defined by outlining its purpose,
specification and period required by completing the following table.
Item No Purpose © Specification Start End Date

. Date
Computer 15 To enable the project team to plan, monitor and High processing 20-01- 12-03-
control the project speed 2018 2018
60 gig disk space
19 inch monitor
2222
Buildin To communicate with client. 20-01- 12-03-

2222
g To
2018 2018
facility
1.2Materials

List all of the generic materials required to undertake the project, including stationery,
computer consumables, building materials, power, water and gas. Each material item should
be defined by outlining its components and period of required use. Complete the following
table.
Item Components© Amoun Start End Date

t Date
Computer Printer No. 22-01- 01-02-

Consumables cartridges 2018 2018
Printer paper
Disks for
backup
Power n No 22-01- 01-02-
Used for
2018 2018
projector
Water To drink No 22-01- 01-02-

2018 2018
2. Resource Plan
2.1 Schedule
Now that the resource types have been listed, we need to identify when each of these
resources is required for the project. A detailed Resource Plan will list the specific resources
required for every day of the project. For simplicity, the following example lists the resources
required on a monthly basis.
Month
Resource Jan Feb Mar Apr May Jun Total
Labour
 Project Manager No. Yes. No. yes yes Yes
.
Equipment yes
 Computer Yes No Yes No. Yes
 Equipment Type
yes Yes No yes yes No

Materials
 Printer
Cartridges
 Material Type

Once the number of resources allocated to the project (each month) have been listed above, it is then
possible to verify the total number of each type of resource allocated to the project for its entire
duration as well as per month.©
2.2 Usage
It is also important to identify which activities the resources will be allocated against during
the project. A detailed Resource Plan will define the activities which each resource will
undertake for each ‘day’ on the project. For simplicity, the following example provides a
listing of the activities which each resource will undertake, on a ‘monthly’ basis.
Month
Activity Jan Feb Mar Apr May Jun

yyy yes yes yes yes yes yes
Initiation
 Appoint Project Team
 Activity
No yes yes No yes yes

Planning
 Develop Quality Plan
 Activity
No No yes yes yes No

Execution
 Build Deliverables
 Activity
No No No yes yes Yes

Closure
 Customer Sign-off
 Activity
2.3 Assumptions
List any assumptions made during this Resource Planning exercise. Examples include:
It is assumed that the:
 Project delivery dates will not change during this project

 Resource requirements will not change during this project
 Resources identified will be available as required. ©
2.4 Risks

List any risks identified during this Resource Planning exercise. Examples include:
 That key staff resign during the project

 That further training is required to complete the tasks allocated.
3 Appendix
Attach any documentation you believe is relevant to the Project Plan. Examples include:
 Other project documentation (Business Case, Feasibility Study, Terms of Reference,

Project Plan)
 Organizational HR policies, guidelines and procedures
 Job descriptions for project roles
 CVs (Curricula Vitae) for project staff
 Other relevant information or correspondence. ©

Database Design Document
1 Purpose

The Database Design Document maps the logical data model to the target database
management system with consideration to the system’s performance requirements. The
Database Design converts logical or conceptual data constructs to physical storage
constructs (e.g., tables, files) of the target Database Management System (DBMS).
1.1 Document Objectives
The Database Design Document has the following objectives:
 To describe the design of a database, that is, a collection of related data stored in one
or more computerized files that can be accessed by users or computer developers via
a DBMS.
 To serve as a basis for implementing the database and related software units. It
provides the acquirer visibility into the design and provides information necessary for
software development.
1.2 Intended Audience
This document is intended for the following audiences:
 Technical reviewers, who must evaluate the quality of this document.

Developers including:
o Architects, whose overall architecture design must meet the requirements specified in
this
Document.
o Designers, whose design must meet the requirements specified in this document.
o Developers, whose software must implement the requirements specified in this
document.
o Quality Assurance personnel, whose test cases must validate the requirements
specified in this document.

1.3 Acronyms and Abbreviations
M
e
a
n
i
n
Acronym / Abbreviation g
RDMS R
e
l
a
t
i
o
n
a
l
D
a
t
a
b
a
s
e
M
a
n
a
g
e

m
e
n
t
S
y
s
t
e
m
D
a
t
a
b
a
s
e
A
d
m
i
n
i
s
t
r
a
t
o
DBA r

D
a
t
a
F
l
o
w
D
i
a
g
r
a
m
DFD s
1.4 Key Personnel
1.5 Data Owners
Type of Data Name Email Address Phone Number

Network Admin admin12345@gmail.com 7890453667
Relational Staff1 staff1@gmail.com 7654223138
Relational Staff2 staff2@gmail.com 8876531220
2 Assumptions, Constraints and Dependencies
2.1 Assumptions
when real money is on the line it could mean the difference between a successful delivery or
ultimate failure of a project. It also shows you understand what needs to be delivered,
demonstrates that you have thought about all facets of the problem and shows that you know
many of the internal and external factors influencing the delivery of the project and can
work around them.
2.2 Constraints
 If a database is to be used, consideration of the record keys necessary to

organize and view the assumptions by owner, by project task, by priority, by
review date or by similar requirement may be required.
2.3 Dependencies
A related application is password verification. Passwords are usually not n clear text, but
instead in digest form, to improve security. To authenticate a user, the password presented
by the user is hashed and compared with the stored hash. This also means that the original
passwords cannot be retrieved if forgotten or lost, and they have to be replaced with new
ones.
3 System Overview
3.1 Database Management System Configuration

3.2 Database Software Utilities
3.3 Support Software
Vendor Product
SQL Queries

4 Architecture
4.1 Hardware Architecture

4.2 Software Architecture
TOP LEVEL DFD FOR PROPOSED SYSTEM:
4.3 Data stores

5. Database wide design decisions
5.1 Interfaces
5.2 Key Factors Influencing Design
A. Functional Requirements :
o The system should be giving minimal and relevant data only to the
users.
o Digital storage of data should be secure, always available and
persistent.
o Admin manages the overall communication system.
B. Non-Functional Requirements:
o Cost of storage and maintenance should be affordable.
o Ease of use should be high.
o Portability: It is portable because it can be used both in Linux and
Windows Operating System.
o Reliability: Accurate feedback is provided.
o Availability: The portal should be available for any number of
systems.
o Security: Authenticated students can fill the feedback.
5.3 Behaviour

Hash algorithms are used to provide information security services. A hash algorithm accepts
a random block of data given by the user encodes it and returns a fixed-size bit string which
is called the hash value, so if the user modifies the same block of data later then it will
simultaneously change its hash value. The encoded data is called "Message" and their hash
value is termed as "Message Digest". SHA1 Description SHA1 is a hashing algorithm
designed by the United States National Security Agency and published by NIST (National
Institute of Standards and Technology). It can have maximum message size of 264 - 1 bits
however it accepts 512 bit block size and outputs 160- bit message digest.
5.4 DBMS Platform
5.5 Security and Availability
The traditional communication uses the internet facility for communication. User can
communicate using Personal computers and laptops. Availability of internet connection is
the most important factor for the users. For eg:-two people chatting on Gmail require to be
having internet connection. Security is major concern. Hackers and illicit users can obtain
password and other important information.
5.6 Distribution

5.7 Backup and Restore Operations
We can see are these options:
 Backup name: the default format is DBName-Backup Type-BackupRunDate

 Recovery model: this shows the recovery model of the database for which we want
to take the backup.
 Backup type: This shows the available database backup options for the database. For
example, in Simple recovery model, only Full and Differential backups are available,
so it only shows these 2 backup options.
 Copy-only backup: If we want to take a copy-only backup, tick this option to
execute a copy-only backup.
 Backup files: It shows the backup location as the default backup directory. If we
want to change it, click the "-" icon below to remove this backup location and then
the "+" icon to add the file into the desired location.
5.8 Maintenance

Web service is a software system designed to support interoperable machine-to-machine

interaction over a network. One of the most interesting features of a web service is that they
are self-describing. This means that once a web service is located we can ask it to describe
itself and tell what operations it supports and how to invoke it, which is handled by the Web
Service Description Language (WSDL). Other systems interact with the Web service in a
manner prescribed by its description using SOAP messages, typically conveyed using HTTP
with an XML serialization in conjunction with other Web-related standards".
5.9 Performance and Availability Decisions
communicate using Personal computers and laptops. Availability of internet connection is the
most important factor for the users. For eg:-two people chatting on Gmail require to be
having internet connection. Security is major concern. Hackers and illicit users can obtain
password and other important information.
6 Database Administrative Functions
6.1 Responsibility
Role Name Responsibility Email Address

Database Prof. Mahendra Administration abc@gmail.com
administrator
System Prof. Suchitha System functioning xyz@gmail.com
administrator
Security Prof. Divya Security issues pqr@gmail.com
Administrator
6.2 Database Identification

6.3 Application / Systems Using the Database
6.4 Relationship to Other Databases
This Database Supersedes This Database
None
6.5 Schema Information

6.6 Schema Description

6.7 Physical Design
The physical design of your database optimizes performance while ensuring data
integrity by avoiding unnecessary data redundancies. During physical design, you transform
the entities into tables, the instances into rows, and the attributes into columns.
6.8 Physical Structure
Physical structure is used in everyday environments and helps people to know what to
expect, it provides meaning to the environment.

6.9 Entity Mapping
 EJB development--You can use UML diagrams to design the entity beans, and the
cardinality and direction of the relationship between each bean, from the perspective
of the EJB objects.
 Database development--You can use ERD diagrams to design the database tables,
complete with the cardinality and direction designated by primary and foreign keys,
that support the entity beans. The focus is on how the database maps each entity bean
and the relationships between them.
6.10 Mapping Rules
You can define the following mapping rules for the fields:

Values:-
You use this rule to assign values to the mapped fields. Select the mapped field and assign
the possible values. You can enter these values from the tables, predefined values from a
domain, or the search help attached to the data elements.
Constant:-
You can use this rule to assign constant values to mapping fields that require all the business
partners to be created with a constant value irrespective of their corresponding entries in the
external list.
Code:-
You can maintain the ABAP code for the mapping fields that require data or value
conversion before they can be assigned to the appropriate fields during the creation of
partners.
6.11 Operational Implications
The results of this study indicate that building and maintaining positive relationships
between teachers and students will improve student engagement and motivation during
class. It was observed that students were engaged in fewer off-task behaviors during the
four-week intervention period. Although the study did not measure academic growth, it is
likely that because students were more engaged in the lessons and activities, they retained
more information and grew academically. Furthermore, the researcher noticed differences in
the attitudes and demeanors of the students. The students for whom the intervention was
intended were more likely to comply with directions and participate during class. These
students also came to class prepared and ready to learn. Students who engaged in off-task
behaviors such as sleeping, putting their head downs, playing on their cell phones, or
working on assignments for other classes, were more involved in 27 the material at hand.
These students were also more open and friendly with the teacher. At the start of the
intervention, the teacher took full responsibility for initiating greetings and conversation
with the students. As the intervention progressed, students also took responsibility for this
task. They greeted the teacher, asked polite questions about her day, and seemed genuinely
interested in her response.

6.12 Data Transfer Requirements
Data transfer is the process of using computing techniques and technologies to transmit or
transfer electronic or analog data from one computer node to another. Data is transferred in
the form of bits and bytes over a digital or analog medium, and the process enables digital or
analog communications and its movement between devices.
6.13 Data Formats
Each type of data is made up of a data source and (one or more) layers. These two
definitions apply to Map Server and OGR.
Data source - a group of layers stored in a common repository. This may be a file that
handles several layers within it, or a folder that has several files.
Layer - a sub-set of a data source often containing information in one type of vector format
(point, line, polygon).
There are three types of data mapping and GIS data formats. Each type is handled
differently. Below are the types and some example formats:
 File-based- Shape files, Micro station Design Files (DGN), GeoTIFF images
 Directory-based - ESRI ArcInfo Coverage’s, US Census TIGER
 Database connections - PostGIS, ESRI ArcSDE, MySQL

6.14 Business Rules
6.15 Storage
The Open Edge database engine stores all database fields and indexes in variable-length format and
does not store trailing blanks in character fields or leading zeros in numeric fields. The benefits
of this variable-length storage technique are:
Disk storage is reduced.
An application is easier to change since you can increase the maximum storage space for a
field without copying or restructuring the entire database. You can put more characters into
newly created records without affecting existing records.
6.16 Backup and Recovery
Backups protect a database from various kinds of failures. They are a set of procedures or methods to
recover a failed system or maintain normal system operation.
Tibero provides two methods to back up a database:
 Logical backups
Logical backups back up a database's logical units such as tables, indexes, and sequences. To
accomplish this, Tibero provides two utilities, tbExport and tbImport. For detailed information
about tbExport and tbImport, refer to TiberoUtility Guide.
 Physical backups
Physical backups back up a database's physical files, and are performed by copying files at the OS
level. The files that need a physical backup include data files and archived log files.
MCA-VTU DSCE [1DS17MCA03] Page 41 of 136

For online log files, this backup method is only useful when recovering the entire database after
backing it up in NOARCHIVELOG mode.
Recovery
 The process of recovering changes which have not been recorded in data files using logs.
Database stability can be maintained by recording all changes in logs to data files. In other words, the
database should apply all tasks by a certain time of operation and see no changes afterwards.
Any problematic database can be restarted only after it becomes stable through this normal recovery.
 The process of recovering data which has not been committed.
This is the process of recovering database changes that were made by uncommitted transactions when
the database failed.
7 Detailed Database Design
The overall objective in the development of database technology has been to treat data as an
organizational resource and as an integrated whole. DBMS allow data to be protected and
organized separately from other resources. Database is an integrated collection of data.

7.1 Data Software Objects and Resultant Data Structures
Data objects are the building blocks for the rule assets that you create. Data objects are custom data
types implemented as Java objects in specified packages of your project. For example, you
might create a Person object with data fields Name, Address, and Date Of Birth to specify personal
details for loan application rules. These custom data types determine what data your assets and
your decision service are based on.

They are used to collect data in a particular fashion. It all depends upon the structure. While array
stores multiple data of single type in a continuous way, structure stores heterogeneous data.
Queues are just array with a LIFO constraint, while Stacks are also array with FIFO principle.
Linked Lists are array of structure instances (At least in C/C++) While Objects are like structure
with behavior (methods), although you can have behavior for structure in C++.
7.2 Database Management System Files
The entity-relationship (ER) data model perceives the real world as consisting of basic objects, called
entities, and relationships among these objects. It was developed to facilitate database design by
allowing specification of an enterprise schema, which represents the overall logical structure of
a database. The E-R data model is one of several semantic data models; the semantic aspect of
the model lies in its representation of the meaning of the data. The E-R model is very useful in
mapping the meanings and interactions of real-world enterprises onto a conceptual schema.
Because of this usefulness, many database-design tools draw on concepts from the E-R model.

Use case Diagram:-

 UCs specify functional requirements
 Helps to understand the system in user perspective
 UCs specify functionality by describing interactions between actors and system
 Focuses on external behavior
 UCs are primarily textual
 UC diagrams show UCs, actors, and dependencies
 They provide an overview

Fig 1.7:
8 Reporting Requirements
Reporting Requirement
Background:
Reporting on project implementation and impacts is required to determine the extent to which the
Productive Ageing through Community Education (PAtCE) Program meets Commonwealth
desired outcomes. This reporting will facilitate timely, regular advice to governments.
The Final Report will be expected to include: • description, length and frequency of course(s)
delivered; • participant numbers • aggregated information collected from participants’ Course
Feedback Forms (see below) • feedback on the PAtCE Program as a whole, including details of
lessons learned in undertaking the project, and san indication of the extent to which activities
contributed to the Program’s objectives and outcomes.

Software Requirements Specification

Introduction
1. Purpose
This document is meant to delineate the features of OSS, so as to serve as a guide to the
developers on one hand and a software validation document for the prospective client on the
other. The Online Shopping System (OSS) for furniture shop web application is intended to
provide complete solutions for vendors as well as customers through a single get way using the
internet. It will enable vendors to setup online shops, customer to browse through the shop and
purchase them online without having to visit the shop physically. The administration module will
enable a system administrator to approve and reject requests for new shops and maintain various
lists of shop category. Document Conventions
Hardware Requirements
Processor : Pentium –IV or above
Speed : 1.2 GHz or above
RAM : 1 GB (min)
Hard Disk : 60 GB (min)
Software Requirements
Operating System: Windows

Front end : PHP
Back end : MySQL
Server : XAMPP/WAMP
Editor : Notepad++
Programming Language :PHP

2. Intended Audience and Reading Suggestions
Prototyping, in some form or another, should be used all the time. However, prototyping is most
beneficial in systems that will have many interactions with the users.
It has been found that prototyping is very effective in the analysis and design of on-line systems,
especially for transaction processing, where the use of screen dialogs is much more in evidence.
The greater the interaction between the computer and the user, the greater the benefit is that can
be obtained from building a quick system and letting the user play with it.
Systems with little user interaction, such as batch processing or systems that mostly do
calculations benefit little from prototyping. Sometimes, the coding needed to perform the system
functions may be too intensive and the potential gains that prototyping could provide are too
small.
2.1 Product Scope
The traditional communication uses the internet facility for communication. User can communicate
using Personal computers and laptops. Availability of internet connection is the most important factor for
the users. For eg :-two people chatting on Gmail require to be having internet connection. Security is
major concern. Hackers and illicit users can obtain password and other important information.
3. OBJECTIVES OF THE SYSTEM:-
The Online Shopping system (OSS) application enables vendors to set up online shops,
customers to browse through the shops, and a system administrator to approve and reject
requests for new shops and maintain lists of shop categories. Also the developer is designing an
online shopping site to manage the items in the shop and also help customers purchase them
online without having to visit the shop physically.The online shopping system will use the
internet as the sole method for selling goods to its consumers.

4. SCOPE OF THE SYSTEM:-
India has witnessed a major breakthrough Mix-Cart success stories particularly in

e-retail in Consumer Electronics & Fashion Apparel & Home Furnishing segments. Mix-
Cart creates new opportunities for entrepreneurial start-ups. Ease of Internet access, Safe
and secure payment modes coupled with aggressive marketing by E- Commerce Giants
has revolutionized this segment. Rapid development in mobile technology has given way
to Mobile Commerce with many Mix-Cart companies shifting to App only model.
References
Reference Website:
www.w3school.com
www.tutorialspoint.com
http://wikipedia.org
www.stackoverflow.com
Books:
Software Engineering by Somerville
The complete Reference Java 2 by Herbert Scheldt
Overall Description
Product Perspective
This system will consist of two parts: one mobile application and one web portal. The mobile
application will be used to find restaurants and view information about them while the web
portal will be used for managing the information about the restaurants and the system as a whole.
The mobile application will need to communicate to a GPS application within the mobile phone,

which in turn communicates with a physical GPS device to find the location of the user, see
Figure 1. The GPS will provide the mobile application with locations of both the user and the
restaurants and the distance between them, but it will also provide maps and the functionality to
display the application’s data on the map. The functionality provided by the GPS will be
embedded into the application in order for the user to be able to use the functions in the
application in a seamlessly manner.
The proposed system is an intra-college communication system based on the concept of web
services. Availability of internet connection is the most important factor for the users. The users
of this system are teachers and students.
5. DFD:-
A data flow diagram is a graphical aid for defining system input and output. The DFD’s are the
most important of modeling techniques. It is used to model the system components. The DFD’s
clarifies the systems requirements and identifies major transformations that will become
programs in the system design and decomposes there requirement specification down to the
lowest level of detail.

Fig 1.4
CONTEXT LEVEL DFD FOR PROPOSED SYSTEM:
6. User Classes and Characteristics
There are three types of users that interact with the system: users of the mobile application,
restaurant owners and administrators. Each of these three types of users has different use of the
system so each of them has their own requirements. The mobile application users can only use
the application to find a restaurant. This means that the user have to be able to search for
restaurants, choose a restaurant from that search and then navigate to it. In order for the users to
get a relevant search result there are multiple criteria the users can specify and all results matches
all of those. The restaurant owners will not use the mobile application but the web portal instead.
There they will manage the information about their restaurant, for example a description of the
restaurant, contact information and their menu. The administrators also only interact with the
web portal. They are managing the overall system so there is no incorrect information within it.

The administrator can manage the information for each restaurant as well as the options for both
the mobile application users and the restaurant owners.
Operating Environment
Operating System :Windows XP/Windows 7
Front End : PHP
Programming Language :PHP
Server :Xamp/wamp
Backend :MySQL
Design and Implementation Constraints
In any educational system, notices, important notifications, information about any event etc. are
displayed on the notice board. In this manual system student didn’t get vital information about
their academics or any updates about notifications regarding events on timely manner. The sizes
of notice boards are small due to this only important notifications are placed there.
IMPLEMENTATION:
During this stage the software design is realized as asset of programs or program unit.
User Documentation
In any educational system, notices, important notifications, information about any event etc. are
displayed on the notice board. In this manual system student didn’t get vital information about
their academics or any updates about notifications regarding events on timely manner. The sizes
of notice boards are small due to this only important notifications are placed there.

7. Assumptions and Dependencies
One assumption about the product is that it will always be used on mobile phones that have
enough performance. If the phone does not have enough hardware resources available for the
application, for example the users might have allocated them with other applications, there may
be scenarios where the application does not work as intended or even at all. Another assumption
is that the GPS components in all phones work in the same way. If the phones have different
interfaces to the GPS, the application need to be specifically adjusted to each interface and that 6
would mean the integration with the GPS would have different requirements than what is stated
in this specification.
8. External Interface Requirements
8.1 User Interfaces
If the user is not a first-time user, he/she should be able to see the search page directly when the
application is opened, see Figure 3. Here the user chooses the type of search he/she wants to
conduct. Every user should have a profile page where they can edit their e-mail address, phone
number and password, see Figure 4. Also, the user can set the mobile application to his/her
preferred language. The “P” icon shows where the user can click to navigate to his/her profile
page.
8.2 Hardware Interfaces
Since neither the mobile application nor the web portal have any designated hardware, it does not
have any direct hardware interfaces. The physical GPS is managed by the GPS application in the
mobile phone and the hardware connection to the database server is managed by the underlying
operating system on the mobile phone and the web server. 3.1.3.
8.3 Software interfaces
The mobile application communicates with the GPS application in order to get geographical
information Figure 5 – List view Figure 6 – Map view Figure 8 – Web Portal Figure 7 – Filter
menu 9 about where the user is located and the visual representation of it, and with the database
in order to get the information about the restaurants, see Figure 1. The communication between

the database and the web portal consists of operation concerning both reading and modifying the
data, while the communication between the database and the mobile application consists of only
reading operations. 3.1.4.
9. Communications interfaces :-
The communication between the different parts of the system is important since they depend on
each other. However, in what way the communication is achieved is not important for the system
and is therefore handled by the underlying operating systems for both the mobile application and
the web portal.
System Features:-
SRS Training
SRS Security
Logon Procedures
SRS Online Help
PF Keys
Establishing Context
SRS Shortcuts
"UNDO" Function
SRS Maintenance Date
Term Calendar
Term Status
Student Name Search
Institutional Index File

10. Other Nonfunctional Requirements
10.1 Performance Requirements
(a) The number of terminals to be supported
(b) The number of simultaneous users to be supported
(c) Amount and type of information to be handled
Static numerical requirements are sometimes identified under a separate section entitled capacity.
Dynamic numerical requirements may include, for example, the numbers of transactions and
tasks and the amount of data to be processed within certain time periods for both normal and
peak workload conditions.
10.2 Safety Requirements
Specific requirements This section contains all of the functional and quality requirements of the
system. It gives a detailed description of the system and all its features.
10.3 Security Requirements
Specify the factors that would protect the software from accidental or malicious access, use,
modification, destruction, or disclosure. Specific requirements in this area could include the
need to:
Utilize certain cryptographic techniques
Keep specific log or history data sets
Assign certain functions to different modules
Restrict communications between some areas of the program
Check data integrity for critical variables

10.4 Software Quality Attributes
There are a number of attributes of software that can serve as requirements. It is important that required
attributes by specified so that their achievement can be objectively verified. The following items provide
a partial list of examples. These are also known as non-functional requirements or quality attributes.
These are characteristics the system must possess, but that pervade (or cross-cut) the design. These
requirements have to be testable just like the functional requirements. Its easy to start philosophizing
here, but keep it specific.

SYSTEM DESIGN DOCUMENT TEMPLATE

INTRODUCTION
This System Design Document has been created to outline the proposed system design for new
Acme Corporation Maintenance Management System (MMS). The MMS is intended to replace
the legacy maintenance tracking system currently used by Acme Corp. By designing, testing,
and deploying the MMS, Acme Corp. will improve its capabilities in maintenance management,
tracking, and reporting. This document and the technical specifications listed herein comply
with all Acme Corp. technical standards and infrastructure.
The most significant form of data as seen by the programmers is data as stored on the direct
access storage devices. This is the difference between logical and physical data. Database files are
the key source of information into the system. It is the process of designing database files, which are the
key source of information to the system. The files should be properly designed and planned for
collection, accumulation, editing and retrieving the required information. The organization of
data in database aims to achieve three major objectives:
1. PURPOSE
The purpose of this System Design Document is to provide a description for how the new MMS
will be constructed. The Systems Design Document was created to ensure that the MMS design
meets the requirements specified in the MMS project requirements documentation as well as the
Acme Corporation’s Executive Bulletin referencing improvements to existing maintenance
management practices and tools. The System Design Document provides a description of the
system architecture, software, hardware, database design, and security.
2. SYSTEM OVERVIEW
This section describes the system in narrative form using non-technical terms. It should provide
a high-level system architecture diagram showing a subsystem breakout of the system, if
applicable. The high-level system architecture or subsystem diagrams should, if
applicable, show interfaces to external systems. Supply a high-level context diagram for
the system and subsystems, if applicable. Refer to the requirements trace ability matrix
(RTM) in the Functional Requirements Document (FRD), to identify the allocation of the
functional requirements into this design document.

A Corporation has historically faced many challenges and shortcomings in managing fleet
maintenance metrics, tracking, and reporting. The proposed MMS tool will utilize existing
Acme infrastructure and hardware to provide an enterprise tool which will standardize and
improve the efficiency of Acme’s maintenance management capabilities.
The MMS is designed as an enterprise software tool which is compatible with and leverages
existing Acme hardware and infrastructure. Additionally, MMS is compliant with all internal
Acme Corporation network security protocols and policies as well as industry regulatory
policies.
The MMS tool is also compatible with existing Acme software suites to include MS Office
applications and SharePoint, as well as SAP. The MMS tool will provide various user interfaces
which will allow data entry, updates, tracking, and report generation. It will also allow users to
export data to various existing software tools like MS Excel and SharePoint for various uses.
3. DESIGN CONSTRAINTS
The MMS Project Team identified several constraints which will impact and limit the design of
the tool. These constraints are beyond the scope of the MMS Project but must be carefully
factored into the system design. To date, the following constraints have been identified:
 MMS must be compatible with existing Acme Corp. infrastructure to include network
tools and applications, security requirements, server capabilities, and network
management hardware. This constraints will impact the design because the team must
ensure the MMS coding and formats meet the capabilities of the infrastructure will limit
the MMS in certain areas—although the capabilities will still far exceed those of the
legacy maintenance management system.
 MMS must comply with all Acme Corp. and industry regulatory policies and guidelines.
These policies and guidelines will impact the tool by requiring certain standards of
coding, user interfaces, security, and management of the tool.

 The MMS tool must be compatible with existing user software suites. This will require
the team to design and code the MMS in a manner in which data can be seamlessly
imported and exported between the MMS and existing software tools.
 Maintenance involves the software industry captive, typing up the system resources.
It means restoring something to its original condition. Maintenance involves a wide range
of activities including correcting, coding, and design errors, updating documentation and
test data and upgrading user support. Maintenance is continued till the product is re-
engineered or deployed to another platform. Maintenance is also done based on fixing the
problems reported, changing the interface with other software or hardware enhancing the
software.
4. ROLES AND RESPONSIBILITIES
The following table defines the MMS System Design roles and responsibilities. This matrix also
serves as the list of points of contact for issues and concerns relating to the MMS System Design.
Name Role Phone Email
Prof. Rakshitha Project Manager (777) 555-1212 a.xyz@acme.com
Prof. Mahendra Project Lead (777) 555-1313 b.black@acme.com
Abhilash S Bale Team member (777) 555-1414 abhilash@acme.com
Abhishek M L Team member (777) 555-1515 abhishek@acme.com
5. PROJECT REFERENCES
Reference Website:

• www.w3school.com
• www.tutorialspoint.com
• http://wikipedia.org
• www.stackoverflow.com
Books:
• Software Engineering by Somerville

• The complete Reference Java 2 by Herbert Schildt
• Core java volume 1,2-Sun Microsystems
•
6. SYSTEM ARCHITECTURE
Hardware:
The MMS design is based on existing hardware architecture already deployed across the Acme
Corp. enterprise. This hardware consists of the following components:
 ABC Quadrant Server Array consisting of

o 8GHz Server Suite
o RAM: 16 GB Fully Buffered
o Array Controller
o 4x 80GB 15,000 RPM Hard Drive
o 4x Giga Network Adapters
 Cisco CSS 11500 Content Services Switch series
 1 TB SAN Storage Devices
 Dell P3000 Workstations
Software:

The MMS design is based on the individual design of various components in which users will
enter and query data. The software architecture is designed to incorporate all data entries and
modifications into an integrated database which tracks maintenance data in real-time as it’s
manipulated. The components which comprise the software architecture include:
 User Data Entry Module: This component provides the user interfaces for all
maintenance data entry. This component consists of several sub-components to include:
o New System Data
o Existing System Maintenance Updates
o System Location Updates
o System History
 Automated Reporting Module: This component provides all of the pre-built automated
reporting capabilities. These are reports that are generated regularly and repetitively at
known intervals.
 Manual Reporting Module: This component provides a list of all searchable fields in
which the user can create a report as the need arises
DATABASE DESIGN
The MMS tool will incorporate existing maintenance data in the legacy database into a new
enhanced database with additional capabilities such as searchable and sortable fields and various
enhanced reporting functions. The MMS database will also have the capability of importing and
exporting data from/to MS Office applications.
The most significant form of data as seen by the programmers is data as stored on the direct
access storage devices. This is the difference between logical and physical data. Database files are
the key source of information into the system. It is the process of designing database files, which are the
key source of information to the system. The files should be properly designed and planned for

collection, accumulation, editing and retrieving the required information. The organization of
data in database aims to achieve three major objectives:
 Data integration.
 Data integrity.
 Data independence.
The proposed system stores the information relevant for processing in the Oracle 10g
database. This database contains tables, where each table corresponds to one particular type of
information. Each piece of information in table is called a field or column. A table also contains
records, which is a set of fields. All records in a table have the same set of fields with different
information. There are primary key fields that uniquely identify a record in a table. There are
also fields that contain primary key from another table called foreign keys.

SCOPE MANAGEMENT PLAN
INTRODUCTION

communicate using Personal computers and laptops. Availability of internet connection is the
most important factor for the users. For eg :-two people chatting on Gmail require to be having
internet connection. Security is major concern. Hackers and illicit users can obtain password and
other important information
1) Collect Requirements – this first step is the process by which we define and document
the requirements needed to meet all project objectives. The foundation of this process is
the project charter and stakeholder register. From these, the team can identify
requirements, collectively discuss details associated with meeting each requirement,
conduct interviews and follow-on discussion to clarify the requirements, and document
the requirements in sufficient detail to measure them once the project begins the
execution phase. This documentation also serves as an input to the next step in the
process which is to define scope.
2) Define Scope – this step is critical to project success as it requires the development of a
detailed project/product description to include deliverables, assumptions, and constraints
and establishes the framework within which project work must be performed.
3) Create WBS – this process breaks project deliverables down into progressively smaller
and more manageable components which, at the lowest level, are called work packages.
This hierarchical structure allows for more simplicity in scheduling, costing, monitoring,
and controlling the project.
4) Verifies Scope – this is the process by which the project team receives a formalized
acceptance of all deliverables with the sponsor and/or customer.
5) Control Scope – this is the process of monitoring/controlling the project/product scope
as well as managing any changes in the scope baseline. Changes may be necessary to the
project scope but it is imperative they are controlled and integrated in order to prevent
scope creep.
This project is for designing, programming, and testing a new software product which will be
used for online shopping. This includes design of the software, all programming and coding, and
testing/validation of the software. No external resources or outsourcing are anticipated for this
project.
1. SCOPE MANAGEMENT APPROACH
For this project, scope management will be the sole responsibility of the Project Manager. The scope for
this project is defined by the Scope Statement, Work Breakdown Structure (WBS) and WBS Dictionary.
The Project Manager, Sponsor and Stakeholders will establish and approve documentation for measuring
project scope which includes deliverable quality checklists and work performance measurements.
Proposed scope changes may be initiated by the Project Manager, Stakeholders or any member of the
project team. All change requests will be submitted to the Project Manager who will then evaluate the
requested scope change. Upon acceptance of the scope change request the Project Manager will submit

the scope change request to the Change Control Board and Project Sponsor for acceptance. Upon
approval of scope changes by the Change Control Board and Project Sponsor the Project Manager will
update all project documents and communicate the scope change to all stakeholders. Based on feedback
and input from the Project Manager and Stakeholders, the Project Sponsor is responsible for the
acceptance of the final project deliverables and project scope.
The Project Manager, Sponsor and team will all play key roles in managing the scope of this
project. As such, the project manager, and team members must be aware of their responsibilities
in order to ensure that work performed on the project is within the established scope throughout
the entire duration of the project. The table below defines the roles and responsibilities for the
scope management of this project.
Name Role Responsibilities
Dr. samitha Project Manager - Measure and verify project scope

- Facilitate scope change requests
- Facilitate impact assessments of scope
change requests
- Organize and facilitate scheduled change
control meetings
- Communicate outcomes of scope change
requests
- Update project documents upon approval
of all scope changes
Prof. Rakshitha Team Lead - Measure and verify project scope
- Validate scope change requests
- Participate in impact assessments of scope
change requests
requests to team
- Facilitate team level change review
process
Abhilash S B Team Member - Participate in defining change resolutions
- Evaluate the need for scope changes and
communicate them to the project manager
as necessary
AbhisheK M l Team Member - Participate in defining change resolutions
communicate them to the project manager
as necessary

3. SCOPE DEFINITION
This application can be implemented in any online shopping such as web based. This
application can be used for a use can buy products there in home and they can
payment pay at product received time. This application gives feedback facility for use
they can gives there feedback about products and website.
4. PROJECT SCOPE STATEMENT
The project scope statement provides a detailed description of the project, deliverables,
constraints, exclusions, assumptions, and acceptance criteria. Additionally, the scope statement
includes what work should not be performed in order to eliminate any implied but unnecessary
work which falls outside the of the project’s scope.
This project includes the design, programming, and testing of a new software application for
online shopping. The deliverables for this project are a completed software application for
online shopping with the flexibility to modify and expand the application as necessary in the
future. This project will be accepted once the new software has been successfully tested in each
department and has been shown to be compatible with the online shopping current information
technology (IT) infrastructure. This project does not include ongoing operations and
maintenance of the software. Only internal personnel and resources may be used for this project.
5. WORK BREAKDOWN STRUCTURE

In order to effectively manage the work required to complete this project, it will be subdivided
into individual work packages which will not exceed 20 hours of work. This will allow the
Project Manager to more effectively manage the project’s scope as the project team works on the
tasks necessary for project completion. The project is broken down into three phases: the design
phase; the programming phase; and the testing phase. Each of these phases is then subdivided
further down to work packages which will require no more than 20 hours of work and no less
than 4 hours of work (see WBS structure below).

Figure 1.1, Work Breakdown Structure (WBS)
6. SCOPE VERIFICATION
As this project progresses the Project Manager will verify interim project deliverables against the
original scope as defined in the scope statement, WBS and WBS Dictionary. Once the Project
Manager verifies that the scope meets the requirements defined in the project plan, the Project
Manager and Sponsor will meet for formal acceptance of the deliverable. During this meeting
the Project Manager will present the deliverable to the Project Sponsor for formal acceptance.
The Project Sponsor will accept the deliverable by signing a project deliverable acceptance
document. This will ensure that project work remains within the scope of the project on a
consistent basis throughout the life of the project.
7. SCOPE CONTROL
The Project Manager and the project team will work together to control of the scope of the
project. The project team will ensure that they perform only the work described in the WBS
dictionary and generate the defined deliverables for each WBS element. The Project Manager
will oversee the project team and the progression of the project to ensure that this scope control
process if followed.
If a change to the project scope is needed the process for recommending changes to the scope of
the project must be carried out. Any project team member can request changes to the project
scope. All change requests must be submitted to the Project Manager in the form of a project
change request document.

SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
___________________________________________ Date:____________________
<Project Sponsor>
<Project Sponsor Title>

SOFTWARE ENGINEERING LABORATORY

17MCA3
9

Introduction
This document comes as a complement to the article “Developing a J2EE Architecture with
Rational Software Architect using the Rational Unified Process®” [RUPRSA]. It illustrates what
can be the content of a Software Architecture Document (SAD) produced during the RUP
Elaboration phase.
As stated in the companion article, a RUP Software Architect will typically perform height major
steps in order to define a global architecture, and each time an activity is completed, a specific
section of the SAD is enriched accordingly.
Architectural activities Software Architecture Document
Step 1 - Identify and prioritize significant Use- Section 4

Cases
Step 2 - Define the candidate architecture Section 3, 5.1, 10, 11
Step 3 - Define the initial Deployment Model Section 7
Step 4 - Identify key abstractions Section 9
Step 5 - Create an Analysis Model Section 5
Step 6 - Create the Design Model Section 5
Step 7 - Document concurrency mechanisms Section 6, 7
Step 8 - Create the Implementation Model Section 8
1. Purpose
The Software Architecture Document (SAD) provides a comprehensive architectural overview of
the Mix-cart (online shopping). It presents a number of different architectural views to depict
different aspects of the system. It is intended to capture and convey the significant architectural
decisions which have been made on the system.
2. Scope
The scope of this SAD is to depict the architecture of the online catering application created by
the company Yummy Inc.
• This application can be implemented for an online shopping and it is use full users.
• This application can be used to buy products by at home.
• This application can be used to save the time for shopping at go and buy.

Definitions, Acronyms and Abbreviations

SAAS: software as a service
GUI: graphical user interspace
UML: Unified Modeling Language
References
1 H. Baumeister, W. Martin, "Applying test-first programming and iterative development in

building an E-business application", International Conference on Advances in Infrastructure for
e-Business e-Education e-Science and e-Medicine on the Internet SSGRR 2002, 2002.
[2]. T. Tsiakis, G. Theodosios, G. Sthephanides, "The concept of security and trust in electronic
payments", Elsevier Computers & Security, vol. 24, no. 1, pp. 10-15, 2005.
3 Hakikur Rahman, Isabel Ramos, "Implementation of Mix-Cart at the Grass Roots",

International Journal of Information Communication Technologies and Human Development,
vol. 5, pp. 1, 2013, ISSN 1935-5661.
Overview
In order to fully document all the aspects of the architecture, the Software Architecture
Document contains the following subsections.
Section 2: describes the use of each view
Section 3: describes the architectural constraints of the system
Section 4: describes the functional requirements with a significant impact on the architecture
Section 5: describes the most important use-case realization. Will contain the Analysis Model
and the Design Model
Section 6: describes design’s concurrency aspects
Section 7: describes how the system will be deployed. Will contain the Deployment Model
Section 8: describes the layers and subsystems of the application
Section 9: describes any significant persistent element. Will contain the Data Model
Section 10: describes any performance issues and constraints
Architectural Representation
This document details the architecture using the views defined in the “4+1” model [KRU41], but
using the RUP naming convention. The views used to document the online shopping.
application are:

Logical view
Audience: Designers.
Area: Functional Requirements: describes the design's object model. Also describes the most
important use-case realizations.
Related Artifacts: Design model
Process view
Audience: Integrators.
Area: Non-functional requirements: describes the design's concurrency and synchronization

aspects.
Related Artifacts: (no specific artifact).
Implementation view
Audience: Programmers.
Area: Software components: describes the layers and subsystems of the application.
Related Artifacts: Implementation model, components
Deployment view
Audience: Deployment managers.
Area: Topology: describes the mapping of the software onto the hardware and shows the
system's distributed aspects.
Related Artifacts: Deployment model.
Use Case view
Audience: all the stakeholders of the system, including the end-users.
Area: describes the set of scenarios and/or use cases that represent some significant, central
functionality of the system.
Related Artifacts : Use-Case Model, Use-Case documents

Data view (optional)
Audience: Data specialists, Database administrators
Area: Persistence: describes the architecturally significant persistent elements in the data model
Related Artifacts: Data model.
Architectural Goals and Constraints
This section describes the software requirements and objectives that have some significant
impact on the architecture
• Operating System: Windows XP, 7, 8, 10,

• Front End: HTML, PHP
• Scripts: JavaScript
• Backend: MySQL
OBJECTIVES OF THE SYSTEM:

• The main Objective of Mix-cart is to provide web based application for the customers to buy
the product through online.
• To provide platform where user can login and buy a product.
• To provide platform where the user can see the product information and prize.
• To save Time.
• To increase communication between user and network server.
Technical Platform
The Mix-cart online application will be deployed onto a J2EE application server (Web sphere
Application Server version 6, as it is already the application server use for internal applications).
Transaction

The Mix-cart online application is transactional, leveraging the technical platform capabilities.
Transaction management model of the J2EE platform will be reused intensively.
Security
The system must be secured, so that a customer can make online payments.
The application must implement basic security behaviors:
 Authentication: Login using at least a user name and a password
 Authorization: according to their profile, online customer must be granted or not
to perform some specific actions (gold customer, business partners, etc..)
For internet access, the following requirements are mandatory
 Confidentiality: sensitive data must be encrypted (credit card payments)
 Data integrity : Data sent across the network cannot be modified by a tier
 Auditing: Every sensitive action can be logged
 Non-repudiation : gives evidence a specific action occurred
J2EE security model will be reused
Persistence
Data persistence will be addressed using a relational database.

The entity-relationship (ER) data model perceives the real world as consisting of basic objects,
called entities, and relationships among these objects. It was developed to facilitate database
design by allowing specification of an enterprise schema, which represents the overall logical
structure of a database.
Relationship:- A relationship is an association among several entities. It is represented by a
diamond.

Reliability/Availability (failover)
The availability of the system is a key requirement by nature, as it is a selling system. The
candidate architecture must ensure failover capabilities. Reliability/Availability will be addressed
through the J2EE platform
Targeted availability is 16/7: 16 hours a day, 7 days a week
The time left (8 hours) is reserved for any maintenance activities
Performance
The payment process (credit card authorization and confirmation) must be under 10 seconds.
Internationalization (i18n)
The online catering service of Mix-cart must be able to deal with several languages (at least
French and English)
So the presentation layer must be able to support i18n.
Other layers must be generic enough to work with any internationalization context
Use-Case View
This section lists use cases or scenarios from the use-case model if they represent some
significant, central functionality of the final system. The only use-case with a significant impact
on the online catering architecture is the one related to online orders. It includes a search feature
as well as a call to external services (delivery and payment)
Ordering Menus
A customer accesses the online catering application and search for the available menus. The
customer chooses from a list of menus and select what she/he wants to order. Then, the customer
performs an payment cash on delivery. Once the payment has been validated, the customer
confirms the order, enters her/his delivery information (name, address, phone number, etc..) and
all the relevant information is sent to the Yummy Inc delivery service.

Use-Case Realizations
Refers to section 5.2 to see how design elements provide the functionalities identified in the
significant use-cases.
Logical View
Overview
The online catering application is divided into layers based on the N-tier architecture

The layering model of the online catering application is based on a responsibility layering
strategy that associates each layer with a particular responsibility.
This strategy has been chosen because it isolates various system responsibilities from one
another, so that it improves both system development and maintenance.

Each layer has specific responsibilities.

 The presentation layer deals with the presentation logic and the pages rendering
 The control layer manages the access to the domain layer
 The resource layer (integration layer) is responsible for the access to the enterprise
information system (databases or other sources of information)
 The domain layer is related to the business logic and manages the accesses to the
resource layer.
 The Common Elements layer gathers the common objects reused through all the layers
The online catering application version 1.0 is quite simple and only contains two basic features,
one for the submit orders and the other allowing a customer to browse the online catalogue.
External services are reused fro the payment and the delivery functionalities.
Architecturally Significant Design Packages
Ordering Menus
This package is responsible for all the logic related to the online orders. It provides ordering
features and the necessary components to access the external services (Payment and Delivery)

Analysis Model
Participants:
Basic Flow:

Design Model
Process Delivery

Delivery Service
Contains all the logic related to the Mix-cart delivery service.
The Delivery Service is an external subsystem documented in its own Software Architecture
Document
Payment Service
Contains all the logic related to the cash on delivery.
The Payment Service is an external subsystem documented in its own Software Architecture
Document.
Process View
There’s only one process to take into account. The J2EE model automatically handles threads
which are instances of this process.
Deployment View
Global Overview
Detailed deployment model with clustering
 One IBM HTTP Server will dispatch requests to two different IBM WebSphere servers
(load balancing + clustering)

 An IBM DB2 Database stores all the information related to online orders
Implementation View
Overview
The Implementation view depicts the physical composition of the implementation in terms of
Implementation Subsystems, and Implementation Elements (directories and files, including
source code, data, and executable files).
Usually, the layers of the Implementation view do fit the layering defined in the Logical view
It is unnecessary to document the Implementation view in great details in this document. For
further information, refer to the Online Catering Service 1.0 workspace in Rational Software
Architect.
Layers
Presentation Layer
The Presentation layer contains all the components needed to allow interactions with an end-user.
It encompasses the user interface
Control Layer
The Control layer contains all the components used to access the domain layer or directly the
resource layer when this is appropriate.
Resource Layer
The Resource layer contains the components needed to enable communication between the
business tier and the enterprise information systems (Database, external services, ERP, etc…)
Domain layer
The Domain layer contains all the components related to the business logic. It gathers all the
subsystems that meet the needs of a particular business domain. It also contains the business
object model.
.
Common Elements Layer

The Common Element layer contains the components re-used within several layers.
Data View
The key data elements related to the online catering system are:

Size and Performance
Volumes:
 Estimated online orders : 100 a day, with peaks in the evening
 Yummy Inc registered individual customer : about 150
 Yummy Inc corporate customers : about 100
Performance:
 Time to process and online payment (credit card validation + confirmation) : less that 10
seconds required
Quality
As far as the online catering application is concerned, the following quality goals have been
identified:
Scalability:
 Description : System’s reaction when user demands increase
 Solution : J2EE application servers support several workload management
techniques
Reliability, Availability:
 Description : Transparent failover mechanism, mean-time-between-failure
 Solution : : J2EE application server supports load balancing through clusters

Portability:
 Description : Ability to be reused in another environment
 Solution : The system me be fully J2EE compliant and thus can be deploy onto
any J2EE application server
Security:
 Description : Authentication and authorization mechanisms
 Solution : J2EE native security mechanisms will be reused
STATEMENT OF WORK (SOW)

INTRODUCTION/BACKGROUND
Mix-cart Project is support to its key intend to improve promoting and customers benefit. With
the end goal to give all the more convenient criticism to imminent customers and enhanced
customers cooperation, the Website Mix-cart will center around building a substance rich site
which gives a rearranged and more easy to use approach for existing and potential customers. It
is basic that Mix-cart uses its site as a stage for conveying new customers, customers necessities,
later new item points of interest, and different items particular data. Mix-cart additionally
understands the significance of working with customers to their criticism counseling
arrangements which the new site will enable the capacity to do. With the end goal to achieve this,
Mix-cart looks to redistribute the Add new items, evacuate the items, and purchase the items.
1. SCOPE OF WORK
The extent of work for the Mix-cart Project incorporates all customers register, all items subtle
elements, customer’s criticisms, administrator contact points of interest, and customers can give
the cash when of accepting the thing. The Ideator will be in charge of the include the new items
and expel the things for dependent on customers criticism to be given by Mix-cart. Each phase of
the task will require endorsement from Mix-cart administration before proceeding onward to the
following stage. The Mix-cart must guarantee it has sufficient assets for including the items,
evacuate the items, customers enlist, and to give the answer for customers feedbacks. Particular

expectations and points of reference will be recorded in the Work Requirements and Schedules
and Milestones areas of this SOW.
2. PERIOD OF PERFORMANCE
The period of performance for the Mix-cart Project is one year (365 days) beginning on 2
January 2018 through 3 January 2019. All work must be scheduled to complete within this
timeframe. Any modifications or extensions will be requested through Mix-cart.
3. PLACE OF PERFORMANCE
The selected vendor for the Mix-cart project will perform a majority of the work at its own
facility. The vendor will be required to meet at Mix-cart facility once per week (day and time
TBD) for a weekly status meeting. Additionally, all products gate reviews will be held at Mix-
cart facility and attended by the vendor. Mix-cart will provide and arrange for meeting spaces
within its facility for all required vendor meetings. Once the customer completes the register to
website, all detail about products and website will be conducted at Mix-cart facility.
4. WORK REQUIREMENTS
As part of the Mix-cart Project the vendor will be responsible for performing tasks throughout
various stages of this project. The following is a list of these tasks which will result in the
successful completion of this project:
Kickoff:
- Vendor will create and present detailed working including schedule, customers register,
selecting the product, sorting the items by the customer required cost, customers
feedback, add to cart, and payment methods.
- Vendor will present working to Mix-cart for review and approval
-
Customers register:
- Work with Mix-cart first step is user or customer can register first
- Customer gives the required details for register to the website
- After giving all the details to register the only they get the information
Select the product:
- When user register to website then they Can see the product

- When users see the products they can select the product because there are three type of
products one is t-shirts, watches and headsets.
- User selects the product in that they can see different item or models in that.
Sorting the items:
- When user or customer selects the product then they can sort the item based on the cost.
- User wants low prized products they can select the cost this facility is provided in this
project.
- User can find the product at what cost there can invest.
Add to cart:
- When use wants to buy more than one product at a time they can add the item to cart they
add the item to cart that is stored in that.
- User or customer they can remove the products to cart when doesn’t need.
Customer feedback:
- User can give the feedback about the product.

- And also they give any modification in the website they can gives through feedback.
- By the user feedback and website design experts feedback then website will modified
here.
5. SCHEDULE/MILESTONES.
The below list consists of the initial milestones identified for the Mix-cart Project:
RFP/SOW Release January 2, 2017
Vendor Selection Review February 1-28, 2017
Vendor Selection March 1, 2017
Period of Performance Begins March 2, 2017
Customers register: August 31, 2017
Select the product: November 30, 2017
Sorting the items: December 31, 2017

Add to cart: February 20, 2018
Customer feedback: February 25, 2018
6. ACCEPTANCE CRITERIA
Drawing upon the extant literature, we summarize individual factors and their impact on
consumer online shopping in Table 1. In particular, we identified nine types of consumer factors,
including demographics, Internet experience, normative beliefs, shopping orientation, shopping
motivation, personal traits, online experience, psychological perception, and online shopping
experience. Among them, demographics were the focus of early studies, while psychological
perception and online experience (e.g., emotion) have been examined in more recent studies. It is
not surprising that some consumer factors were found to have consistent effects across different
studies, while others were found to have mixed or even contradictory impacts. To enable better
understanding of the results, we provide alternative explanations for some of the mixed findings.
In addition, we analyze how the importance of the nine factors evolves over time.
7. OTHER REQUIREMENTS
When user wants to buy the product they first register to website and user give some user name
and password at the time of register, by using that user name and password they can login at any
time and also when use they have any problem with website they can contact to the admin and
also everyone who are all register to the website they are gives there feedback. And when user
wants to come out of the website they logout and website will closed.
All products adding and removing will be done through online. A network outage will be
scheduled for the feedbacks read and solve the problem of this project. Prior to the network
outage, all servers will be backed up and a notification will be distributed to all users.
ACCEPTANCE
Approved by:

___________________________________________ Date:____________________
<Approvers Name>
<Approvers Title>
CONFIGURATION MANAGEMENT PLAN

INTRODUCTION
The Mix-cart Project will utilize existing online shopping website and add features in order to
attract peoples, directly they can buy the products through online, and improved online shopping
website tools and devices. As a result, Mix-cart ability to perform online shopping maintenance
and updates will be significantly improved. Additionally, Mix-cart will improve its ability to
monitor all user requirements in real time and streamline workforce efficiency. Cost savings will
be realized by greatly reducing the amount of time associated with competing online shopping
and allowing customers to buy the products through online.
In order to effectively manage the Mix-cart Project, a coordinated Configuration Management

(CM) Plan is needed. This plan will establish CM roles and responsibilities and describe how the
Mix-cart Project team will track, implement, and communicate configuration items (CIs) and
changes throughout the project lifecycle.
The following roles and responsibilities pertain to the CM Plan for Mix-cart Project.
Configuration Control Board (CCB)

The CCB is comprised of the Mix-cart Project Sponsor, Project Manager, Configuration
Manager, and the Lead Engineer for the configuration item (CI) under consideration. The CCB
is responsible for the following:
 Review and approve/reject configuration change requests

 /Ensure all approved changes are added to the configuration management database
(CMDB)
 Seeking clarification on any CIs as required

Project Manager
The Project Manager is responsible for:
 Overall responsibility for all CM activities related to the Mix-cart project

 Identification of CIs
 All communication of CM activities to project stakeholders
 Participation in CCB meetings
 Re-baselining, if necessary, any items affected by CM changes
Configuration Manager
The Configuration Manager will be appointed by the Program Management Office (PMO). The
Configuration Manager is responsible for:
 Overall management of the CMDB

 Providing configuration standards and templates to the project team
 Providing any required configuration training
Project lead
All identified CIs will be assigned to a Lead Engineer. The assigned Project lead
is responsible for:
 Designating a focus group to develop the change request

 Ensure all change requests comply with organizational templates and standards prior to
the CCB

Name Role Responsibilities

Dr. samitha Project Manager - Measure and verify project scope
- Facilitate scope change requests
- Facilitate impact assessments of scope change
requests
- Organize and facilitate scheduled change
control meetings
- Communicate outcomes of scope change 2.
requests 2.
- Update project documents upon approval of 2.
all scope changes
Prof. Rakshitha Team Lead - Measure and verify project scope 2.
- Validate scope change requests 2.
- Participate in impact assessments of scope 2.
change requests 2.
requests to team 2.
- Facilitate team level change review process 2.
Abhilash S B Team Member - Participate in defining change resolutions 2.
communicate them to the project manager as
2.
necessary 2.
Abhishek M l Team Member - Participate in defining change resolutions 2.
- Evaluate the need for scope changes and 2.
communicate them to the project manager as
necessary
2.
2.
CONFIGURATION CONTROL
The Mix-cart Project will use a standardized configuration control process throughout the project
lifecycle in order to ensure all CIs are handled in a consistent manner and any approved changes
are fully vetted regarding impact and communicated to stakeholders.
As CIs are identified by the project team, the Configuration Manager will assign a CI name and
the CI will be entered into the CMDB in an “initiate” status. The CI will then be assigned to an
engineer focus group. Each member of a CIs focus group will have the ability to access the CI
through the CMDB, make changes and edits, and enter the CI back into the CMDB with a
description of the change/edit annotated in the CMDB log.
It is imperative that for any software changes testing is conducted by the focus group in order to
validate any changes made. The Lead Engineer assigned to manage the focus group is
responsible for ensuring that testing has been conducted, changes are entered into the CMDB
log, and that all changes/edits are saved properly into the CMDB. The Lead Engineer is also
responsible for assigning new version numbers and CMDB status for any changes made by
his/her assigned focus group.

Many times a CI will have a relationship with one or more other CIs within a project. The Lead
Engineer, CM, and Project Manager will work together to ensure these relationships are fully
understood. The Lead Engineer and CM will then be responsible for illustrating these
relationships and co-dependencies in the CMDB to ensure a full understanding of each CI and
how they relate to one another.
Any configuration changes which are identified by the project team or stakeholders must be
captured in a configuration change request (CCR) and submitted to the CCB. The CCB will
review, analyze, and approve/deny the request based on the impact, scope, time, and cost of the
proposed change. If the change is approved, the project requirements will be re-baselined (if
necessary) and all changes will be communicated to the project team and stakeholders by the
Project Manager. Denied CCRs may be re-submitted with additional or new information for re-
consideration by the CCB.
3. CONFIGURATION MANAGEMENT DATABASE (CMDB)
The CMDB will be the centralized repository for all configuration information for the Mix-cart
project. The CMDB provides a common platform for the project team to edit, change, revise,
and review CIs and also to ensure all documents and data are updated with the latest revision and
release formats.
Access to the CMDB will be granted and governed by standard UNIX permissions. Two types of
CMDB access will be granted for the NexGen project:
1) Full read and write access will be granted to the CM, Project Manager, Lead Engineers,
and Engineers. These individuals will be authorized to access the CMDB to make
changes, edit documents and data, and review and approve versions and CI status.
2) Read only access will be granted to the Project Sponsor and all other stakeholders. This
access will allow these individuals to view all CIs and CI data but they will not be
authorized to make any changes. If these individuals identify the need for a change or
edit they will notify the CM who will review the notification and provide feedback.
3.1 CONFIGURATION STATUS ACCOUNTING

It is important that for the Mix-cart Project, the Project Sponsor and Vice President of
Technology have the ability to review configuration status at any given time. The Project
Manager will also submit weekly reports, to include configuration status, every Friday. These
reports will consist of the following information as part of the configuration status section:
1) Change requests
a. Aging - How long change requests have been open
b. Distribution – number of change requests submitted by owner/group

c. Trending – what area(s) are approved changes occurring in
2) Version Control
a. Software
b. Hardware
c. Data
d. Documentation
3) Build Reporting
a. Files
b. CI relationships
c. Incorporated Changes
4) Audits
a. Physical Configuration
b. Functional Configuration
c.
Prior to any new software releases, the CM will work with each Lead Engineer to ensure all CIs
are updated with latest release versions.
3.2 CONFIGURATION AUDITS
Configuration audits will be an ongoing part of the Mix-cart project lifecycle. The purpose of
the configuration audit is to ensure all team members are following the established procedures
and processes for configuration management. Project audits for the Mix-cart Project will occur
prior to any major software release or at the Project Manager or Sponsor’s discretion if they
determine the need for one.
All Mix-cart configuration audits will be performed by the CM. Throughout the project the CM
works closely with Lead Engineers to ensure that all configuration processes and procedures are
being followed. As part of the configuration audit the CM will perform the following tasks:
1) Establish an audit environment in the CMDB

2) The CM will copy all of the latest software, data, and document versions into the audit
environment
3) The CM will ensure all versions are correctly numbered and that version control has been
performed properly

4) The CM will analyze historical versions and timestamps of all software, data, and
documents to ensure all changes/edits were properly recorded and captured
5) The CM will copy latest software versions and conduct software testing to ensure
requirements are being met
6) The CM will ensure all required artifacts are present and current in the CMDB
7) The CM will ensure all approved CCRs have been incorporated into the project and are
recorded in the CMDB
Once the audit has been performed, the CM will compile his/her audit findings. For each
finding, the CM must work with the Project Manager/Team to identify the corrective action(s)
necessary to resolve the discrepancy and assign responsibility for each corrective action.
Upon completion of the project audit and findings, the CM will note all discrepancies and
compile a report to be presented to the Project Manager, Sponsor, and VP of Technology.

SPONSOR ACCEPTANCE
___________________________________________ Date:____________________
<Project Sponsor>

Cost-Estimation



Design Document

Introduction
This section addresses the purpose of this document including the intended audience, an
introduction to the problem and a detailed view of the project's design. In the discussion, the
design of the final system including several detailed diagrams will be described in detail.
1. Purpose
India has witnessed a major breakthrough E-commerce success stories particularly in e-retail in
Consumer Electronics & Fashion Apparel & Home Furnishing segments. E-commerce
creates new opportunities for entrepreneurial start-ups. Ease of
Internet access, Safe and secure payment modes coupled with aggressive marketing by E-
Commerce Giants has revolutionized this segment. Rapid development in mobile
Technology has given way to Mobile Commerce with many E-Commerce companies
Shifting to App only model.
1.1 System Overview

Before ordering a product, he has to register with an account, after that he has to login
With his user name and password, then he is allowed to buy an product. Once user selects
an item then they will get the price and overview of that product, if he satisfied he can
add that product in to the cart. In case user thinks the selected item is not useful for me,
then deleted that item from shopping cart and if he wants to add still more items into the
cart, he can update the items in the cart by adding more items. After that the customer can
order the product. Usually, the customer will be asked to fill billing address, a shipping
address, a shipping option, and payment information. Here the customers can give the
feedback about this E-Commerce website and he can view the feedback from users and
also they can contact the admin of that E-Commerce website by providing his contact
information.
1.2 Design Objectives

Open Source:
PHP is freely available for use. The community of open source PHP developers provides
Technical support and is constantly improving updating the core PHP functionalities.
Cross-Platform:
PHP provides high compatibility with leading operating systems and web servers such as

there by enabling it to be easily deployed across several different platforms .PHP scripts
can run across operating systems such as Linux, Windows, Solaris, Open BSD, Mac OSX
etc and also provide support for all major web servers such as Apache, IIS, i Planet etc.
Power:
Several web tasks can now be easily perform using PHP. For example now we can
develop from small websites to giant business and organizational websites, informative
forums, chatting platforms, CRM solutions, e-commerce shopping carts, community
websites, e-business, shopping carts and gigantic database driven sites.
Quick:
PHP is designed to work well with the web, and so things like accessing the GET and
POST and working with HTML and URLs are built-ins in the PHP language. This makes
it really concise and straightforward to make a website.
Community Support:
A huge advantage that PHP offers is its community. If you are looking for a particular
script, chances are another user has already created something similar. Check within the
PHP community for availability
Talent Availability:
You can hire PHP programmers more easily than any other language programmers since
so many people know the language..
References
[1]. H. Baumeister, W. Martin, "Applying test-first programming and iterative
development in
building an E-business application", International Conference on Advances in
Infrastructure for
e-Business e-Education e-Science and e-Medicine on the Internet SSGRR 2002, 2002.
[ 2 ] . T. Tsiakis, G. Theodosios, G. Sthephanides, "The concept of security and trust in

electronic
payments", Elsevier Computers & Security, vol. 24, no. 1, pp. 10-15, 2005.
[3]. Hakikur Rahman, Isabel Ramos, "Implementation of E-Commerce at the Grass

Roots", International Journal of Information Communication Technologies and Human
Development, vol. 5, pp. 1, 2013, ISSN 1935-5661.
Definitions, Acronyms, and Abbreviations

PHP: Personal Home Page

SQL:Structural Query Language

DDL:Data Definition Language
ER Digram:Entity relationship Digram
Design Overview
Introduction
Software design sits at the technical kernel of the software engineering process and
is applied regardless of the development paradigm and area of application. Design is t h e f i r s t
step in the development phase for any engineered product or system. The
d e s i g n e r ’s g o a l i s t o p r o d u c e a m o d e l o r r e p r e s e n t a t i o n o f a n e n t i t y t h a t
w i l l l a t e r b e built. Beginning, once system requirement have been specified and
analysed, system design is the first of the three technical activities -design, code and test that
is required to build and verify software. T h e i m p o r t a n c e c a n b e s t a t e d w i t h a s i n g l e
w o r d “ Q u a l i t y ” . Design is the only way that we can accurately translate a
customer’s view into a finished software product or system. Software design serves as a
foundation for all the software engineering steps that follow. Without a strong design we risk
building an unstable system – one that will be difficult to test, one whose quality cannot be
assessed until the last stage. During design, progressive refinement of data structure,
program structure, and p r o c e d u r a l d e t a i l s a r e d e v e l o p e d r e v i e w e d a n d
documented. System design can be viewed from either technical or project
m a n a g e m e n t p e r s p e c t i v e . F r o m t h e t e c h n i c a l point of view, design is comprised of
four activities – architectural design, data structure design, interface design and procedural
design.
Environment Overview
In day to day life, we will need to buy lots of goods or products from a shop. It may be food
items, electronic items, house hold items etc. Now days, it is really hard to get some time to go
out and get them by ourselves due to busy life style or lots of works. In order to solve this, B2C
E-Commerce websites have been started. Using these websites, we can buy goods or products
online just by visiting the website and ordering the item online by making payments online. This
existing system of buying goods has several disadvantages. It requires lots of time to travel to the
particular shop to buy the goods. Since everyone is leading busy life now a days, time means a
lot to everyone. Also there are expenses for travelling from house to shop. More over the shop
from where we would like to buy something may not be open 24*7*365. Hence we have to
adjust our time with the shopkeeper’s time or vendor’s time. In order to overcome these, we have

e-commerce solution, i.e one place where we can get all required goods/products online. The
proposed system helps in building a website to buy, sell products or goods online using internet
connection. Purchasing of goods online, user can choose different products based on categories ,
online payments , delivery services and hence covering the disadvantages of the existing system
and making the buying easier and helping the vendors to reach wider market.
System Architecture
The following is provided as an example

Top-level system structure of Fuel level controller
Constraints and Assumptions

Assumptions
An assumption is a belief of what you assume to be true in the future. You make assumptions
based on your knowledge, experience or the information available on hand. These are anticipated
events or circumstances that are expected to occur during your project’s life cycle.
Assumptions are supposed to be true but do not necessarily end up being true. Sometimes they
may turn out to be false, which can affect your project significantly. They add risks to the project
because they may or may not be true.
Suppose in our shopping example, you assumed that it would take one hour for you to reach the
destination. What will happen if, due to traffic, you don’t reach the mall on time?
Your assumption is false and your plan for shopping is endangered.

This can also happen to your project.
For example, you have made the assumption that some particular equipment will be made
available to you whenever you need it. However, when the time comes, the equipment is not
available.
Now you are in a difficult situation.
Assumptions play an important role in developing the risk management plan. Therefore, as a
project manager you must collect and identify as many as assumptions you can. It will assist you
in developing a sound risk management plan.
The following are a few examples of assumptions:
 You will get all resources required by you.

 During the rainy season, cheap labor will be available.
 All important stakeholders will come to the next meeting.
Constraints
Constraints are limitations imposed on the project, such as the limitation of cost, schedule, or
resources, and you have to work within the boundaries restricted by these constraints. All
projects have constraints, which are defined and identified at the beginning of the project.
The PMBOK Guide recognizes six project constraints: scope, quality, schedule, budget, resource,
and risk. Out of these six, scope, schedule, and budget are collectively known as the triple
constraints.
A constraint can be of two types:
1. Business Constraints
2. Technical Constraints
Business Constraints
Business constraints depend on the state of your organization; for example, time, budget,
resource, etc.
Technical Constraints
Technical constraints limit your design choice. For example, let’s say you’re constructing a
pipeline, and according to the design your pipeline should be able to withstand a certain amount
of pressure. This pressure limit is your technical constraint.

So now you know that every project has constraints; therefore, you must identify all your project
constraints (such as any milestone, scope, budget, schedule, availability of resources, etc.), and
develop your plan accordingly.
Constraints are outside of your control. They are imposed upon you by your client, organization,
or by any government regulations.
There is an interesting fact about the constraints: If the constraints become false or are no longer
valid, it is more likely that your project will benefit from it.
The following are a few examples of constraints:
 You must complete 25% of the work within the first 30 days.
 You have to work with the given resources.
 You will be given only two site engineers
Interfaces and Data Stores

This section describes the interfaces into and out of the system as well as the data stores you will be
including in your system.
2. System Interfaces
2.1 User
User has to register with an account, after that he has to login with his username and password,
then he is allowed to buy an product. Once user select an item then they will get the price
and overview of that product, if he satisfied he can add that product in to the cart. In case
user thinks the selected item is not useful for me, then deleted that item from shopping cart
and if he wants to add still more items into the cart, he can update the items in the cart by
adding more items. After that he can order the product. Usually, the customer will be asked
to fill billing address, a shipping address, a shipping option, and payment information.
2.2 Products
This module contains product name, and related image, and cost of its. Like Headphones, T-Shirts,
Watches, etc. whatever customer wants from the shopping cart.

Data Stores
Data stores are storage containers for files. They could be located on a local server hard
drive or across the network on a SAN. Data stores hide the specifics of each storage device
and provide a uniform model for storing virtual machine files.
Structural Designs
Design Explanation and Rationale
3. Class Diagram
4.2 Class Descriptions

3.1. User:

User has to register with an account, after that he has to login with his username and
password, then he is allowed to buy an product. Once user select an item then they will get the
price and overview of that product, if he satisfied he can add that product in to the cart.
3.2 Products:
This module contains product name, and related image, and cost of its. Like
Headphones, T-Shirts, Watches, etc. whatever customer wants from the shopping cart.
Classes in the Subsystem
Class: customer’s cart

 Purpose: customer can add their products to cart for future purchasing.
 Constraints: None
 Persistent: No
Attribute Description
 Attribute: cart_id
Type: real
Description: Stores the customers product for future use
Constraints: none
 Attribute: order_id
Type: numeric
Description: every customer will have particular id for each products.
Constraints: non-negative
Method Descriptions
Method: upload
Return Type: Boolean
Parameters: file_url – the file to be uploaded
Return value: success or failure

Pre-condition: file size should be within the limit
Post-condition: file size should be within the limit
Attributes read/used: file_url, date_time, file size
Methods called: upload_file(), upload_img()
Processing logic:
The file is obtained from the file_url attribute of the method. The file_size is
computed before submission. If limit falls outside the range then it will gives an alert
message and is stopped.
Dynamic Model
UCs specify functional requirements
Helps to understand the system in user perspective
UCs specify functionality by describing interactions between actors and system
Focuses on external behaviour
UCs are primarily textual
UC diagrams show UCs, actors, and dependencies
They provide an overview
Scenarios
For each scenario you will have a subsection with the following information:
 Scenario Name: user
 Scenario Description: User has to register with an account, after that he has to login
with his username and password, then he is allowed to buy an product.

 Sequence Diagram:

Supplementary Documentation

Non-functional requirements DEFINITION
Introduction
1. Purpose of the Non-Functional Requirements Definition
Look and feel requirements. The online shopping system has a decent look, and satisfies all the
requirements. For example, 5 displays the main page where the user can sign in by inserting a
username and password or create an account and return to the main page to insert the username
and password as shown.
• Usability and humanity requirements. The online shopping system provides adequate usability
and meets client requirements.
• Performance requirements. The online shopping system has adequate performance
requirements. For instance, it does not take more than 10 seconds to match the inserted username
and password. A buyer obtains a result in 5 or 10 seconds after selecting the features and
preferences. Figure 7 presents performance testing with benchmarks in the mixed page of the
online shopping system. Operational and environmental requirements. The operational and
environmental requirements of the online shopping system do not require too much equipment,
and can be easily accessed from a laptop, a desktop computer or any device with an internet
connection.
• Maintainability and support requirements. So far, there are no maintainability or support
requirements in the online shopping system. However they will be added in the near future.

• Security requirements. The online shopping system. Shows sign up page of the online shopping
system. Robustness testing with some incorrect data in the main page. protects the users account.
When a buyer types or inserts an incorrect username or password in the login page, the system
displays an error message
Business Requirements Overview
Many businesses have a process in place to assist with project management and implementation.
One opportunity for improvement involves making reasonable estimates of how big a project is
and how much it is going to cost. There are many different names for tools used with this
process: business needs specification, requirements specification or, simply, business
requirements. Business requirements are the critical activities of an enterprise that must be
performed to meet the organizational objective(s) while remaining solution independent.
A business requirements document (BRD) details the business solution for a project including
the documentation of customer needs and expectations. If an initiative intends to modify existing
(or introduce new) hardware/software, a new BRD should be created. The BRD process can be
incorporated within a Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) culture.
Assumptions / Constraints
Determine Requirements
The fundamental requirement is the business goal discussed earlier, but considers the
following:
• Are there security and legal restrictions on the data or project results?
• Is everyone aligned on the project scheduling requirements?
• Are there requirements on results deployment (for example, publishing to the Web or reading
scores into a database)?
Clarify Assumptions
• Are there economic factors that might affect the project (for example, consulting fees or
competitive products)?
• Are there data quality assumptions?
• How does the project sponsor/management team expect to view the results? In other words, do
they want to understand the model itself or simply view the results?

Verify Constraints
• Do you have all passwords required for data access?
• Have you verified all legal constraints on data usage?
• Are all financial constraints covered in the project budget?
Non-Functional Requirements
Hardware Requirements
RAM: 1GB and above
Hard disk: 60 GB and above
Operating System: windows
Front end: PHP
Back end: MySQL
Server: XAMPP/WAMPP
Editor: Notepad++
Performance Requirements
There are several classes of performance requirements. Most traditional are response times and
throughput.
Response times depend on workload, so it is necessary to define conditions under which specific
response times should be achieved; for example, a single user, average load or peak load.
Throughput is the rate at which incoming requests are completed. Throughput defines the load on
the system and is measured in operations per time period. It may be the number of transactions
per second or the number of adjudicated claims per hour.
Supportability Requirements
The notification advisor help desk will support users of "update information" daily on weekdays
only excluding certain fields.
The system needs to be COST-EFFECTIVE TO MAINTAIN.

The application shall support online-backup.
Security Requirements
 Privacy - Requirements can dictate protection for sensitive information. Some types of
privacy requirements include: data encryption for database tables, policies regarding the
transmission of data to 3rd parties (e.g., scrambling user account numbers), etc... Sources for
privacy requirements could be legislative or corporate.
 Physical - These requirements relate to the physical protection of the system. Other types of
physical requirements include items such as elevated floors (for server cooling), fire
prevention systems, etc... Access - Access requirements define account types / groups and
their access rights. An example of an access requirement could be to limit each account to
one login at a time or to restrict where an application can be deployed or used.
Interface Requirements
The Interface Requirements Specification (IRS) specifies requirements on a given external
interface (e.g. Remote Programming Interface) required of a System of Interest (SoI).
Interface Design Description (IDD) records design decisions on a given external interface (e.g.
Remote Programming Interface) taken in designing the System of Interest (SoI). These interface
design decisions have the same sort of information content as interface requirements.
Interface Management is needed to ensure that interface design is created consistently with
respect to the two ends of the interface.
Availability Requirements
High availability: The system or application is available during specified operating hours
with no unplanned outages.
Continuous operations: The system or application is available 24 hours a day, 7 days a week,
with no scheduled outages.
CONTINUOUS AVAILABILITY: THE SYSTEM OR APPLICATION IS AVAILABLE 24

HOURS A DAY, 7 DAYS A WEEK, WITH NO PLANNED OR UNPLANNED OUTAGES.
when real money is on the line it could mean the difference between a successful delivery or
ultimate failure of a project. It also shows you understand what needs to be delivered,
demonstrates that you have thought about all facets of the problem and shows that you know
many of the internal and external factors influencing the delivery of the project and can work
around them.

Compliance Requirements
Business compliance requirements fall into two categories: internal and external. Internal
requirements are actions that must be taken within the corporation or Limited Liability Company
by the directors and shareholders or members and managers, respectively.
External requirements are imposed by the state in which your business is incorporated and any
state where it is registered to transact business. State compliance requirements often include an
annual state filing (annual report) and payment of a corresponding state fee.

If a database is to be used, consideration of the record keys necessary to organize and view the
assumptions by owner, by project task, by priority, by review date or by similar requirement may
requiredNon-Functional Requirements Definition Approval
The undersigned acknowledge they have reviewed the Mix-cart Non-Functional Requirements
Definition and agree with the approach it presents. Any changes to this Requirements Definition
will be coordinated with and approved by the undersigned or their designated representatives
Signature: Date:
Print Name: Abhilash S B
Title: Management
Role: Project Manager
Signature: Date:
Print Name: DR.SUMA
Title: Working
Role: Project Guide
Signature: Date:
Print Name: Prof. RAKSHITHA K
Title: Testing
Role: Test Lead

Appendix A: References
The following table summarizes the documents referenced in this document.

Document Name Description Location
and Version
CDC_UP Mix-Cart online shopping https://ijcsmc.com/docs/papers/
Version 1.0 March2014/V3I3201499b19.pdf
Design Template Online shopping web based https://ijmter.com/papers/volum
Version 1.0 e-3/issue-5/Mix-cart-based-on-
web -2.pdf
Appendix B: Key Terms
The following table provides definitions for terms relevant to this document.
Term Definition
IRS Interface Requirements Specification
IDD Interface Design Description
SOI System of Interest

ASSESSMENT DOCUMENT

INTRODUCTION
This Assessment Document has been developed as a result of Mix-cart assessment of the online
shopping process. Periodically, Mix-cart assessments to determine the current state of its
programs, processes, and business functions. These assessments, and the resulting
documentation, have historically provided Mix-cart with many opportunities to identify
efficiencies and improve its business functions and add value to our organization. These
assessments are also a key driver in maturing our business practices and improving the collective
performance level of the organization.
EXPLANATION OF ASSESSMENT DOCUMENT
Assessment Purpose: This system is intended for online shopping purpose for the users at
home.
Description: This system helps the administrator to easy access the buy products at home. This
system is also save the time you can buy the products at anywhere.
Analysis: The application will be installed on the users Smartphone. Apart from that, the
application supports strong user authentication and quick transmission of data via the web
service. Another noticeable feature of the entire application would be that no data would be
stored on the user device in any form whatsoever.
Discoveries: Each level of user will have its own interface and privilege to manage information.
For e.g. supervisor will be able to monitor/manage user’ progress and make comment on it,
admin and user can change his detail, view the progress. The System also provides a feedback
form for all users to give comments or ask questions. It provides a FAQ to minimize the
workload of system administrator.
Recommendations for Improvement: The SOAP and XML will be used to facilitate
communications between the client and server.
Impact: The system helps the administrator to easy access the information of user. This system
is also helpful for the administrator because he/she can easily bring changes to the records of the
user

Current Performance Level: One of the most interesting features of a web service is that they
are self-describing. This means that once a web service is located we can ask it to describe itself
and tell what operations it supports and how to invoke it, which is handled by the Web Service
Description Language
Maturity: SAAS is one of the methodologies of Cloud Computing, which is based on a "one-to-
many" model whereby an application is shared across multiple clients. The SAAS model can add
efficiency and cost savings for the both the vendor and customer.
SAMPLE ASSESSMENT DOCUMENT
Process for New Software Request

Assessment:
Organization: DSCE
Created By: AbhisheK M L Last Updated By: Abhilash S B
Date Created: 5/1/2017 Last Revision 5/2/2017

Date:
Assessment Purpose: The purpose of the New Software Request process assessment is to
identify and capture the current state of the process as well as any
opportunities for improvement and/or impacts to the organization.
Description: The New Software Request process was developed to facilitate internal
user requests for software packages to assist in the performance of
user’s duties. The steps of the process are:
1 User submits completed software request form to supervisor for

approval
2 Supervisor approves and send form back to user
3 User submits form to help desk
4 Help desk logs request form and identifies availability and
licensing requirements
5 If software is available and licensing requirements are met the
help desk contacts the user to schedule an appointment to install
the software
6 Help desk technician installs software on user’s work station
7 Help desk technician closes ticket
Analysis: The assessment and analysis were performed on the overall New
Software Request process. No single portion of the process was singled
out for analysis. The assessment team used notional trial data to

request new software and follow/monitor the process through its

lifecycle to identify where efficiencies and improvements could be
gained.
Discoveries: The assessment identified several discoveries which follow:
1
The process does not make efficient use of the local area
network (LAN) capabilities. Instead, the process relies on
technicians scheduling appointments to manually install
software on workstations.
2 There are inefficiencies with the user requesting approval from
supervisor, receiving approval, and submitting the request to the
help desk.
3 The average time from request submission is often several days
depending on user availability
Recommendations for The assessment team has identified several opportunities for
Improvement: improvement. The following is a list of recommendations:
1All users are required to log off of workstations after close of

work. The help desk can use the LAN to remotely connect to
the user workstation after hours and push the software
installation over the LAN as opposed to scheduling an
appointment to perform the installation manually. This will
significantly reduce the length of time required to install
software.
2 The assessment team recommends modifying the process so that
user submit the New Software Request form to their supervisor
and the supervisor then submits the approved form directly to
the help desk instead of sending it back to the user to submit.
This process change will improve the efficiency of the process
and also reduce the length of time required to install the
software.
Impact: The assessment team has identified several impacts associated with the
recommendations above:
1 Supervisors will need to be made aware that they will submit

approved forms to help desk and not back to the requesting
employee.
2 All users need to be made aware that they will not receive an
approved form back from their supervisor to submit to the help
desk.
3 Management must reiterate the importance of logging off of
workstations after close of business so that not only can security
patches be performed, but also so that any newly requested
software can be pushed to their workstation for installation.

4Help Desk management and technicians will need to test

performing software installation over the LAN.
Current Performance The performance of the New Software Request process has been FAIR.
Level: Users have communicated that often, new software installations take
several days to complete which results in lost productivity. The
recommendations above provide a good opportunity to improve this
performance level by reducing the amount of time required and utilizing
technology to improve efficiency.
Maturity: The maturity level of this process is low. The New Software Request
process has only existed for 6 months. The number of software requests
in this time is limited and there has been some user and management
turnover which results in uncertainty and a limited data set. However,
the assessment team is confident that by incorporating the
recommendations, this process can continue to improve and reach a
much higher maturity level.
SPONSOR ACCEPTANCE
___________________________________________ Date:____________________
<Project Sponsor>

TEST PLAN
Introduction

Purpose of the SOFTWARE ENGINEERING LABORATORY

17MCA39 Document
The SOFTWARE ENGINEERING LABORATORY
17MCA39 document documents and tracks the
necessary information required to effectively define the approach to be used in the testing of the
project’s product. The SOFTWARE ENGINEERING LABORATORY
17MCA39 document is created during the
Planning Phase of the project. Its intended audience is the project manager, project team, and
testing team. Some portions of this document may on occasion be shared with the client/user and
other stakeholder whose input/approval into the testing process is needed.
System Testing
Test Risks / Issues
 Manual testing
 The confused test team
 The test maintenance failure
 The uncertainty principle.
Items to be Tested / Not Tested
Item to Test Test Description Test Date Responsibility
Approve user Approving the user to use the 20/04/2017 Admin

system
Username Entering correct username 30/04/2017 Supervisor
Password Entering a valid password 30/04/2017 Supervisor

Test Approach(s)
 Dynamic approach
 Methodical approach
 Model based approach
Test Regulatory / Mandate Criteria

 Compliance test
 Manufacturing or production test
Test Pass / Fail Criteria

 Pre and Post conditions
 Approvals
Test Entry / Exit Criteria

 Defined and approved requirements
 Test plan
 Test cases and test data
 Ensuring all critical test cases are passed
 Achieving complete functional coverage
 Identifying and fixing all the high-priority defects.

Test deliverables
 Test strategies
 Test plan document
 Test scenarios
 Effort estimation reports
 Test cases
Test suspension / resumption criteria

 Unavailability of external system
 When a defect is introduced
 Critical path deadline is missed.
Resumption criteria
 When the external dependent systems become available again.
 When a fix successfully implemented
 The contract is renegotiated with client
Test environmental / staffing / training needs

 System and applications
 Test data
 Database server
 Front end running environment
 Client operating system
 Browser
 Network
 Documentation

Unit testing
Test risks / issues
 writing the wrong type of tests
 Misunderstanding test doubles
 Test names don’t communicate intent
Item to test Test description Test date Responsibility
Name extractor Getting proper name 25/04/2017 Testing head
Business rules Getting the words in strict order 25/04/2017 Testing head
Test approach(s)
 Dynamic approach
 Methodical approach
 Model based approach
Test regulatory / mandate criteria

 Compliance test
 Manufacturing or production test
Test pass / fail criteria

 Pre and post conditions
 Approvals
Test entry / exit criteria

 Defined and approved requirements
 Test plan

 Test cases and test data
 Ensuring all critical test cases are passed
 Achieving complete functional coverage
 Identifying and fixing all the high-priority defects.
Test deliverables
 Test scenarios
 Effort estimation reports
 Test cases
Test suspension / resumption criteria

 Unavailability of external system
 When a defect is introduced
 Critical path deadline is missed.
Resumption criteria
 When the external dependent systems become available again.
 When a fix successfully implemented
 The contract is renegotiated with client
Test environmental / staffing / training needs

 System and applications
 Test data
 Database server
 Front end running environment
 Client operating system
 Browser

 Network
 Documentation
SOFTWARE ENGINEERING LABORATORY

17MCA39 Approval
The undersigned acknowledge they have reviewed the SOFTWARE ENGINEERING
LABORATORY 17MCA39 document and
agree with the approach it presents. Any changes to this Requirements Definition will be
coordinated with and approved by the undersigned or their designated representatives.
Signature: Date:
Print Name: PROF MAHENDRA
Title: HEAD
Role: HEAD
Signature: Date:
Print Name: PROF RAKSHITHA
Title: GUIDE
Role: GUIDE

Appendix A: References
The following table summarizes the documents referenced in this document.

Document Name Description Location
and Version
<Document [Provide description of the <URL or Network path where
Name and document] document is located>
Version Number>
Appendix B: Key Terms
The following table provides definitions for terms relevant to this document.
Term Definition
[Insert Term] [Provide definition of the term used in this document.]

Sepfinal1 Odt

Uploaded by

Copyright:

Available Formats

Sepfinal1 Odt

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sepfinal1 Odt

Uploaded by

Copyright:

Available Formats

SOFTWARE ENGINEERING LABORATORY 18MCA39

MCA-VTU DSCE Page 1 of 136

Privacy concerns — If a site doesn’t have a comprehensive privacy policy, it is

MCA-VTU DSCE Page 2 of 136

reducing costs, and capitalizing on technology. The recommended Mix-cart will

2. BUSINESS CASE ANALYSIS TEAM

Role Description Name/Title

Technology Support Provides all technology support VP Information Technology

Process Improvement Advises team on process Process Team Lead

Project Manager Manages the business case and Project Manager

MCA-VTU DSCE Page 3 of 136

The following provides a high-level explanation of how the organization, tools,

Roles and Responsibilities: in addition to the Mix-cart Project allowing greater

MCA-VTU DSCE Page 4 of 136

Hardware/Software: in addition to the software and licensing for the project, We

Phase I: Hardware/Software will be purchased and the Mix-cart system will be

MCA-VTU DSCE Page 5 of 136

Today there are very least organizations which are manual.

4.2.Goals and Objectives

Business Goal/Objective Description

MCA-VTU DSCE Page 6 of 136

4.6.Major Project Milestones

MCA-VTU DSCE Page 7 of 136

Milestones/Deliverables Target Date

Plan Goals/Objectives Relationship to Project

6. COST BENEFIT ANALYSIS.

MCA-VTU DSCE Page 8 of 136

Action Description First year costs

MCA-VTU DSCE Page 9 of 136

Action Description First year costs

Approver Title Signature Date

Prof.Rakshita Project guide

MCA-VTU DSCE Page 10 of 136

1.2 FEASIBILITY STUDY

MCA-VTU DSCE Page 11 of 136

2. DESCRIPTION OF PRODUCTS AND SERVICES

MCA-VTU DSCE Page 12 of 136

MCA-VTU DSCE Page 13 of 136

6. ORGANIZATION AND STAFFING

Jan 6, 2018: Initiate Project

February 20, 2018: Project kickoff meeting

March 7, 2018: Complete on-line sales site design

April 25, 2018: Complete testing of on-line sales site

July 21, 2018: Go live with site launch

MCA-VTU DSCE Page 14 of 136

The assumptions for these projections are as follows:

 In store sales projections remain unchanged

9. FINDINGS AND RECOMMENDATIONS

 Will utilize existing technology which lowers project risk

MCA-VTU DSCE Page 15 of 136

9. Minimal increases to staffing are required with no changes to organizational

 Breakeven point occurs early in the second year of operation

MCA-VTU DSCE Page 16 of 136

PROJECT TEAM DESCRIPTION

Outstanding staff/volunteer issues:

DATE: <04, APRIL, 2017>

MCA-VTU DSCE Page 17 of 136

Version Issue Date Changes

Role Name Signature Date ©