E Boutique TutorialsDuniya
E Boutique TutorialsDuniya
COM
E- Boutique
E-Boutique
om
.c
i ya
un
University of Delhi
D
Submitted By:
ls
Sneha Bharti
Komal Bhagat
ia
Kiranjote Kaur
t or
Tu
B.Sc.(H)
Sc.(H) Computer Science
IV Semester
Shyama Prasad Mukherji College
Acknowledgement
On the successful completion of project entitled “E-Boutique” we would like to
express our sincere thanks and profound gratitude to our supervisor
TutorialsDuniya.Com for her kind supervision, valuable guidance and constant
om
encouragement towards fulfillment of this project. The attention and ease with
which she has followed us through to this work can never be aptly repaid.
.c
Sneha Bharti
ya
Komal Bhagat
i
un
Kiranjote Kaur
Certificate
This is to certify that the project report entitled, “E-boutique” has been submitted
by Sneha Bharti, Kiranjote Kaur and Komal Bhagat for partial fulfillment of the
requirement of Bachelor of Computer Science (H) embodies the work done by
om
them during semester IV of their course under the supervision of
TutorialsDuniya.Com from Shyama Prasad Mukherji College.
.c
ya
TutorialsDuniya.Com
i
un
D
ls
ia
t or
Tu
Introduction
om
about the boutique, select the boutique of their choice and can make
payment. The software will able to manage customer’s data, data about
boutiques and order placed by the customers. Boutique manager will be able
to add, edit and view services provided by boutiques. Customer’s
.c
information will be kept confidential by system and security is provided by
login procedure.
i ya
un
D
ls
ia
t or
Tu
INDEX
1. Problem statement
2. Process model
om
3. Project Scheduling
.c
5. Entity Relationship Diagram
ya
6. Data Dictionary
i
un
8. Data Flow Diagram Level-1
15. Testing(Whitebox)
Problem Statement
The problem definition for the system is to develop an online platform for boutiques to mark
their presence digitally via a user friendly with 24x7 availability.
Objective: - The purpose of this software is to develop e-boutique store where users can
om
browse the catalog and select the boutique of their choice.
An overview of functionalities:-
Anyone can register and view available boutiques.
There are three roles available : Registered user, Unregistered user, Boutique manager
.c
Unregistered user can view available boutiques.
Registered user can view and place an order.
ya
A boutique manager(admin) can add new boutique, services, edit information
and remove services provided by boutiques.
Filtering of services on users choice such as :
i. Category- Men, Women, children
ii.
i
Occasion- Marriage, Party, Conference, Interview etc.
un
iii. Ethnic/Western wear
iv. Alterations
v. Famous boutique/ Pocket friendly
D
Add to cart
Contact Us – for technical help.
Order Confirmation and acknowledgement for the same via sms as well as via email.
ls
Web Pages:
Home page- The home screen will consist of screen where one can browse the through
or
Contact us page - Registered and unregistered users can contact website owners or
administrator for technical help.
Register page- New users can register here.
Login page- Login page for both users and administrators.
Process Model
The basic idea in Prototype model is that instead of freezing the requirements before a design or
coding can proceed, a throwaway prototype is built to understand the requirements. This
prototype is developed based on the currently known requirements. Prototype model is
a software development model. By using this prototype, the client can get an “actual feel” of
om
the system, since the interactions with prototype can enable the client to better understand the
requirements of the desired system. Prototyping is an attractive idea for complicated and large
systems for which there is no manual process or existing system to help determining the
requirements.
The prototype are usually not complete systems and many of the details are not built in the
.c
prototype. The goal is to provide a system with overall functionality.
i ya
un
D
ls
functional, application.
Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
Incomplete application may cause application not to be used as the
full system was designed
Incomplete or inadequate problem analysis.
om
The desired system needs to have a lot of interaction with the end users.
Typically, online systems, web interfaces have a very high amount of interaction with
end users, are best suited for Prototype model. It might take a while for a system to be
built that allows ease of use and needs minimal training for the end user.
.c
Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.
i ya
un
D
ls
ia
t or
Tu
Project Schedule
JANUARY FEBUARY MARCH APRIL
Week 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
1.PROBLEM
STATEMENT
om
2. SOFTWARE
MODEL
3.PROJECT
SCHEDULING
.c
4.SRS
ya
5.ER DIAGRAM
6.DATA
DICTATIONARY
7.CONTEXT
i
un
LEVEL DIAGRAM
8.DFD 1
D
9.DFD 2
ls
10.USE CASE
DIAGRAM
ia
11.USE CASES
12.FUNCTION
or
POINT METRIC
13.COCOMO
MODEL
t
14.RISK
Tu
ANALYSIS
15.TEST
CASES
Task Table
om
1.PROBLEM Wk1,D1 Wk1,D3 Wk2,D3 Wk2,D3 Sneha 2P-D
STATEMENT Kiranjote
2. SOFTWARE Wk2,D3 Wk2,D3 Wk3,D1 Wk3,D1 Komal 1P-D
MODEL
.c
3.PROJECT Wk3,D2 Wk3,D2 Wk3,D5 Wk3,D5 Komal 2P-D
SCHEDULING Kiranjote
4.SRS Wk4,D1 Wk4,D1 Wk1,D5 Wk1,D5 Sneha 2P-D
ya
Kiranjote
5.ER-Diagram Wk2,D1 Wk2,D2 Wk2,D5 Wk2,D4 Sneha 1P-D
i
un
7.CONTEXT Wk3,D1 Wk3,D1 Wk3,D5 Wk3,D5 Kiranjote 1P-D
LEVEL
DIAGRAM
8.DFD Level 1 Wk4,D1 Wk4,D1 Wk1,D5 Wk1,D6 Sneha 1P-D
D
MODEL
14.RISK Wk2,D4 Wk2,D4 Wk3,D2 Wk3,D3 Kiranjote 1P-D
ANALYSIS
t
CASES
om
project's target audience and its user interface, hardware and software requirements. It
defines how our client, team and audience see the product and its functionality.
Nonetheless, it helps any designer and developer to assist in software delivery lifecycle
(SDLC) processes.
1.1 Purpose
.c
This document provides an overview of the final product and assures the project
management stakeholders and client that the product which is being delivered meets
what they asked for. The document is intended for the customer and the developer
ya
(designers, testers, maintainers). The readers should have basic knowledge about the
terms used for an e-commerce website. Knowledge and understanding of UML
diagrams is also required.
i
un
1.2 Scope
The software product allows customers to browse the catalog and select the boutique of
their interest. The selected boutique will be added in a cart. At checkout time, customer
D
will be asked to fill or select an appointment address and proceed for the transaction. An
e-mail notification is sent to the customer as soon as an appointment with the selected
ls
boutique is created. It focuses on the company, the stakeholders and applications, which
allow for online sales, distribution and marketing of boutiques’ services and products.
ia
1.4 References
1. Software Engineering 7th Edition by Roger Pressman
2. IEEE recommended Practice for Software Requirement Specifications.
t
ISO/IEC/IEEE 29148:2011
Tu
1.5 Overview
The remaining sections of this document provide a general description, including
characteristics of the users of this project, the product's hardware, and the
functional and data requirements of the product. General description of the project is
discussed in section 2 of this document. Section 3 gives the functional requirements,
data requirements and constraints and assumptions made while designing the E-
Boutiques.
2. Overall Description
E-boutique is an electronic commerce system which provides means by which customer
can view available boutiques. Browse for more information about the boutique, select the
om
boutique of their choice and can make payment. The software will able to manage
customer’s data, data about boutiques and order placed by the customers. Boutique
manager will be able to add, edit and view services provided by boutiques. Customer’s
information will be kept confidential by system and security is provided by login
procedure.
.c
2.1 Product Perspective
ya
The application will be window-based, self-contained & independent.
i
un
2.1.2 Hardware interface
1. The application must run over the internet, all the hardware shall require to
D
connect internet will be hardware interface for the system. As for e.g.
Modem, WAN – LAN, Ethernet Cross-Cable.
2. Minimum 512MB RAM.
ls
4. Pentium IV 1GHz
3. WAMP Server
The e-boutique system shall use the HTTP protocol for communication over the
internet and for the intranet communication will be through TCP/IP protocol suite.
om
2. Minimum 512MB RAM.
2.1.6 Operations
None.
.c
2.1.7 Site Adaptation Requirements
The terminal will have to support the hardware and software interfaces specified
ya
in above sections.
i
un
The software represented by this report is meant to offer the following functionalities.
The system will display all the products that can be configured, allow user to select the
D
product to configure, enable user to add one or more component to the configuration.
The system will display detailed information of the selected products and provide browsing
options to see product details.
ia
. The system will display both the active and completed order history in the customer profile
and will allow user to select the boutiques from the order history.
The system will display the detailed information about the selected order, most frequently
searched items by the user in the profile.
The system will provide online help, FAQ’s customer support, and sitemap options for
customer support.
Email confirmation.
The system will maintain customer email information as a required part of customer profile
and will send an order confirmation to the user through email.
om
Provide shopping cart facility.
The system will provide shopping cart during online purchase and will allow user to
add/remove products in the shopping cart.
.c
Allow multiple payment methods.
. The system will display available payment methods for payment and will allow user to
ya
select the payment method for order.
Allow Online Product reviews and ratings
The system shall display the reviews and ratings of each product, when it is selected as well
as enable the user to enter their reviews and ratings.
i
un
Offer online promotions and rewards
The system will display all the available promotions to the user and will allow user to select
available promotion.
D
Online Purchase of products
The system shall allow user to confirm the purchase and to enter the payment information.
ls
Educational level: User should be atleast 12th pass so that he/she should
know terms related to e-commerce website and how to make a transaction.
or
application on a computer.
Tu
2.4 Constraints
1. Validate for registered user via email id and password.
2. Be robust enough so that users do not corrupt it in the event of application.
3. Be able to handle multiple users at the same time.
2.5 Assumptions and Dependencies
1. Boutique managers’ have the proper system for the product and service delivery.
2. Users have access to internet.
3. Specific Requirements
This section contains all the software requirements at a level of detail sufficient to enable
designers to design or system to satisfy these requirements, and testers to test that the
om
system satisfies those requirements.
The application will have user friendly and menu based interface. There are many types
.c
of interfaces as such supported by the E-Store software system namely; User Interface,
Software Interface and Hardware Interface.
The protocol used shall be HTTP.
ya
The Port number used will be 80.
Following Screens will be provided:
i
1. Home Page: - The home page for online boutique store will have different links to
un
other pages that act like directions for the users.
2. User Registrations Page:- Enable users to register before doing any transaction or
using the system to order.
3. Login Page: - Registered user uses the username and password to login to their
D
system accounts and orders using the system.
4. Boutique Page: - Shows available boutiques, used as products display.
5. Customer cart Page:- It shows the boutiques list he/she has selected but haven’t
ls
ordered.
6. Checking out Page:- when customers wants to place an order to boutique , some
ia
7. User profile page:- Display users details and allow editing of both login and profile
details.
8. Admin login Page:- Allow admin to log in the system to enjoy management
t
privileges.
Tu
9. Admin home page:- Displays all privileges an admin have include viewing the
following reports:
Viewing of registered customer
View boutique
Add boutique
View total orders in a day
om
help and comment.
.c
2. High data transfer rate
3. 24/7 data connection should be available
4. 95% of the transactions shall be processed in less than 3 sec.
ya
3.4 Logical Database Requirements:-
The application communicates with the internal database and PayPal service is provided
i
for Payment purpose as an external interface which will access users bank database.
un
3.5 Software system attributes:-
3.5.1 Security:-
D
3.5.2 Probability:-
ls
password B_id
U_id B_img
sex category
username address
om
User Views Boutique
Contactno
.c
Write
Email_id feedback
ya
Adds
Make feedback
payment comment Name
i
un
FeedbackType
Admin Email
PinNo
password
Register Admin_id
Account
D
places
Emailid BankName
ls
AccountNo
provides
ia
Complaint Views
ComplaintId
or
Message
orders
DateOfPurc Price_s
t
hase
services
Tu
Order_id description
ShippingAddress
Ser_id
price occasion
User_name
Service_name
Data Dictionary
User Table
S No. Field Type Data Type Field Length Description
1. U_Id Number 20 Unique ID of user
2. Password Varchar 20 Password for login check
3. Username Varchar 40 Name of user
om
4. Email Id Varchar 30 Email id of user
5. Contact No Number 10 Contact no. of user
6. Sex Char 10 Sex of user
.c
Boutique
ya
S No. Field Type Data Type Field Length Description
1. B_ ID Number 20 Unique id of Boutique
2. B_IMG Image File - Image of Boutique
3. Address Varchar 60 Address of Boutique
4. Category Varchar
i 20 Category-Men,Women,Kids
un
Services
D
Admin
S No. Field Type Data Type Field Length Description
t
Bank Account
om
1. Bank Name Varchar 20 Name of bank
2. Account No Number 20 Account no of
user
3. PIN No Number 4 PIN no of user’s
ATM
.c
Orders
S No. Field Type Data Type Field Length Description
1. Order_Id Number 20 Unique id of order
ya
2. Username Varchar 20 Name of user who has ordered
3. Date_of_purchase Date 20 Date when the order is placed
4. Price Decimal (20,2) Total price
5. Quantity Number 20 Quantity of the order
6. Shipping_Address Varchar
Type
2. Comment Varchar 40 Message of the customer
ia
Complaint
or
Update profile
om
View Order History
.c
View Boutique
ya
Place order
i
un
Submit Feedback
Registered
User
D
Registration
ls
Admin
Login
ia
or
Add Boutique
Tu
Visitor
Update /Edit Boutique
Register complaint
Resolve complaint
USE CASES
Login
Brief Description: This use case describes how a user will log onto the “E-Boutique”
software.
om
Actors: The Following actors interact and participate in this use case.
1. Registered user
2. Administrator
.c
Flow Of Events
Basic Flow:
ya
1. The system requests that the actor enter his/her id and password.
i
un
3. If registered, the user is granted access.
Alternative Flow:
If the id and password don’t match, the user is prompted by an error message that either directs
D
them to re-enter password or get registered before using the software.
Pre-conditions: The actor must have registered himself/herself prior to logging in.
ia
Registration
t
Tu
Actors: The Following actors interact and participate in this use case.
1. Unregistered user
Flow Of Events
Basic Flow:
1. The system takes username, password and Email id and of the user.This data is stored
into a database. Returns an integer value based on successful completion of input query
or reports an error in case of failure.
Alternative Flow:
om
In case user is not registered into the system, the user is notified and asked to re-enter the data,
correctly. If no entry is made, the database holds its status as it is.
.c
Pre-conditions: None.
Post conditions: If this case is successful, respective user get registered into the system
ya
and data is stored in the database permanently.
i
un
View Boutique
Brief Description: This use case describes how the actors can browse different boutiques
D
stored in the system’s database.
Actors: The Following actors interact and participate in this use case.
ls
1. Registered user
ia
2. Unregistered user
3. Administrator
or
Flow Of Events
Basic Flow:
t
1. Takes as parameter category (men, women, or kids), sorts the boutiques in database
Tu
based on selected category. It further filters the database based on selected sorting
order and available filtering options.
Alternative Flow:
In case no matching boutique is found with a record, the user is notified and asked to re-select
the options to browse other categories boutique.
Pre-conditions: None
Post conditions: If this case is successful, Different boutiques matching the selected
categories and filtering options is fetched from the database and is displayed to the user.
om
Extension Points: None
.c
Brief Description: This use case describes how user’s orders history is displayed to the
user
ya
Actors: The Following actors interact and participate in this use case.
1. Registered user
Flow Of Events
i
un
Basic Flow:
1. Fetches from the boutique database and display order Ids, amount, purchase date.
D
Alternative Flow:
screen.
Pre-conditions: The user must be logged into the system to use this case.
or
Post conditions: If this case is successful, an order history is displayed that can be
printed as well.
Submit Feedback
Brief Description: This use case describes how the registered user submits his/her
feedback.
Actors: The Following actors interact and participate in this use case.
1. Registered user
Flow Of Events
Basic Flow:
1. This function accepts one parameter- the feedback type – good, very good, excellent,
average, poor. The system then saves the feedback as a record in the E-boutique
database and displays a successful submission message to the user.
om
Alternative Flow: If the user doesn’t give a feedback then there will be no change in the status
of the database.
.c
Pre-conditions: The user must be logged into the system to use this case.
ya
Extension Points: None
i
un
Add boutique
Brief Description: Let’s admin to add a new boutique in the system’s database.
Actors: The Following actors interact and participate in this use case.
D
1. Teacher
ls
Flow Of Events
Basic Flow:
ia
1. The actor is made to enter different information about the boutique as- Name,
address, category, pricelist, image of boutique, types of services it provides.
or
2. These details are stored in the database and a new boutique id is generated for the
newly added boutique.
t
Alternative Flow:
Tu
There will be no change in the status of the database if the actor doesn’t fill all the input field
correctly and will be asked to re-enter the data.
Pre-conditions: The user must be logged into the system to use this case.
Post conditions: If this case is successful, a new boutique will be added in the database
and user will get a message of successful submission of the data.
om
Update/Edit boutique
Brief Description: Describes how the admin updates the boutiques’ detail in the
database.
Actors: The Following actors interact and participate in this use case.
.c
1. Admin
ya
Flow Of Events
Basic Flow:
i
1. The admin selects the boutique which is to be updated.
un
2. The admin can enter the input field that is to updated.
Pre-conditions: The user must be logged into the system to use this case.
ia
Post conditions: If this case is successful, update value will be reflected in the database.
Register complaint
t
Tu
Actors: The Following actors interact and participate in this use case.
1. Registered user
Flow Of Events
Basic Flow:
1. The function accepts as parameters- Email id, username, and a complaint message -
which is stored in the database.
om
Alternative Flow: None
.c
Post conditions: If this case is successful, a login id given to the user and a successful
submission message is displayed.
ya
Extension Points: None
Resolve complaint
i
un
Brief Description: Describes how a registered complaint is resolved.
Actors: The Following actors interact and participate in this use case.
D
1. Admin
Flow Of Events
ls
Basic Flow:
ia
1. The admin retrieve the complaint message saved in the database and send a reply to
user who has registered the complaint via mail.
or
Pre-conditions: The user must be logged into the system and complaint should be in the
Tu
database.
Post conditions: If this case is successful, a reply message is sent to the user.
Brief Description: Describes how an admin views total orders made in date wise.
Actors: The Following actors interact and participate in this use case.
1. Admin
Flow Of Events
om
Basic Flow:
1. The admin enters the date and the functions displays the total orders made in the
selected date with order Ids, amount, boutiques name.
.c
Alternative Flow: If no orders have been made on the selected date then nothing will be
returned by the function.
ya
Special Requirements: None
i
Post conditions: Order Ids, amount, boutique’s name will be displayed from where order
un
has been made.
Update profile
D
Actors: The Following actors interact and participate in this use case.
1. Registered user
ia
Flow Of Events
or
Basic Flow:
1. The function will return the user’s profile details in editing field where user can
update hid/her name, phone no, email id, shipping address and the updated value will
t
Alternative Flow: In case no field is updated then the status of the database will remain
unchanged.
Pre-conditions: The user must be logged into the system and user’s various details
should be in the database.
om
Place order
Actors: The Following actors interact and participate in this use case.
.c
1. Registered user
Flow Of Events
ya
Basic Flow:
1. The user will be asked to verify his/her order before paying. The user can make
i
changes before checking out. Once the user verified order he/she is asked to enter
un
credit/debit card no, cvv code, name of the customer holding bank account and one
time password.
2. After submitting the card details, transaction will be proceeded via customer’s bank
interface. After successful transaction an order Id will be generated and a payment
D
Alternative Flow: If transaction fails the customer is notified of the same and is asked to pay
ls
again.
Pre-conditions: The user must be logged into the system and have ordered some items.
or
Product metrics
Project metrics and the indicators derived from them are used by the project manager and a
software team to adapt project work flow and technical activities. The intent of project metrics is
twofold. First, these metrics are used to minimize the development schedule by making the
adjustment necessary to avoid delays and mitigate potential problems and risks. Second, project
metrics are used to assess product quality on an on-going basis and when necessary modify the
om
technical approach to improve quality.
.c
using an empirical relationship based on countable (direct) measure of software information
domain and assessments of software complexity.
ya
Function Points:
Function point measure functionality from user point of view, that is , on the basis of what user
request and receives in return from system.. Function points are computed by completing the
i
five information domain characteristics are determined and counts are provided in the
un
appropriate table location. Information domain values are defined in the following manner:
1. Number of user inputs: Each user input that provide distinct application oriented data
to the software is counted. Input should be distinguished from inquiries, which are
counted separately.
D
2. Number of user outputs: Each user output that provides application oriented
information to the user is counted. In the context output refer to reports screen error
ls
message etc. Individual data items within a report are not counted separately.
3. Number of user inquiries: An inquiry is defined as an on line input that result in the
generation of some immediate software response in the form of an on line output. Each
ia
5. Number of external interfaces: All machine readable interfaces (e.g., data files on
storage media) that are used to transmit information to another system are counted.
Once these data have been collected, a complexity value is associated with each count.
t
Organizations that use function point method develop criteria for determining whether a
Tu
om
Number of user enquiries 0 0 0
Number of internal logical files 1 7 7
Number of user external interfaces 1 10 10
Total 290
.c
The f1 (i=1 to 14) are “COMPLEXITY ADJUSTMENT VALUES” based on responses to the
following question: Rate each factor on an influence scale
ya
1. Does the system require reliable backup and recovery? 5
2. Are data communications required? 1
3. Are there distributed processing function? 1
4. Is performance critical? 3
i
un
5. Will the system run in an existing, heavily utilized operational environment? 3
6. Does the system require on line data entry? 5
7. Does the on line data entry requires the input transaction to be built over multiple screens 1
or operation?
8. Are the master files updated on line? 5
D
14. Is the application designed to facilitate change and ease of use by the user? 5
∑ (F) =43
or
FP = 313.2
Tu
Risk analysis
Risk analysis is a series of steps that help a software steps that help a software team to
understand and manage uncertainty. A risk is a potential problem – it might happen, it might not.
om
1. Risk identification i.e., to recognize what can go wrong.
2. Analysis of each risk to determine the likelihood that it will occur and the damage that it
will do if it does occur.
3. Ranking of risks, by probability and impact.
.c
4. Development of plan to manage those risks with high probability and high impact.
Risk identification
ya
Product Size (PS): Risk associated with overall size of the product to be built or
modified.
i
Business impact (BU): Risk associated with constraints associated by the management
un
or the market place.
Customer characteristics (CU): Risk associated with sophistication of the customer and
developers ability to communicate with the customer in a timely manner.
Technology to be built (TE): Risk associated with the complicity of the system. To be
D
build and new risk of the technology that is packed by the system.
Development Environment (DE): Risk associated with the availability and quality of
ls
Process Definition (PD): Risk associated with degree to which the software process has
been defined and is followed by the developed organization.
or
The following questions have derived from risk data obtained by surveying experienced software
project managers in different parts of world.
t
Tu
-Yes
-Yes
-Yes
-No
om
Does project meet deadline?
-Yes
.c
-Yes
Are end users enthusiastically committed to the system and product to be build?
ya
-Yes
i
un
-No
Do all customers agree on the importance of the project and on the requirements for the system?
-Yes
D
-Yes
-Yes
t or
Tu
Risk projection
Risk projection also called risk estimation, attempts to rate risk in two ways –the likelihood or
probability that the risk is real and the consequences of the problem associated with the risk,
should it clear.
om
A risk table is a simple technique for risk projection.
.c
low
Large no. of user than planned PS 50% 3
ya
Less reuse than planned PS 40% 3
End user may resist the system BU 30% 3
Delivery deadline will be tightened BU 60% 2
Funding will be lost
i
CU 30% 1
un
Customer will change requirements PS 80% 2
Technology will not meet expectation TE 30% 1
D
Impact values:
1-catastrophic
or
2-critical
3-marginal
t
Tu
4-negligible
om
Post architecture state model
Our project is based on application based model as this model is used during early stages of
software when prototyping of user interfaces, consideration of software, system interaction,
assessment of performance and evaluation of technology maturity are paramount.
.c
The COCOMO II software model which we are using uses object points:
ya
OBJECT TYPE COMPLEXITY WEIGHT
The object count is determined by multiplying the total number of object instances by weighing
ls
factor. When component based development or general software re-used is to be applied, the
percent of re-use is estimated and object count is adjusted. In our software project, since we’re
not re-using any of the components, the percent re-use here is zero.
ia
PROD 4 7 1.3 25 50
PROD = NOP/person-month
No of screens = 26
om
No of reports = 1
There are 25 simple screens and 1 medium screens and 1 simple reports in our case therefore,
.c
= 25+4+1=30
ya
= 30*[(100-0)/100]
= 30
i
un
Person-month assumed to be very low = 4
PROD = 30/4
= 7.5 ~8
D
PSEUDOCODE
om
2. READ username
3. READ password
4. READ confirm_password
5. IF confirm_password matches password
6. Then
.c
7. DO WHILE Email is not of valid format
8. READ Email
ya
9. END DO
10. Register the user
11. ELSE
12. Show “password doesn’t matches”
13. END IF
i
un
14. END DO
Flow Chart:
1
D
2
ls
3
ia
or
5 4 6
t
Tu
6 9
om
5, 7 6
R3
R2
.c
ya
8
9
i
un
D
CYCLOMATIC COMPLEXITY
ls
(1) {G}=E-N+2
Here no of edges, E=6
No. of nodes, N=5
ia
So, V{G}=6-5+2=3
Hence, cyclomatic complexity is 3.
or
Test Case
Input Actual Output Expected Output
ID
To be observed Show error message
1 Confirm_password=Invalid
om
after execution
To be observed
2 Confirm_password=Valid Go to Email field
after execution
Registration successful
3 Email= Valid
Reread Email from Email input
.c
4 Email= Inalid
field
i ya
un
D
ls
ia
t or
Tu