Systems Development Life Cycle The systems development life cycle (SDLC) is a conceptual model that describes the

phases involved in an information system development project, from an initial feasibility study through maintenance of the completed application. In SDLC, it is possible to complete some activities in one phase in parallel with some activities of another phase. Sometimes the life cycle is iterative; that is, phases are repeated as required until an acceptable system is found. Some people consider the life cycle to be spiral, in which we constantly cycle through the phases at different levels of detail. Also, the life cycle can be thought of as circular process in which the end of the useful life of one system leads to the beginning of another project that will develop a new version or replace an existing system altogether. Generally, an SDLC methodology follows the following steps: 1. The existing system is evaluated. Problems are identified. These can be done through system user interview and with support personnel consultation. 2. The new system requirements are defined. The problems in the existing system must be addressed with specific proposals for improvement. 3. The proposed system is designed. Plans are laid out involving physical construction, hardware specifications, operating systems, programming, communications, and security issues. 4. The new system is developed. New components and programs must be obtained and installed. System users must be trained with the new system, and all aspects of performance must be tested. At this stage, adjustments must be made, if necessary. 5. The system is put into use. The new system can stepped in, according to application or location. Then, the old system is gradually replaced. 6. The new system should be evaluated once it is up and running. Maintenance must be kept up rigorously at all times. System users should be updated with the latest modifications and procedures. The figure below depicts the systems development life cycle.

Planning Phase Project planning is the process of defining clear, discrete activities, and the work needed to complete each activity within a single project. The primary objectives of this phase are: _ identify the scope of the new system _ ensure that the project is feasible _ develop a schedule, resource plan, and budget for the remainder of the project The activities that a systems analyst perform during the project planning phase include the following: _ Define the problem define precise business problem and scope of the required solution _ Confirm project feasibility feasibility analysis is conducted _ Produce the project schedule detailed listing of tasks and activities _ Staff the project detailed listing of required staff _ Launch the project initiation of the project Analysis Phase The primary objective of the analysis phase is to understand and document the business needs and the processing requirements of the new system. This phase is basically a discovery process. The activities in this phase include the following: _ Gather information observing the users as they do their work; by interviewing and asking questions to the users; by reading existing documents about procedures, business rules, and job responsibilities; and by reviewing existing automated systems _ Define system requirements drawing diagrams to express and model the new systems processing requirements _ Build prototypes for discovery of requirements reviewing working prototypes of alternatives _ Prioritize requirements important needs must be identified and given priority for development

 _ Generate and evaluate alternatives building the system inhouse, buying a software package, or contracting to a third party to develop and install a new system _ Review recommendations with management recaps the results of the analysis phase activities to make decisions about an alternatives Design Phase This phase is where the technical blueprint of the system is created. The primary objective of the design phase is to design the solution system based on the requirements defined and decisions made during the analysis phase. The activities done during this phase are: _ Design and integrate the network configuring computer equipment, network, and operating system platforms that will house the new information system _ Design the application architecture consists of using the diagrams showing the systems requirements that were developed during analysis _ Design the user interfaces consists of forms, reports, screens, and sequences of interactions _ Design the system interfaces design of the method and details of the communication between the new information system and existing system must be precisely defined _ Design and integrate the database database for the specific system must be integrated with information databases of other systems already in use _ Prototype for design details ensure that prototypes function correctly in the operating environment; test and verify alternative design strategies by building prototypes of the new systems _ Design and integrate the system controls every new system must include adequate mechanisms to protect the information and assets of the organization Implementation Phase In the implementation phase, the final system is built, tested, and installed. The objective of the activities of this phase is not only to produce a reliable, fully functional information system, but also to ensure that the users are all trained and that the organization is ready to benefit as expected from use of the system. The activities that make up the implementation phase are: _ Construct software components constructed through various techniques, development tools, and existing components

 _ Verify and test prototypes are used to verify different implementation strategies and to ensure that the system can handle the volumes of transactions that will exist after it is placed in production _ Convert data convert to the format required in the new system _ Train users and document the system users should understand and use the new system appropriately _ Install the system new equipment must be in place and functioning, the new computer programs must be installed and working, and the database must be populated and available Maintenance Phase The objective of the maintenance phase is to keep the system running productively during the years following its initial installation. This phase begins only after the new system has been installed and put into use, and it lasts throughout the productive life of the system. At some stage in this phase, upgrades or enhancements may be carried out to expand the systems capabilities. The activities occur during maintenance phase are: _ Maintain the system include both fixing the errors (also known as fixing bugs) and making minor adjustments to processing requirements _ Enhance the system the company must approve and initiate an upgrade development project _ Support the users a help desk is assigned to answer users questions and help increase their productivity; training new users and maintaining current documentation There are many variations of the systems development life cycle (SDLC). Among the common models or methodologies used are discussed in the succeeding sections of this topic. The Waterfall Model Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. This model is based on the metaphor that when one phase was finished, the development proceeds to the next phase with no turning back. The figure below depicts a traditional waterfall SDLC.

