ISSN: 2278-3369

International Journal of Advances in Management and Economics

Available online at: www.managementjournal.info

RESEARCH ARTICLE

Understanding Traditional Systems Development Methodologies

Tefo Sekgweleo*

Polytechnic of Namibia, Department of Business Computing, Windhoek, Namibia

*Corresponding Author: Email: [email protected]

Abstract

Software development methodology plays a vital role in systems development life cycle. It is a framework that
guides the systems development team in achieving what the customer/user has requested. Decision making may
impact the systems development team positively or negatively. Hence, understanding strengths, limitations, how,
why and who can use the software methodology is imperative. It helps all the stakeholders involved in a systems
development team to make informed decision for a particular project. Hence, the software development
methodology is not a silver bullet for all the projects.

Keywords: Systems development methodology (SDLC), Information technology (IT), Systems development.
Introduction
There is a stage in life where a need arises within the main purpose of this paper is to examine the
the organisation to purchase or develop a system. traditional methodologies and to understand why,
This need may require the organisation to who and how they are used and also highlight the
undergo through a system development life cycle limitations thereof.
(SDLC) in order for it to increase productivity to
Traditional Systems Development
remain competitive. To achieve that, most
organisations have to make a decision to The traditional systems development existed prior
developing a system or purchase a system. to the agile systems development. These
Therefore, there are various systems development methodologies include waterfall method, V-model,
methodologies that can be followed after making Rational Unified Process and others [4].
that crucial decision because there are finances According to Matkovic and Tumbas [5], these
involved. methodologies are based on the systems
development principles that have served as a
Nelson and Teng [1] define SDLC as a guideline foundation for the creation of the systems
and logical process used by system developers to development to date which can be either
develop systems. According to Rob [2], SDLC sequential or iterative. Sequential approach
stipulates the required ways that comprises means that the methodology is made up of a
various stages and activities to successfully series of steps/stages that follow each other
develop the system. However, it should be taken sequential. The steps are dependent of each.
into consideration that the methodology is not one
size fit all. The software development team has to With the iterative approach, [6] posits that the
carefully select the appropriate methodology for a methodology divides the intended system into a
particular project they are undertaking. series of versions. After the implementation of
version1 the additional work is done on version 2
These methodologies serve as a framework to be and the process continues until the completion of
followed by a software development team. It can the overall system. The emphasis of the
also be used to ensure that the designed solution traditional development approach is to create
meet the user requirements that supports ample documentation which serves as a means for
business strategic goals and objectives. The communication and traceability of the design [7].
SDLC can be either agile or traditional. However, Documentation also plays a vital role in sharing
both methodologies are made up of various stages knowledge and keeping tacit knowledge within
namely analysis, design, development, the organisation. However, knowledge
implementation and maintenance [3]. However, management is of vigorous importance within

Tefo Sekgweleo | May-June 2015 | Vol.4 | Issue 3 |51-58 51

 Available Online at www.managementjournal.Info
Waterfall Model
organisations [8]. Documentation serves as a
The waterfall model (also referred to as systems
means of knowledge for newly recruits and any
development life cycle) is the most popular of the
organisational employee who may want to join the
traditional models. This model was originally
systems development team.
proposed by Winston W. Royce in 1970 to define a
potential software engineering practice [10]. It is
There is a variety of traditional systems
made up of various stages and has distinct goals
development methodologies that can be adopted
for each stage of software development. Hedman
within the organisation. They include waterfall,
and Lind [11] argue that the waterfall model is a
Spiral, V-Model, Rational Unified Process (RUP)
process that describes and recommends the stages
and Rapid Application Development [9]. The
that have to be completed in the process of
traditional methodology is the most commonly
developing a system for a particular usage. It
used approach by organisations whereby software
consists of six stages including requirement
development activities are completed
gathering, analysis, design, testing,
sequentially. The traditional methodologies are
implementation, and maintenance [12].
briefly explained below.

Figure 1: Adopted from [10]

These stages are dependent on each other and

