Progress Comparation with the Gantt Chart

This is our team project Gantt Chart. Actually, our progresses are a slightly different from our Gantt chart. Mostly, the steps are same. We followed so our project will not stray from the main idea. We do as what are plan as a Gantt chart. Just the spend time of each task are maybe different. We maybe overused time on Build Database but we’ve shortened on Design Application Interface and Build Interface.

Now is already week 10/11. The progress was supposed to be Link Coding with Database, but we haven’t reached there yet. Therefore, we need to done all the left progress fast. Double up our works. So, we’ll able to be on the Gantt chart track back.

We also hope that we able to finish this project on time.  

Problems Encountered During Software Development

Clashed time, other group members got a class or other works during another group member’s free time.

             We doing the entire project task during the night. Everybody’s free and there.

Some other members are weak in programming and database part, so the other will do a lot of work than the weak member.

That members will do more works on documentation, reporting and else. In a same time, that person can slowly learn about the programming part too. Sooner he/she will be able to do programming by he/herself.

Lack of group members, unbalance numbers of student in a class lead to an unbalanced team member among another group. The work will be harder.

             Just do with willing hearts. Don’t ever feel betrayed or else. It’s not lecturers false. :D

When dividing task to group members, sometimes there will be different idea from two or more developer. Thus, the project will be more complicated and need to be re-do. It’s take a lot of time.

We need to discuss before proceed with the idea. It does prevent from dissatisfied, disagreed and argued amongst members.

Last minute job, members of group eager to do this task last call. Regarding to when the due date is. So, the work will be unsatisfied and not good enough.

We need to reschedule our daily routines, to see what the best option is. So, we will able to prevent from this problem again.

We've done a few progress, suddenly we’ve discovered that the software doesn’t match with the project. So, we need to re-start back from the beginning.

Plan and analyzed first before proceed with the project. So, we can prevent all of this from happen.

SRS -Stationery Inventory System

SCOPE

 

Stationery Shop system in an application that allows user to update their own financial, database, shops inventory and items stock for the routine business. 

PURPOSE  

• To reduce worker
• To reduce any mistaken in handling inventory
• To track any stock came into inventory
• To facilitate the process of managing inventory
• To reduce time for searching the files.

OVERVIEW DESCRIPTION

• An inventory system of stationery shops.
• Create a login form for a security
• Product form, where users can view and edit all the data about their stocks
• Vendor form,The manager will be able to see whether the vendors are still active or not.
• Purchasing order situation when the income is included
• Account form will be created to manage the business flow steadily without having any worst situation
• Receipt also will be provided as the evidence for the transaction.

-overall use case-

Product Perspective

• Our product is independent and self-contain.
• The system will update the entire inventory database without searching the inventory files and can control it.

PRODUCT FUNCTION

Login

• User needs to enter an ID and password before can use the system
• Able to change their password if they feel their currently password insecure.  

-login use case-

Product

• User to select the product that they business were doing
• user also can edit or update the product regarding to product itself.

-product use case-

Vendor Information

• Control all the vendors that are doing business with them.
• User can add more vendors or just remove them

-vendor information-

Purchasing And Order Process

• User can make a new order through this system.
• Edit the order if they are any mistaken.
• User can view their order from

-purchasing and order process-

Receiving and Shipping

• User will be providing the invoice and receipt of the business transaction.
• In the receipt will be written down all the information about the business
• User can view and edit the invoice if there are any problems.

-receiving and shipping-

Payment and Account

• User can access through their account information .
• User can view their account balance.
• Add another more account and delete inactive account.
• The account will keep in user database.

-payment and account-

Catalogue

• Allow customer to register and be a membership
• Customer will use their password and username to enter our system but they only can review our product

-catalogue use case-

Customer

• Allow management to view all their customer details.
• They also can search their customer. 

-customer use case-

User Characteristic

• To use this system doesn’t involved or educational higher level needed.
• All the staffs are will be able to use this system.
• User friendly system environment.
• Any technical expertise will help more on using this system

NON-FUNCTIONAL

1. Reliability 
1. Availability 
• The system is available 100% for the user and is used 24 hours a day and 365 days a year.   The system shall be operational 24 hours a day and 7 days a week. 
2. Mean Time between Failures

   • Even if the system fails, the system will be recovered back up within an hour or less.
2. Efficiency
1. Stationery system will store many product list, vendor list and customer list
2. The system must be efficient for the frequent user
3. Usability 
1. This section lists all of those requirements that relate to, or affect, the usability of the   system. 
• Learnability
• The user documentation and help should be complete
• The help should be context sensitive and explain how to achieve common tasks
• The system should be easy to learn.
• Operability
• The interface actions and elements should be consistent Error messages should explain how to recover from the error
• Actions which cannot be undone should ask for confirmation
• The system be customisable to meet specific user needs