Numerous writers have identified problems with the commonly used systems development lifecycle. Yet it is still commonly used in practice. Here it will be illustrated that, even if developers formally use the model, the activities associated a project do not seem to align particularly well with this popular model

Hocking, Lynley

English

AIS Electronic Library (AISeL)

Association for Information SystemsAIS Electronic Library (AISeL)AMCIS 1998 Proceedings Americas Conference on Information Systems(AMCIS)December 1998The Systems Development Lifecycle in PracticeLynley HockingUniversity of TasmaniaFollow this and additional works at: http://aisel.aisnet.org/amcis1998This material is brought to you by the Americas Conference on Information Systems (AMCIS) at AIS Electronic Library (AISeL). It has been acceptedfor inclusion in AMCIS 1998 Proceedings by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contactelibrary@aisnet.org.Recommended CitationHocking, Lynley, "The Systems Development Lifecycle in Practice" (1998). AMCIS 1998 Proceedings. 328.http://aisel.aisnet.org/amcis1998/3281Of the 25 texts on systems analysis/development surveyed, 21 used the SDLC as a framework.-965-P R O P O S A LP L A N N I N GR E Q U I R ’ SD E S I G NS Y S T E MS E L E C T I O N/ D E V TI M P L E M ’ NH A N D O V E RP r e s e n t a t i o nP r o p o s a l B u s .  c a s eP r o j e c te x e c u t i o np l a nR e q .  S p e c ’ nR F I D e s i g n  S p e c ’ nT e n d e rC o n t r a c tD e t a i l e dd e s i g nS y s t e mD o c ’ nC h a n g eD o c ’ nU s e rD o c u m e n t a t i o nP o l i c y  m a n u a lD o c u m e n t a t i o n   S t a n d a r d s /  D o c u m e n t  C o n t r o l  S t a n d a r d sFigure 1.  Generic Model of Process by Case Study Project LeaderThe Systems Development Lifecycle in PracticeLynley HockingUniversity of TasmaniaNumerous writers have identified problems with the commonly used systems development lifecycle.  Yet it is still commonlyused in practice.  Here it will be illustrated that, even if developers formally use the model, the activities associated a project donot seem to align particularly well with this popular model.The Systems Development Lifecycle ModelChange is often described in a linear fashion where the process is illustrated by a series of identifiable steps and with systemsdevelopment, such linear change models have become known as the systems development life cycle (SDLC).  As Friedman(1989) describes it, the lifecycle is "an ordered set of activities which combine to make up the conception, development, use andeventual replacement of new computer-based systems" (p 175).  Derived from operations management, systems and managementscience literature, these models show a linear sequence of events to be followed, the main advantage being that the process canbe standardised and well-defined (Eliason 1990: p 175). Here the systems development lifecycle model is described, criticallyevaluated and its use in practice analysed.The lifecycle model does have strengths.  It allows the overall task to be planned and subdivided so that the process is morecontrollable and, as it is predetermined, everyone understands the sequence of events so communication is improved(Nandakumar 1993; Avison and Fitzgerald 1995).  Avison and Fitzgerald (1995) argue there is intrinsically nothing wrong withthe lifecycle model and much depends on the way it is used,  commenting it needs to be sufficiently resourced and any deviationsnoted and controlled early.  It should not be seen as a rigid process, but a flexible and iterative one.   Despite its wide use and the proposed advantages, the lifecycle model is recognised to have some serious and fundamentalproblems (Eason 1988, Frenzel 1996, Krogstie 1995, Lewis 1994, Nandakumar 1993, Siddiqi and Shekaran 1996, Truex 1993).However, the systems development lifecycle is almost generally accepted as the norm for considering the systems developmentprocess.  Most systems development texts employ it in some form or another.1  The model is used by Avison and Fitzgerald(1995) as a framework by which to judge methodologies.  The ISO 9001 standards for developing and supplying softwaresystems views the process as a broadly linear one, with the process beginning with the definition of functional requirements,programming, inspection and testing, and delivery and installation.  Such international standards are used as a benchmark forassessing commercial methodologies and the process of systems development as it unfolds in organisations.  Most "standard"methodologies, such as SSADM, are based on basic variations of this waterfall model (Krogstie 1995).The Lifecycle in Practice: ACase StudyReflecting common practices, the systems developers in the project described here used the SDLC to conceptually describetheir working processes.  The commercial systems development methodology they used was expressly based on the approach,though it only claimed to provide tools which could be used throughout the lifecycle of systems development, and the systemsdevelopers used it in this way.  The project management metho-dology was also based on the lifecycle approach.  Formally, theproject team adhered to these models, a reviewstating the pro-ject management methodology wasemployed to guide team struc-ture, stakeholderidentification and management and the manage-ment of suppliers while the systems developmentmethodology was used in early and later stages ofthe project.  The detailed design stages, outsourcedto the technical systems contractors, was alsocovered by a similar methodology, also based onthe SDLC.  The project leader’s generic conceptionof the process is illustrated in Figure 1 and isreflective of the SDLC model.  This was only oneof many process models articulated, but most ofthem reflected the SDLC in some form.Using only available documentation to gain aninsight into the process proved problematic.  To gain a deeper understanding, topics that were discussed during regular meetings-966-3/4/93 20/10/93 8/5/94 24/11/94 12/6/95 29/12/95 16/7/96 1/2/97 20/8/97 8/3/98Business Case PEP (project execution plan) Req’s SpecnRFI/ tender negotiations design tendercontract (relationship with TSC after RFI) acc testing implementationFigure 2.  The SDLC in Practice051015202530354045503/4/93 20/10/93 8/5/94 24/11/94 12/6/95 29/12/95 16/7/96 1/2/97 20/8/97 8/3/98Business Case PEP (project execution plan) delaysLPP Req’s Specn RFI/ tender negotiationschange requests OPC processes standardisationdesign tender contract (relationship with TSC after RFI)data conversion cam ready & interim processes purchase/choice of hw/swacc testing implementation leg changestech support/issues (printer etc) training cmgtaccess to users OPC involvement stakeholder involvementprototyping qualityFigure 3.  All Topics Discussed in Meetings Throughout the Project Againstthe SDLC Model Employedthroughout the project were compared with the systems developer’s Gantt and other charts.  Regular staff meetings, projectmanagement meetings, steering committee meetings and project directors meetings were held throughout all or part of the projectand the topics discussed at such meetings give an indication of activities at that time. Fortnightly progress reports also gave anindication of activities and concerns at the time.  Figure 2 maps activities obviously related to phases in Figure 1.Broadly, it suggests thatthe formal model employeddo reflect the actions of thoseinvolved in the project, butthat there was even a greaterdegree of overlap thansuggested in the SDLCmodel.  For example, thescope of the project was dis-cussed  on several occasionswhile the functional require-ments were being developedand it, the business casedocument and the strategy fordeveloping the system wereoccasionally raised until just before implementation activities were being discussed.  Nevertheless, Figure 2 provides a shadowof a SDLC in practice, with the waterfall falling from the top left hand corner forwards. Yet these activities only form no morethan 32% of topics under discussion at these regular meetings. Other issues discussed include the acceptance of the project orsystem by the users, change management (change facilitation), users’ lack of knowledge, training the development andimplementation of interim processes such as camera-ready processed, relationships with the technical systems developers, delays,related projects and so forth.  Many of these topics can be viewed as associated with particular phases of the SDLC model.Planning activities could also include issues of delays, for delays entail that plans have to be changed.  Change requests couldbe considered as part of requirements analysis, as it suggests that requirements are still being determined while "design" coulalso include the purchase of the technology required.  Other tasks which are difficult to identify with phases of the SDLC includeissues of standardisation, quality issues, the development and the implementation of interim processes, prototyping andstakeholder involvement. Their inclusion in Figure 3, along with the other tasks, gives a better insight into how the processactually unfolded.When we consider allthese other issues discussedin regular meetings duringthe project, the overallprocess becomes morecomplex, untidy andemergent than either theSDLC or project’s Ganttcharts would suggest.Implementa-tion issues arebeing considered while thesystem is being planned,even if they are not termedas such.  Plans must changeas circumstances demand itand planning is a continualactivity.  Generally, thedivision between planning,design and implementationbecomes blurred, while theSDLC aims to keep themdistinct and separate.DiscussionThe confusion in the profusion of models used by the project team seems to reflect a balancing act as the systems developersadopted the common broadly linear models of the systems development literature, but had to adapt it to the local circumstancesand recognise the emergent and inherently messy nature of planning and implementing change.  That change was emergent is-967-reflected in the many changes to the development strategy and the number of different models used.    The variety of models andchanges in how the process was formally conceived seems to be a result of a balancing act, as the project team tried to fit themessy, constantly changing reality into formal linear models and a need to reflect a rationalistic managerial approach.  Aimingto adhere to recognised best practice, they adopted standard approaches to the process but were not able to strictly adhere to themand operate effectively in their organisational situation.Westrup (1995) suggests that systems developers can exhibit a much greater degree of organisational awareness than theirmodels and methodologies would imply.  Observations of the actions and models used in the case study supports this stance,specifically in relation to how the overall process of systems development is conceived.  The normative literature tends toemphasise that phases need to be distinct, and even that they are strictly sequential.  Formally, those involved in the project werealigned with these principles broadly, at least to a degree, but when one looks at the issues actually discussed at the time, realityemerges as being far more complex and messy.  On the surface, observations of how people involved in the project viewed theprocess of development were confusing because they were inconsistent and conflicting.  However, when one looks at the actualissues and when they were discussed in relation to the models employed, one starts to suspect that the models employed are notadequately describing what is actually occurring and that those involved in such projects are also having trouble aligning theiractions to such models and an alternative process model which reflects the emergent nature of the process is needed.The lifecycle approach is sometimes referred to as the "waterfall" model.   Iterations are recognised, in much the same waythat salmon ladders are built into dams.  Change flows like water down a river, from step to step, from one deliverable to another.Iterations are movements against the flow of change in which we usually drift, but are necessary in order to navigate the rightpath. The flow down the river is illustrated as a series of arrows from one stage to the next, but how and why we move betweenthem is rarely examined. This paper describes part of a research project aiming to produce such a model of process and considerhow it is reflected in normative models.ConclusionsDespite its deficiencies, the commonly employed lifecycle model is often treated as an objective fact (Lewis 1993).  Thedevelopers were thus not unusual in initially and formally adopting the SDLC model when thinking about the broad process ofdevelopment.  Yet increasingly in the case study, the model did not match the reality of how the project unfolded.  This analysisof the systems development lifecycle in practice suggests that the commonly used process model does not adequately reflect theprocess as it unfolds in reality.  It suggests the process is far more emergent than the lifecycle model suggests and that otherprocess models should be investigated.  These implications are pursued in the larger research project and further details can beobtained from the author.ReferencesReferences available upon request from the author (lynley.hocking@utas.edu.au).

The Systems Development Lifecycle in Practice

https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1755&amp;context=amcis1998

The Systems Development Lifecycle in Practice

Abstract

Similar works

Full text

Available Versions

AIS Electronic Library (AISeL)