The History Of The Rapid Application Development

Published Date: 02 Nov 2017

This document details the important of quality in software. Apart from that, this document describes the process to ensure the quality of software. Also explains the process to measure the quality of software. The Shewhart cycle, also known as PDCA cycle, will be introduced in Quality Assurance Process (QAP).

Moreover, this document also details the Software Quality Assurance Plan (SQAP) for the selected software. The SQAP includes the QA activities for QA team to follow during the development processes. The details for the SQAP can be found in Appendix A.

1.0 Introduction

Due to rapid evolution of technology, people are increasingly dependent on electronic products, especially mobile devices. Nowadays, mobile phone not merely used for communication. For instance, people use their mobile phone as an alarm clock. In addition, mobile phone also acts as a notepad, memo and reminder, music and video player, web browser, and game console. Thence, traditional mobile phone has evolved into smart phone. People undoubtedly cannot live without smart phone.

Modern smart phone has equipped with touch screen. User is able to control the phone by touching and/or sliding on the screen. Due to the popularity of smart phone, numerous developers have moved to the area of mobile applications development. Therefore, many mobile applications were born. People are enjoying install applications into their smart phone in order to gain new functionality and/or increase the entertainment capability.

However, too many of applications are installed on the smart phone also have some drawbacks. The most common problem faced is people need to search through the application drawer, also known as application directory, in order to find a particular application or function. This will increase the workload of the user. To solve this problem, some of the users will create a shortcut for their commonly used application. Yet, too many of shortcuts will decrease user experience, performance and smoothness of smart phone due to insufficient of random access memory (RAM) and/or processor capability.

According to the issue stated above, a handwriting gesture recognition application, "Gesture Control", will be introduced as a solution for the user.

1.1 Scope and Objectives

The handwriting gesture recognition application allows user easily to launch specific application by drawing gesture on the screen of the smart phone. User only needs to customize a gesture for the application. By using this application, user will not need to purposely search through the application directory just for the sake of an application. Apart from that, user would be able to hide the application which they do not want to show in the application directory. However, user can launch the hidden application by drawing the designated gesture. No one will know what the gesture to launch the hidden application, except the owner. This will provide privacy protection for the user. Below are the cores functions of the application which will be achieved before delivering:-

Allow user to customize gesture.

Allow user to launch application by drawing gesture.

Allow user to hide application.

Allow user to launch hidden application by drawing gesture.

2.0 Methodology

A system development methodology refers to the framework that is used to structure, plan, and control the process of developing an information system (Centers for Medicare & Medicaid Services (CMS) Office of Information Service, 2008). There are various types of software development methodologies available in today's professional environment. The researcher has selected a software development methodology which seem like the most suitable to design and construct the development process.

2.1 Rapid Application Development (RAD)

2.1.1 Introduction of RAD

What is Rapid Application Development (RAD)? According to James Martin (1990), "Rapid Application Development (RAD) is a development lifecycle designed to give much faster development and higher-quality results than those achieved with the traditional lifecycle. It is designed to take the maximum advantage of powerful development software that has evolved recently."

Professor Clifford Kettemborough of White College, University of Redlands, defines Rapid Application Development as "an approach to building computer systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven prototyping, and stringent project delivery time limits into a potent, tested, reliable formula for top-notch quality and productivity. RAD drastically raises the quality of finished systems while reducing the time it takes to build them."

RAD process.png

Figure

2.1.2 Evaluation of RAD

Advantages of RAD:

Early visibility

(Because of prototyping)

Greater flexibility

(Because developers can redesign almost at will)

Greatly reduced manual coding

(Because of wizards, code generators, code reuse)

Increase user involvement

(Because they are represented on the team at all times)

Possibly fewer defects

(Because CASE tools may generate much of the code)

Possibly reduced cost

(Because time is money, also because of reusability)

Shorter development cycles

(Because development tilts toward schedule and away from economy and quality)

Disadvantages of RAD:

Harder to gauge progress

(Because there are no classic milestones)

Less efficient

(Because code is not hand crafted)

Less features

(Because of timeboxing, software reuse)

Reliance on third-party components may

Sacrifice needed functionality

Add unneeded functionality

Create legal problems

Unwanted features

(Because reuse of existing components)

2.1.3 Justification

There are many advantages of using RAD, and it can solve many concerns of the user as well as the developer.

The primary advantage of Rapid Application Development is increased in development speed, by using Computer Aided Software Engineering (CASE) tools.

The RAD process directly integrates the end-users in the development of the application. End-users are involved in prototyping process.

Because end-users are involved in prototyping process, each prototype is tested by them and returned to the development team for reworking. Hence, RAD is more flexible and adaptable to changes.

On the other hand, when the prototype is returned to development team for reworking, the quality of product is increased.

In short, Rapid Application Development enables the user to develop quality products in less time. Also, RAD provides collaborative atmosphere for stakeholders to participate in prototyping.

3.0 Quality Assurance Process

3.1 What is Quality?

According to Oxford Dictionary, quality is the standard of something as measured against other things of a similar kind; the degree of excellence of something.

