Software Design Essay For Fuel Consumption And Employee Records System.

Demonstrate skills in project planning and management, problem solving,analysis, and evaluation.
Demonstrate skills in software design, development, implementation,testing, and documentation of an authentic industry type project, that is, a less well-structured or messy problem, requiring demonstration of high level skills.

This report should be in MS Word format. Software Design Documents typically contain several types of UML/other diagrams and tables. If you are using other tools to generate the diagrams paste the generated images on to the Word document. That is only one Word file needs to be uploaded per group. Note that the report is not an essay and should not be text heavy. 

Business Component Design

The current fuel consumption management system used by the Dynasoft filling station is marred with a lot of challenges due to the manual nature of most of its operation especially recording the fuel consumed by the clients on a daily basis (Anund and Kircher, 2009). Most of the data is fed into a manual counter book by the attendant, making it difficult for analysis and forecasting due to its inability to provide a good visual report of the consumption rate. Employee management of the pump firm is also manually kept in manual HR files and it is difficult to track employee activities as such things as leave and timesheet are done manually (Urquhart et al., 2009).

It is in this regard that Dynasoft requested an information system to help solve the situation. The software requirements specifications (SRS) of the proposed system had been documented and handed over. The detailed design of FCERM is discussed in this document. A detailed outline of the document is explained below.

1.1     Document Overview

The chapter following next has described the software design specification which entails the business component design, front-end design, workflow, and the process designs, security, and control design and last but not the least, the database design which is key as it provided how data is designed and relationships among the data entities.

The third chapter which finalizes the document by providing a detailed project management in terms of requirement traceability from the SRS, the project risks and risk management plan and project monitoring, evaluation and controls put in place to ensure the proposed system is a success. 

1.3 Deliverables

The SDS seeks to deliver the following items which shall be used during the project development lifecycle,

• A complete software design specification document detailing the architectural and low-level designs diagrams such as Use Case, Sequence, activity, database, and class diagrams for the FCERM proposed a system.
• A risk management document which entails the risk identification, assessment, and mitigation plans.
• The project schedule which identifies key milestones and deliverables.
• 2.0   Software Design Specification

This section provides the details of the design from the high level architectural and business design to very low-level process, workflow, database and user interface design (Class, 2018). The goal of this section is to provide the visual design details of how the system should be. The output of this section is particularly important for the developers as they do the design into code and implementation (Cooling, 2013)

2.1 Business Component Design

This sections describe the high level design of the business component from the what the business services the system shall provide, why the service is particularly important, when the service should be provided and how the service will be completed, to fully design the service, the table below was used (Laguna and Marklund, 2013).

2.1.1 What

The what question answer what the company seeks to provide the solution for, Below are the details

1. Design and develop the FCERM system
2. Test the FCERM system

• Deploy the FCERM system

1. Optimize the FCERM system
2. 2.1.2 Why

The why questions answer the business component design question of why the organization has endeavored to implement the fuel consumption and employee records system, The following details the answers to why

1. The Dynasoft seeks to automate the business process of recording the fuel consumption of their customer usage of fuel
2. The company seeks to find a more robust solution tool for reporting to the board about the performance off the company to enhance decision making.
3. 2.1.3 When

The FCERM system development should take 3 months starting October 1 2018 to December 31^st 2018. This shall give the designers and developers have ample time designing the processes and activities that the system shall provide.

2.1.4 How

Workflow Design

The How question seek to answer the methodology that shall be used. In this system, the Agile methodology shall be used in all the stages of the system development. This shall make sure there is collaboration between the business owner and the developers and validate and verify the product being developed.

2.1.5 Who

The FCERM system shall be developed by the In-house ICT department and tested by external tester with higher knowledge in the product domain. This shall ensure the system performs normally and that the business processes are followed to the letter

Table 1 Business Processes Description