A drawback in using the waterfall model is that it does not accept the expected changes and revisions that become necessary with most projects. Once an application is in the testing phase, it is very difficult to go back and change something that was not thought of in the concept stage. Some alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), and spiral model. The Prototyping Model Prototyping is a systems development methodology in which a prototype is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. In addition, this model is an iterative, trial-anderror process that takes place between the system developers and the end users. The figure below illustrates the prototyping model.

The prototyping model has several advantages: _ May provide the proof of concept necessary to attract funding _ Early visibility of the prototype gives users an idea of what the final system looks like

_ Encourages active participation among users and producer _ Enables a higher output for user _ Cost effective (Development costs reduced) _ Increases system development speed _ Assists to identify any problems with the efficacy of earlier design, requirements analysis and coding activities _ Helps to refine the potential risks associated with the delivery of the system being developed There are also drawbacks to using the prototyping model. These are the following: _ Possibility of causing systems to be left unfinished _ Producer might produce a system inadequate for overall organization needs _ User can get too involved where as the program can not be to a high standard _ Structure of system can be damaged since many changes could be made _ Not suitable for large applications The Spiral Model The spiral model is an SDLC model used in information technology that combines the features of the prototyping model and the waterfall model. The model shows the life cycle as a spiral, starting in the center and works its way around, over and over again, until the project is complete. A spiral model is illustrated in the figure below.

The spiral model is intended for large, expensive, and complicated projects. The spiral model can be generalized in the following steps: 1. The new system requirements are defined in details. This involves interviewing a number of users representing all external or internal users and other aspects of the existing system. 2. An initial design is created for the new system. 3. A first prototype of the new system is constructed from the initial design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. 4. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype. 5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-thansatisfactory final product. 6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. 7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. 8. The final system is constructed based on the refined prototype. 9. The final system is completely evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime. The advantages of using a spiral model are: _ Estimates of the budget and schedule become more realistic as work progresses because of the questions that have been raised _ Easier to cope with the changes inherent to software development _ Software engineers can start working on the project earlier rather than wading through a lengthy early design process However, a drawback of a spiral model is that estimation of budget and time are harder to judge at the beginning of the project since the

requirements evolve through the process. Rapid Application Development (RAD) Rapid application development is a system development methodology that emphasizes speed of development through extensive user involvement in the rapid, iterative, and incremental construction of a series of functioning prototypes of a system that eventually evolves into the final system (or a version). This figure is a conceptualization of James Martins original RAD phases.

In the requirements planning phase, high-level users decide on what functions the application should feature. In the user design phase, the users are characterized as being engaged in discussing the non-technical design aspects of the system, with the assistance of the analysts. In the construction phase, any designs that were created in the previous phase are further enhanced with RAD tools. The analysts are able to make continuous changes in the design of applications using these RAD tools. In the cutover phase, the old application will be replaced with the new one. The newly developed application is tested, users are trained, and organizational procedures are changed before the cutover occurs. Consider using RAD when: _ The team includes programmers and analysts who are experienced with it _ There are pressing business reasons for speeding up a portion of an application development _ Working with a novel ecommerce application and the development team believes that the business can sufficiently benefit over their competitors from being an innovator if this application is among the first to appear on the Web

