Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Brilliant Supermarket Inventory Management System

No description

John Uesi

on 13 June 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Brilliant Supermarket Inventory Management System

System Design Process
Transformation of detailed requirements into complete, detailed System Design Document focuses on how to deliver the required functionality stated in the Requirements Specification Report.

artifacts and careful planning have allowed us to:
understand the client problem
envision an adequate solution
design and build a strong solution

Provides an automated system that keeps track of inventory on a regular basis.

The system ensures that items marked for inventory and distribution are accounted for and that stock levels, quantities and costs are reasonable when requisitions for inventory are placed through the system by automatic or manual ordering functions.
Project Background
Brilliant supermarket is a well-known supermarket in Australia. The business currently runs with 8 staff members and an exponentially growing customer-base.

The paper record of all the transactions is overwhelming the current system and enacting a heavy cost to the company in terms of staff time expended on record keeping and stock management.

BSDMG has been engaged to produce a database management system to provide an automated system that keeps track of inventory on a regular basis.

Requirements Analysis
The Team
Cheng Bian
Team Leader
Network Administrator
Irina Pinsker
Lead Designer
Quality Assurance Coordinator
Stephan Manlokis
Deputy Leader
Frank Wong
Requirements Analyst
Standards Coordinator
John Uesi
Recording Secretary
Lead Builder
Brilliant Supermarket Inventory Management System
System Development Cycle
Testing & Maintenance
Planning the Solution
Designing the Solution
Development and Implementation
Understanding the Problem
The Major Techniques
Requirements Analysis Phase
Frank and John

Implementati Testing

Design Phase
Ira and Cheng
1. Functional Decomposition
2. Event Table
Develops use cases based on system response to events

Perceives system as black box interfacing with external environment

Keeps focus on EBPs and business requirements

3. Use Case
Use Case is one way to capture functional requirement
Is a story of using a system to fulfil a goal
What the system responds to when the event is produced

4. Domain Model
Created in order to represent the vocabulary and key concepts of the problem domain.
Identifies the relationships among all the entities within the scope of the problem domain, and commonly identifies their attributes.

5. System Sequence Diagram & Contracts
System Sequence Diagrams & Contracts are artifacts of the Requirements discipline used when a more detailed description of system behavior is needed.

Functional Decomposition
The main purpose of functional decomposition is to break up a large or complex business operation or function into smaller and more manageable chunks. It therefore facilitates understanding of the business operation or function and hence is a useful tool in conducting analysis and design.

A large or complex function is more easily understood when broken down using functional decomposition.

An Example
Event: an event which causes the system to do something.
Trigger: It helps the system know the event occurred.
Source: the source of an event .
Use Case: the system functionality which we need.
Response: The object affected by this action and further react to it.
Destination: An actor that receive the result of an event execution.

BSIMS Domain Model
SSDs illustrate input (data flow into system) and output (system responses) events related to the system under discussion.

Example of SSD
Contracts reflect changes of objects in the Domain Model, after a system operation has executed.

Example of Contract
Development & Implementation
Planning the Solution
Determine which tasks need to be undertaken

The start and end timeframes of these tasks

The sequence in which the tasks will be carried out

Any dependencies

Who will be delivering the specified tasks
The solution was developed for operation on SQL server (for database use) and Visual Basic (for user-interface use).

Additionally, the final solution was developed to be implement on at least 5 computers/consoles.

1. Unit Testing
The smallest unit of the software is tested at the first stage of testing by the individual coder to check the design of the unit and rectify problems quickly.

2. Integration Testing
We ensured there were no defects in the integration and interfaces of the software components within the software development itself. Several defect in the design of the solution were exposed at this stage and we worked to ameliorate them.

3.System Testing
Finally we confirmed that the software developed has met all the business requirements documentation specified by the client. It is also involved re-checking the project management requirements specified.
Sequence Diagrams
Design Class Diagram (DCD)
Database Design

- translate the logical description of data into the technical specifications for storing and retrieving data.
- create a design for storing data that will provide adequate performance and insure database integrity, security and recoverability.

Conceptual ERD
A Conceptual Data Model identifies the highest-level relationships between the different entities and includes the important entities and the relationships among them.

Logical Schema

At logical design phase, Conceptual ER Model is converted into a Logical Schema, which is independent of a particular DBMS.

Features of a Logical Data Model include:

All entities and relationships among them.
All attributes are specified.
The primary key is specified.
Foreign keys are specified.
Normalization occurs at this level.

Design Report
Incorporates all artifacts above and sets forth the design for the solution.
Sequence Diagram is the most important part of the UML.

It shows the interactions between the actors and the objects within a system, via messages, to fulfil the requirements (give a dynamic view of the design model).

Points to note about Sequence Diagrams
The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these.
Interactions between objects are indicated by annotated arrows.
Detail how operations are carried out.
Organized according to time.

Example of Sequence Diagram
provide a static view of the Design Model;
construct and reflect the design decisions about assigning responsibilities to objects.

Design Class Diagrams illustrate:

Classes (from Sequence Diagrams or Domain Model)

Attributes (based on Domain Model)

Methods (by analysing the Sequence Diagram)

Associations (based on attribute visibility between objects)

Example of DCD
First, we started with the Conceptual Data Model (so we understand at high level what are the different entities in our data and how they relate to one another),
then we moved on to the Logical Data Model (so we understand the details of our data without worrying about how they will actually implemented),
and finally the Physical Data Model (so we know exactly how to implement our data model in the database of choice).

Example of ERD
Example of Logical Schema
Physical Database Model

At the Physical Database Design Phase, Logical Model is converted into the technical specifications for storing and retrieving data.

Physical Data Model represents how the model will be built in the database and shows all table structures, including column name, column data type etc
Data Dictionary
contains a comprehensive description of each element in the database.

User Interface
Issues and Learning
What did we learn?
How to write a project charter
Writing use cases
Creating sequence diagrams
creating SSDs and contracts
Working in a team a effectively
Creating web applications using Microsoft Visual Studio
Creating a domain model
Effective project management
Create databases in SQL Server
Database Design
Determining business requirements
Creating ER diagrams
Backup and restoring databases in SQL Server
Generating Scripts in SQL Server
Writing a logical schema
Writing a test plan
Writing a implementation plan

Advice to someone starting a new project
Create a backup of your database at the end of each lesson
Review all database design documentation
Assist team members when they are having difficulty whenever possible.
Familiarizing yourself with Microsoft Visual Studio and Microsoft SQL server before working on the project is highly recommended.

Difficulties faced
Inconsistent naming
Occasional cut-off of communication
Meeting deadlines
Little experience with creating a web applications

What it was like working in a team
Sharing ideas as group
Contribution of different perspectives and ideas
Assistance provided from the team when experiencing difficulty
Practice decision making skills
Negotiation and compromise
Divided workload
Full transcript