Introduction

For every product or system that we build, there is a need and important to have a series of
predictable steps to act as a road map to help us to create a high-quality software or product in
timely manner. In consider of this, a process model was needed to provide stability, control,
and organization to an activity. Example of models include the Prescriptive Process Models
(e.g. waterfall model), Specialized process model (e.g. component-based model) and Agile
Process Model (e.g. extreme programming (XP)).

Category 1 Prescriptive Process Models

A prescriptive model prescribes how a new software system should be developed. It is called
prescriptive because they prescribe a set of process elements framework activities, software
engineering actions, tasks, work products, quality assurance, and change control mechanisms
for each project besides prescribed a predictable process work flow the manner in which the
process elements are interrelated to one another. (Pressman, 2010)

The Waterfall Model

Description
The waterfall model, also referred to as a linear-sequential life cycle model is the earliest
software development life cycle (SDLC) approach that was used for software development. It
suggests a systematic, sequential approach to software development that begins with customer
specification of requirements and progresses through planning, modelling, construction, and
deployment, culminating in ongoing support of the completed software. In a waterfall model,
each phase must be completed before the next phase can begin and there is no overlapping in
the phases.

Figure 1. Different phases of the Waterfall model (TutorialsPoint., 2014)

In waterfall model, the development process is seen as flowing steadily downwards through
several phases, as shown in Figure 1. The phases that involved is:
1. Requirement Gathering and analysis where the possible requirement of the system
are documented in a requirement specification document.
2. System Design in specifying hardware and system requirements and also helps in
defining overall system architecture.
1 | Page

3. Implementation where the small program called unit was developed and unit testing
was conducted to test for each unit for its functionality.
4. Integration and Testing which involved the integration of all the tested units into a
system and the system is tested for any faults and failures.
5. Deployment of system where the product is released into the market once the
functional and non-functional testing is done.
6. Maintenance to fix and enhance the product and release deliver these changes in the
customer environment.

Modified version of the waterfall model

However, there is a modified version of the waterfall method V model (Figure 2) , in which
the stages turn back upwards after the coding phase is done which is oppose to the original
version that designed in a linear axis. This model also termed as the verification and
validation model, where verification side is the development side and validation consists of
the testing activities.

Figure 2. V-model (Pressman, 2010)

The activities that fall under the verification side are:

Requirement analysis which involve gathering requirement from the end user.
System Design to prepare functional design of the software.
Architectural design/module design where the interface relationship, database
tables, their dependencies, etc. are all worked upon.
Coding

The activities that fall under the validation side are:

Unit testing small modules developed are tested to check if they fit for purpose.
2 | Page

 Integration testing - integrated modules are tested to determine faults in the interface
and the interaction between two different modules.
System testing The actual is tested against the system specification.
User acceptance testing system is tested to check for whether the system is in line
with the software requirement specification.

Differences of the waterfall model and V-model

Waterfall model

V-Model

Commencement of
testing activity

After the development

activities are over.

Start with the first stage

itself.

Process

Continuous process

Simultaneous process

No. of defeats

Less

Lesser

Flexibility

Hard in applying changes

Easier in applying changes

Pros
Simple and easy to understand and use.
Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
Phases are processed and completed one at a time.
Works well for smaller projects where requirements are well understood.
Clearly defined stages.
Well understood milestones.
Easy to arrange tasks.

Process and results are well documented

Cons

NO working software is produced until late during the life cycle.

High amounts of risk and uncertainty.

Not suitable for the projects where requirements are at a moderate to high risk
of changing.

Difficult to measure progress within stages.

Poor model for long and ongoing projects.

Issues

3 | Page

Real projects rarely follow the sequential flow that the model proposes. If any
changes occur, that will cause confusion as the project team proceeds.

Difficult for the customer to state all requirements explicitly. The customer
will not know what they want until they experience it.

The working version of the program will not be available until late in the
project time span where it will be disastrous if major blunder was undetected.

Category 2 Specialized Process Model

Specialized process models take on many of the characteristics of one or more of the
conventional models. However, specialized models tend to be applied when a narrowly
defined software engineering approach is chosen.

Component-Based Development (CBD)

Description
The primary goal of component-based software engineering is to address the development of
systems as an erection of system components, and development component as the reusable
entities and maintenance or upgrading of system. Component-based development (CBD) is a
transpire rule that promises to take software engineering into a new epoch. The CBD
methodologies dealing with COTS components. Component based software development is
integrated with a shift from statement-oriented coding to building a system by plugging
together with components.
The component-based development model incorporates many of the characteristics of the
spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of
software. However, the model composes applications from pre-packaged software
components. Besides, this model is an adaptation of object oriented software development
(OOD). While both share the goal of software reusability, OOD is an implementation
methodology, while CBD is an interface methodology. In CBD the emphasis is on
standardizing the interfaces between components, with no restriction on how the
implementation is accomplished. CBD therefore is closely related to module design in
separating interface and implementation.
Modelling and construction activities begin with the identification of candidate components.
These components can be designed as either conventional software modules or objectoriented classes or packages of classes. The CBD incorporates the following steps:
1.

