Analysis

Project Title : A point of Sale System for a Fast Food Chain

Description of point of sale system to be implemented 
 - Parts of system : cashier, point of sale system.
 - Input of system : food selected payment mode.
 - Output of system : receipt, total cost, change (for payment by cash)
 - Constraints :customer must pay first before collecting food
 - Performance : fast service, accurate calculation of change
 - Tasks : listed in initial requirement
 - Software maintenance : maintain software, technical support

In the development of our software, we decided to adhere to the Spiral Model in the progression of the various processes in our project. The Spiral Model may be viewed as a metamodel. Due to the nature of our project, several cycles through the planning, risk analysis, engineering and eventually customer evaluation may be needed. A metamodel can also accomodate a combination of the other software development process models, namely, the waterfall model, the prototype model and the cleanroom model.

The following shows the cartesian diagram of the Spiral Model :

We have chosen to use the object oriented approach in developing the software project. This choice is mainly due to the list potential benefits that we have came up with:

Potential benefits of OOA
1. Better modeling of the problem domain

2. Better overall software design with a focus on class structure

3. More flexible and maintainable systems through better class partitioning

4. Good documentation (the notations)

5. Single central overall design notation (object model)

6. Flexible approach to project phasing

7. Assistance in typing down requirements

8. Less work in the long run

Project Estimates

Constructive Cost Model (COCOMO)

The Basic and Intermediate COCOMO Models are used to predict the total development effort required to produce the system software in terms of manpower and duration.

1. The Basic COCOMO Model

The Basic COCOMO equations take the following form:

E = ab (KLOC) exp(bb)

D = cb (E) exp(db)

where E = the effort applied in person-months

D = the development time in chronological months, and

KLOC = the estimated number of delivered lines of code for the
project (expressed in thousands)

The coefficients ab and cb and the exponents bb and db are given in the table below:

Software Project ab bb cb db
Organic Mode 2.4 1.05 2.5 0.38
Semi-Detached Mode 3.0 1.12 2.5 0.35
Embedded Mode 3.6 1.20 2.5 0.32

Since the project is in Organic Mode,

ab = 2.4 bb = 1.05 cb = 2.5 db = 0.38

Total Estimated Lines Of Codes = 1500

Assume KLOC = 1.5K Lines of Codes.

E = ab (KLOC) exp(bb)

   = 2.4(1.5)1.05

   = 3.67 person-months

D = cb (E) exp(db)

	 = 2.5(3.67)0.38

	 = 4.10 months

2. Estimation Using The Intermediate COCOMO Model

The Intermediate COCOMO equation takes the following form:

E = [ai (KLOC) exp(bi)] * EAF

where E = the effort applied in person-months

KLOC = the estimated number of delivered lines of code for the
project (expressed in thousands)

EAF = the Effort Adjustment Factor

The coefficients ai and bi are given in the table below:

Software Project ai bi
Organic Mode 3.2 1.05
Semi-Detached Mode 3.0 1.12
Embedded Mode 2.8 1.20

Since the project is in Organic Mode, ai = 3.2 and bi = 1.05.

Assume KLOC = 1.5K Lines Of Codes and EAF = Nominal (1.00).

Estimated Effort, E = [ai (KLOC) exp(bi)] * EAF

                          = [3.2(1.5)1.05] * (1.00)

                          = 4.90 person-months

P = LOC / E where P = the productivity of the software development project

Estimated P = LOC / E

	               = 1500 / 3.67

	               = 409 lines of codes per person-months

Average Staffing, AS = E / D

where AS = a measure of the equivalent number of people working
on this project at a given time. The unit for AS is FSP (Full-Time-Equivalent Software Personnel)

Estimated AS = E / D

	                 = 3.67 / 4.10

                   = 0.895 FSP
 

Business Impact Risk:

This is the risk concerning that of not being able to come up with, or produce a product that has a positive impact on the client’s business. If the software produced does not achieve its goals or if it fails to help the business of clients improve in certain ways, the software development basically fails.

Customer Risks:

This is the risk concerning the client’s motivation or willingness in helping the software development team. If the client fails to attend meeting regularly or fails to describe the real needs of the business, the produced software will not be one that will help the business.

Development Risks:

If client fails to provide all the necessary equipment for the development and execution of the software, the software will become a failure. The customer has to be able to provide time and resources for the software development team. If all the reasonable requested resources are not provided to the software development team, the odds of the software development failing will rise greatly.

Employee Risk:

This risk is totally dependent on the ability, experience and willingness of the software development team members to create the working product desired. If the team members are not experienced enough to use the application necessary to develop the software, the development dates will at best be pushed back, or the project will fail. If one or more members of the software development team are not putting in enough effort to finish the project, it will cause the project to fail. Employee risk is one of the major risk to consider while managing the software development.

Process Risks:

Process risk involves product quality. If the product developed does not meet the standards set by the customer or the development team, it is a failure. This can happen because of the customer’s failure to describe the true business needs, or the failure of the software development team to understand the project. Product quality may also include lack of proper documentation, lack of error checking, program prone to failure, etc.

Product Size:

This risk involves misjudgment on the part of both the customer and the project manager. If the customer fails to provide the proper size of the product that is to be developed, it may cause major problems for the completion of the project. If the project manager misjudges the size and scope of the project, the formed team may be too small or too large for the project, resulting in not being able to complete the project either due to lack of time (team too small) or lack of finance (team too large).

Technology Risk:

Technology risk involves using technology that already is or is soon to be obsolete in the development of the software. Such software will only be functional for short period of time thus taking away resources from the customer. Since technology changes rapidly, it is important to treat this risk seriously. If the customer request use of software that will soon be obsolete, the software development team must give professional advise to the customer to reconsider.