Development and Relevance of System Development Life Cycles - Term Paper Example

Hope you find all your requirements in the paper. It is now 2, 908 words, excluding diagrams. I’ve tried my best to clearly present it to you. RAD is not included in the 4 models you mention but I took the freedom of including it because as an IT Professional, I do believe that it is necessary. You can delete it if you really want to. I have marked important topics in red color for your convenience. THANK YOU VERY MUCH!!! SYSTEMS DEVELOPMENT LIFE CYCLE Name : Course : Prof : Date : The System Development Life Cycle (SDLC) is the method of developing information systems through investigation, analysis, design, implementation, and maintenance.  The System Development Life Cycle (SDLC) is also known as Information Systems Development or Application Development. The SDLC is a series of steps or phases that guide the development in the hierarchy of information systems to its end. The typical steps involved in the System Development Life Cycle are: Software Concept Software concept, as the first step, is to identify the need for a new system. It consists of investigative study on whether a business impediment or opportunity exists; carry out a feasibility study to distinguish the cost effectiveness of the solution proposed. The method may employ IT professionals alone or confer with end-users who have the idea to enhance their work. The concept must go along with the organizations strategic plan to ensure compatibility with the overall strategic objectives of the company and must meet management expectations before any budget is allocated for its development. Requirements Analysis Perform requirements analysis and documentations of the existing system being used, organization set-up, requirements of end-users and development of functional details to meet them. Architectural Design After doing the analysis and requirements fully identified, The IT personnel will perform architectural design and write the applicable specifications for hardware, software, people and data resources. The design must be submitted to the end-users for review to ensure that the design meets their need. The design will act as a blueprint of the new system that would help to identify and rectify flaws before building the final system. Assessed and conforming to the specified requirements, the IT personnel can now start building the final system. Coding and Debugging The task to code and debug the programs is now in the hands of competent systems programmer. System Testing After the completion of the system, its actual functionality must be tested and evaluated. End-users will determine whether the newly developed system meets their specifications and express their satisfaction for initial system deployment.   If the management decision is to purchase commercial software rather than developing a new customized application, the system development life cycle in most parts remains the same. Evaluation of off-the-shelf software and the process in purchasing the software will replace coding and debugging. Minor coding and debugging maybe required for optional system interface. This will link the existing system to the new system to enable communication between them. Another point to consider in SDLC is the equal importance of the planning stage. A good and precise planning will reduce errors in design stage and save a lot resources. A business and a project plan are formed during the theoretical phase and constantly restructure throughout the life cycle as end-users and software developers are more aware of the scope of the project. The SDLC model is a guide to the processes involved from the preliminary feasibility study through the maintenance stage of the completed application. SDLC models are: THE WATER FALL MODEL This is the traditional model of SDLC, it has a linear and sequential method that include goals for each development stage. A purely sequential model, which critique referred to as an inflexible, non-iterative, naive, and unsuitable for a real world application. . The waterfall model proceeds from the starting phase to the next in an entirely sequential or chronological manner. Using the above the diagram, the work involve in the “feasibility” phase must be completed first before you can proceed to the “analysis” phase. The same is applicable to the subsequent phases in the diagram. The Feasibility Phase of the Waterfall Model is where all requirements for the project are determine. These requirements are software, hardware, human resources, time duration, paper works, and most importantly, the budget. This phase is very useful for the management because they can identify and make the proper decision if they will push through with the project or not. Here, they will be able to compare and select other options beneficial to the company. The Analysis Phase of the Waterfall Model is purely technical in nature. The phase deals with the details of the proposed software before formally designing the complete application. The details include interviews with end-users to determine their detailed requirements, the logical flow of the existing system or the manual system currently in use. The Design Phase of the Waterfall Model is the actual coding and debugging of the software. The phase where analyst and application programmers work together to code, debug, and produce a complete software. The documentations created on the design stage will serve as a blueprint for future technical maintenance and upgrading. The Implementation and Testing Phase of the Waterfall Model is the actual installation of the completed software to the company’s computer network. After the proper installation of the software, employees or company workers can now work with the new software with the guidance of the developers as part of the familiarization training. This is the phase where some bugs in the system may arise and eventually corrected by programmers. The Maintenance Phase of the Waterfall Model is the preservation and safeguarding phase of the whole project. This is the phase where occasional bug fixing happens. Back-up, minor patching or additional modules maybe added to enhance the security and integrity of the system. In addition, there is a possibility for some additional works to add more modules (not included or maybe neglected in the initial planning) which management believes will be helpful in their current state of business operations. THE RAPID APPLICATION DEVELOPMENT MODEL Rapid Application Development is the opposite of a non-agile process developed in the 1970’s like the Waterfall Model. The previous methodology in application development is the enormous time it takes to build or to complete the system. In a fast growing company for example, a system developed six months ago may not be compatible to the current state of the business today. With the need to address the requirements of the business environment, RAD was developed in the 1980’s. The six RAD core elements are prototyping, iterative, time boxing, team members, management approach, and RAD tools. PROTOTYPING – the objective of this element is to create a working application in a very short time for the end-user to “flash out” the real and “complete” requirements of the application. The problem with interviews is it will not produce the complete requirements needed by the end-user. The end-user, especially those that are not computer oriented, may not reveal or possibly unaware of their real requirements until they actually using the new application. ITERATIVE – is building an application in a short development time where each application release will produce feedbacks that will be use in developing the next version. The iterative element is very common in software development today wherein you will find version numbers of the software like “Beta Release”, “Version 1.0”, “Version 1.1” etc. and “Final Version”. TIME BOXING – it provides support to ITERATIVE development by pushing off features to future versions of the application. This is necessary to complete the ITERATIVE cycles in the soonest time possible by putting the cycles in a limited period. TEAM MEMBERS – specifies and restricting the members of the development team involving only the most experienced, adaptable, and dedicated members. MANAGEMENT APPROACH- this requires the constant involvement of management in keeping the development cycle short by enforcing deadlines. In addition, management is encouraged to support the development team and make it easier for them by removing procedural constraints and technical obstacles. RAPID APPLICATION DEVELOPMENT TOOLS – supports the principle that speed is more important than the cost of tools such as Computer Aided Software Engineering (CASE) Applications. Use of the latest software building technologies is encourage to increase development speed. RAD ADVANTAGES AND DISADVANTAGES RAD has two main advantage, increase in the development speed and better quality. The speed is attributed to RAD tools such as CASE that swiftly captures the system requirements and turn them into usable computer codes in the soonest time possible. Application quality in terms of accurate response to the needs of the users and low maintenance cost of the system completed. The whole process is made possible by the participation of the user in the early stage of development such as analysis and design. RAD also has two main DISADVANTAGES such as scalability and feature reduction. It is not possible for a RAD application to have the advantage of scalability because the development itself started as a prototype and grow as a finish application. The application was developed for specific purpose and for a specific environment that do not have room for scalability and adaptability. The reduction of features is the product of “time boxing” restriction where versions of the software are pushed to the next stage to finish a release in a short time. Apparently, some features of the software, especially those minor ones are neglected or ignored. RAD PROCESS DIAGRAM This model was based on the principle that better products can be developed more swiftly. RAD diagram using iterative prototyping: ITERATIVE MODEL Iterative or incremental development is process where developers take advantage of the ideas learned during the development of previously completed versions of the system. It maybe learned from the development process itself or from the actual use of the system. The key step in the process is by starting (Initialization step) on simple requirements of the system and gradually or repeatedly enhancing the versions design and includes new functional facilities until such time that the system is operational. To guide the progression of iteration, an project control list is produced having the record of tasks that are required to be performed. The list is constantly being modified because of continuing or repeated analysis. The analysis of iteration came from user feedbacks that will be use to clarify the goals, determine the structure, modularity, usability, reliability, and efficiency of the system. The guidelines that push the implementation and analysis are: Any sign of difficulty and problem fitting newly modified modules into the system is a signal to implement a re-design work. A table or databases should be modifying with ease and quick, if not, a re-design work is needed. It should be easier to modify things in the system as the iteration progresses but if it is not possible then it will be assume that there is a problem with the basic design or previous patches. Patches, as a rule, should be remove after one or two iterations. The implementation should be monitored and analyzed to ensure that it is measuring up to the set project goals. The use of program analysis facilities to aid in implementation analysis is required. User feedback, reports or reaction must be taken and analyzed to identify the flaws in the existing implementation. THE ADVANTAGE/ DISADVATAGE OF ITERATION It provides the advantage in the use of measurement within the evolution of the system. Measurement are very informative and can be the basis of comparison between versions of the system. An observer can view and monitor that relation of changes in a variety of characteristics of the product or measure to signal significant problems and irregularities. Iterative model, like prototyping complexity, is belived to be hard to manage. This model is particularly relying on development tools rather than concentrating on the user needs. Needless to say that developers maybe overwhelmed by the endless loop of refinement. THE PROTOTYPING MODEL A prototype is advance estimates of the final system, put together, tested, and then modify as required until a satisfactory prototype is finally completed. The completed prototype will be use as the model for the development of the final product. Prototyping is creating a sample solution to user’s problems. Developers must gather the key points for the development cycle. It must begin with a task analysis so that all persons involved may understand the problem. After the task analysis, the developers should effectively create a scenario where users and the proposed system doing the real work. These created scenarios will provide the initial model for the system. The developers can now build and polish prototypes of the solution. The prototype will be subject to iteration, test, and improvement as it-undergoing iteration. The prototype will be tested in the intended environment to find its usefulness. THE ADVANTAGE AND DISADVANTAGE OF PROTOTYPING Although, prototyping is beneficial as the Iterative model, the prototypes in high-tech prototyping tend to be fashioned by development tools than listening to user needs. Concentrating more on the technical side of the prototype may take away the attention from the real problems to be address. Like iteration, developers may be trapped in an endless loop of repeated revisions and because prototyping start early in the development cycle, the ideas maybe rejected too early if the cost of implementing the idea is unaffordable. Prototypes may loose their original objectives and reasoning through the process resulting into a more complicated and unpredictable system. THE SPIRAL MODEL This model is recommended for large and complicated development projects. It combines the characteristics of the waterfall model and prototyping. Each phase in the spiral model starts with analysis, a design goal, engineering works and ends with the end-user review. In spiral model, user elements are given the priority to come up with an operational application rather than the technical elements of the system, which might add to the duration of the project development. THE ADVANTAGES/DISADVANTAGES OF THE SPIRAL MODEL The main advantage of the Spiral model is evident in the realistic budget, schedules, and other aspects of the development. Here, important issues in the development are being revealed earlier and eventually solved. It is more adaptable to eminent generally experienced changes in the software development process. SPIRAL MODEL DIAGRAM THE TRADITIONAL AND CONTEMPORARY MODEL COMPARISON The main advantage or the great difference of Rapid Application Development and other modern SDLC MODELS from the traditional SDLC is time. Contemporary applications development consume less time and therefore reduce development cost. The disadvantage of traditional SDLC is the restriction in the development flow. In SDLC, you cannot move and work to the next stage until the current stage is complete. However, building a very critical system that requires meticulous details may need such approach. RAD as the name entail, works on a system that need to be develop rapidly. Other contemporary models also thrive is development speed. This is useful in building systems for fast pace businesses that do not have the convenience of waiting for applications to complete using standard development time. Unlike SDLC, Many contemporary models like RAD’s emphasis on speed result in many vital software engineering concepts being neglected and this possibly will result in enormous errors. We can consider RAD as a powerful method but it doesn’t have the room for scalability. Inadequately designed system means more maintenance cost and may sometimes exceed the cost of developing or changing the system. SDLCs emphasis on meticulous system development produces quality applications that need less maintenance. THE IMPORTANCE OF USER PARTICIPATION OR INVOLVEMENT IN THE DEVELOPMENT MODELS In SDLC’s WATERFALL, RAD, PROTOTYPING, ITERATIVE, SPIRAL and other development model, user involvement is clearly defined. End-users are very important factors in the development stage. The primary focus of development is to acquire a detailed perception of the problem at hand or prospect for building a new application. User interaction and documenting user interviews is a major task to identify requirements and put an end to conflicting goals. The information gathered from the users will be the key input to the design stage. The first stage of SDLC delivers the most important requirements of the system that needs the majority of end-user involvement, the result of the feasibility study will greatly influence management decision. Next, is the analysis of the requirements, followed by the design stage that produces the blueprint of the system. As part of the implementation stage, the blueprint will guide programmers in coding and debugging of the applications and finally test the new system into the intended environment. The user’s involvement in the testing stage is vital and compulsory. This is necessary to have a realistic assessment of the new software in terms of accuracy and performance. THE MANAGEMENT OPTIONS TO ABORT OR CONTINUE WITH THE DEVELOPMENT The management decision to continue or abort the system development will come from the in-depth assessment of all aspect of the organization. Assessment will take into account potential hindrance of the project such economic, technical, operational, legal and political issues. The detailed outline of issues, benefits, cost and time duration of the project. If all the assessments presented conformed with the organization objectives then development can commence. However, there maybe some reasons to postpone or permanently cancel the development of the proposed system if the management is seriously considering the human factor involved especially when some of the employees will be retrench by the impending modernization. Management will never have the problem in deciding or choosing an option in the system development process because all SDLC models, in the early stage, are capable of creating decision-making guidelines and references for the management. References: Brainpulse, n.d., "System Development Life Cycle Model", [online], http://www.brainpulse.com/software_development_india/software-articles.php?AID=49 Gates, n.d., "Systems Development Life Cycle", [online], http://gates.comm.virginia.edu/rrn2n/teaching/sdlc.htm Maner W, 1997, "Rapid Application Development", [online], http://csweb.cs.bgsu.edu/maner/domains/RAD.htm#1 Moris C., 2002, "Information System Analysis", [online] , http://polaris.umuc.edu/~cmorris/paper.html Creative Data, 2001, Development Methodology – JAD, [online], http://www.credata.com/research/jad.html Read More