Available component-based products are researched and evaluated for the application
domain in question.

2. Component integration issues are considered.

3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality

4 | Page

Figure 3 Constructing CBD (Ashwini M.,Gayatri M., P.M.Chawan, May-Jun 2012)

Pros
The benefits of applying CBD is as below:

Software reuse which saves money in the development phase of software

projects, i.e., the more components you reuse, the less software you have to build.

The component becomes more valuable if the given component is used in more
application.

Reusable components enable application developers to customize applications

without high costs and long development cycles.

Reused software components have fewer bugs because they are used more often,
and errors are uncovered and corrected along the way.

The productivity will be increased as the components can be written using

different languages, hence developers can choose most suitable language for the
components functionality.

The deployment of components is much more efficient, because if the small

change is needed, only the affected component will have to be changed and
deployed back. In the case of very large systems this can save a lot of time and
effort.

The complexity is significantly decreased because the system is split up into

independent smaller parts, and the testing is made much easier.

Cons
The disadvantages of CBD is that:
Time and effort required for development of components. Among the factors which
can discourage the development of reusable components is the increased time and
effort required, the building of a reusable unit requires three to five times the effort
required to develop a unit for one specific purpose. (B. Spencer, Microsoft,
Presentation at 22nd ICSE, 1999, also an interesting observation about efficient reuse
of real-time components, made by engineers at Siemens that, as a rule of thumb, the
overhead cost of developing a reusable component, including design plus
documentation, is recovered after the fifth reuse. Similar experience at ABB shows
that reusable components are exposed to changes more often than non-reusable parts
of software at the beginning of their lives, until they reach a stable state.)
5 | Page

 Unclear and ambiguous requirements. Reusable components, by definition, to be

used in different applications, some of which may yet be unknown and the
requirements of which cannot be predicted. This applies to both functional and nonfunctional requirements.
Component maintenance costs. Even though application maintenance costs can
decrease, component maintenance costs can be very high since the component must
respond to the different requirements of different applications running in different
environments, with different reliability requirements and perhaps requiring a different
level of maintenance support.
Reliability and sensitivity to changes. As components and applications have separate
lifecycles and different kinds of requirements, there is some risk that a component
will not completely satisfy the application requirements or that it may include
concealed characteristics not known to application developers. When introducing
changes on the application level (changes such as updating of operating system,
updating of other components, changes in the application, etc.), there is a risk that the
change introduced will cause system failure.

Issues
There are several problem regarding to the application of CBD. A major problem with CBD is
the limited possibility of ensuring the quality and other non-functional attributes of the
components and thus our inability to guarantee specific system attributes.
Besides, even though CBD is easier to maintain, cost-efficient and incorporates a shorter
development cycle, but software components arent utilized in more applications or can say,
there is slow adoption in the industry. The reason is due to lack of discipline and lack of
expertise, especially when applying CBD methodology to the application development
process. Software applications need to be well defined before coding begins.
The last driving factor behind CBD's slow adoption is that proper application development
isn't done rigorously. First, it takes knowledge and foresight to break down an application
design to its lowest level. Second, there is always the urge to quickly finish designing and
start coding.

Current Practice in the ICT Industry

Some approaches, such as Visual Basic Controls (VBX), ActiveX controls, class libraries, and
JavaBeans, make it possible for their related languages, such as Visual Basic, C++, Java, and
the supporting tools to share and distribute application pieces. But all of these approaches rely
on certain underlying services to provide the communication and coordination necessary for
the application. The infrastructure of components (sometimes called a component model) acts
as the "plumbing" that allows communication among components. Among the component
infrastructure technologies that have been developed, three have become somewhat
standardized: OMG's CORBA, Microsoft's Component Object Model (COM) and Distributed
COM (DCOM), and Sun's JavaBeans and Enterprise JavaBeans.

6 | Page

Category 3 Agile Process Model

Agile process model is a type of incremental model. Software is developed in incremental,
rapid cycles. This results in small incremental releases with each release building on previous
functionality. Each release is thoroughly tested to ensure software quality is maintained. It is
used for time-critical applications. Extreme Programming (XP) is currently one of the most
well-known agile development life cycle model.

Extreme Programming (XP)