_ Users are sophisticated and highly engaged with the organizational goals of the company The RAD methodology has several advantages: _ It is useful for projects in which the user requirements are uncertain or imprecise. _ It encourages active user and management participation, which increases end-user enthusiasm for the project. _ Projects have higher visibility and support because of the extensive user involvement throughout the process. _ Errors and omissions tend to be detected earlier in prototypes than in system models. _ The iterative approach is a more natural process because change is an expected factor during development. There are also disadvantages of the RAD approach. These are as follows: _ RAD prototypes can easily solve the wrong problems since problem analysis is abbreviated or ignored. _ A RAD-based prototype may discourage analysts from considering other, more useful technical alternatives. _ The emphases on speed can adversely impact quality because of ill-advised shortcuts through the methodology. oint Application Development ( AD) Joint application development is a systems development methodology that involves the client or end users in the design and development of an application, through a succession of collaborative workshops called JAD sessions. Participants of these sessions would typically include a facilitator, end users, developers, observers, mediators, and experts. This methodology was developed in the late 1970s by Chuck Morris and Tony Crawford, which were both from IBM. In comparison with the Waterfall model, the JAD approach is thought to lead to faster development times and greater client satisfaction, since the client is involved throughout the development process. Alternatively, in the traditional approach, the developer investigates the system requirements and develops an application, with client input consisting of a series of interviews. A variation on JAD is the RAD which attempts to create an application more quickly through strategies that include fewer formal methodologies and reusing software components. A major advantage of JAD is that allows for the simultaneous gathering and consolidating of large amounts of information. However, a drawback of JAD is that it opens up a lot of scope of inter-personal

conflict.

Project Initiation Information system development projects are initiated for several reasons. There are three general driving forces and these are: 1. To respond to an opportunity 2. To resolve a problem 3. To conform to a directive Most companies continue to look for ays on ho to increase their market share or to open up ne markets. !ne ay these companies create opportunities is through strategic plans" hich is both short term and long term. #n optimal ay to identify ne projects is through planning. The advantage of this approach is that it provides a more stable and consistent environment in hich to develop ne systems. $rojects are identified" prioriti%ed" and scheduled as strategic plans are developed. $rojects are initiated to solve immediate business problems. These projects try to close the gap bet een hat information processing is re&uired to run the business correctly and hat is currently in operation. They can be initiated as part of a strategic plan but more commonly are re&uested by middle managers to resolve some difficulty in company operations. $rojects are initiated to respond to outside directives. !ne common outside pressure is legislative changes that re&uire ne informationgathering and e'ternal reporting re&uirements (such as changes in ta' la s and labor la s). *urthermore" legislative changes can e'pand or contract the range of services and products that an organi%ation can offer in the market. +atest la s and regulations can affect the strategic plan hich results in an e'pedited need for ne systems. These regulatory changes can be seen in the telecommunications industry" ith cable T, and telephone companies competing for opportunities to provide cellular services" Internet access" and personali%ed entertainment. #s discussed in the previous session" the project planning phase of the -.+/ is consists of activities that are re&uired to get the project organi%ed and started. These activities include: define the problem" confirm project feasibility" produce project schedule" staff the project" and launch the project.

In this session" e ill focus the discussion on confirming project feasibility and producing project schedule. Project Feasibility #ccording to $ressman" all projects are feasible given unlimited resources and infinite time. 0nfortunately" most of the projects must be developed ithin tight budgetary and time constraints. .uring project feasibility" the project manager ans ers &uestions such as" 1#re the e'pected benefits reasonable23 and 1#re the assumed costs realistic23 # re&uired activity for all information system projects is to assess project feasibility. The objective of this activity is to determine hether a development project has a reasonable chance of success. *easibility analysis basically identifies all the risks of failure. # project team considers the original assumptions and identifies other risks that could endanger the success of the project. The team identifies first those risks and then establishes plans and procedures" if necessary" to make sure that these risks don4t interfere ith the project4s success. If the team thinks that there are serious risks that could affect the project" the members should discover and evaluate them immediately. Areas of Feasibility There are several areas of risk that a project team considers for a ne system hen confirming project feasibility and these are discussed in the follo ing sections. Economic Feasibility 5conomic feasibility is the process of identifying the financial benefits and costs associated ith a development project. This consists of t o tests: 1. Is the anticipated value of the benefits greater than projected costs of development2 2. .oes the organi%ation have ade&uate cash flo to fund the project during the development period2 # determination of the economic feasibility of the project al ays re&uires a thorough cost-benefit analysis. /ost6benefit analysis is the analysis to compare costs and benefits to see hether investing in the development of a ne system ill be beneficial. 7hen developing a cost6benefit analysis" it re&uires a three6step process. *irst" estimate the anticipated development and operational costs. .evelopment costs are those that