they follow each other sequentially. Pefkaros [13]
posits that each stage within the waterfall model Spiral Model
flows downward into each other. Each stage has
to be completed prior to the next stage could The spiral model was introduced by Barry W.
commence [14]. One of the strengths of the Boehm in 1988 [5]. It was introduced to solve the
waterfall model is the extensive documentation of limitations encountered in the waterfall model.
requirements which is good for communication Boehm created the spiral model with the
among the systems development team [15]. intention of introducing iterative software
development. This model combines the features
However, the waterfall model does not allow of the prototyping and the waterfall model.The
changes to be made to the previously completed spiral model consists of four stages starting with
the planning, objectives, risk analysis and
stage [16]. As a result, the system will have to be development [14].
implemented with missing/faulty requirements or
mistakes committed in any stage of system The model arranges all the activities in the form
development. Fixing such mistakes is not easy of a spiral. All the stages are continuously
but costly and it also leads to late delivery of the repeated for a certain period of time until the
requested system [15]. The user requirements completion of the requested system [18]. The
keep on changing throughout the system emphasis of the spiral model is to evaluate risks,
development because the client does not usually which are used as a source for decision making to
know what they exactly want. To fix mistakes or further develop the system [5]. In each cycle,
gaps encountered in the business requirements problems that are encountered are resolved. The
specification, change requests are often logged but next iteration occurs until the system completed
can only be attended to once the system has been and meets the user requirements. A prototype is
implemented. built for every iteration.

Tefo Sekgweleo | May-June 2015 | Vol.4 | Issue 3 |51-58 52

 Available Online at www.managementjournal.Info

Figure 2: Adopted from [17]

waterfall model. In the waterfall model defects
Due to iterative pattern of the spiral development, were found very late in the development life cycle
feedback given on each stage makes it possible to
fix errors at early stages, enhance requirements because testing was not involved as early as the
and get rid of risks identified. According to Butt initial stage. The emphasis of the V-Model is
and Hameet [18], problems encountered in every more on the testing of each stage of the
iteration, are resolved quicker and possible risks development life cycle. Balaji and Murugaiyan
are removed earlier stages of systems [21], posits that the V-Model illustrates the link
development. This approach makes it possible for between each stage of the systems development
the organisations to safe costs since it is cheaper life cycle relating to its software testing stage.
to identify problems and risk in the early stages of
the systems development. This model also makes Mushtaha and Tolba, [22] posits that the V-
it possible to enhance or make changes to the Model is made up of four main stages of the
requirements until the acceptable system is waterfall model with their equivalent testing
delivered to the users. stages such as requirements analysis -
(acceptance testing), requirements specification-
The spiral development starts smaller and grows (system testing), design specification -
bigger depending on the number of iterations. (integration testing), program specification and
However, lots of activities occur parallel and coding-(unit testing).The mentioned testing
make it difficult to manage the systems activities should be carried out in parallel to the
development and rework is likely to occur since development activities so that testers can produce
requirements are not fully specified prior to a set of test deliverables. However, the V-Model
systems development [19]. Due to the fact that outlines who is responsible for conducting a
requirements are not fully specified when the particular testing at which stage [23]. Without
development starts, additional work may be that kind of information it would be very difficult
required. The main reason for not specifying all to execute testing.
requirements at once is because users do not
normally know exactly what they want until the It is always a best practice to involve software
system is delivered to them. Another setback of testers at earlier stages of the product life cycle.
the spiral model is that is works well for big The overlap of testing stage with the development
projects than small ones [17]. stage ensures that problems encountered are
addressed as early as possible [4]. Lee and Xia
V-Model
[24] posits that the response from software teams
The V-Model was first proposed by Paul Rook in with regards to vital requirement changes in early
the late 1980s and can be thought as the stages of systems development life cycle is critical
extension of the waterfall model [20]. It was as it enables organisations to save time and cost
introduced was developed with the intention to in later stages. However, the V-Model does not
address some of the problems encountered in the indicate a clear path for problems encountered
during the testing stage [17].

Tefo Sekgweleo | May-June 2015 | Vol.4 | Issue 3 |51-58 53

 Available Online at www.managementjournal.Info

