Software Engineering Project

Group 3 Chevaughn Walker 1203383 Carlington Palmer 1201861

Julia Pottinger 1200639 Stephen Hing 1306717

Software Engineering: Analysis & Design Tutor: Arleen Penrose-Whittaker

Company Name: Smartbox Address: Shop 5 Grove Court Shopping Centre, Mandeville, Manchester, Jamaica

Name of System: Ulti-Stocks and Database Management

Members: Chevaughn Walker 1203383 Julia Pottinger 1200639 Carlington Palmer 1201861 Stephen Hing 1306717



Contents Background to the Problem .................................................................................................................................1 Identification and Justification of process model and methodology being used ................................................4 Work Breakdown Structure .................................................................................................................................6 Precedence Table .................................................................................................................................................8 Gantt chart ........................................................................................................................................................ 11 Risk Mitigation table......................................................................................................................................... 12 Risk Mitigation ................................................................................................................................................. 13 Reporting Structure .......................................................................................................................................... 20 Roles and Responsibilities of team members ................................................................................................... 21 A Breakdown of major Roles and their responsibilities ................................................................................... 24 

Accurately assess the needs of their clients, should be familiar with the SDLC. ................................. 25

 Understand what clients want, and to present the proposed solutions in terms that the user can visualize and understand. .............................................................................................................................. 25 Responsibility: ............................................................................................................................................. 25 Responsibility: ............................................................................................................................................. 26 Object Oriented Analysis .................................................................................................................................. 29 Problems, opportunities, objectives and constraint matrix ............................................................................. 32 Actor Identification Form of existing system .................................................................................................... 34 Use Case Identification Form of existing system .............................................................................................. 35 Use Case Diagram of Existing System…………………………………………………………………………………………………………….36

Functional and Non-Functional Requirements .................................................................................................. 37 Actor Form of Proposed System ....................................................................................................................... 40 Entity Relational Diagram ................................................................................................................................. 54 Process Diagram................................................................................................................................................ 55 Appendices........................................................................................................................................................ 58 Minutes ......................................................................................................................................................... 58 Fact- Finding Technique ................................................................................................................................ 61



Project Background



Background to the Problem Smartbox is an authorized dealer in computer and computer supplies. The store is located at Shop 5 Grove Court Shopping Centre, in Mandeville, Manchester, Jamaica. Smartbox’s main purpose is to sell customers the best computers and other technological devices available on the market today. Smartbox also offers computer repairs for customers and it also has Internet Café where customers can access the internet. Smartbox has only one branch which is located in Manchester. It employs on average 10 persons to ensure the efficient running of the organization. Its customer base on a daily basis is between 65-75 individuals. The business has excellent customer support and payment plans. Smartbox offers numerous payment plans, therefore customers can expect affordable deals and ample time to pay for their purchases. Also customers are given the option of exchange, if they no longer want an item they have already purchased.

1



PROJECT PLAN

2



SMARTBOX TECHNOLOGY Phone: 876-962-1946 Email:[email protected] Fax: 876-622-7481 DATE OF REQUEST 02/09/2014

SERVICE REQUESTED FOR DEPARTMENT(S) Customer Services, Repair Services

