You are on page 1of 10

ATAL BIHARI VAJPAYEE- INDIAN INSTITUTE OF INFORMATION

TECHNOLOGY AND MANAGEMENT


GWALIOR-474015

E-COMMERCE PRICE COMPARISON


SOFTWARE PROJECT ESTIMATION REPORT

Submitted By:

Azmeera Deepika(2018IMT-024)

Nanduri Srinivas(2018IMT-055)

Raparthi Sai Madhuri(2018IMT-080)

Sana Jahnavi(2018IMT-089)
1. Size Estimation

1.1. Introduction

Software Engineering is an experimental and logical technique for developing any software
project. Size estimation of the software product is one of the concepts of Software
Engineering. Line of Code (LOC), Constructive Cost Model (COCOMO), Agile (Story
Points) and Function Points (FP) are the leading techniques for estimating the size of the
software. From the size, we can easily calculate the cost and price of the software product.

1.2. Function Points


Function Points: Function Point method is independent of the language, tools, or
methodologies used for implementation i.e., they do not take into consideration of
programming languages, management systems, processing hardware, any other database
technology or any platform. Function points can be expectable from requirement specifications
or design specifications, thus creating it possible to guess development effort in premature
phases of development. Function points are directly linked to the statement of requirements;
any alter of requirements can simply be followed by a re-estimate. Function points are founded
on the system user’s external opinion of the system; non-technical users of the software system
have a greater understanding of what function points are computing.

1.3. Limitations of Function Point


a) The correctness in function point calculation is extremely difficult for contemporary
software like E- Commerce system. As on International Function Point Users Group
(IFPUG) study, defects per function point are 4.5.
b) Complex algorithms and heavy calculations that are a part of transaction’s processing
logic don’t seem to be separately considered as part of the functional sizing.
c) Functionality enabled/disabled through ‘application configuration’ kind of work doesn’t
fetch additional size.
d) FP only considers interactions between the (external) user and therefore the application.
Interactions between various internal parts of the application aren’t considered by the FP
model.
e) Repositioning of User Interface (UI) elements without adding/deleting/modifying any of
them isn’t included within the sizing process.
f) If the identical output is formed in multiple formats or methods (e.g. MS-Excel and
PDF), no additional size is calculated for the multiple formats (i.e., only 1 format is
included for the size calculation).

1.4. Size Estimation of E-Commerce Price Comparison using


Function Points
1. ECSSIZE – E-Commerce Comparison System Size : E-Commerce Comparison is a
complex software structure includes Application Programs, Text Documents and help files,
WebPages, Databases, Networking and Security Software and Fund and Product
Transaction. So a single size estimation technique is not sufficient to estimate the size of
the ECommerce Comparison system accurately. So that, we need a specific and
specialized technique to E-Commerce system for measuring the size. That is why, we are
using a new technique ECSSIZE.

2. Functional Units for E-Commerce Comparison System : The six functional units are
present with the E-Commerce System a) External Input (EI) b) Internal Input (II) c) External
Output (EO) d) External Inquiry (EQ) e) Internal Logical Files (ILF) f) Interface
Table i: E-Commerce Function Points

S.No Application Type Functional Type Functional Unit


1 Application Programs Application External Inputs (AEI) EI
Application Internal Inputs (AII) II
Application External Output (AEO) EO
Application External Inquiries (AEQ) EQ
Application Internal Logical Files (AILF) ILF
Application External Interface Files (AEIF) EIF
2 Web Pages Webpage External Inputs (WEI) EI
Webpage Internal Inputs (WII) II
Webpage External Outputs (WEO) EO
Webpage External Inquiries (WEQ) EQ
Webpage Multimedia System Files (WMSF) II
Webpage Multimedia Drivers (WMD) ILF
Webpage Navigation Points (WNP) EIF
Webpage Dynamic Points (WDP) ILF
3 Database Database External Input (DEI) EI
Database Internal Inputs (DII) II
Database External Outputs (DEO) EO
Database External Queries (DEQ) EQ
Database Size (DS) II
Database Keys (DK) ILF
Database Table Relationships (DTR) ILF
Database Remote Accessing (DRA) EIF
4 Networking & Securities Security User Names (SUN) EI
Security Passwords (SP) EI
Security Outputs (SO) EO
Security Algorithms (SA) ILF
Security Encryption Keys (SEK) ILF
Security Decryption Keys (SDK) ILF
Networking System Distribution (NSD) EIF
5 Transactions Commodity Information Inputs (CII) EI
Money Transaction Inputs (MTI) EI
Commodity Information Outputs (CIO) EO
Money Transaction Outputs (MTO) EO
Number of Banks Involved (NBI) ILF
Number of Logistic Units (NLU) ILF
Number of Insurance Agencies (NIA) ILF
Transaction Inquiries (TQ) EQ
External Agents Involved (EAI) EIF
6 Documents Document External Inputs (DEI) EI
Document External Inquiries (DEQ) EQ
Functional Units Weighting factors
Low Average High Very
High
External(EI)
Inputs 3 4 6
Internal(II) 10
External Output (EO) 4 5 7 11
External Inquiries 3 4 6 10
(EQ)
Internal Logical Files 7 10 15 20
(ILF)
External Interface 5 7 10 15
Files (EIF)

3. Function Point Calculation