Figure 3: Adopted from

Rapid Application Development
RAD follows the same stages used in the waterfall
The need arose in the early nineties, to speed up model but it has added certain features to achieve
the systems development within organisations. quick and better results. Some of the features of
That is when James Martin in 1991, introduced RAD are outlined below:
rapid application development (RAD) to rapidly
develop systems [9]. The main objective of RAD is Table 2: Adopted from (Avison and Fitzgerald, 2006)
RAD Features Definition
to develop systems faster and produce high Incremental Requirements are never complete but evolves
quality results compared to linear traditional Development
model. As a result, this enables organisations to Time Box Functions developed parallel into time boxed
cycle
take leadership in implementing latest technology Prototype Developed functions are assembled into a
systems quicker. In order to shorten the systems working prototype
development schedules it is imperative for the Pareto Principle 80/20 rule applied to requirements. 80% of the
functioning system can be delivered, 20% effort
team to identify the systems development required to complete 100% of the requirements
methodology, tools, techniques and technologies MoSCoW rules Must Haves, Should Haves, Could Haves, Won’t
Haves
suitable for the selected methodology [19]. JAD Sessions These meetings are used to beef up the
requirements and occur throughout time box
RAD methodology makes use of Computer Aided cycles
Sponsor and The success of the system relies on a committed
Software Engineering (CASE) tools in Champion sponsor and the champion of the system
combination with iterative development and rapid Toolsets It helps to speed up the process and improve
prototyping in order to achieve quick systems. productivity

Choo and Lee [25] posit that various products are

used in RAD including testing tools, groupware Within RAD, clients are involved very early in the
for communication, requirements gathering tools, systems development because they provide
CASE tools, prototyping tools and language feedback which helps to enhance requirements. A
development environments such as Java and C++ prototype is developed and given to clients to use
environments. The advantage of using such tools in order to critique it and with that feedback a
is that they can be reused within or in other proper system is developed. The system developed
systems development projects. In order to achieve in components/functions which occurs parallel in
the best results, the systems development team time boxed cycles which are then integrated into a
should be dedicated and highly skilled in using working prototype. However, if the tools and
the above mentioned tools.
Tefo Sekgweleo | May-June 2015 | Vol.4 | Issue 3 |51-58 54
 Available Online at www.managementjournal.Info

techniques mentioned above are not properly and adaptability during the system development
managed then the systems development may not process [26]. As a result RUP becomes extremely
be a success. The success of the system is flexible as it allows change to occur at any time at
tremendously dependent on high technical skilled any stage of systems development. RUP is made
developers [26]. up of four stages namely inception, elaboration,
construction and transition [27]. These stages are
Rational Unified Process (RUP)
executed sequentially and iteratively throughout
Due to the dynamic nature of technology, new the systems development life cycle. Every stage of
methodologies keeps on being implemented to RUP is composed of one or more iterations [28].
improve limitations encountered to its Any discrepancies, risks and errors encountered
predecessors. According to Jain and in each stage are addressed in each iteration of
Chandrasekaran [9] in 2000, Kruchten introduced that particular stage. The final iteration forms
rational unified process (RUP). It was introduced part of the final system.
to consider the need for accommodating change

Figure 4: Adopted from [29]

Table 2: Adopted from

Discipline Description
Business Modeling Describe the business process and the internal structure of the business in order to capture
proper requirements for the system to be built
Requirements Management Elicit, organise and document the requirements
Analysis and Design Create the architecture and design of the system
Implementation Write and debug the source code, conduct unit testing and build management
Test Conduct functional, integration, system and user acceptance testing
Deployment Packaging the software, creating in-stallation setups, compiling end user manuals and other
tasks needed to make the software available to its end users
Project Management Project planning and monitoring
Configuration and Change Management Covers all the tasks concerned about release management and change request management
Environment Adapt the RUP process according to the needs of the project and selecting the supporting
systems development tools.