Apart from that, quality as defined by ISO 9000:2000, "Quality is the degree to which a set of inherent (existing) characteristics fulfils requirements."

However, some people said that, quality is conformance to specifications (how well a product or service meets the targets and tolerances determined by its designers).

There are a lot of definitions of quality. However, the researcher thinks that, every quality expert and every single person defines quality in a bit different way depends on the situation they are experimenting, the environment and the criteria/point of view they apply. Therefore, we apply from the point of view of this project, if this system able to meet the minimum requirements of the end-users, then this system considered quality product.

3.2 What is Quality Assurance Process?

Quality Assurance Process (QAP) is a process-centered approach to ensuring that a company or organization is providing the best possible products or services. It is related to quality control, which focuses on the end result, such as testing a sample of items from a batch after production (Shannon, 2012).

3.3 Shewhart Cycle

The Shewhart Cycle, also known as Plan-Do-Check-Act (PDCA) cycle, and is often referred to as the Deming Cycle, will be introduced in order to ensure the quality of this system.

The Shewhart Cycle was originally developed as a model to promote organizational change, but has been widely adopted as a strategy for dealing with all kinds of dynamic project environments. The Shewhart Cycle comprises four key steps: Plan, Do, Check, Act. This sequence is repeated continuously throughout the project's life, with each iteration moving the project closer to its overall objectives. Its real strength lies in its formulation of a process for exerting control in a rapidly changing environment, whether that be competing effectively in the marketplace or copying with highly novel projects (David, 2009).

Shewhart Cycle.png

Figure

3.3.1 Plan

Plan is the first step of Shewhart Cycle. This is the foundation of the entire Shewhart Cycle. Proportionate planning means only developing the necessary level of planning detail at the right time. This step let the researcher design or revises system process components.

The researcher needs to analyze the data available in the system. For instance, what could be the most important accomplishments of the team? What changes might be desirable? What data are available? Are new observations needed? If yes, plan a change or test. Also decide how to use the observations.

3.3.2 Do

Do is the second step of Shewhart Cycle. The researcher will implement the plans from previous step and measure its performance. The researcher will carry out the change or test decided upon, preferably on a small scale. This minimises disruption to routine activity while testing whether the changes will work or not.

3.3.3 Check

Check is the third step of Shewhart Cycle. Checkpoints provide the opportunity to take stock and measure how well the plan is being met - both for the current cycle and the overall objectives. It is better to have a checkpoint after a period of activity, but if the project cycles are long, too much time may have elapsed between a problem materializing and its analysis. In this step, the researcher can assess the measurements and report the results to decision makers, if any.

Apart from that, check whether the small scale or experimental changes are achieving the desired result or not. Also, continuously check nominated key activities (regardless of any experimentation going on) to ensure that you know what the quality of the output is at all times to identify any new problems when they crop up.

3.3.4 Act

Act is the last step of Shewhart Cycle. The act part of the cycle is where learnt lessons are put into practice (David, 2009). In this step, the researcher will decide on changes needed to improve the process.

The researcher implements changes on a larger scale if the experiment is successful. This means making the changes a routine part of your activity. Also to involve other persons affected by the changes and whose cooperation you need to implement them on a larger scale or those who may simply benefit from what you learned.

4.0 Estimation

As an activity, software cost estimation performs fundamental functions. Primarily, budgeting - in terms of both fiscal cost and time - is the key area informed by an estimate. Estimation has implications for project scheduling and control, and illuminates risk by exposing the impact of decisions regarding staffing, requirements and quality assurance on the budget (James, 2009).

In his 2004 study, Capers Jones exposed that, of the software projects analysed, only 10% were 'deemed successful' in terms of the 'achievement of schedule, cost, and quality objectives'. In contrast, around 70% of these projects experienced 'major delays and overruns or were terminated without completion'. Jones identifies six 'key factors' that contribute to this poor performance; of these, inadequate cost estimation plays a significant role in the failure of many projects.

4.1 Algorithmic Cost Modelling

According to James Crowe (2009), "Algorithmic cost estimation attempts to implement a mathematical calculation to forecast costs based on identified drivers, constructing a mechanical quantification of inputs. Therefore, correctly judging the process of inputting variables into a parametric formula, and the ability to interpret and use the results of this implementation, is important. Project size, the number of development staff, and external influences are manipulated alongside historical project data to fit the parameters of an algorithmic model. The specification of these cost drivers is examined later."

Algorithmic Cost Models.png

Figure

4.1.1 Constructive Cost Model (COCOMO)

There are a variety of different models available, the best known are Boehm's Constructive Cost Model (COCOMO). This model was first published by Dr. Barry Boehm in 1981, and reflected the software development practices of these days. This model uses a basic regression formula with parameters that are derived from historical project data and current project characteristics.

The coefficients a, b, c and d depend on the mode of the development. There are three modes of development:

Development Mode

Project Characteristics

Size

Innovation

Deadline / Constraints

Organic

Small

Little

Not Tight

Semi-detached

Medium

Medium

Medium

Embedded

Large

Greater

Tight

Table

The basic COCOMO equations take the form:

Effort (E) = ab × (KLOC)bb