What	Why	When	How
Check Fuel Consumption	This service enables the customer to check the amount of fuel he/she has purchased from the business	Daily	The customer should log into the system, click on view fuel consumption
Booking fuel in advance	This service allows the customer to make advance booking of fuel from the system to enhance efficiency in service delivery	This is done one day in advance	The client login to the web app, go to book fuel command, fill the detail of fuel to book and click save
Making payment	This service enables the clients to make payments directly from the web app using payment gateways such as PayPal and credit card. This increases efficiency and enhances accountability by the management	After purchasing fuel or making bookings	The client logs into the system, click on make payment command, fill in the billing address and click pay

Actor	Use Cases
Customer	Check FuelConsumption
	Book Fuel
	Make Payment
Employee	Record fuel consumption
Admin	Manage Customer
	Manage Employees

The Use cases are described in the table below.

Table 3 Check Fuel Consumption Use Case

ID	Use Case 0
Title	Check FuelConsumption
Description	Check the total fuel consumption for a given time frame
Actor(s)	Customer
Pre-Condition	The customer is logged in successfully
Post-Condition	Customer successfully checked their fuel consumption levels

Table 4 Book Fuel Use Case

ID	Use Case 1
Title	Book Fuel
Description	The customer books the fuel he/she will need in advance
Actor(s)	Customer
Pre-Condition	The customer successfully logged in,
Post-Condition	Customer successfully booked fuel from the firm

Table 5 Make Payments Use Case

ID	Use Case 2
Title	Make Payment
Description	The customer makes payment after a purchase is done or a booking is done
Actor(s)	Customer, Payment Gateway
Pre-Condition	The customer is successfully logged in and has enough money in his/her payment gateway
Post-Condition	The payment is successfully done

Table 6 Record Fuel Consumption Use Case

ID	Use Case 3
Title	Record FuelConsumption
Description	The use case enables employees to record fuel consumption on a daily basis for record and reporting
Actor(s)	Employee
Pre-Condition	Employee logged in successfully
Post-Condition	The records are saved successfully

Table 7 Manage Customers Use Case

ID	Use Case 4
Title	Manage Customers
Description	Add, Edit, Update, delete
Actor(s)	Admin
Pre-Condition	The admin is logged in successfully
Post-Condition	A new customer is either added, update or deleted successfully

Table 8 Manage Employee Use Case

ID	Use Case 5
Title	Manage Employee
Description	Add, Edit, Update, delete
Actor(s)	Admin
Pre-Condition	The admin is logged in successfully
Post-Condition	A new  employee is either added, update or deleted successfully

Workflow design is critical for the correct representation of business rules and correct execution of processes; the processes should adhere to the following standards (Cerezo, Montagnat and Blay-Fornarino, 2013).

• Strive to make the processes more generic than specific.
• Always consider at what point the process under construction generates notifications especially when the during the occurrence of the following event; when decisions are to make when a specific path is reached and a task is assigned.
• Always consider what mechanism will be used to handle the null values
• Design ways to limit infinite loops in processes.
• Enhance code efficiency by either creating sub-processes or looping.

To properly design the workflow and processes, the following UML diagram was used; sequence and activity diagrams respectively

2.3.1 Activity Diagram for Pay Fuel

The above activity diagram designs the process flow for the payment of fuel by the customer, The initial activity involves the customer entering his/her credentials, which act as the pre-condition before the process kicks, if the login is correct, then the system calculates the fuel cost best on the current base rates for fuel/ liter. The total price is presented to the customer (Chanda et al., 2009). The customer then checkouts to the pay the invoice via the approved payment gateways. The payment gateway checks if the account has sufficient funds or not. If funds are sufficient to pay the order and transaction fees, the amount gets debited from the customer account, otherwise, the system shows the insufficient amount in the wallets (Motameni et al., 2008).

2.3.2 Sequence Diagram

The sequence diagram is a behavioral UML diagram used to model the behavior of the system as it interacts with the actors and other external in temporal time frames. The sequence diagram for the pay fuel business process is as shown below.

From the diagram, the customer visits the filling station to have a refill, the system verifies the customer using his/her credit card and amount parameter (Panthi and Mohapatra, 2013). If the customer wants to pay by cash, then the verify_customer() transaction gets canceled. If the verify_customer() returns okay that is the funds are enough to pay the amount, the new_fuel(customer, date, quantity) method get executed to refuel the automobile,

 Class Diagram