SUBMITTED BY (key user contact) EXECUTIVE SPONSOR (funding authority) Name: Carlington Palmer Name: Stephen Hing Title: Manager Title: President Office: C00T Office:007 Phone: 567-4564 Phone:878-8756 TYPE OF SERVICE REQUESTED: Information Strategy Planning Existing Application Enhancement Business Process Analysis and Redesign Existing Application Maintenance (problem fix) New Application Development Not Sure Other (please specify ________________________________________________________ BRIEF STATEMENT OF PROBLEM, OPPORTUNITY, OR DIRECTIVE (attach additional documentation as necessary) The manual inventory system at Smartbox does not provide details of when the inventory needs to be restocked. They have to manually check the stocks, as the system does not prompt as to when the stock needs to be refilled. In addition, the method of keeping track of computer repairs and customer information related to these repairs is manual. Both methods of keeping track of inventory, customer information and the related repairs being done can be tedious, time consuming and error prone. BRIEF STATEMENT OF EXPECTED SOLUTION A software is required that should be dedicated to the updating and tracking of stock and customer information and the associated computer repair jobs. The software should help the Smartbox store to keep better track of their stock inventory. It should reduce the time used to check inventory level from two days to a couple of minutes at most. The designed software will have a reorder function that automatically checks and informs Smartbox if items in stock are at a low percentage or number and needs to be refilled. It will also have a database to keep track of the customers that want to have repairs done and also to keep track of the repairs that are done. A form will be created that will ask the user for contact information and other information related to the repair of the item. ACTION (ISS Office Use Only) Feasibility assessment approved Assigned to _Chevaughn Walker_ Feasibility assessment waived

Approved Budget $ __500,000___________ Start Date _21/01/2014_ Deadline 31/03/2014_ Backlogged until date: ______________ Reason: ________________________________________

Request delayed Request rejected Authorized Signatures: _____________________________________ Project Executive Sponsor

3



Name of System: The name of the system is Ulti-Stocks and Database Management. This name is suitable because of its likeness to the problem it was designed to solve i.e. inventory/stock management and creating a customer database to manage customer and stock information efficiently.

Identification and Justification of process model and methodology being used In creating this system, our team will be using the Incremental Process Model and will be combining the Object Oriented and the prototyping methodologies. The Incremental Process Model will be used as the system that will be created working software is required by the client quickly and early during the software life cycle. With the Incremental process model at each stage of the increment a prototype is produced to be shown to the client. As a result of this the users of the system will have an idea of what the system is capable of and if there are any changes that the user wishes to make then it is less costly to change scope and requirements. The Incremental Model was chosen as each week or every two week a specific task was completed and a deliverable was produced at the end of that time. Prototyping and Object oriented methodologies were incorporated in the completion of the system due to the fact that with prototyping a working model of the system will be provided so that the users- employees at Smartbox will get a better understanding of the system being developed. In doing this we will be better able to determine the real needs of the customer, thus by choosing this model the customer will be satisfied. In addition to that we will get a faster user response and this should lead to a better solution being developed.

4



The object oriented methodology is also being incorporated as an object oriented system is easier to manage and maintain and the user will be able to understand the system better as it will be built in a way related to real world scenarios as our software will more closely reflect the real world. In addition the Object Oriented approach is very stable in that if we want to make small changes to the system, the entire system won’t be affected.

5



Work Breakdown Structure Ulti- Stocks & Data Management

Problem Definition

Risk Analysis

Establish Business Objectives

Feasibility Report

System Analysis

Fact Finding /Elicitation

Identification of Problem

Design and Development

Define System Requirements

Cause and Effect Analysis

Network Design

Design System Environment Design Security and System Controls

Implementation, Testing and Training

Database Design

User Interface Design Debug and Test Software

Code User Interface Creating and Testing Databases Train Users Create User Manual

Implement Software Code system and security controls

6

Install Systems Environment and Network



Final product delivered. The work breakdown structure is a fundamental part of defining the project scope. It is used to identify the project deliverables or tasks; the WBS starts at a high level and decomposes the project deliverables to a work package level. At a work package level, it is possible to determine which activities are necessary to produce the deliverable and achieve the key project objectives. The UltiStocks & Database Management System may be broken down into 4 levels.

7



Precedence Table Task Description

Detailed Activity

Task

Predecessor

Duration (Days)

Identification of Problem

Identifying the problem the current system has

A

2

Establish Business Identify what it is the Objectives proposed system should achieve Feasibility Report Estimate budget, deadline. Identify resources Risk Analysis Conduct Risk analysis of the problem at hand Fact Conduct interviews and Finding/Elicitation questionnaires. Cause& Effects Conduct cause and effect analysis of the problem at hand Define System Ascertain from the customer Requirements the features and behaviour of the proposed system.

B

A

3

C

A,B

2

D

A,B

8

E

D

5

F

E

5

G

D

7

Network Design

H

G

15

I

G

25

J

G

16

Define how system will interact with other systems and establish network based on strategic plan.

Database Design

-Create ERD -Choose database structure -Design database architecture -design database schema -design referential integrity constraints

Environment

Define all the technology

Design

required to support the

8



software application Design Security

-define controls for access by

and System

different users

controls

-design how to protect the

K

G

15

L

G

13

M

H,I,J,K,L

15

N

H,I,J,K,L

25

P

N

10

O

P

10

Q

O

5

R

O

7

database from software/hardware failure -define how to protect communications on the network Design User

defines how user interacts

Interface

with system

Code User

Create the user interface

Interface

including GUI, mouse controls, sound, video and voice commands.

Create and Test

Create the actually database

Database

and test its efficiency and correctness

Code system and

Limit access to authorized

security controls

users, and implement other necessary security measures.

Install Systems

Install Operating System,

environment and

Local Area Network

Network

connections and Desktop Computers.

Debug and Test

System Evaluation.

Software

Introduce prototype & observe reactions. Perform cost/benefit analysis.

Implement

Install the software and Test 9


Software

it.

Create User

Create document to guide

Manual

Users on how to use the


S

R

10

T

R

10

system. Train Users

Present final proposal. Train users to use the system



The precedence table shows a list of activities labeled from A-H.



These activities or tasks are represented by their description.



The predecessor is stated if there is any.



The duration for each activity to be completed is stated in the duration’s column. The duration is represented in days.

10



Gantt chart

A 2 B

3

C D

2 8

E

5

F

5

G

7

Task

H

15

I

25

J

16

K

Start Duration

15

L

13

M

15

N

25

O

10

P

10

Q

5

R

7

S

10

T

10

11



Risk Mitigation table There are a number of risks associated with the design and implementation of the Ulti-Stocks and Database Management System. The goal of the risk mitigation plan is to identify as many potential risks as possible. When all risks have been identified, they will then be evaluated to determine their probability of occurrence, and how the project will be affected if they do occur. Plans will then be made to avoid each risk, to track each risk to determine if it is more or less likely to occur, and to plan for those risks if they should occur. The table below outlines the probability of a risk occurring. Impact Values

Description

1 2 3 4

Catastrophic Critical Marginal Negligible

Risk Summary/Description Customer fail to participate Malfunction of Computers / System failure Lack of experience in Software Development Insufficient capital Change of project requirements Insufficient time to complete project A team member may be unable to continue school

Risk Category Customer Risk/Customer characteristics Technology

Probability 14%

Impact(1-4) 3

10%

3

Technical Risk

35%

2

Budget Scope Business Impact Project completion risks

30% 25% 15% 19%

2 3 3 3

12



Risk Mitigation A Team Member may be unable to continue School. Students from time to time are unable to continue with their education at university as a result of financial issues, being deregistered, late enrollment, death or illness. This results in the team being short on a member and this places strain on the remaining members. Mitigation: Meetings will be held to discuss the possibility of any member having to discontinue school. Measures will be put in place to have the work delegated in a manner that if 1 person discontinues then the aspect of the project that they are doing will jeopardize the entire project. Monitoring: Students progress will be monitored to ensure that they are completing their part of the project in a timely manner. They will also be asked on different intervals about their state of affairs with the school. Managing: The team will have to find ways to finish the project without the team member. Delegate work that wasn’t completed by that member and try as best as possible to complete the project on time.

Lack of training and understanding of software If the person that you are creating the software for does not understand how to use the software efficiently, then despite how the good the software that you create is a problem will still exist in the organization. Mitigation: Training session will be held to teach the employees of Smartbox how to use the system properly. There will be a series of training sessions involving various employees with various skill 13



set and roles in the organization. Persons that will be interacting with the system directly will be given special training so as to ensure that are well equipped to use the system. Monitoring: During the development of the system at various stages the employees will be met with and the different software that will be used in the system and the different interfaces will be discussed with them. An idea of their technical experience and what they know and don’t know to do will be gathered and based upon that knowledge training sessions will be held to teach them. Their progress will be monitored and improvements noted and any adjustments that need to be made in their training will be made. Managing: In the event that the employers cannot use the system properly then we would have to create an interface that they can use more easily or that they are more familiar with. If that does not work, then the company will have to hire new employees that are tech savvy and will be better able to use the system. Customer fail to participate An important part of the entire end result is that the customers that come into the store are willing to fill out the form and provide information so that the database can be created on the customers that want to repair electronic items. Mitigation: The team will do their best to create a form that is efficient in collecting all the relevant information and at the same time does not take a lot of time to fill out. A prototype of the form filling out process could be created so that the customer would have a feel of what is coming and valuable feedback could be gained from this that would help the team to know what to add or subtract from the form.

14



Monitoring: This process would be monitored over a period of time and questionnaires could be given to the customers so as to find out their opinion on the entire process. Managing: If the customers are reluctant to fill out the form then another method to gather the needed data will have to be implemented.

Malfunction of Computers / System failure The cost associated with a computer crash resulting in a loss of data is crucial. As a result, Smartbox will be instructed to make multiple backup copies of the software in development and all documentation associated with it, in multiple locations. System failures happen to companies of all sizes. They don’t always occur regularly but when they do occur they can be devastating to the company’s finances.

Mitigation: The Company will create a parallel system that can act as a solution if the current system should fail. The system will also have an auto-backup feature that will ensure only minimal data is lost from the databases if a system failure should occur. Monitoring: The system is checked regularly for malicious software and other types of intrusions. Checks for signs of a possible system crash will be carried out, thus giving an early warning system for system failures. Managing: If the system fails, then the early warning system would have predicted it but we were just unable to stop it. In such a case, the databases would have already been backed up and the alternative system put in place to ensure the continued operation of the system.

15



Lack of experience in Software Development This lack of experience could result in the project being poorly planned and as such the system that is delivered to the customer is of a poor quality. Poor project planning skills and not knowing the correct steps to take in developing software could result in the wasting of time and resources. Mitigation: In order to prevent this from happening, the development team will be required to learn the different skills and techniques needed to develop the software properly. The member of the team that is the most experienced in a particular area will need to instruct those who are not as well versed. Guidance should be sought from persons who have experience in software development. Monitoring: Each member of the team should watch and see areas where another team member may be weak. Also if one of the members is weak in a particular area it should be brought to the attention by that member, to the other members. Management: The members who have the most experience in a particular area will be required to help those who don’t out should it come to the attention of the team that a particular member needs help.

Insufficient capital Companies from time to time attempt to save money by suggesting surprisingly low budgets for complex projects. At times these companies refuse to adjust the budget to a seemingly sensible budget. With a budget being too low, most of the expectations of the company cannot be met – not unless the developers suffer a loss in the process. Mitigation: A detailed pricing scheme will be given to the company highlighting the different costs for the project and how the final estimate was reached. With a logical and detailed explanation of

16



how the final figure was reached, the company is generally less likely to try and undercut the figure being given. Once a figure is agreed on, a written agreement is signed between the vendor and the company to ensure the project is funded to at least this figure. Monitoring: Our team plans to deliver regular progress reports to the company in an effort to keep them interested in spending money. If an investor sees that his money is working, he/she is more likely to continue investing. Management: In the event the company attempts to undercut the agreed price, then the written agreement will be used as leverage to say that this is what we agreed on and if we do not get that amount then it will be very difficult for you to get the finished system that you want at the deadline that you want and with the quality that you want. Change of Project Requirements During a project’s development cycle, the company may have a change of heart or comes across a problem that they didn’t notice before or forgot to mention. Whenever this happens the development team is usually asked to adjust their project to suit the new requirements of the company. These changes create added difficulty for the development team. This could affect whether or not the team is able to meet the deadline. If the deadline is no longer feasible then this added pressure can cause forced errors in the system.

Mitigation: The development team will conduct detailed interviews with the company in an attempt to cover all angles. This should ensure that most of the necessary features are included in the system that the company and the team agree to build and that the product we are producing, and the

17



requirements of the customer are equivalent.

Monitoring: During the development cycle of the project, the company will be requested for consultation and testing of the project. Prototypes will be created at various stages of the project so that any issues that the company may have with the system can be dealt with in a fast and timely manner. This will create a sort of early warning system for the team, allowing us to predict possible changes. Managing: Should the development team come to the realization that their idea of the product requirements differs from those of the customer, the customer should be immediately notified and whatever steps necessary to rectify this problem should be taken. Preferably a meeting should be held between the development team and the customer to discuss at length this issue. If the company needs the project to be delivered on the agreed date then we will add more members to the team to compensate for the additional work or have the current team work longer hours.

Insufficient Time to complete Project It is very challenging to balance the time between the many courses that one is required to do while at university and plan a project at the same time. There is a limited time in which this project has to be planned and with the many different negative factors in play the project may be completed late. Mitigation: Steps have been taken to ensure a timely delivery by gauging the scope of project based on the delivery deadline. Work Breakdown Structure and precedence tables have been made so as to guide the team as to the timeline for completing the project. Monitoring: 18



A schedule has been established to monitor project status. Falling behind schedule would indicate a potential for late delivery. The schedule will be followed closely during all development stages. Managing: If it becomes apparent that the project will not be completed on time, the only course of action available would be to request an extension to the deadline from the customer. In the event that this is not possible then the area of the project that was completed will be given to the customer and further tasks will be held towards seeking time to finish the project.

19



Reporting Structure

Project Manager

Designer

Chief Engineer

Development Manager

Coder/ Programmer

Technical Writer /Librarian

Requirements Analyst

Architect GUI Designer

Project Database Designer

Systems Environment Designer

Trainer

Interaction Designer

20



Roles and Responsibilities of team members Role Project Manager

Team Member

Functions

Julia Pottinger

-Coordinates and oversee all

Chevaughn Walker

activities of the project. - Help ensure that the software development process works as it is intended.

Development Manager

Chevaughn Walker

- managing multiple priorities

Julia Pottinger

of conflicting projects. -address issues from the team, which it is unable to resolve internally

Designer

Carlington Palmer

Design the entire network

Chevaughn Walker

inclusive of:

Stephen Hing

-defining controls for access

Julia Pottinger

by different users -design how to protect the database from software/hardware failure -define how to protect communications on the network - Define all the technology required to support the software application -Delegate task to other designers -supervise other designers that report to him.

21



- Generate system-level description of what the system is to do. GUI Designer

Chevaughn Walker

-Design the user interface including GUI, mouse controls, sound, video and voice commands. - defines how user interacts with system

Project Database Designer

Chevaughn Walker

Design the database.

Julia Pottinger

Create ERD -Choose database structure -Design database architecture -design database schema -design referential integrity constraints

Chief Engineer

Stephen Hing

-Determines the (stakeholders) needs that the product must meet and continually oversees the development of the product to ensure that it’s on target to meeting those needs.

Coder/Programmer

Carlington Palmer

- Write code for all aspects of

Chevaughn Walker

the system and implement the

Stephen Hing

software

Julia Pottinger

-Create the actually database and test its efficiency and correctness - Limit access to authorized users, and implement other 22



necessary security measures. - Install Operating System, Local Area Network connections and Desktop Computers. - Install the software and Test it.

Technical Writer/Librarian

Julia Pottinger

- Prepare and store all documents that are used during the life cycle of the system. -Create document to guide Users on how to use the system. - Estimate budget, deadline. Identify resources - Conduct Risk analysis of the problem at hand

Requirements Analyst

Chevaughn Walker

- Works with Smartbox, breaking down what their wants into discrete requirements. -Identifying the problem the current system has - Identify what it is the proposed system should achieve - Conduct interviews and

23



questionnaires. - Conduct cause and effect analysis of the problem at hand - Ascertain from the customer the features and behaviour of the proposed system. Architect

Carlington Palmer

-Help to catch faults that the system overlooks - Converting the requirements into an architecture and design that will become the blueprint for the solution being created.

Trainer

Stephen Hing

- Creates the materials

Carlington Palmer

necessary to train users how to use software. -Present final proposal. Train users to use the system

A Breakdown of major Roles and their responsibilities Project Manager Main Function- Coordinates and oversee all activities of the project. Responsibility: -Assessing User Needs

24



 Connect and communicate between software developers, programmers and other members of the technical team and the non-technical users who actually work with the project every day.  Accurately assess the needs of their clients, should be familiar with the SDLC.  Understand what clients want, and to present the proposed solutions in terms that the user can visualize and understand. -Building a Team  Know which resources will be needed, this can include members of the programming team, software developers and even outside vendors. Understanding who to turn to get the job done is an essential part of the job.

Programmer Responsibility:

 Responsible for the underlying architecture for the software program, as well as for overseeing the work being done by any other software engineers working on the project.  Act as a mentor for new or lower-level software developers or programmers, as well as for all the members on the development team.  Code, test and troubleshoot programs utilizing the appropriate hardware, database, and programming technology.

Trainer Responsibility:  Training 25



 Prepare and maintain training materials for standard products and end user applications.  Present using a variety of techniques and styles, including team exercises, group discussions, presentation slides, and demonstrations.  Monitor level of success of training engagements and recommend suggestions for continued improvements.  Work with clients to identify specific training needs and prepare individual curriculum to fulfil needs.  Assist with end user support to ensure highest level of client satisfaction.  Provide assistance with software installation and implementation.

GUI Designer Responsibility:

 Design the graphical environment for the software ensuring that the different users will be able to easily interact with the system  Responsible for ensuring that users with different access can only see certain aspects of the system. Librarian Responsibility:  To ensure that all the relevant documents that are to be developed at every stage of the SDLC are created in a timely and efficient manner. Also ensuring that these documents are up to standard.

26



 To keep all relevant document including receipts and the documents used in the analysis phase in order and have them available when necessary. Chief Engineer Responsibilities 

Determines the (stakeholders) needs that the product must meet and continually oversees the development of the product to ensure that it’s on target to meeting those needs.



Listens to the stakeholders and then negotiates with the project team to address the stakeholders’ needs (and desires).

Architect Responsibilities 

Ensuring the product or service under development achieves its performance and other qualitative requirements.



Guiding the interfacing and Integration of the solution components of this project into the existing architectural landscape.

Requirements Analyst Responsibilities 

Solicitation and elaboration of stakeholder needs and requirements.

Technical Writer Responsibilities 

Providing early feedback to the core and extended teams about e.g. desirable features.



Creating closer and more productive relationships with the various stakeholder communities (through e.g. creating tutorials, reference manuals, technical overviews, brochures, video, audio, etc.) 27



Designer Responsibilities  Finding solutions to known requirements.  Exploring the requirement space.

Coder Responsibilities 

Advising on economic feasibility of implementing designs / requirements in available programming languages.



Implementing i.e. user stories – in whatever language is most suited to the problem at hand

28



Object Oriented Analysis Description of Existing System At Smartbox, a manual inventory system is used. The day to day operation of Smartbox is as follows. 

A customer comes into the store seeking a particular item.



The store clerk takes the customer request and if the item is on the rack or in the display case he/she takes the item, cashes it and gives it to the customer.



Whenever items are cashed, it is recorded in a log book.



If the item that the customer wants is not on the shelf then the clerk will go into the stock room and search for the item.

This causes inefficiencies when dealing with their customers as it is error prone and sometimes the item that the customer wants is not there. The waiting process at times is long and tedious for the customer. Due to the inefficient inventory system that Smartbox has, at times the item that the customer wants is not in stock. The store then tries and source the item. This can take 3-4 weeks. It also takes time for the employee in the store to search for the item in the store room after the customer has requested the item that they want. This takes a bit of time as there are a lot of items in the store room. The customer waits an average time of 10-20 minutes for the clerk to search the stock room and to return with the item or in some instances without the item if the item is out of stock.

29



Smartbox does an inventory check every two weeks. This is really inefficient and time consuming as it is manual and takes on average 1-2 days. It is error prone as: 

The person counting the stock may miscount.



They may forget to write down the correct amount for a particular stock.



The book in which they keep track of the items sold may be incorrect or illegible and this may result in the calculating of items sold to be wrong. This may also result in the calculation of the items left in stock to be incorrect as at times they subtract the number of items sold from that of the number of items that were bought.



Other problems sometimes arise as they cannot find invoices and sales receipts and as such they cannot accurately calculate the number of items left in stock. Whenever this happens they have to go into the stock room and check every item that is there.

At Smartbox, they do not have a computerized customer database in which they store customer information and the repairs that they are getting done. The process is like this: 

The customer brings an item to be repaired.



The item is recorded in a book and the customer is asked to make a deposit of half the cost of repairing the item. The customer’s first name and telephone number is taken and recorded in the book.



While the item is being repaired the technician at times takes items from the store room to repair the item. However, this item is not recorded in the sales book that is to be used to determine the items left in the store room. The customer is billed for this item however a copy of the sales receipt is not made and placed with those used to check sales made from the store room. 30





After the item is repaired the customer is called. At times the customer is not called as their information cannot be found and they have to come to the store and ask if their item is repaired.

The problems with this system are that Smartbox record all the customer and repair information in a book. When the items are finished being repaired it takes a long time for the employee to find the contact information for the customer to inform them to come and collect the item. This is so as they have to search through the entire book looking for the item. At times there are several of the same items being repaired so the employer has no idea which customer it belongs to. In addition to that, at times the parts used to repair the item are taken from the store and the customer is billed for it along with being billed for the repairs that were done. They do not have a proper inventory system in place that keeps track of the items that are used for repair and update the amount of that item left in stock.

31



Problems, opportunities, objectives and constraint matrix

Cause-And-Effect Analysis

System Improvement Objectives

Problem or

Causes and Effects

System Objective

Insufficient

This may be as a result of the

The proposed system

customer data

store clerk not taking all the

should reduce the time

necessary information from

spent searching for

the customer. This may result

customer information to

in the customer not being

approximately 30

contacted when their repair

seconds. It should also

has been completed. Also the

store all relevant data on

company will receive less

the customer.

Opportunity

customers due to a bad reputation Manual stock

Stock is only checked every

The automated system

checking system two weeks. This results in

will check stock every

is too outdated

stock at times running out and

day after closing hours

and is not

the store clerks not being

and will have a reorder

preformed

aware of it. This results in

level that alerts the store

regularly as

orders not being filled as there clerks or the relevant

required

is no stock there. It may also

persons that the item(s)

32

System Constraint



result in repairs not being

is/are running low and

done as the stock to complete

needs to be refilled. It

these repairs are not there.

will also attempt to

This will result in disgruntled

reorder the stock based

customers.

on the information that was set. This information includes the number of items to order, who to order it from and contact information for the supplier.

The waiting

This is as a result of the store

To provide stock

The system

process at times

clerk not knowing beforehand

information and

developed must be

is long and

if the item is in stock or not.

significantly reduce

compatible with the

tedious for the

The store clerk will have to go delays

latest windows

customer.

and check if the item is there.

operating system

If it isn’t there then the customer would have wasted a lot of time waiting. This result in the customer getting irritated. This may also

33



prompt the customer to start seeking other stores that offer the same services and this may result in Smartbox losing customers. Incorrect

Stock is counted incorrectly

System will eliminate

Counting of

as a result of various things.

manual checks with an

stock.

They include:

automated one.

•The person counting the

This will be done by

stock may miscount.

updating the stock

•They may forget to write

inventory every time

down the correct amount for a

something is sold and

particular stock.

every time an item is put

Whatever the reason this

in stock.

miscount results in an incorrect amount of stock being reported and this may result in further problems when the expected amount of stock is not there.

34


Items taken

This occurs when the


The system will have a

from stock room technician uses items from the feature which requires and used in

stock room without properly

the technician to record

repairs aren’t

recording it. This results in

the items that were used

being recorded

the incorrect number of items

in each repair and

as sales.

being counted as being in

whether or not that

stock.

particular item was taken from the stock room. If it was taken from the stock room then it will be deducted from the main inventory system and the number of items left in stock will be adjusted accordingly.

35

Actor Identification Form of existing system Who or what

Clerk

provides input

Cashier

to the system? Who or what receives outputs from the

Clerk

Cashier

Customer

system? Are interfaces required to other systems? Are there events that are automatically triggered at a predetermined time? Who will maintain information in

The Clerk

the system?

34



Use Case Identification Form of existing system

Actors

What are the main tasks of the actor?

What information does the actor needs from the system?

What information does the actor provide to the system?

Customer

To request a service.

Purchase information

_____

Clerk

To help manage stock and customer requests.

Previous stocks that have been written down and the amount sold(to calculate current stuck)

The current inventory of items.

Cashier

Bills customer

Price of item

35

Does the system need to inform the actor of any changes or events that have occurred? _____

Does the actor need to inform the system of any changes or events that have occurred?

_____

_____

_____



Use Case Diagram of Existing System

Arrange Payment

Order item

Supply data

<> <>

<>

Update inventory

Clerk

Check store room

<> Purchase

<>

Item

Customer

Takes customer info

Request Repair

<>

Assign computer to customer

<>

Request Internet service

<>

<>

Allocates chosen time

Choose time Bills customer

Cashier Issues receipt Cash items

36



Functional and Non-Functional Requirements Functional Requirements of the Ulti-Stocks and Database Management System 

The Ulti-Stocks and Database Management System shall make it easier for the employees of Smartbox to keep track of the items currently in stock.



The system shall have a display stock feature which enables employees to view their entire stocks along with the amount in supply and prices.



The user shall be able to save customer information in a database so that it can be easily accessed.



The sales and costs of items shall be automatically calculated and the system shall prompt the user of ordering when the stocks are low.



The Smartbox System shall allow users to add new items to their stocks that they want to be sold.



The cashier shall help with customers’ requests and make sure these services are met and efficiently billed.



The clerk is to check the system inventory and adequate update it to maintain daily business.

Software Features Feature Complete Inventory Tracking

Benefits Record, update and search items such as product types and prices.

Automatic Reminder &

Automatically calculates the sales and costs of items and prompts

Calculator

the user of ordering when the stocks are low.

Edit Inventory

Allows users to add new items to their stocks that they want to be 37



sold. Controlled User Security

Control the tasks users are allowed to perform, and the information they can view. Allows users access to different areas according to their responsibilities, while giving other users viewonly rights.

Display Feature

Enables users to view their entire stocks along with the amount in supply and prices.

Manage Customer Repairs

Track customer information such as contact details and device being repaired.

Non-functional requirements 

The system shall prompt users to enter a password if before gaining access to any information. This will enhance the security of the system



The system shall have user accounts which allow only specific user to have certain rights.



The system shall have quick recovery times of approximately 1-3 minutes in case of errors or failures. This shall be dependent on the processor speed of the computer the user is using.



The system runtime shall take a matter of seconds to execute and display output. The system shall be very robust.



The Smartbox System shall occupy little space of approximately 250mb



The Smartbox system shall be very scalable in the amount of platforms it can be installed on i.e. laptops, desktops, notebooks and even some cellular phones, particularly those with

38



android technology.

Implementation of the software In using this software, Smartbox’s management will make sure the following objectives are met: 

Train their staff appropriately in its use.



They will also ensure that all manuals applicable to the implementation of the system are available when needed.



Provide all needed technical assistance.



Scheduling any special computer processing required for the implementation



Acquiring special hardware or software



Prepare data to be loaded into the system

39



Actor Form of Proposed System

Who or what

Clerk

provides input

Cashier

Merchant

Cashier

Customer

to the system? Who or what receives outputs from the

Clerk

system? Are interfaces required to other systems? An order request is Are there events signaled when that are stocks are on a automatically

low

triggered at a predetermined time?

Who will maintain information in

The Clerk

the system? 40

Technician



Use Case Identification Form of Proposed system

Actors

What are the main tasks of the actor?

What information does the actor needs from the system?

What information does the actor provide to the system?

Customer

To request a service.

Purchase information

_____

Clerk

To help manage stock and customer requests.

Previous stocks that have been written down and the amount sold(to calculate current stuck)

Cashier

Bills customer

Price of item

Takes customer order, Record item that was bought, cashes item, Check if item is in stock, Count stock, Calculate sold items. Collect customer info, Contact customer

Invoice, Sales receipts, Price, Stock count, Customer info, Customer who owe,

Store clerk

Does the system need to inform the actor of any changes or events that have occurred? _____

Does the actor need to inform the system of any changes or events that have occurred?

The current inventory of items.

_____

_____

Customer request, Calculation Customer info, Stock info,

Yes- that the store is running out of stock,

Yes- new stock is available

Merchant To order new

Stock count ,

Confirmation 41

_____

Yes- stocks are Yes – back in stock remember to


stock

Ulti-Stocks System Database System

Technician

Maintains items currently in stock Stores customer information

1.Identify the problem with the system 2. Fix the problem and bill for new equipment used to fix the computer and to then compile a bill


Types of stock needed, Amount of stock need Item info

Customer personal info such as contact info and address Stock inventory of parts and items that may be needed.

42

of purchase, delivery dates

The current inventory of items Info on customers and the items they have left for repairs Customer billing for repairs

restock

Whether or not the inventory is empty When item has been repaired

If new parts are required and if the customer would like to continue with repairs by purchasing these parts.

Whether or not the item have been picked up by the customer The removal of stock that has been purchased and used in repairs.



Use Case Diagram of Proposed System

Arrange Payment

Order item

Supply data

Update inventory

<> <>

<>

Clerk

Check store room

<> Purchase

<>

Item

Customer

Takes customer info

Request Repair Request Internet service

<>

<>

Assign computer to customer

<> <>

<>

Choose time

Bills customer Allocates chosen time

Issues receipt

Cashier Cash items Tracks store inventory

Stores customer info <> <>

Calculate & generate fee

Stores repair info Database System

Inventory System <> Identify Problem Buy Stocks

Fix Problem 43 Merchant

Technician



Use Case Narratives

Author (s): Chevaughn WalkerUlti-Stocks System

USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PRIMARY BUSINESS ACTOR: OTHER PARTICIPATING ACTORS: OTHER INTERESTED STAKEHOLDERS: DESCRIPTION: PRE-CONDITION: TRIGGER: TYPICAL COURSE OF EVENTS:

Request Purchase SB2014-01 High

Date: March 28, 2014 Version: 1 USE CASE TYPE Business Requirements: 

Customer 

Inventory System



Smartbox-Interested…

The use case describes the event of a customer requesting to purchase an item. Once he/she has done so, clerk will assist them.  The applicant must be able to pay for item.  The applicant must have valid identification The uses case is initiated when the applicant selects the item he/she would like to purchase. Actor Action System Response Step 1: The customer indicates Step 2 The system validates product they would like to purchase an identity. item Step 3:The system verifies product availability Step 4: The customer identifies the method of payment Step 5:The customer enters their credit/debit card number and currency type Step 6: The system validates the credit/debit card. Step 7: The system determines the total cost for the item or items. Step 8: The system records purchase information and releases the purchase 44


ALTERNATE COURSES:

CONCLUSION: POST-CONDITION: BUSINESS RULES IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS ASSUMPTIONS: OPEN ISSUES:


Step 9: The system generates receipt to customer Alt-Step 1: The customer may decide to not purchase an item but instead just looking around at different items Alt-Step 6: If the customer did not specify credit or debit card as there method of payment, the customer may choose to pay for the item with cash. The use case concludes when the customer receives receipt. The customer’s purchase info is recorded along with other customer data.  There are no refunds only exchanges.  Only cash and debit/credit cards are accepted. The customer should be willing to provide certain personal info to be stored The system updates the inventory of the item/s sold

45



Author (s): Chevaughn WalkerUlti-Stocks System

USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PRIMARY BUSINESS ACTOR: OTHER PARTICIPATING ACTORS: OTHER INTERESTED STAKEHOLDERS: DESCRIPTION: PRE-CONDITION: TRIGGER: TYPICAL COURSE OF EVENTS:

ALTERNATE COURSES: CONCLUSION: POST-CONDITION: BUSINESS RULES IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS ASSUMPTIONS: OPEN ISSUES:

Store Repair Info SB2014-02 High


Database System 

Customer




The use case describes the event of storing repair info for a customer  The customer must have an item to be repaired.  The customer must have valid identification The uses case is initiated when the customer states the problem with the device. Actor Action System Response Step 1: The customer indicates Step 2 The system verifies if the device they have an item for repair can be repaired. Step 4:The system collects info on the malfunctioning device and customer Step 3: The customer provides Step 5: The system records collected device info and personal info data to database Step 6: The system issues date to recollect device Step 7: The system records recollection dates Alt-Step 2: The device the customer wants to repair might be too damaged for repair. The use case concludes when the customer receives date to collect device. The customer’s device info is recorded along with some contact info.  There are no refunds only exchanges.  Only cash and debit/credit cards are accepted. The customer should be willing to provide certain personal info to be stored The customer will be back to collect the device

46



Author (s): Chevaughn WalkerUlti-Stocks System USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PRIMARY BUSINESS ACTOR: OTHER PARTICIPATING ACTORS: OTHER INTERESTED STAKEHOLDERS: DESCRIPTION: PRE-CONDITION: TRIGGER: TYPICAL COURSE OF EVENTS:


Buy Stocks SB2014-03 High


Merchant 

Inventory System




The use case describes the merchant buying products to restock the inventory  The inventory must be running low  The merchant must have supplier The uses case is initiated when the inventory is low and a reorder is alerted Actor Action System Response Step 2: The store manager Step 1 A reorder stocks alert is contacts merchant to buy generated. stocks. Step 3:The system generates a report on what inventory items needs to be replenished Step 4: The merchant buys Step 5: The system updates the inventory items from the inventory system with the newly bought store’s suppliers. items Alt-Step 1: A reorder stocks alert is not generated because inventory is not running low The use case concludes when the inventory system is updated with the newly bought items. The inventory system must be updated  There are no refunds only exchanges.  Only cash and debit/credit cards are accepted. There might be a bug in the system in calling the reorder function even when the inventory is not running low The inventory is running low

47



Author (s): Chevaughn WalkerUlti-Stocks System USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PRIMARY BUSINESS ACTOR: OTHER PARTICIPATING ACTORS: OTHER INTERESTED STAKEHOLDERS: DESCRIPTION: PRE-CONDITION: TRIGGER: TYPICAL COURSE OF EVENTS:


Track store inventory SB2014-04 High


Inventory System 

Customer, Clerk




The use case describes how the inventory is maintained by the system  New items added to the inventory are verified  Items removed from the inventory via purchases are verified This use case is initiated as soon as a purchase is made Actor Action System Response Step 1: A customer requests Step 2: The system is checked for item purchasing an item availability Step 3: The system gets stored info on the item selected for purchase Step 4: The system generates cost of item Step 5: That item is removed from the inventory for sale Step 6: The inventory system is updated of the sale of an item, Alt-Step 2: The requested item might not be available therefore a sale would not be made The use case concludes when the inventory system is updated of the sale of an item, which has been removed from stock The inventory system tracks amount of each items left in stock  There are no refunds only exchanges.  Only cash and debit/credit cards are accepted. Incorrect data might be stored about an item in stock The inventory updates itself after sales

48



Sequence Diagrams

Purchase Item Diagram

Customer

Purchase Item

Supply Data

Payment

AcceptsItem

Clerk

User Interface

Check Stock

Takedata

Ulti-Stock System

Track itemfile

Verify

GiveItem

Calculatefee

GenerateFee

UpdateInvento ry

49

Check itemfile

showfile

StoreData

StoreData

Database



Store Repair Info Sequence Diagram

Customer

Repair Item

IssueDate

Clerk

User Interface

Ulti-Stock System

EnterInfo

generatedate

VerifyDevice

Verify

50

createfile

storeData

Database



Buy Stocks Sequence Diagram

Merchant

User Interface

Inventory System

Ulti-Stocks System

RequestOrder

EnterOrder

Update

SendReport

BuyStock

Reorder

51



Track Inventory Sequence Diagram

Customer

Inventory System

User Interface

PurchaseItem

Purchase

CheckStock

getdata Update

GenerateCost RemoveItem

Update

52



Class Diagram Customer -name :string -id:int -address:string -down_payment:float -tel_num:int +Customer() +Customer(string, int, string float, int) +SetName(string):void +GetName():string +SetId(int):void +GetId():int +SetAddress(string):void +GetAddress():string +SetD_Payment(float):void +GetD_Payment():float +SetTelNum(int):void +GetTelNum():int +MakePayment():void +OrderItems():void +CollectItems():void Store Clerk -name: string -Id: integer -salary: integer -address: string - inventory: Inventory -customer: Customer -merchant: Merchant +checkStock(): bool +getCustomer(): void +getInventory(): void +makePayment(): void +addStock(): void +addCustomer(): void

Technician -repair_num:int -cost:float -items_used:string -customer:Customer -Technician() -RecordItemsUsed(int,string):void -GetCustomerInfo():void

Inventory Type: string ItemNum: integer Price: integer TotNumofStock: integer + countStock(): integer + checkIfStockAvail(): bool + getType(): integer + searchStock(): bool + reorder(): void + calculate(): void

Merchant -email:string -phone: integer -address:string -merhantRep:string -Item_name: string -Price: integer -Type: string -amount: integer +sell_stock(): void +getOrder(): void +deliverItem(): void +recievePayment():void 53



Entity Relational Diagram Repair_num Decription Date Repair

Address

Address

ID

ID

Name

Name

Cashier

Cashed

Distributes

Customer

Purchase

ID_code Amount

Item_name

Merchandiser

Supply

Product

Item_name Type Price

ID_code Type

Price Amount

54



Process Diagram Reorder

No

Place order

Purchase or Repair

Purchase

Is product availablility?

Picking up

Complete payment

Repair

Dropping off or picking up?

Dropping

Take customer info

Make deposit

55

Yes

Cash product



Activity Diagram

Reorder Product

NO YES [Check place next order]

[Check if Purchase]

[Check product availablility]

YES

Place order

Purchase

[Check purchase more]

NO

NO Cash product

YES YES

NO

Repair [Check Dropping off]

NO Picking up

YES Take customer info and Item

Make deposit

56

Complete payment



Appendices

57



Appendices Minutes Minutes for Meeting held on Sunday February 10, 2013. Meeting was called to order at 1 pm. The meeting was held to discuss the different aspects of the project that we had to work on. Work was delegated to each member of the group. Carlington did the RSS form. Julia did the background to the problem and the problem statement, whilst Chevaughn and Stephen did the Cause and Effect table. The work was put together and Submitted via email to the teacher. Further plans were made as to how to move forward with the project. A date for the next meeting was set. It was agreed that the group would meet again on Sunday February 16, 2014.

Minutes for Meeting held on Sunday February 16, 2014. Meeting was called to order at 12:30 pm. The meeting was held to discuss corrections to the project as we had added a new aspect to the project. The problem statement was updated and the solution was altered to add the new aspect of the project that we had incorporated. The project plan was started and different portions of it were allocated to the different members of the group. The deliverables for the project that were due in the week was discussed and ways on how we were going to finish it was discussed. We agreed to meet in class to collate what we had done. The next meeting was scheduled for Tuesday February 18, 2014.

58



Minutes for Meeting held on Tuesday February 18, 2014. Meeting was called to order at 12:10 pm. The meeting was held to discuss how far we were in the project. The project plan was put together. It was discussed that we were a bit behind on the project and we needed to put more time into doing the project. All aspects of the project plan were not completed and as such we agreed that we needed to put more work into the project. We agreed to meet and complete as much of the project as possible. The next meeting was set for Wednesday February 19, 2014. Minutes for Meeting held on Wednesday February 19, 2014. Meeting was called to order at 2:00 pm. The meeting was held to complete the project plan and to discuss other aspects of the project that needed completing. Issues in the project were addressed and work was done on the project. The risk Mitigation was done in addition to the roles and responsibilities of the group members. Other aspects of the project plan were completed and the meeting was adjourned at 4:30. A date was not set for the next group meeting.

Minutes for meeting held on Sunday March 2, 2014. Meeting was called to order at 1:20 pm. The meeting was held to discuss how far we are in the project. The project plan was completed and the project put in a specific order. The project was then scrutinized by the team to ensure that it met all the requirements that the rubric asked for. The next phase of the project was discussed and steps 59



to how it should be approached were decided upon. It was agreed upon that Miss needed to look at the project and see how far we were and if we were on the right track. It was also brought up by a member of the group that the only place we should have the problem statement and the expected solution was in the RFISS form. It was checked and found to be true and the project6 was then corrected accordingly. The meeting was adjourned at 5:00 pm.. A date was not set for the next meeting.

60



Fact- Finding Technique Interview 1. Where do you get all of your supplies from and how long does it take for those supplies to be delivered to the store? 2. Are there different departments that have specific tasks to ensure the efficient running of the organization? What are they and what are their roles? 3. What are some of the inefficiencies experienced when processing customers’ orders? 4. Describe the process of serving a customer? 5. How do you meet the demands for a specific item needed by a customer? 6. How do you keep track of items in stock? 7. Are there any concerns with the tracking of items in stock? 8. Is there a need for software to run your store and if so what kind of software? 9. What information is needed from the customer for them to order items? 10. Do you provide a delivery service? 11. What kind of convenience do you make for customers’ payment scheme? 12. How is a customer billed? 13. How do you keep track of the item that a customer has brought in to be repaired? 14. How do you bill the items that are used to repair a customer computer or other electronic device? And how do you link that to the inventory that is kept?

61



References

ISQTB- International Software Testing Qualifications Board. (2012, January 12). What is Prototype model- advantages, disadvantages and when to use it? Retrieved March 2014, from ISQTB - Exam Certification: http://istqbexamcertification.com/what-is-prototype-model-advantages-disadvantagesand-when-to-use-it/ Tilloo, R. (2013, August 4). What Is Incremental Model In Software Engineering ? It’s Advantages & Disadvantages. Retrieved March 2014, from Technotrice : http://www.technotrice.com/incremental-model-in-software-engineering/

62

Software Engineering Project

Recommend Documents