Online Rent A Car System In Malaysia

Published Date: 02 Nov 2017

INTRODUCTION TO THE TOPIC

1.1 Software Quality

In software engineering, a definition that is assigned to Software Quality is how well a software has been designed (quality of design) and how the software adapts to the design (quality of conformance) (XBOSoft Ltd., 2013). Testing software functional requirements such as business rules and functionalities, is very easy compared to the testing of non-functional requirements such as performance which can be way more difficult. For example, if a user can complete a task it does not necessarily means that the software is of good quality. Software Quality for a company/developer is about defining what qualities are being looked for in the designed software and what measures should be taken to measure and evaluate the software. It is very important to note that if the developer/company does not know what to measure, then it is impossible to evaluate and call the product, a software of quality. For example, ISO developed ISO 25010 (ISO/IEC CD 25010, 2010) as a model for categorising non-functional requirements as shown below:

Figure : Classification of Qualities for a software Product

(Source: http://www.xbosoft.com/definition-software-quality/)

1.2 Software Quality Assurance (SQA) and Roles

Software Quality Assurance is a process-centered approach to confirming that a company or business is providing the top possible products or services (WISEGEEK, 2013). It is related to quality control, which emphases on the end result. For example, testing a sample of items from a batch after production to see whether it conforms with standards. Quality Assurance focuses on improving the process that is used to create the end result, rather than focusing on the result itself. Among lifecycle parts of the project, the ones that are considered in Quality Assurance are planning, design, development, production and service. Roles:

The overall roles that are assigned to the quality team are as follows:

The Lead oversees all staff and activities for all assigned applications while ensuring all the standards are being met, and provide weekly report that provides software quality metrics (Unknown., 2013).

The Test Analyst and Performance Analyst follow standards and provide the Lead with weekly reports.

Note: This section gives only a brief about the Quality assurance processes. It will be described in more details in section 4.0.

1.3 Objectives

The main objective of Software Quality Assurance is making sure that quality can be delivered in the software, usually related to processes and standards. Software Quality Assurance is more related to prevention and not similar to testing as testing does detection. It involves monitoring and improving processes constantly ensuring that all standards are being met and deal with problems arising mid-way. The Case Study of the ORAC Project discussed in section 2.0 is going to be monitored for quality using a software quality assurance plan. The objectives listed below have to be met by the system processes of ORAC in order to be a product of Quality.

Produce a product of high quality including reliability and performance standard.

Solve all issues in the product even before release.

Reach a minimum of Capability Maturity Model Integration (CMMI) Level 3 of International Quality Standards for the project.

1.4 Assumptions

Before proceeding further with the research, the assumptions put forward have been as follows:

The development and assurance process is being carried out in a team.

The project is about creating a general-purpose software called, Online Rent-A-Car System in Malaysia which will be customised and sold to different companies.

This process is being carried out since the methodology used in the case study is Rapid Application Development and doesn’t concentrate much on documentation.

The purpose is to obtain an international standard quality for the project.

1.5 Problem Description

Since the ORAC project is supposed to be completed within a limited length of time, it is very difficult to manage standards in codes and other non-functional requirements. Together with time, another factor is human nature. Human cannot recognise his mistakes on his own. By making use of a Quality Assurance Process Model, the person can track and remove non-functional bugs to achieve the objectives listed above.

1.6 Benefits gained from Software Quality Assurance

The benefits of using Software Quality Assurance are given below:

Greater Customer Satisfaction due to higher reliability.

Cost of Software Production is reduced.

Maintenance cost is also reduced after software since project requires lesser correction after Software Quality Assurance is performed.

SQA gives developer opportunities to be self-organised and self-regulated which enhances professionalism.

It establishes where to make effective and continuous improvements to raise quality constantly.

2.0 INTRODUCTION TO THE SYSTEM

2.1 Introduction

"If your business is not on the internet, then your business will be out of business" – Bill Gates, Founder of Microsoft (September 2011).

An online car rental system allows a person to book/reserve a vehicle with/without payment on one end while the company staff handles the transactions, on the other via the Internet. Online Car Rental Systems are used mostly in developed countries such as England and Australia where electronic commerce has been fully accepted in the society. Famous companies such as Europcar from United Kingdom, has gained popularity since the business used the technologies available to expand and provide more facilities to their customers.

The basic functions of an online car rental system are to keep tracks of vehicles, staff, customers and booking. It provides useful information to the staff such as giving daily reports of vehicles to be delivered/picked up and acts as a vehicle management system by monitoring the use and price of the vehicles.

2.2 Problem Identification

Malaysia is a developing country where almost all businesses are automated. Even car rental companies use on-site database to store their daily transactions. But it is surprising that 95% of companies approached, were not very enthusiastic in turning their business to online although it can bring them a lot of benefits. It is also seen that when a car rental company tried to do it, it was not successful and therefore became inactive.

"Are the available car rental systems in Malaysia reliable enough, to manage all the transactions, while ensuring security of the company and the customers?"

Malaysian companies were not satisfied with the quality of online car rental systems that are being offered to them and the ones that are very good happen to be costly and unprofitable to their businesses.

This is where the idea of building Online Rent-A-Car System in Malaysia, hereafter referred to as ORAC, was born. ORAC is an online car rental system that will bring a revolutionary change in the car renting business in Malaysia. It hasn’t been associated to any company name but can be integrated in any company where it will handle effectively the transactions of the whole system. Though online car rental systems happen to be very common around the world, ORAC will be a complete, i.e. secure and reliable system for use.

Existing car rental systems are fully functioning but when security, reliability, safety and privacy is concerned, it is disappointing after doing the evaluation of the existing systems. The main concerns of the companies are classified as security issues, public safety, law and regulations, time concerns and losses in the business.

Security is a fundamental aspect in the world of electronic business and it deals with money. Existing car rental systems have flaws in matters of security. Having come across many car rental websites which have integrated payment systems but are not able to provide HTTPS (Hyper Text Transfer Protocol Secure) protocol are endangering the customer as well as the company. These websites can easily be hacked and all the banking details of both parties can be retrieved. This is a foremost concern that has to be catered for in an electronic business.

Public Safety is a prime concern for any responsible human. The issue related to public safety is the control of the legal papers of a driver. Existing car rental companies have until now not given consideration to the flaw that the websites do not provide authentication of the license and IC/Passport of the person booking the car. It is a must for a driver to have a license while driving any car so that not to endanger the lives of pedestrians. If any mishap occurs, it may result in death of people and as well destroy the image of the company.

Law and Regulations of Malaysia state that the cost to bear in case of road accidents is fifty per cent from the company and the driver while the company can be dragged to court if the driver did not have license. Providing cars on rent to illegal drivers is not safe and these systems are absolutely not recommended if identity of a driver cannot be authenticated by the company.

Time concerns result from the fact that booking have to be made a minimum of 48 hours prior to the time of delivery which is not time effective for the customers. Customers who need cars urgently won’t be able to receive one on time. This discourages people from using the systems and therefore not flexible enough for use.

Existing car rental businesses have to bear a lot of costs. If they use a doubtful system with much loopholes it can lead to losses in the business instead of profit and may even lead to bankruptcy. Additional costs are risky according to businessmen therefore, they prefer not taking the risk of involving more costs.

2.3 Rationale

ORAC has been basically proposed to be built in Malaysia due to various reasons. The main one being that the amount of tourists and students coming over to Malaysia have increased greatly and most of them wish to rent cars with legal companies at reasonable prices to go around the country and secondly, to provide a more secure and reliable system to users (both company and customers) and for the benefit of the country by introducing concepts of documents upload for the booking process (local/international driving license copy, IC/Passport Copy).

The Car Rental System will be designed for many reasons that will help to promote a car rental system of quality. Quality here specifies for a software that will cater for the needs of both the company and the customers, along with the benefits of the country.

2.4 Aims, Objectives and Deliverables

2.4.1 Scope of Proposal

"The scope of a system defines the boundaries of the system to be built". In other words, the assumptions used and the different features to be considered before building up the system have to be pre-defined in order to have a system of quality For this car rental software, the assumptions made are as follows:

This system is for use by only one company which will be maintained by the staff.

The company has different branches in Malaysia.

The customers will be charged according to terms and conditions specified.

The different features of a car rental system to be included will be:

Managing details of Vehicles

Managing Staff details

Managing Customer Details

Producing Daily, weekly and monthly reports

Booking of Vehicles

2.4.2 Out of Scope

The "Out of Scope" sections describes the parts of the system that form part of the existing systems but cannot be included because of the amount of time dedicated in building up the system. It is as follows:

Vehicle Management System – This is a management system on its own whereby the insurance details, servicing details, mileage and other vehicle details are maintained.

Staff Log – It is used to keep track of who signed in at what time and how many transactions did each one handle.

Customer Feedback Page – This is to gain feedback of customers on the system so as to know which features should be improved in the future.

No mobile application version will be created for this car rental system.

Since time is limited and the list of deliverables is already bulky, it is next to impossible to complete these stated parts in the time limit given for the project. One or two may be included only if at the end of the project, there is still sufficient time to code the above mentioned section.

2.4.3 Aims of the System

The aims of ORAC will be to improve cost-handling activities so that the company profit margin increases while decreasing the labour cost, taxes and it becomes easier to handle have control on the employees. Secondly, it helps promote safety of people, security and therefore keeps integrity of confidential customer data. Moreover, the company transactions will comply with all the Law and Regulations of Malaysia, reducing to the maximum number of frauds occurring through verification processes. Finally, owner of can have a centralised based whereby all the staff can work and have different locations to keep the vehicles.

2.4.4 Objectives of System

Objectives are more specific statements about what ORAC will be able to do after completion of the system.

The first objective is to reduce cost of the system by centralising all the data which requires less staff under a more controlled environment.

Secondly, ORAC should reduce the risk of fraud occurring as it uses document upload feature for verification of license and IC/Passport purposes, making a system complying with Rules and Regulations of Malaysia.

Together with a safe website, ORAC is meant to provide security and guarantee of user data integrity and confidentiality, thus reassuring users that their personal details are in safe hands, by using a secure Instant Payment Notification system, called Paypal Sandbox Configuration.

ORAC has to be a time saving website as it uses a Real Time Notification System where a notification is issued to the staff to verify and authenticate users on the spot.

Another objective of ORAC is to prevent spams from registering by using features called Email Verification links and SMS Verification Codes to verify authenticity of users.

Last but not least, having a simple interface with minimum data to fill up to encourage more people to use the system for booking is very necessary.

2.4.5 Deliverables

"Deliverables is concerned with the detailed features to be included in the software that solve the problems mentioned in the description of problem area section". The deliverables have been broken down into three different categories which are the "core", "additional" and "special" features.

The "core" features are as follows:

Provide login interface for the customers, staff and manager of the company.

Allow manager to manage (view, add, edit, delete, save) details of staff.

Allow staff to manage (view, add, edit, delete, save) details of vehicles.

Allow staff to manage (view, blacklist) details of customers.

Allow customers to manage (view, edit, save) their own details.

Allow staff to print their daily, weekly and monthly reports about vehicles and bookings' details.

Allow customers to view, choose vehicle and make their booking.

The "additional" features are those which help to enhance security for both customers and company:

Document Upload for passport/IC copies and valid international/local driving license for booking.

Email and SMS verification and confirmation for customers' authentication.

A notification page for the staff as soon as a booking is made a tag to booking page by the staff who is checking the authenticity of the customer.

A manual that will help the company staff to learn how to use the system and explain the functioning of the software in details.

The "special/extra" feature for this software will be the instant payment method which is of high level security and help to protect the confidential details of the customers and make sure that the company receives its payment before making any delivery to its customers.

3.0 METHODOLOGY – James Martin’s RAD

3.1 Description of Software Development Methodology

"The James Martin’s RAD is named as such because it was developed by James Martin (born 1933) in the 1980’s (CaseMaker Inc., 2007), British Information Technology Consultant and Author."

This methodology is defined as an approach to building a computer system that uses Computer Assisted Software Engineering Tools (CASE Tools) and techniques together with user-driven prototyping under a strictly given time limit (CaseMaker Inc., 2007). The main objective of RAD is to provide software of quality, even though developed in a small amount of time. The RAD uses automated tools, i.e., software in order to automatically generate the system diagrams, called UML Diagrams to restructure the building up of information systems.

The RAD involves four essential aspects namely Methodology, People, Management and Tools as shown in the diagram below:

Figure : Essential Aspects of RAD

(Source: http://www.casemaker.com/download/products/totem/rad_wp.pdf)

Methodology

The RAD development path faces the challenges that are normally encountered with other methodologies, directly by providing ways of developing systems faster, while minimising cost and maximising quality. It combines the best accessible techniques and specifies the order of tasks, thus making the techniques more operative.

The structure of RAD thus, allows the developers to build up the specifically required system that the user really needs. The four major stages of RAD are as follows:

http://www.devfaction.com/Images/RAD.png

Figure : Stages of RAD

(Source: http://www.devfaction.com/Services.aspx)

Requirements Planning

It is the Concept Definition stage, where the business functions, processes and data subject areas are translated into the scope and objectives of the system (Barbara T., 2010). The requirements are analyses for conflicts and after requirements finalisation, the user design is started.

User Design

Known as Functional Design Stage, workshops are used to model the system’s processes and data to be able to build a working prototype of critical system components using automated tools so that system can be clearly understood by both project team and stakeholders (Developers.Net, 2007). Before going to the construction phase the project team should focus more on efforts in order to improve the prototype before every start of the cycle.

Construction

Also called the Development stage, the system is being built with all the specified requirements to provide a system performing all of the activities being carried out in the actual system so that the project can be incorporated. The CASE Tools, that may be already in the development software or external, are used to automatically generate the system diagrams and the interfaces also sometimes, which saves a great deal of time.

Cutover/Implementation

Upon completion of system building, the Implementation/Deployment stage is where the different types of testing are carried out, training sessions are given to users of new system and finally system is launched.

People

In RAD methodology, interaction with stakeholders of systems is often. In order to create a system of quality, constant interaction is made between stakeholders and developer so as to avoid misunderstanding before moving ahead in each phase. Excellent tools are fast, but it does not necessarily means that they guarantee success. In order to achieve success in any IT project, stakeholders need to be involved in every stage to avoid conflicting requirements. Thus both the developer and the stakeholders must be highly motivated to work in a team. It allows a person to play different roles at a time. Communication is essential in developing a system and is of great need to give a product of quality.

Management

The management should dedicate itself entirely to the RAD process so as to manage the change in culture (CaseMaker Inc., 2007). The management has to keep off the obstacles and problems that become a handicap in the fast development course in order not to lack back in limited time given. Dedication from a good management is ideal to fasten the process of system building.

Tools

Tools used in order to fasten the system building process are automated and also includes human techniques that help to achieve goals of high quality, as well as high speed (Developers.Net, 2007). A fundamental principle in RAD is to use help of diagrams wherever clear thinking is required which makes it a lot simpler to understand both requirements and functioning. CASE Tools help the building up of system through use of simple tools to draw UML Diagrams.

Advantages of RAD:

The primary advantage of RAD is a faster development, with a high quality of product in less time.

Although RAD may compromise in case of scalability and range of features, it gives a product of higher quality by meeting all the user requirements and providing an error-free software.

RAD involves maximum user interaction which gives a great customer satisfaction at the end of the project.

RAD gives time boxing facilities, whereby different versions of the product can be launched with time and with more features of the software.

RAD involves all the stakeholders and the development team which gives a better collaboration and understanding of the user expectations.

Due to the iterative approach of the methodology and user feedback available at every stage, risk of failure is eliminated from the project.

RAD promotes a better documentation by using written test cases.

Usability of Components increases the development speed.

Disadvantages of RAD:

If any of the parties do not have the will to collaborate, this methodology will not work.

The methodology works only if the project has existing prototypes in order to ease the process.

This methodology is not useful is projects if highly complex, unique and large.

3.2 Reasons for Choice of Methodology

After studying the different methodologies existing, the conclusion is that James Martin’s RAD is the best methodology, hybrid with minor changes made on the side of the developer in order to develop ORAC. The main reasons being, the high quality project delivered in a limited amount of time. RAD consists of simplifying the developer’s tasks and the cost to bear. Another reason for choosing RAD, is that the software being used for building up ORAC supports RAD Tools and provides full flexibility of generating the required diagrams for the project.

4.0 QUALITY ASSURANCE PROCESSES

In Section 1.2, Quality Assurance process was defined. As there are various ways to carry out a process, there are different Quality Assurance Process Models that exist in order to carry out this process. There are some briefly defined in the following paragraphs:

McCall Model

McCall, introduced in the 1970’s, uses external quality factors in order to define the product quality criteria. It classifies all software requirements into three categories, product operations, product revision, and product transition.

Boehm Model

Boehm Model, introduced in the 1970’s attempts to define the quality of software qualitatively, by a predefined set of attributes and metrics.

FURPS Model

Brought in the industry by Robert Grady and Hewlett-Packard, it is a model with the industrialised approach which aims at improving management of software development processes.

4.1 Software Quality Factors

Software Quality Factors are characteristics which are measured for testing the quality of software. The table on the following page shows the characteristics and the description for each.

Figure : Defining the Attributes/Characteristics

(Source: http://www.asmedu.org/uploadfiles/image/file/pdf/INCON13-IT-070.pdf)

The following table shows which model satisfies which characteristics.

Figure : Characteristics of each Model

(Source: http://www.asmedu.org/uploadfiles/image/file/pdf/INCON13-IT-070.pdf)

From the given table, the required characteristics to be included in the ORAC Project, has been covered by the McCall’s Quality Model. McCall’s Model has been described in details in section 4.2, with respect to the attributes required in the ORAC in section 4.3.

4.2 McCall Quality Model

In 1977, Jim McCall produced a model for the US Air Force with the intention of bridging the gap between users and developers. The Model tried to map the user’s views to the developer’s priorities. McCall’s model can be called as more renowned predecessors of today’s quality model and another name of this model is electronic model. The following shows the McCall Quality Model:

http://csis.pace.edu/~marchese/cs615sp/L9/fg1.gif

Figure : McCall Quality Model

(Source: http://csis.pace.edu/~marchese/cs615sp/L9/lec9.html)

The McCall Quality Model identifies three perspectives/stages of characterisation of the software product which are as follows:

Product Revision

This identifies quality factors influencing the ability to change the software product which are as follows:

Flexibility (Make changes as written in the business rules)

Maintainability (Find and fix a problem)

Testability (Validate the software requirements)

Product Transition

This refers to the quality factors that affect the adaptability of the software in new environments:

Portability (Transfer Software from one environment to another)

Reusability (Using existing software components in different contexts)

Interoperability (the extent to which software components work together)

Product Operations

This identifies the extent to which the software fulfils its requirements and includes the following quality factors:

Correctness (Functionalities match business specifications)

Reliability (To which level is the system a success)

Integrity (Unauthorised access is not allowed)

Usability (Easy to use)

Efficiency (Usage of system resources)

4.3 Quality Factors involved in ORAC

The quality factors involved in ORAC are as follows:

Integrity

In ORAC, Integrity is preserved as each level of user are entitled to see a specific menu whereby some features can’t be viewed by staff and customers while administrator has access to almost all features.

Efficiency

Efficiency in ORAC is measured on what the user needs to access the system. Basically ORAC, an internet connection and a device to open the website are the only requirements to access/register on the site.

Usability

The target audience for using ORAC is very broad, including from novice to expert computer users. Therefore, the design should be meaningful enough for all the categories of people involved to find it easy to use.

Reusability

It involves using existing logics/components of codes to carry out a specific task in a different context. ORAC can make use of reusability as it is improving existing systems which have existing codes for basic functions.

Reliability

Reliability is an important quality factor as ORAC needs to achieve all the objectives listed in section 2.0.

Correctness

All the business specifications must be present in ORAC for a proper functioning of the system.

Interoperability

Some components of ORAC need to be linked in order to perform some tasks in the proper way. This means if a payment is made by the customer, a notification will be issued to the staff and an email is sent to the customer. If these components are not linked it is not possible to do the three actions together.

Flexibility

Flexibility of the ORAC system comes when the business rules have minor changes. Moreover, for ORAC the system is flexible whereby customers need approval for their registration before being able to book a car. This is important in order to avoid frauds to be committed in the system.

Maintainability

Finding and fixing problems is an easy process if coding has been done using standards. Maintainability forms part of ORAC as improvements are made to cater for small changes in functions/features.

Testability

In order to validate the requirements put forward for the development of ORAC, testability is a required quality factor in order to remove all bugs and provides an error-free product of high quality.

4.4 Capability Maturity Model Integration (CMMI)

ORAC has an aim of reaching at least the CMMI Level 3, which is the minimum to be on an international level of standards. The CMMI is a process improvement approach to software development. It identifies a set of Software Engineering Processes listed as follows:

Requirements Development

Requirements Management

Technical Solution

Product Integration

Verification

Validation

CMMI covers both Software Quality Assurance (SQA) and Software Quality Control (SQC) while SQA is defined under the Product and Process Quality Assurance process area and Software Quality Control is under the Verification and Validation Area (Anonymous, 2007). The diagram below shows the structure of the CMMI:

http://img66.ph.126.net/4XhhwFu2BeleYRkQr3g63g==/836262155809110042.jpg

Figure : Structure of CMMI

(Source: http://nustchenhf.blog.163.com/blog/static/1120679920113643020781/)

The aims of CMMI are to enhance the capabilities of development and maintenance by using a set of key process areas (KPAs). Each CMMI Level has a certain number of KPAs which have to be satisfied for achieving that CMMI Level. The Maximum Number of Maturity Level is five (5) which will be shown in the following diagram:

http://www.tutorialspoint.com/images/cmmi-staged.jpg

Figure : Brief Description of the five Maturity Levels of CMMI

(Source: http://www.tutorialspoint.com/cmmi/cmmi-maturity-levels.htm)

The KPAs of each Maturity Level is shown in the diagram below:

http://www.etestinghub.com/images/kpa.GIF

Figure : KPAs of each CMMI Level

(Source: http://www.etestinghub.com/cmm.php)

5.0 ESTIMATION TECHNIQUES

The accuracy of an estimation result is important in any software development project (Academia, 2013). Estimation of resources should be made at the Planning Stage of the project whereby resources needed are outlined and estimated approximately. The success factors in order to estimate cost, efforts and time for the ORAC Project so that to prevent problems (over budget, time lacking) are as follows:

Entertainment

Entertainment refers to the cost to bear for going out in meetings, which is normally ignored in the estimation whereby the project manager has to bear the cost from his own pocket. This often creates misunderstandings and the budget may be over exceeded when the issue is raised.

Sponsor’s Role

The sponsor’s role is to make sure that the proper planning is done by the project manager within the budget provided rather than keep increasing resources required by asking him to give frequent reports regarding the progression of work.

Proper Tool Selection

In order to find an accurate estimate, use of a proper tool is important so as to keep track of previous estimations and learn from the loopholes. Since Recently, Microsoft Project is being used but it is very difficult to keep track of previous estimations and compare.

Suitable Estimation Method

A suitable estimation method is very important in a software project. Until now, there is no research that says which estimation method is the best but what is surely known is that different approaches applied in the estimation techniques might produce different accuracy of result.

For ORAC System, the estimation technique to be used is the Basic Constructive Cost Model (CoCoMo’81). It provides a well-defined, open engineering basis for reasoning about the cost and schedule implications of a software solution (Nancy M., 2002).

5.1 Constructive Cost Model (CoCoMo’81)

It is an algorithmic software cost estimation model developed by Barry Boehm. The model uses a basic regression formula, with parameters that are derived from historical project data and current project characteristics (Suiss A., 2009). The CoCoMo’81 has the following advantages:

CoCoMo has been derived from close analysis of hundreds of software projects.

There are also claims that CoCoMo has been validated in practice.

It has been subject to three major updates.

The table shows the functional requirements of the system with classification:

No

Functional Requirement

Type

Complexity

1

Sign in to ORAC Application

EI

Low

2

Register Customers

EI

Average

3

Register Staff

EI

Average

4

Add Cars

EI

Average

5

Edit Cars

EI

Average

6

Delete Cars

EO

Average

7

Subscription Emails

EQ

Average

8

Show Reports for Cars

EQ

Low

9

Send SMS to customers

EIF

High

10

Document Upload for Photos

EIF

High

11

Edit User Information

EI

Average

12

Real Time Notification System

EIF

High

13

Online Payment

EIF

High

14

New Password Request

EI

Average

Figure : Functional Requirements and assigned complexity (Source: Author)

The Legend used for classifying the Functional Requirements is as follows:

EI – External Inputs

EIF – External Interface Files

EO – External Outputs

EQ – External Inquiries

The complexities of the different classifications are given in the table below:

Complexity Description

Low

Average

High

Total

EI

1x3=3

6x4=24

0x6=0

3+24+0=27

EO

0x4=0

1x5=5

0x7=0

0+5+0=5

EIF

0x7=0

0x10=0

4x15=60

0+0+60=60

EQ

1x3=3

1x4=4

0x6=6

3+4+0=7

Total

99

Figure : Classifications of complexities and values assigned (Source: Author)

The values for complexities given above have been taken from the table below:

Figure : Values assigned for complexities

(Source:http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/gamel/cocomo.html)

Data Functions

Data functions represent functionalities provided by users when they are defining their internal and external requirements. There are many ways of classifying functional requirements. The data function used in ORAC is defined on the next page.

External Interface Files

The external Interface file is an end user is also related to logical groupings of data. In this case the user is not responsible for maintaining the data. The data resides in another system and is maintained by another user or system. The user of the system being counted requires this data for reference purposes only. 

Transactional Functions

Transactional Functions’ capability includes maintaining data together with inquiring and outputting data. The transaction functions used in the ORAC Project are:

External Input

It permits user to maintain Internal Logical Files (ILFs) through the ability to add, delete and change the data.

External Output 

This gives the user the capacity to generate outputs.

External Inquiries 

This ability is provided to users through a computerized system that addresses the requirement to select and display specific data from files, by inputting a certain criteria which determines which data to display.

The classifications of the functional requirements have been rated as low, average, high based on complexity. The following tables defined have been used in the estimation processes which have been put forward by researchers of COCOMO.

Figure : Linear Productivity Factor Coefficient

(Source: http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/gamel/cocomo.html)

Figure : Exponential Size Penalty Factor

(Source: http://cs.iupui.edu/~mroberts/n361/SDArticle1.pdf)

Focusing on Figure 13, there are three types of projects, namely organic, semi-detached and embedded. ORAC Project can be said to be an organic project because it is a single developer with "good" experience working with "less than rigid" requirements. To add upon, the developer has previously worked on applications similar to this one but in different industries.

ORAC is software to be created on PHP and since PHP is an object-oriented language, the lines of codes per requirements are counted as 30 based on the researcher’s exponential size penalty factor in figure 14.

5.2 Size Estimation - Lines of Codes (LOC)

The lines of codes calculation is made as follows:

No of Function Points = 99

Single Lines of Codes (SLOC) : No of Lines of Codes x Function Points = 30 * 99 = 2970

KLOC : SLOC / 1000 = 2.97 KLOC

5.3 Schedule Estimation

Schedule Estimation refers to calculating the amount of time required to finish the project.

Duration (D) = cb (E) ^db

2.5*7.5 ^0.38= 5.4 (~ 6 months)

Conclusion:

The Duration of the Project will be around 6 months to finish the development and documentation.

5.4 Effort Estimation

Effort Estimation refers to the amount of man power required in order to complete the project.

Effort (E) = ab (KLOC) ^ bb

2.4 * 2.97^1.05= 7.5 persons (~8 persons/month)

Conclusion:

From the above calculation it can be noted that, approximately 8 persons are required to complete tasks for one month.

5.5 Person Estimation

Estimate People: Effort/Time Duration

7.5/5.4 = 1.4 people

Conclusion:

A person is entitled to work for 6 months, doing the efforts of approximately eight persons per month to complete a project like ORAC.

5.6 Cost Estimation

Assuming that people are supposed to work for ORAC 8 hours per day and 5 days a week, the salary is calculated given that each hour is given RM25.

Working hours per day x Working days per week x Weeks per month x Duration x per hour Salary = 8 x 5 x 4 x 6 x 25 = RM 24,000

Conclusion:

The developer is supposed to earn RM 24,000 during the course of the project.

6.0 SOFTWARE QUALITY ASSURANCE PLAN (SQAP)

Planning is one of the most important aspects of Software Quality Assurance. The entire operation of the SQA team depends on how well their planning is done. In smaller businesses, planning might not really dictate the flow of SQA but in larger businesses, SQA Planning takes on center stage. Without it, each component or department that works on the application will be affected and will never function (ExforSys, 2011).

SQA Planning covers every aspect of SQA’s operations. Through planning, each of the SQA team is unmistakeably defined. The reason is when everyone knows their role and boundaries there won’t be overlapping of responsibilities and everyone could focus on their roles.

SQA Planning is not only a document that instructs tasks. The stages involved are also detail. The whole SQA team will be very busy once the actual testing starts but with SQA, everyone’s work is clearly laid out. Through planning, the actual state of the application testing is known.

The SQAP has been given in the Appendix Section.

7.0 SOFTWARE METRICS

A software metric is a rule for quantifying some characteristic or attribute of a computer software entity. It is one of a set of techniques whose aim is to measure the quality of a computer program (Business Dictionary, 2013).

There are different categories of Software metrics that have been used in the quality assurance process and the quality assurance plan (in appendix) which are described in the following sections.

7.1 Product Metrics

A Product Metric is divided into three categories namely:

Size

Complexity

Quality

In ORAC, only size and quality product metrics have been used.

7.1.1 Product Metric – Size

There are various metrics used to measure size of a project. The most common ones that have been used in ORAC are Lines of Codes (LOC) and Functional Point Analysis (FPA).

Lines of Codes

According to Conte (1986), a line of code is any line of program text that is not a comment or a blank line, regardless of the number of statements or fragments of statements on the line. This specifically includes all lines containing program headers, declarations, and executable and non-executable statements.

It consists of finding an estimate for number of delivered source instructions (DSI) in order to estimate size of a software. Detailed calculation process has been given in section 5.2.

Functional Point Analysis

It is a measure of the functionality perceived by the user delivered by the software developer. It is a weighted sum of the number of:

Inputs to the software application

Outputs from the software application

Enquiries to the software application

Data files (internal to the software application, shared with other software applications)

In section 5.1, functional point analysis has been explained in details with calculations performed and formulas given.

7.1.2 Product Metric – Quality

In ORAC, Defect Tracking was used in order to improve and emphasize on quality of the software. Defect Tracking enables the quality assurance team detect and record all the bugs found in the software in order to provide a bug-free product. An example of defect tracking graph is as follows:

Figure : Defect Tracking

(Source: http://www.teknologika.com/blog/software-development-metrics-defect-tracking/)

The graph shows the bugs accumulated in different components of the software and these are recorded in order to debug them by developers. Defect Tracking is a simple process but can be really revealing.

7.2 Process Metric

Process metric is about using methods and tools in order to monitor and have a better control on stages of the methodology.

In ORAC the process metrics also comprise of using standards to produce documents of high quality, improve effectiveness of management system and performance of development system.

Using Standards

IEEE Standards have been used for documentation process while PHP coding standards have been used for development process.

Improve Effectiveness of Management System

It is an integrated collection of procedures, tools, and training for increasing product quality, improving development-team productivity, or reducing development time.

Note: Please refer to SQAP for more details

8.0 CONCLUSION

The assignment consists of choosing a project upon which resource estimation is calculated, with a detailed analysis and methodology explanation. Through the estimation process, an estimation technique is chosen and based on the Model chosen, the size, effort, labour and cost evaluation is made. For ORAC, the RAD Methodology has been chosen to develop a software of quality as limited time has been allocated to finish the project. The McCall Model has been used as a Quality Assurance process in order to assure that the project developed conforms to quality standards as required by CMMI. Constructive Cost Model has been used as an estimation technique for finding the effort, cost, size and labour estimation for the project.

After elaborating more on the project, a software quality assurance plan has been designed for ORAC in order to list precisely all the tasks that has to be carried out by the quality assurance team in order to verify the quality of the project. Lastly, the software metrics used in ORAC have been discussed.

It was a very tough and challenging coursework where deep research was required in order to fulfil the requirements of the tasks to be completed. During the course of this assignment, I have learnt a lot of new estimation techniques as well as quality assurance models which will be very useful for my career. Along with this, it is important to note that as a software engineer, to have these capabilities before starting to work helps a lot and is classified as technical skills. Overall, it was a very good experience and a very knowledgeable one.

9.0 REFERENCES

Academia. (2013) Estimation Techniques. [online] Available at: http://cs.gmu.edu/cne/pjd/PUBS/softqual92.pdf [Accessed: 21 Mar 2013].

Anonymous. (2012). What is Methodology?. Available: http://www.wisegeek.com/what-is-methodology.htm. Last accessed 09th Mar 2013.

Anonymous. (2012). What is Rapid Application Development?. Available: http://www.selectbs.com/analysis-and-design/what-is-rapid-application-development. Last accessed 06th Mar 2013.

Barbara, T. (2010). Rapid Application Development - Analysis and Design. Rapid Application Development. 1 (6), p12-14.

Business Dictionary. 2013. Software Metrics. [ONLINE] Available at:http://www.businessdictionary.com/definition/software-metrics.html. [Accessed 10 February 13].

CaseMaker Inc.. 2007. RAD Methodology. [ONLINE] Available at:http://www.casemaker.com/download/products/totem/rad_wp.pdf. [Accessed 05 February 13].

Developers.Net. 2007. RAD Methodology. [ONLINE] Available at: http://www.corepartners.com/pdf/rad.pdf. [Accessed 05 February 13].

EnginGroup (n.d.) Basic COCOMO Model. [online] Available at: http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/gamel/cocomo.html [Accessed: 21 Mar 2013].

Nancy, M. (2002) CMM 3: The Capability Maturity Model. [online] Available at: http://nustchenhf.blog.163.com/blog/static/1120679920113643020781/ [Accessed: 21 Mar 2013].

Pranita, S. (2012). ADVANTAGES AND DISADVANTAGES OF RAPID APPLICATION DEVELOPMENT (RAD). Available: http://msdnnepal.net/blogs/pranita/archive/2012/01/24/advantages-and-disadvantages-of-rapid-application-development-rad.aspx. Last accessed 12th Mar 2013.

Suiss A. (2009) Untitled. [online] Available at: http://cs.iupui.edu/~mroberts/n361/SDArticle1.pdf [Accessed: 21 Mar 2013].

Tutorialspoint.com (2013) CMMI Maturity Levels. [online] Available at: http://www.tutorialspoint.com/cmmi/cmmi-maturity-levels.htm [Accessed: 21 Mar 2013].

wiseGEEK (2003) What Is Software Quality Assurance?. [online] Available at: http://www.wisegeek.com/what-is-software-quality-assurance.htm [Accessed: 21 Mar 2013].