Problems Encountered During Software Development

Problems

• Poor requirements – if the requirements are not clear, unfinished, too common, and not testable, then there will be problems.

• Unrealistic schedule – if too much work is given in too little time, problems are inevitable.

• Inadequate testing – no one will know whether or not the program is any good until the customer complain or systems collide.

• Futurities – requests to pile on new features after development is underway; extremely common.

• Miscommunication – if developers do not know what’s needed or customer’s have wrong expectations, problems are assured.

Solutions

• Solid requirements – clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all players.

• Realistic schedules – allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out.

• Adequate testing – start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing.

• Stick to initial requirements as much as possible – be prepared to defend against excessive changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes.

• Communication – require walkthroughs and inspections when appropriate.

Progress Comparation with the Gantt Chart

 

 

The above chart shows what we are planning a project early in project development. However plans have been arranged to have some differences with the way the project is now but the step that are shows in gantt chart have been followed. For example, now we have to finished the task to build the database but we didn't do the task anymore. so what was planned in gantt chart will be changed according by this progress project.

therefore, we hope our project will be complete on time, although our early plan is no same with our progress project.

Software Requirement Specification (SRS)

SRS is a complete description of a system to be developed. Includes use cases which also known as functional requirements. SRS also contains non - functional requirements which impose constraints on the design or implementation.

Car Accessories Inventory System

Purpose 

The objective of this SRS document is to define the activities for the Car Accessories Inventory System which is using web based application in terms of its iterations, requirements, specification and flow required during the phases of its development.

Scope

Car Accessories Inventory System is an offline application that allows user to update their own financial, marketing, database and item stock according to their daily, monthly and yearly business.

Objective

 To reduce the difficulties in handling any stock in the shop and to increase the use of computers in business management.

Functional Requirements

System Environment

Use Case Diagram

Functional Requirement Specification

Login

Description

This use case allows the administrator such as accounting staff and marketing staff   to enter into the system by entering their username and password as provided. Besides that, the administrator that forgot their password can enter the reset password process to get their new password to login. 

 Manage Financial

Description

This use case allows the accounting to update all data for car accessories shop for daily, monthly n yearly financial.

Manage Stock

Description

This use case allows the accounting to manage stock for their item that whether they want to order the new product or update the current stock.

Maintain Product Catalog

 

Description

This use case allows the marketing staff to make the new idea of promotion catalog for print and distribute it for customer.

Setup Promotion

Description

This use case allows the marketing staff to setup promotion for this car accessories shop. The marketing will provide idea to do the promotion such as banner or advertisement.

Manage Item

 

Description

This use case allows the vendor to deliver or collect back the order.

Actors of The System

Non Functional Requirements 

Security

Employee and management are required to login before using the system.

- Require Login

Each employee and management must have their own id to login in the system.

Flexibility

The system that being used is capable of being change and update.

Performance

The performance of the system is good because the system is running on high end device.

- Device

The system is using a computer with Intel i7 Processor and running on 2 GB RAM.

Usability

This system can be used by employee and management without any difficulties.

Reliability

This system can perform and maintain its functions in routine circumstances without any major error.