The above mentioned stages are accompanied by an industry-standard language that allows the
nine principles described in the table. systems development team to clearly
communicate requirements, architectures and
The aim of introducing new methodologies is to designs visually [12]. Pictures or diagrams enable
fill up the gaps encountered in the previous the entire systems development team to visualise
methodologies. RUP has been adopted in the the inner workings the system to be built. It also
systems development industry as a model for the makes it easier for the team to explain the how
reason that it is well defined and documented the system is going to work.
[30]. The documentation is accessible
electronically. RUP is an adaptable model The rational unified process (RUP) is a process
allowing organisations to select elements of framework that provides a disciplined approach to
processes that are most relevant to the particular define activities and responsibilities inside the
project. RUP make use of unified modelling organised system development [32]. The four
language (UML) to emphasise object-oriented development stages are accompanied by the nine
analysis and the maintenance model [31]. UML is basic principles. Hence each stage is iteratively

Tefo Sekgweleo | May-June 2015 | Vol.4 | Issue 3 |51-58 55

 Available Online at www.managementjournal.Info

executed. The main goal of RUP is to make pass a quality check, this approach is referred to
changes manageable because problems as a stage-gate model [36]. After the stage-gate
encountered in testing of each iteration are model, it is when the document is signed off and
resolved early in the systems development life the next stage begins.
cycle [33]. RUP also ensure the production of
high-quality software that meets the needs of its The traditional methodologies endorse a strict
end-users, within a predictable schedule [12]. sequence of the quoted stages and it cannot be
However, this model is too complex, not easy to violated. Hence, the processes have to be fully
learn and problematic to apply correctly if project defined and documented. Stages such as
managers or team members are not experts in requirements gathering and systems design, the
using it [33]. Another limitation is that RUP is a way they are performed in the traditional
commercial product and needs to be purchased methodologies helps the team members to broadly
from IBM before it could be used [33]. gain knowledge about the entire system [37]. It is
vital for organisations to keep knowledge within
Why is Traditional Methods Applied
itself because the systems that are developed
Any organisation that needs to develop a system require maintenance. Therefore, these documents
may use the traditional systems development. that are compiled and stored empower the
These methodologies consists of a sequence of employees who later join the organisation to know
stages that must be followed and completed by what the systems are all about hence they may be
system designers and developers in order to the same people to maintain such systems.
achieve some results and deliver the requested
Who Uses Traditional Methods
system [10]. One thing that users must know is
that it takes time for the program to be complete. People who use the traditional methods are
It is built in such a way that the programmer known as IT professionals. Such professionals
cannot move on to the next step if the step prior to include systems analyst, database analysts,
that is not yet completed. The traditional systems database administrators, network administrators,
development methods are dependent on a set of webmasters, programmers, vendors, steering
prearranged processes and continuing committees and other IT professionals [38].
documentation which is written as the work However, the structure of the company also
evolve to guide further development [4]. determines how the systems development team is
setup. The other IT professionals include project
The traditional development attempts to manager, software development manager,
minimize change during system development software architect, software developer, test
through severe upfront requirements gathering, manager, test leader, test designer, software
analysis and design with the intent to achieve tester, quality manager, quality assurance
higher quality results under a controlled schedule engineer and quality control engineer [20].
[34]. There are various specialists involved in
Limitations and Challenges of
each and every stage of systems development.
Traditional methodologies, the development is Traditional Development
done by immense and organised teams with Due to the formal/sequential pattern of the
specialists for some activities in the stages of traditional methodologies, users are expected to
development. With traditional methods, systems give out requirements at the early stages of the
are fully specified, predicted and built through project. As a result users may give out incorrect
careful and extensive planning [35]. requirements or leave out critical requirements.
According to Mujumdar et al., [39], due to
How are Traditional Methods Used
uncertainties at the beginning of the project with
The whole process of software development, regards to the requirements the traditional
according to the traditional methods, begins with models are unable to accommodate such
the understanding of the requirements and uncertainties properly. These traditional
expectations from the customer or end user. After methods are not most suitable for the
the requirements are clearly understood by the development of projects whereby system
developers, analysis and design of the software requirements change regularly, the development
begins. The systems development undergoes schedules have to be shortened because that has a
through a sequence of some fundamental stages negative impact on quality [40].
such as planning, analysis, design, and
implementation [2]. The activities of one stage The traditional methodologies (also known as
must be completed before moving to the next plan-driven methodologies) assume that the
stage. Amid all the stages the documents have to correct information can be obtained up front [41].