Classes are the blueprints from which objects are created. The FCERM system contains several blue classes that are related to one another. The diagram below illustrates the various classes in the system,(Sharif and Maletic, 2009)

The above classes are vital for the programmer who will be writing codes for the objects in the development stage. The various attributes and methods have been designed making the actual creation of objects from the classes enjoyable.

Sequence Diagram

2.4 Security and Control Design

Security designs provide various techniques and the various methods that can be used to make the software and or hardware components to enhance the security of the software. To design took into consideration the following techniques (Pathiyal, 2013)

• Handshaking
• Authentication
• Encryption
• Authorisation

The details of the design are explained below,

2.4.1 Handshaking

Since the application shall be hosted in the cloud, it is vital to design a handshake protocol to help with the initiation, maintenance, and termination of all sessions between the client and the server. This diagram below shows the design (Dierks and Rescorla, 2008),

2.4.2 Authentication

                         The access to the web application shall require a username and password combination that shall be used to authenticate the users into the application. The entry of the wrong username and/or password shall lead to temporally block the application for the machine for at most 15 minutes. This improves on the security of the system from brute force. The password must meet the following requirements during the creation of accounts, (Schneider, 2012)

Item	Minimum Requirements
Minimum Length	Acceptable length of  eight (8) characters
Storage	Never stored in plain text, recommend memorizing
Character combinations	Must contain at least 1 character from atleast any of the 3 character sets Uppercase letter (A-Z) Lowercase letter (a-z) Digit (0-9) Special character (~`!@#$%^&*()+=_-{}[]|:;”’?/<>,.)
Ownership	private

2.4.3 Encryption

The encryption assures the user of the security of their data in case of incidences of data breaches. This provides a layer of security on top of the application. All the sensitive data for the user especially the credit card numbers are encrypted using the AES-128 encryption algorithm. The design of the algorithm is as shown below (Daemen and Rijmen, 2013),

2.4.4 Authorization

                         Authorization ensures the permission level is well managed so that all the users accessing the system only get the services they need to reasonably conduct their duty. The access to the proposed system shall be role-based, where the admin has root privileges while the customer has the least privileges to the system (Kaur and Kaushal, 2011).

                         Apart from the security design explained above, it is vital for the proposed system to have some level of application control to ensure the services provided by the application are effective and efficient and that all the business rules are met to the latter and verification and validation is done. The control designed into the application are listed below,

• Completeness in process execution
• Validation
• Form input controls
• Unique identifications

The above are designed as explained below

Completeness in process execution

All the processes in the application are designed inside a transaction which rolls back everything if there is the incomplete execution of processes, this provides data integrity, the transaction is designed in the algorithm below (Shibayama, Matsushima and Kikushima, 2008),

START TRANSACTION

    [transaction_characteristic [, transaction_characteristic] ...]

transaction_characteristic: {

    WITH CONSISTENT SNAPSHOT

  | READ WRITE

  | READ ONLY

BEGIN [WORK]

COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]

ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]

SET autocommit = {0 | 1}

Validation

Validation of data input and the data being processed are vital in enforcing data reliability. All the validation rules shall be done at both the front end and the back end (Gruschka and Iacono, 2009).

the fields to be validated in the front end includes,

Field	Validation Check
Username Field	Maximum length 25, Minimum length 5
Password Field	Refer to password field design
Email	Refer to email field design
Phone number	Minimum  length 10, maximum length 15

Unique Identification

All entities must have a unique way to identify them so that records about them can be generated. The users shall be identified using the username attribute.

Class Diagram

2.5 Database Design

The database design is derived from the ERD diagram. The ERD is as shown below,

                         The primary key is the ID field. The username is varchar datatype with a maximum field length of 25. The password field has varchar datatype with a field length of 32. The Phone_No is a variable character with a length of 15, email address field is a varchar field with a length of 255, account status is Boolean with default is Yes meaning active accounts and finally, the date added is a timestamp for the date the account was created.

Employees table

The employee's table has the following columns

• The ID of type auto-increment
• Username varchar of 25 field length
• Password of varchar of 64 field length
• Email of varchar of 255 field length
• FirstName of varchar 25 length
• LastName of varchar 25 length
• PhoneNo of varchar 15 length
• AccountStatus of Boolean

Customers table

This table store the following data about the customer,

The column is described below,

• ID type autonumber
• Username of varchar 25
• Password varchar 64
• FirstName varchar 25
• LastName varch 25
• PhoneNo varchar 15
• EmailAddress varchar 255
• Date Added timestamp
• AccountStatus Boolean

Bookings Table

The booking table is designed as below

The columns are explained below,

• ID contains the booking id, it is of type autonumber,
• CustomerID is a foreign key that references the CustomerId in the customer's
• Quantity; is a double value that stores the amount of fuel in gallons to be reserved for the customer
• The amount is a currency value that store the price of the gallons reserved
• Databook is a timestamp for the date the reservation was made
• Status is a Boolean for storing whether the reservation is pending or approved

Purchases

The purchase table store the details of the customer who wants to make a direct purchase of the petrol fuel. It is designed as shown below

The details of the columns are as shown below

• ID is a primary key of the purchases table which is of type autonumber
• CustonmerID is a foreign key that references the customer in the customer table.
• Quantity store the quantity of fuel in gallons purchased by the customer
• DatePurchased is a timestamp that store the date the purchase was done
• EmployeeID is a foreign key that references the EmployeeID in the employee table.

Once the design is done, it is important to design how the project shall be managed, this is explained in the section below,

3.0 Project Management

                         Project management is key since risk is always bound to be mitigated during the execution of the project. To completely design the management of the project and ensure the complete realization of project objectives, the requirement traceability matrix, risk management plan, and project monitoring and control tools must be designed in advance to guide in the management. The details are described below (Turner, 2014)

3.1 Requirements Traceability

                         Requirement traceability is key is providing a way to always know where the requirement came from i.e who initiated the requirement be it the product owner or the users themselves. This is key in maintaining the linkage of the features to the set requirements. Traceability can also be done within artifacts of the software development landscape from SRS to SDS to implementation to testing. This ability to trace requirement is done via a requirement traceability matrix which provides a tool to link the requirements as enlisted in SRS to the SDS (Li et al., 2008). The FCERM  traceability matrix is as tabled below,

Table 9 Requirement Traceability Matrix

Feature ID	Feature	Use Case ID	Use Case
Feat0	The system should allow customers to check the fuel consumed in a given timeline	UC0	Check fuel consumption
Feat1	The system should allow the customer book fuel in advance	UC1	Book Fuel
Feat2	The system should allow the customer make payment using the mobile wallets, credit card, and other payment gateways	UC2	Make Payment
Feat3	The employee should be able to record the fuel consumption rate any time	UC3	Record Fuel Consumption
Feat4	The system should manage the customer from registration, update and archiving	UC4	Manage Customers
Feat5	The system should manage the employee from registration, updating and archiving	UC5	Manage Employees

3.2 Risk Management Plan

A risk is an event which when occur can negatively or positively affect a given project. The FCERM project risk plan was designed by outlining key risks, the mitigation option and the determination of risk appetite (Hubicki, 2014). This is outlined in the table below

Table 10 Risk Plan

Key Risk	Mitigation	Appetite
Increasing speed of technological development	-Encourage the team to continual train on new tools -Invest in new technological tools and methods	MODERATE
Unqualified staff to run the system	The petrol station should insist on basic ICT skills as an added advantage in the HR policy	LOW
Changing business models	The
Inadequate financial funding	The manager should avail the required capital for initiating and working	HIG
Data Breaches	Ensure proper compliance with privacy laws and procedure	HIGH

3.3 Monitoring and Control

To ensure the project is finished within time, scope and budget, it is important for monitoring and control methods set up to ensure the smooth execution of the project. The project Gantt chart and the critical path method is set to graphical check the progress of the project and check task dependencies (Aliverdi, Naeni, and Salehipour, 2013).

4.0 Conclusion

In conclusion, the FCERM system design document when followed by the developers and analyzed by both the developers and business analysts shall be very important blue print in ensuring the product being developed follows the various laid down rules and procedures and documented in this document, this shall make the various feature developed in the final product traceable since all the requirements shall be traced via the design document into the SRS document already written.

References

Aliverdi, R., Naeni, L.M. and Salehipour, A., 2013. Monitoring project duration and cost in a construction project by applying statistical quality control charts. International Journal of Project Management, 31(3), pp.411–423.

Anund, A. and Kircher, K., 2009. Advantages and disadvantages of different methods to evaluate sleepiness warning systems. Statens väg-och transportforskningsinstitut.

Blair-Early, A. and Zender, M., 2008. User interface design principles for interaction design. Design Issues, 24(3), pp.85–107.

Cagiltay, N.E., Tokdemir, G., Kilic, O. and Topalli, D., 2013. Performing and analyzing non-formal inspections of entity relationship diagram (ERD). Journal of Systems and Software, 86(8), pp.2184–2195.

Cerezo, N., Montagnat, J. and Blay-Fornarino, M., 2013. Computer-assisted scientific workflow design. Journal of grid computing, 11(3), pp.585–612.

Chanda, J., Kanjilal, A., Sengupta, S. and Bhattacharya, S., 2009. Traceability of requirements and consistency verification of UML use case, activity and Class diagram: A Formal approach. In: Methods and Models in Computer Science, 2009. ICM2CS 2009. Proceeding of International Conference on. IEEE, pp.1–4.

Class, Z.-W.T.-E.C., 2018. Software Design Specification.

Cooling, J.E., 2013. Software design for real-time systems. Springer.

Daemen, J. and Rijmen, V., 2013. The design of Rijndael: AES-the advanced encryption standard. Springer Science & Business Media.

Dierks, T. and Rescorla, E., 2008. The transport layer security (TLS) protocol version 1.2.

Elbendak, M., Vickers, P. and Rossiter, N., 2011. Parsed use case descriptions as a basis for object-oriented class model generation. Journal of Systems and Software, 84(7), pp.1209–1223.

Gruschka, N. and Iacono, L.L., 2009. Vulnerable cloud: Soap message security validation revisited. In: Web Services, 2009. ICWS 2009. IEEE International Conference on. IEEE, pp.625–631.

Hubicki, M., 2014. Risk Management Plan.

Kaur, P.J. and Kaushal, S., 2011. Security concerns in cloud computing. In: High Performance Architecture and Grid Computing. Springer, pp.103–112.

Laguna, M. and Marklund, J., 2013. Business process modeling, simulation and design. CRC Press.

Li, Y., Li, J., Yang, Y. and Li, M., 2008. Requirement-centric traceability for change impact analysis: a case study. In: International conference on software process. Springer, pp.100–111.

Motameni, H., Movaghar, A., Daneshfar, I., Zadeh, H.N. and Bakhshi, J., 2008. Mapping to convert activity diagram in fuzzy UML to fuzzy Petri Net. World Applied Sciences Journal, 3(3), pp.514–521.

Panthi, V. and Mohapatra, D.P., 2013. Automatic test case generation using sequence diagram. In: Proceedings of International Conference on Advances in Computing. Springer, pp.277–284.

Pathiyal, K.K., 2013. Security interface for a mobile device. Google Patents.

Schneider, J.P., 2012. Username based authentication security. Google Patents.

Sharif, B. and Maletic, J.I., 2009. An empirical study on the comprehension of stereotyped UML class diagram layouts. In: 2009 IEEE 17th International Conference on Program Comprehension (ICPC 2009). IEEE, pp.268–272.

Shibayama, S., Matsushima, Y. and Kikushima, K., 2008. Parallel process execution method and multiprocessor computer. Google Patents.

Turner, J.R., 2014. Handbook of project-based management. McGraw-hill New York, NY.

Urquhart, C., Currell, R., Grant, M.J. and Hardiker, N.R., 2009. Nursing record systems: effects on nursing practice and healthcare outcomes. Cochrane database of systematic reviews, (1).