USER INPUT = 30
USER OUTPUT = 20
USER INQUIRIES = 15
USER FILES = 2
EXTERNAL INTERFACE = 1

F = 14 * scale
Scale varies from 0 to 5 according to character of Complexity Adjustment Factor (CAF).
Below table shows scale:

0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential

As complexity adjustment factor is average (given in question), hence, scale is 3


F= 14*3=42

CAF = 0.65 + ( 0.01 * F )


CAF = 0.65 + ( 0.01 * 42 ) = 1.07

As weighting factors are also average hence we will multiply each individual function point to
corresponding values in TABLE.
UFP = (30*4) + (20*5) + (15*4) + (2*10) + (1*7) =307

FP = UFP * CAF
FP=307*1.07=328.49
2. Effort and Time Estimation

2.1 Introduction
Software Cost Estimation models [1] can be possible by several estimation models such as
Line of Code, Function Point and Constructive Cost Model (COCOMO). The original
COCOMO model is one of the most widely practical and popular among the software
development community due to some flexibility usages. Using this model, we will estimate
the cost of the software very easily. There are two varieties of COCOMO (Constructive Cost
Model) i.e. COCOMO I and COCOMO II. The fundamental objective of COCOMO model
estimates the cost of the software and helps the developers for further estimation. It also
helps for software decision making because the cost of application is the backbone of the
application. It not only offers a cost estimation tools, but also provides a good number of
parameters which explain what the model is estimating and why it produces the estimate it
does. COCOMO I is actually a hierarchy of three sub models and each sub model is
progressively more details than the other. The first sub-model is Basic COCOMO. It is a
single valued model and calculates the software development cost and effort estimation of a
program by measuring Lines of Code (LOC).
Basic COCOMO further divided into three modes based on the nature of the software
project. First is Organic Basic COCOMO. It is employed in small size simple software
project that developed by small team with good experiences. Second is semi-detached
Basic COCOMO, employed in medium size software project developed by team with
diversified levels of experience. Third is embedded basic COCOMO, that is used
in massive software project with strict resource constraints development by multiple
teams acquiring the immense levels of experience and sophistication.
The second sub model is intermediate COCOMO, it simply ‘Basic COCOMO’ plus a
collection of subjective ‘Cost Drivers’. These drivers are used to access product, computer
and project attributes of a software project. The evaluator uses a six-level scale to decide
where each attribute fall. When an attribute is accessed, it produces an adjustment factor.
This adjustment factors are multiplied together and give an Effort Adjustment Factor (EAF)
that is usually equal to a value between 0.9 and 1.4. The EAF is then mathematically
applied on all basic COCOMO’s formulas.
The third sub model is detailed COCOMO, as the name indicates, it produced the most
accurate cost estimation of all three sub models of COCOMO I. It combines Basic and
Intermediate COCOMO together boosted by an assessment of every cost Driver’s impact on
each stage of ‘Barry Boehm’s software engineering processes.
On the other hand, COCOMO II divided into four sub models. Each sub model is predicated
on different input and estimates the effort of different activities of a software project.
Application composition is the first sub-model. It estimates the effort of prototype systems
developed using script, database programming etc. Second sub-model is ‘Early Design’ that
calculates the initial effort based on system requirement and style option and uses function
points as input. Third sub- model is “Reuse’, it estimates the effort of integrating reusable
automatically generated line of code as an input. Fourth sub- model is ‘Post Architectural. It
estimates the development effort of system design specifications and use line of source
code as an input.
2.2 Calculation of Effort and Time

MODEL USED: ORGANIC


FORMULA USED:
EFFORT(MAN/MONTH) = 32 *(KLOC)^1.05 PM
TDEV = 2.5 *(EFFORT)^0.38 MONTHS

Calculating Total LOC:


Webpage Name Numbers of Lines of Code

About Us 101 LOC


Book Details 119 LOC
Categories 376 LOC
Home 91 LOC
Contact Us 114 LOC
Feed Back 267 LOC
Index 276 LOC
My Account 114 LOC
Payment 245 LOC
Search Results 327 LOC
Shopping Cart 157 LOC
Sign In 118 LOC
Sign Up 190 LOC
Verification 146 LOC
Total=2918 LOC, 2.918
KLOC

Estimating effort

Effort= 32* (2.918)^1.05 =9.851 PM

Estimating Time

Tdev=2.5*(9.851)^0.38=5.963 Months
3. Project schedule breakdown (Activity network and
PERT chart)

The activity network representation is

Task number Task Duration Dependent on


task

T1 Specification 15 -

T2 Design 45 T1
Database

T3 Design GUI 30 T1

T4 Code Database 105 T2

T5 Code GUI part 45 T3

T6 Integrate and 120 T4 and T5


test

T7 Write User 60 T1
Manual
Based on this table the activity network can be shown as:

Projected Parameters Computed from Activity Network

Task EARLY EARLY LATEST LATEST SLACK TIME


START FINISH START FINISH

Specification 0 15 0 15 0

Design database 15 60 15 60 0

Design GUI part 15 45 90 120 75

Code database 60 165 60 165 0

Code GUI part 45 90 120 165 75

Integrate and test 165 285 165 285 0

Write user manual 15 75 225 285 210


The Calculated ES, EF and LS, LF have mentioned the Diagrams below Also the critical
path is analyzed.
The final PERT Chart is presented below.

You might also like