Tefo Sekgweleo | May-June 2015 | Vol.4 | Issue 3 |51-58 56

 Available Online at www.managementjournal.Info

Humans are prone to committing errors since

customer/user. It is crucial for the systems
there are uncertainties in developing systems.
development team to also understand the type of
Things cannot always be done correctly the first
project they are faced with before they could start
time since we are humans. Another limitation of
working on it. That enables the team to decide on
the traditional methodologies is that customers
which system development methodology to follow.
realises the problems of early stages very late
The understanding of how each methodology is
when they have to accept the system they
applied by who, how and why is applied helps the
requested [36]. Therefore, any change requested
system development team to make informed
late in the development or after sign off of a
decision. The intention of most organisations
particular stage, requires additional cost.
when it comes to systems development is to be
Conclusion successful since IT enables them to be efficient
and remain competitive to its counterparts.
Prior to systems development it is vital for the
Failure is not an option to organisations and
systems development team to have a good
success is what is expected from the systems
understanding of what is required by the
development team.
References
1. Nelson AC, Teng JTC (2000) Do systems development 10. Bassil Y (2012) A Simulation Model for the Waterfall
methodologies and CASE tools decrease stress among Software Development Life Cycle. International Journal
systems analysts? Behaviour & Information Technology, of Engineering & Technology, 2(5).
19(4):307-313. 11. Hedman J, Lind M (2009) Is There Only One Systems
2. Rob MA (2006) Dilemma between the Structured and Development Life Cycle? Information Systems
Object-Oriented Approaches to System Analysis and Development: Challenges in Practice, Theory, and
Design. Journal of Computer Information Systems. Education, 1:105-115.
3. Avison DE, Fitzgerald G (2003) Where Now for 12. Jiang M, Jong CJ, Poppell P, Budhathoky, K, Hull R
Development Methodologies? Communication of the (2009) System Infrastructure Development Life Cycle for
ACM, 46(1):79-82. Enterprise Computing Systems.
4. Leau YB, Loo WK, Than WY, Tan SF (2012) Software 13. Pefkaros K (2008) Using Object-Oriented analysis and
Development Life Cycle Agile vs Traditional Approaches. Design over Traditional Structured Analysis and Design.
International Conference on Information and Network International Journal of Business Research, 8(2):219-227.
Technology. 14. Avison DE, Fitzgerald G (2006) Information Systems
5. Matkovic P, Tumbas P (2010) A Comparative Overview Development Methodologies, Techniques & Tools. 4th Ed.
of the Evolution of Software Development Models. The McGraw-Hill Companies.
International Journal of Industrial Engineering and 15. Nasution MFFA, Weistroffer HR (2009) Documentation
Management, 1(4):163-172. in Systems Development: A Significant Criterion for
6. Ayman Al Ahmar M (2010) Rule Based Expert System for Project Success. Paper presented at the Proceedings of the
Selecting Software Development Methodology. Journal of 42nd Hawaii International Conference on System
Theoretical and Applied Information Technology. Sciences.
7. Nerur S, Mahapatra R, Mangalaraj G (2005) Challenges 16. Seilheimer SD (2000) Information management during
of Migrating to Agile Methodologies. Communications of systems development: a model for improvement in
the ACM, 48(5):73 -78. productivity. International Journal of Information
8. Mishra, S. & Weistroffer, H. R. (2008). Issues with Management, 20:287-295.
Incorporating Regulatory Compliance into Agile 17. Munassar NMA, Govardhan A (2010) A Comparison
Development. Between Five Models Of Software Engineering. IJCSI
9. Jain R, Chandrasekaran A (2009) Rapid System International Journal of Computer Science Issues,
Development (RSD) Methodologies: Proposing a Selection 7(5):94-101.
Framework. Engineering Management Journal, 21(4):30- 18. Butt A, Hameed S (2011) Success of Spiral Model along
35. with its Development Techniques. Models and methods
applied in sciences.