Description
Extreme Programming (XP) is a set of values, principles and practices for rapidly developing
high-quality software that provides the highest value for the customer in the fastest way
possible. The extreme Programming project was first started on March 6, 1996. It is
successful because it stresses customer satisfaction and has already been proven by many
companies of all different sizes and industries worldwide. With the teamwork process and
self-organized team, the problem can be solve as efficiently as possible with high
productivity.
Extreme programming improves a software project in five essential ways-communication,
simplicity, feedback, respect, and courage. Extreme Programmers constantly communicate
with their customers and fellow programmers, make sure that their design is simple and clean
and get the feedback (the degree to which the software implements the output, function, and
behaviour of the use case) through testing the software from the first day. They try their best
to deliver the software as early as possible and implement the change as suggested. Besides,
an agile XP team must have the courage to accept the demanding of substantial rework of the
design and implemented code through the recognition of changing requirement in the future.
The respect will be grown by following each of these values and the team be able to
successfully deliver the software increments.
The XP uses an object-oriented approach as its development paradigm and encompasses a set
of rules and practices that occur within the context of four framework activities: planning,
design, coding and testing.
i.

Planning
The planning activity begin with the creation of user stories that describe
required output, features, and functionality for software to be built via listening to
the customers put. Agile team then assesses each story and assigns a cost
(development time). After that, stories will be grouped to for a deliverable
increment. A commitment is made on delivery date. Project velocity: is used to
help define subsequent delivery dates for other increments after the first
increment was made.

ii.

Design
XP follows the KIS (Keep It Simple) principle by discouraging the design of
extra functionality. XP also encourage the use of CRC (class-responsibilitycollaborator) cards as an effective mechanism for thinking about the software in
an object-oriented context. When difficult design prototype is encountered, the
immediate creation of an operational prototype, called spike solution is
recommended to lower the risk when true implementation starts and to validate
7 | Page

the original estimates for the story containing the design problem. Refactoring is
encouraged as an iterative refinement of the internal program design.
iii.

Coding
XP recommends the construction of a unit test for a store before coding
commences. After the unit test, the XP encourages the uses of pair programming
(two people work together at one computer workstation) as a key concept during
a coding activity. This provides a mechanism for real-time problem solving and
real-time quality assurance.

iv.

Testing
XP encourages all unit tests should be executed daily and acceptance tests or
customers tests should defined by the customer and executed to assess customer
visible functionality.
Diagram of extreme programming as explained to Beck .k, & Fowler, M (2004)

Figure 4. XP process diagram.

Pros
XP do not design for the future, but design for today. The whole idea is to write
simple code and change the design plan accordingly if the need arises in the future.
The software is visible to the customer at the end of every iteration because the tested
software can have small release at the end of each iteration.
XP starts with the simplest solution by allowing the extra functionality to be added
afterwards.
With the feedback from the system, flaws in the system can be detected in the earlier
stage and acceptance test can be conducted repeatedly to minimize the error during
the deliverables.
With the lesser risk through implementation of XP, the working software is delivered
with less money.

8 | Page

Cons
XP encourages pair programming. There may be a huge amount of duplication of
codes that clubs with unit test. As a result, it is going to take long time to run and
leave the database with lot of duplicate data.

XP is code centric rather than design centric development. The lack of XP design
concept may not be serious for small programs. But, it can be problematic when
programs are larger than a few thousand lines of code or when many people are
associated with the project.

The unstructured XP programming may be difficult to find significant number of

defects for testers by just mere looking at the screen. On the contrary, traditional
programming enables testers to find improved number of defects because it is well
documented.

Issues

Requirements volatility
The continual change to requirement of the customer as the active member has made
the scope of the project can change and earlier work may need to be modified to
accommodate current needs. This cause the proponents to argue as that happen
regardless of the process that is applied and that XP provides mechanisms for
controlling scope creep.

Conflicting customer needs

Many projects have multiple customers, each with his own set of needs. In XP, the
team itself is tasked with assimilating the needs of different customers, a hob that
may be beyond their scope of authority.

Requirements are expressed informally

User stories and acceptance tests are the only explicit manifestation of requirements
in XP. Critics argue that a more formal model or specification is often needed to
ensure that omissions, inconsistencies, and errors are uncovered before the system is
built. Proponents counter that the changing nature of requirements makes such
models and specification obsolete almost as soon as they are developed.

Lack of formal design

XP deemphasizes the need for architectural design and in many instances, suggests
that design of all kinds should be relatively informal. Critics argues that when
complex systems are built, design must be emphasized to ensure that the overall
structure of the software will exhibit quality and maintainability. XP proponents
suggest that the incremental nature of the XP process limits complexity and therefore
reduces the need for extensive design.