are incurred during the development of the ne system. !perational costs are those that ill be incurred after the system is put into production. -econd" estimate the anticipated financial benefits. *inancial benefits are the e'pected annual savings or increases in revenue derived from the installation of the ne system. #nd lastly" the cost6benefit analysis is calculated based on the detailed estimates of costs and benefits. *re&uent error that most ine'perienced analysts make during cost6benefit analysis is to try to do the calculations before thoroughly defining costs and benefits. 8enerally" benefits can be vie ed as tangible and intangible. Tangible benefits refer to items that can be measured or estimated &uantitatively and that accrue to the organi%ation. 5'amples of tangible benefits include reduced personnel e'penses" lo er transaction costs" or higher profit margins. Intangible benefits may have direct organi%ational benefits" such as the improvement of employee morale" or they may have broader societal implications" such as the reduction of aste creation or resource consumption. In parallel ith benefits" an information system can have both tangible and intangible costs. Tangible costs refer to items that you can easily measure or estimate &uantitatively and ith certainty. 7hile intangible costs are those items that you cannot easily measure in terms of &uantity and ith certainty. There are three popular techni&ues to assess economic feasibility and these are the follo ing: Net Present Value (NPV) The t o concepts behind 9$, are that all benefits and costs are calculated in terms of today4s present value and that benefits and costs are combined to give a net value. The objective of 9$, is to determine a specific value based on a predetermined discount rate. Payback Period #lso called the breakeven point" is the point in time at hich the increased cash flo (benefits) e'actly pays off the costs of development and operation. Return On Investment (ROI) This is a measure of the percentage gain from an investment such as a ne system. The objective of the :!I is to calculate a percentage return (like an interest rate) so that the costs and the benefits are e'actly e&ual over the specified time period.

The ime Value of !oney (T,M) is the concept that should be applied to each techni&ue. This refers to the concept of comparing present cash outlays to future e'pected returns. ec"nical Feasibility # large part of determining resources has to do ith assessing technical feasibility. The purpose of assessing technical feasibility is to gain understanding of the organi%ation4s ability to construct the proposed system. Technical feasibility should include an assessment of the development group4s understanding of the possible target hard are" soft are" and operating environments to be used as ell as system si%e" comple'ity" and the group4s e'perience ith similar systems. Operational Feasibility !perational feasibility is the process of assessing the degree to hich a proposed system solves business problems or takes advantage of business opportunities. This is a measure of ho ell the solution ill ork in the organi%ation. #lso" this is a measure of ho people feel about the system;project. !perational feasibility is dependent on the human resources available for the project and involves projecting hether the system ill operate and be used once it is installed. #c"edule Feasibility The purpose of assessing schedule feasibility is for systems analyst to gain understanding of the likelihood that all potential time frames and completion date schedules can be met and that meeting these dates ill be sufficient for dealing ith the needs of the organi%ation. -chedule feasibility is a measure of ho reasonable the project timetable is. Resource Feasibility The project team must assess the availability of resources for the project. The most important resource consists of the members of the team. In developing projects" it re&uires the involvement of systems analysts" system technicians" and users. #t necessary times" some re&uired people may not be available to the team. #nother risk to consider here is that the people ho are assigned may not have the essential skills for the project. !ther resources needed for a project to be successful include ade&uate computer resources" physical facilities" and support staff.