Tefo Sekgweleo | May-June 2015 | Vol.4 | Issue 3 |51-58 57

 Available Online at www.managementjournal.Info
19. Satzinger JW, Jackson RB, Burd SD (2004) Systems 30. Bergandy J (2008) Work in Progress - Software
Analysis and Design in a Changing World. 3rd ed. USA: Engineering Capstone Project with Rational Unified
Thomson. Process. 38th ASEE/IEEE Frontiers in Education
20. Mathur S, Malik S (2010) Advancements in the V- Conference.
Model. International Journal of Computer Applications, 31. Wu X, Ge C (2010) The Research on Necessity and Plan
1(12):29-34. for Using Extreme Programming in Rational Unified
21. Balaji S, Murugaiyan, MS (2012) Waterfall vs V-Model Process.
vs Agile: A Comparative Study on SDLC. International 32. De Barros Paes CE, Hirata CM (2007) RUP Extension
Journal of Information Technology and Business for the Development of Secure Systems. International
Management. Conference on Information Technology (ITNG'07).
22. Mushtaha A, Tolba R (2008) Integrating V-Model Into 33. Khan ME, Khan F (2012) A Comparative Study of White
The Web Development Process. International Arab Box, Black Box and Grey Box Testing Techniques.
Conference on e-Technology-IACET. (IJACSA) International Journal of Advanced Computer
23. Skidmore S (2006) The V-Model developing systems. Science and Applications, 3(6):12-15.
Student Accountant. 34. Vinekar V, Slinkman CW, Nerur S (2006) Can Agile and
24. Lee G, Xia W (2010) Toward Agile: An Integrated Traditional Systems Development Approaches Coexist?
Analysis of Quantitative and Qualitative Field Data on An Ambidextrous View. Information Systems
Software Development Agility. MIS Quarterly, 34(1):87- Management.
114. 35. Dyba T, Dingsoyr T (2008) Empirical studies of agile
25. Choo CH, Lee SP (2008) Towards Persistence software development: A systematic review. Information
Framework-Based Rapid Application Development and Software Technology.
Toolkit for Web Application Development. Journal of 36. Petersen K, Wohlin C, Baca D (2009) The Waterfall
Computer Science, 4(4):290-297. Model in Large-Scale Development. LNBIP, 32:386-400.
26. Khan AI, Qurashi RJ, Khan UA (2011) A 37. Uikey N, Susman U, Ramani AK, A Documented
Comprehensive Study of Commonly Practiced Heavy and Approach in Agile Software Development. International
Light Weight Software Methodologies. IJCSI Journal of Software Engineering (IJSE), 2(2):13-22.
International Journal of Computer Science Issues, 38. Shelly GB, Cashman TJ, Vermaat ME (2004)
8(4:2):441-450. Discovering Computers 2004 A Gateway to Information
27. Ge C (2010) Modifying RUP (Rational Unified Process) to Web Enhanced. Thomson Course Technology.
Comply with CMM (Capability Maturity Model) Levels 39. Mujumdar A, Masiwal G, Chawan PM (2012) Analysis of
2&3. IEEE. various Software Process Models. International Journal
28. Manzoni LV, Price RT (2003) Identifying Extensions of Engineering Research and Applications, 2(3):2015-
Required by RUP (Rational Unified Process) to Comply 2021.
with CMM (Capability Maturity Model) Levels 2 and 3. 40. Carlo KM, Estevez E, Fillottrani P (2010) A
IEEE Transactions on Software engineering, 29(2):181- Quantitative Framework for the Evaluation of Agile
192. Methodologies. JCS&T, 10(2):68-73.
29. Guo F, Xia B, Xue F (2011) Analysis on Software 41. Marchesi M, Mannaro K (2008) Adopting Agile
Processes and Enhancement for RUP. ethodologies in Distributed Software Development.

Tefo Sekgweleo | May-June 2015 | Vol.4 | Issue 3 |51-58 58