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

SDD Content and Summary

CONTENTS

1. Introduction
    1.1 Purpose
    1.2 Scope
    1.3 Overview
    1.4 Reference Material
    1.5 Definitions and Acronyms
2. System Overview
3. System Architecture
    3.1 Architectural Design
    3.2 Decomposition Description
    3.3 Design Rationale
4. Data Design
    4.1 Data Description
    4.2 Data Dictionary
5. Component Design
6. Human Interface Design
    6.1 Overview of User Interface
    6.2 Screen Images
    6.3 Screen Objects and Actions
7. Requirement Matrix
8. Appendix

SUMMARY 

A software design document (SDD) is a written documentation made by the software @ application designer to give the project team overall view of what architecture of the software project is. SDD basically comes with architecture diagram and any detail points for the application design specification. Its help a lot especially on what are the needs in the system. This document commanded to give a fairly complete description, while maintaining a high-level view of the software. SDD provides entire document needed from every little things from the system to the interface designing. Although the system looks complete, the design still document needs to be a stable reference, outlining all parts of the software and how they will work. Otherwise the document design will be look messy.

Hospital Muar Problem's

 EXISTING PROCEDURE

• Hospital Muar make an order for Clinic Desa.
• Hospital Muar make an order directly to supplier.
• Clinic Desa make an order through Hospital Muar. 
• XY Pharmacy as a supplier.
• They supply the medicine directly to Hospital Muar & Clinic Desa.
• Hospital Muar will send purchasing order to supplier.
• Hospital Muar will receive the invoice from supplier.

Form Involve

Invoice - Accept by hospital/clinic to prove that they already receive the item ordered and paid it. The hospital/clinic will keep the invoice and send it to financial department.

Purchase order - Create by hospital to make an order to supplier. Include of medicine name, amount and price.

Delivering note - Receive by supplier to inform them that the item have receive.

Receipt - Information about amount they have paid.

HOW OUR NEW SYSTEM WORKS

• Hospital reply and give the authority
• Clinic make order list
• Clinic make order direct to pharmacy
• Pharmacy need prove that hospital approved the authority
• Pharmacy sent the delivery direct to Clinic
• Clinic receive invoice and forward to hospital
• Hospital keep the invoice as prove
• Hospital make an order direct through pharmacy without any permission
• Pharmacy will insert the order into the database for their used

TECHNOLOGY SOLUTIONS

Online - Clinic department make their order with online direct to supplier compare to the existed system. This is to avoid any mistake that occurred with existing procedure.The hospital department also use online to make the order.

Fax - Since the clinic make the order direct to the supplier,  fax used for request and receive authorization from hospital.

HOW TO DEVELOP

METHODOLOGY

To deal with this uncertainty, two or more approaches to the objective may be continued in parallel until a clear choice can be made, a parallel strategy. A strategy that can provide better information for a decision, maintain options, or hedge against the occurrence of an unsatisfactory outcome. It begins from one phase to another. Whenever got own problems, it can be solve first before proceed to another phase. Its safety and efficient to develop an application.

DATABASE

clinic inventory

pharmacy inventory

hospital inventory

FORM

Hospital

Description

• This interface contains a textbox, Masked text box, combo box and button.
• Hospital Muar directly make an order to the supplier.
• This system will include data on the pharmaceutical and medical staff. 
• Date of order is important so that we can know how  long will  taken by the supplier to   deliver medicine.
• Pharmacists and staff information required in this system as a reference to ensure the order as are required, and to know which the staff responsible for ensuring that information entered is accurate.
• Other than that ,the system need to key in data on the medicine name and quantity to be ordered.
•  After all the information filled in the system, system users need to press the submit button and data will be stored in a database.

   Clinic

Description

•  Clinic Desa make an order through Hospital Muar. 
•  Clinic Desa must request permission from Hospital Muar before order the medicine.
•  After the hospital approve the form, this system will key in pharmacy, staff and medicine information.
• Date of order is important so that we can know how  long will  taken by the supplier to deliver medicine.
• Pharmacists and staff information required in this system as a reference to ensure the order as are required, and to know which the staff responsible for ensuring that information entered is accurate.
• Other than that , the system need to key in data on the medicine name and quantity to be ordered.
•  After all the information filled in the system, system users need to press the submit button and data will be stored in a database.

Pharmacy(Hospital)

Pharmacy(Clinic)

 Description

•  XY Pharmacy as a supplier.
•  They supply the medicine directly to Hospital Muar & Clinic Desa.
• Therefore, this system will consist all information about Hospital and Clinic for confirmation ordering.
• Then, press submit button to store the information in the database.
•  Beside that,when press print button,it will appear an invoice which hospital or clinic will get invoice pharmacy as prove that they already receive the item ordered and paid it.

Invoice

 

REQUEST PERMISSION

Project Description

LULU STATIONERY Sdn Bhd

mission:
to develop an application that can handle an inventory in stationery shop efficiently

objective:
1) to reduce difficulties in handling any stock in the shop
2) to create and maintaining computer application
3) to reduce workers and papers

about:
Our project is about to build a system that can control an inventory so that it can be work easily. To make sure that the process will work smoothly, we develop an application that can plan and conduct an inventory to be ready for any request at any time. The system is consists of supplier, warehouse and customer. The inventory will order when it reach the safety stock with optimum quantity to avoid loss. The re-order cost will calculate with unit quantity when ordering. The holding cost will calculate during the inventory in store. We'll receive invoice during the order from supplier and produce the receipt to the customer after the transaction

Members Introduction

Muhammad Nor Azlan Bin Reduan
from Seremban, Negeri Sembilan
September 11th
studied Diploma in Comp. Science (Info. Technology) from UTMKL
Prog skills: Java, VB, C++, HTML

Noor Dayana Binti Khairuddin
from Temerloh, Pahang
January !4th
studied Diploma in Comp. Science (Info. Technology) from UTMKL
Prog skills: Java, VB, C++, HTML

Muhammad Yasir Bin Md Ismail
from Pulau Pinang
September 6th
studied Diploma in Comp. Science (Info. Technology) from UTMKL
Prog skills: Java, C++, HTML

Group Name

D'lulus 

history: 

we have taken this name from our project name. first we would glad to using name The Lulu Stationery.

then we reduce it to The Lulu S. Later, we shorted it more to d'lulu s. After final conversation among members. we agree to use D'lulus as our group name.