Duration (D) = cb × (Effort)db

People needed (P) = Effort ÷ Duration

KLOC is the estimated number of delivered lines (expressed in thousands) of code for project. The coefficients ab, bb, cb and db are given in the following table:

Software Project

ab

bb

cb

db

Organic

2.4

1.05

2.5

0.38

Semi-detached

3.0

1.12

2.5

0.35

Embedded

3.6

1.20

2.5

0.32

Table

For instance, there are 5000 lines of code and the cost for a developer is RM 80/day. Plus, this project only consists of 2 members. The estimation effort, duration and cost for this project are as below:

Effort (E) = 2.4 × (5)1.05

Effort (E) = 14 man-months

Duration (D) = 2.5 × (13)0.38

Duration (D) = 7 months

Cost = (2 × 80) × (7 × 30)

Cost = RM 33,600.00

5.0 Software Quality Assurance Plan (SQAP)

5.1 What is Software Quality Assurance Plan?

According to SWEBOK Guide (2004), SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning, enacting, and performing a set of activities to provide adequate confidence that quality is being built into the software. This means ensuring that the problem is clearly and adequately stated and that the solution’s requirements are properly defined and expressed. SQA seeks to maintain the quality throughout the development and maintenance of the product by the execution of a variety of activities at each stage which can result in early identification of problems, an almost inevitable feature of any complex activity. The role of SQA with respect to process is to ensure that planned processes are appropriate and later implemented according to plan, and that relevant measurement processes are provided to the appropriate organization.

Apart from that, the SQA plan identifies documents, standards, practices, and conventions governing the project and how they will be checked and monitored to ensure adequacy and compliance. The SQA plan also identifies measures, statistical techniques, procedures for problem reporting and corrective action, resources such as tools, techniques, and methodologies, security for physical media, training, and SQA reporting and documentation. Moreover, the SQA plan addresses the software quality assurance activities of any other type of activity described in the software plans, such as procurement of supplier software to the project or commercial off-the-shelf software (COTS) installation, and service after delivery of the software. It can also contain acceptance criteria as well as reporting and management activities which are critical to software quality.

The detail of SQAP document for this project can be found in Appendix A.

6.0 Software Metrics

According to Mark Piscopo (n.d.), "Quality metrics are a key component of an effective quality management plan and are the measurements used in ensuring customers receive acceptable products or deliverables. Quality metrics are used to directly translate customer needs into acceptable performance measures in both products and processes."

There are various types of metrics to help measure the quality of software. Below is the metrics that the researcher has used for this project:

6.1 Coupling

In software engineering, coupling is the degree to which each program module relies on each one of the other modules. The software quality metrics of coupling was invented by Larry Constantine (1974), an original developer of Structures Design, who was also an early proponent of these concepts.

Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability. The formula for this metric is as below:

For data and control flow coupling:

di: number of input data parameters

ci: number of input control parameters

do: number of output data parameters

co: number of output control parameters

For global coupling:

gd: number of global variables used as data

gc: number of global variables used as control

For environmental coupling:

w: number of modules called (fan-out)

r: number of modules calling the module under consideration (fan-in)

Coupling (C) =

6.2 Function Point

Quality metrics based either directly or indirectly on counting lines of codes in a program or its modules are unsatisfactory. These metrics are merely surrogate indicators of the number of opportunities to make an error, but from the perspective of the program as coded. A typical function point metric developed by Allan Albrecht (1979) at IBM is a weighted sum of five components that characterize an application:

4 × the number of external inputs or transaction types

5 × the number of external types or reports

10 × the number of logical internal files

7 × the number of external interface files

4 × the number of external (online) inquiries supported

The Function Count (FC) is the double sum: FC =

The second step employs a scale of 0 to 5 to access the impact of 14 general system characteristics in terms of their likely effect on the application: Data communications, Distributed functions, Performance, Heavily used configuration, Transaction rate, Online data entry, End-user efficiency, Online update, Complex processing, Reusability, Installation ease, Operational ease, Multiple sites, and Facilitation of change.

The scores for these characteristics ci are then summed based on the following formula to find a Value Adjustment Factor (VAF):

VAF = 0.65 + 0.01

Finally, the number of function points is obtained by multiplying the number of function counts by the value adjustment factor:

Function Point (FP) = FC × VAF

7.0 Conclusion and Recommendation

By finishing this research, the researcher found out that apart from the functionalities of the system, the quality of the system also important. If the system does not have quality, the end-users may choose to use other system indeed.

Consequently, in order to guarantee the quality of the system, the researcher needs to implement the Quality Assurance Process (QAP) in system development process. Apart from that, there are various types of quality control standard, such as CMMI and ISO. Also there are several types of metrics for measure the quality of software. The researcher has study few metrics seem more suitable for use to measure this project.

There are various types of framework for the researcher to choose in order to implement the QAP. By following the framework progressively, the researcher can improve every activity involved in this project. Therefore, improve the quality of the system.

Finally, by finishing this research, the researcher found out that the quality of the activities involved in the project will determine the quality of the whole system. Thus, implement QAP in project management is very important in order to produce a quality product.