Project Scheduling $roject scheduling determines the order in hich activities ill be performed" setting start and end times for each activity" and assigning specific tasks to team members. The activity of developing project schedule is one of the most difficult efforts of the project planning phase" yet it is one of the most important. There are several tools used for project scheduling and these are discussed in the succeeding sections. Work Breakdown Structure # ork breakdo n structure (7<-) is a hierarchy of phases" activities" and individual tasks that are re&uired to complete the project. This is important in planning and e'ecuting the project since it is the foundation for developing the project schedule" for identifying milestones in the schedule" and for managing cost. 7<- is developed before dependencies are identified and activity durations are estimated. This can be used to identify the tasks in $5:T diagram. # 7<- can be illustrated in a block diagram.

-ince the 7<- is a hierarchical structure" it may be conveyed in outline form:

5ach organi%ation uses its o n terminology for categori%ing 7<components according to their level in the hierarchy. -ome organi%ations refer to different levels as tasks" subtasks" and ork packages" as depicted in the outline above. 7hile others use the terms phases" entries" and activities. It is someho difficult to develop a 7<- from scratch. The project team can meet to brainstorm and try to think of everything that it needs to complete the project. This meeting is a type of bottom6up approach= brainstorm for each single task and make sure to cover everything. The major advantage of a good 7<- is that it provides the most accurate estimate for the duration and effort re&uired for the project #lso" schedules built from a good 7<- are much easier to monitor and control. Therefore" 7<- is a key to a successful project. PERT !P" #iagra$ $5:T is an acronym for Pro$ram Evaluation and Revie% ec"ni&ue and /$M stands for 'ritical Pat" !et"od. *ormerly these ere t o distinct techni&ues" ho ever recently these ere merged into a single scheduling techni&ue. $5:T;/$M is a diagram of all the tasks identified in the 7<-" illustrating the se&uence of dependencies of the tasks. This begins ith the list of activities and tasks developed in the 7<-. The 7<- is analy%ed" including the duration and e'pected resources for each task" to determine the dependencies. *or every task" the chart identifies all the immediate predecessor tasks and the successor tasks. The figure belo is an e'ample of a $5:T;/$M diagram.

The critical path is the longest path through the $5:T;/$M diagram and contains all the tasks that must be done in the defined se&uential order. It is called critical path since if any task on the critical path is delayed" the entire project ill be completed late. The tasks on critical path are monitored very carefully by project managers. There are rules in $5:T;/$M diagram and these are the follo ing: 5ach activity must be represented by its o n branch on the chart. .irection of time flo s is indicated by arro s. #n activity line meeting an event node indicates activity completion. The length of an activity branch is not representative of the time the activity ill take. :elationships bet een activities are determined by the se&uence of the branches. If several activities terminate at one node" no activities starting at that node may begin until all entering activities are completed. *or analysis reason" no t o activities are allo ed to both start and end at the same nodes. If the project net ork ould seem to re&uire this" a dummy activity must be inserted. # dummy activity has no time> it merely preserves the proper se&uencing in the net ork design. !ne of the advantage of the $5:T;/$M techni&ue is that it produces a diagram that makes it easy to see dependencies and the critical path. Though it is not easy to vie the project4s progress on a $5:T chart. # different chart is used in vie ing the activities spread out over a calendar and this is called a 8antt chart. There are also disadvantages of $5:T;/$M and these are the follo ing: There can be potentially hundreds or thousands of activities and individual dependency relationships.

The lack of a timeframe on most $5:T;/$M charts makes it harder to sho status although colors can help (e.g." specific color for completed nodes). 7hen the $5:T;/$M charts become un ieldy" they are no longer used to manage the project. %antt !harts .eveloped in 1?1@ by Aenry 8antt" a 8antt chart is a bar chart that represents the tasks and activities of the project schedule. This chart is good for monitoring the progress of the project as it moves along. The 8antt chart belo sho s three kinds of schedule dependencies (in red) and percent complete indications.

The major advantage of the 8antt chart is its simplicity. The systems analyst ill not only find this techni&ue easy to use" but also it lends itself to orth6 hile communication ith end users. #nother advantage of 8antt chart is that the bars representing activities or tasks are dra n to scale=that is" the si%e of the bar indicates the relative length of time it ill take to complete each task.