9 | Page

Comparison
Comparison between different process models
(Ashwini Mujumdar,Gayatri Masiwal, P.M.Chawan, May-Jun 2012)

Model/Features

Waterfall

Component-based Agile (XP)

development(CBD)

Requirement
Specifications

Beginning

Beginning

Frequently
changed

Cost

Low

Low

Very high

Resource Control

Yes

Yes

No

Simplicity

Simple

Intermediate

Complex

Risk Analysis

Only at beginning

Yes

Yes

User Involvement

Only at beginning

High

High

Flexibility

Rigid

Rigid

Highly flexible

Reusability

Limited

Component reuse

Use Case reuse

Based on the comparison table above, the requirement specification of waterfall

model and CBD are needed at the beginning of the process, but for agile model, the
requirement specifications will always be changed during the development process. The
waterfall model and CBD also will have low cost requirements for software development
whereas the agile process model leads to very high cost. From the research, it is concluded
that agile models do not have their control over resources, but on the contrary waterfall model
and CBD will have control over resources. Furthermore, when dealing with the project in
which simplicity is the main factor, the waterfall model is the most suitable models. The CBD
have limited impact because they have intermediate with regard to simplicity factor, while the
agile model is unsuitable because of complex nature. Also because of its complexity, more
time and money is required to complete a software project.
For risk analysis, waterfall model have risk involved only at beginning, while on the
contrary the CBD and agile process model have risk analysis being used in any software
project. When dealing with the user involvement, the waterfall model has very less
involvement of the users because it requires user involvement only at the beginning of
project, whereas CBD and agile process models require high user involvement as a
requirement of these models. For flexibility features, the agile model are highly flexible as
this model is going to accept every immediate change of requirement, while the CBD is less
flexible than the agile process. Waterfall model is rigid comparative to these models. Finally,
the waterfall model has less or no reusability features at all, the CBM was implement
component reuse whereas the agile model is using use case reuse.

Current Practice in Industry

10 | P a g e

Classical waterfall model

Agile process model

Today, waterfall model has been less practiced in the industry. However, the new process
model, called agile process model was become more and more popular with the advantages it
possess. Even the Toyota Company who was currently practicing Waterfall model in their
software development process also considering moving the process to the lean software
development, according to the survey make by the Henrik Knibery. They stated that there are
many problem faced with the implementation of waterfall model.

Phase-Role-Skill-Responsibility (PRSR) model A model for Open Source

(Yuhong Tian, 2011)
Open source software is becoming popular recent year. This is because of its lower cost and
its flexible software customization. The success of the open source software is because of
their unique software development process which was quite different from closed source
software. The closed source software development (CSSD) implements Unified Process (UP)
and XP as their process model, however, open source software development (OSSD)
implements (PRSR) model which was the best practice for OSSD project management as it
not only serves as a guideline to open source software development practice while preserving
the dynamics of OSSD. OSSD process involved three phases launch stage, before the first
release, and between releases. In the PRSR model, different roles/ actors are required to have
different skills and responsibilities corresponding to each of the three OSSD phases.

11 | P a g e

References
Ashwini Mujumdar,Gayatri Masiwal, P.M.Chawan, May-Jun 2012. Analysis of
various Software Process Models. International Journal of Engineering
Research and Applications (IJERA), 2(3), pp. 2015-2021.
Beck K., & Fowler, M. (2004). Planning extreme programming. Upper
saddle River, NJ; Addison-Wesley.
ComputerWorld, 2003. Component-Based Development: Why Hasn't the
Vision Met Reality? [Online]
Available at: http://www.computerworld.com/article/2579531/appdevelopment/component-based-development--why-hasn-t-the-vision-metreality-.html
[Accessed 1 2 2015].
John Brewer, Jera Design, 2001. Extreme Programming FAQ. [Online]
Available at: http://www.jera.com/techinfo/xpfaq.html
[Accessed 1 2 2015].
Kniberg, H., 2010. Crisp"s Blog. [Online]
Available at:
http://blog.crisp.se/2010/03/16/henrikkniberg/1268757660000
[Accessed 8 2 2015].
Pressman, R. S., 2010. Software Engineering: A practitioner's approach.
seventh ed. s.l.:McGraw-Hill.
Tutorialspoint, 2014. SDLC Waterfall Model. [Online]
Available at: http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm
[Accessed 3 2 2015].
Yuhong Tian, "Developing an open source software development process
model using grounded theory" (January 1, 2006). ETD collection for
University of Nebraska - Lincoln. Paper AAI3216341.
Available at: http://digitalcommons.unl.edu/dissertations/AAI3216341

12 | P a g e