Development and Relevance of System Development Life Cycles - Essay Example

Running head: System Development Life Cycle Development and Relevance of SDLC Management Information Systems Accounting Finance System Development Life Cycle In order to develop new systems organizations can select among four basic systems development life cycles: Traditional Prototyping Rapid Application Development (RAD) End-user development Traditional Systems Development Life Cycle A traditional SDLC has the following characteristics: Identify need for a system Problem identification and solution. Alternative solutions Technical design layout System testing System upgradation A traditional SDLC is often represented by "Waterfall" model. The Waterfall Model The Waterfall Model, often recognized as classic life cycle, possesses the following features: A linear and sequential approach Gathering requirements from customer Progresses through the phases of: Communication Planning Modeling Construction Deployment Being the oldest paradigm for software engineering, it has gone through several critics like: It is very rare to follow this model in real life projects because of the sequential flow it deploys. As a result it is indirectly applied which creates confusion for the project team. The waterfall model requires an explicit elaboration of all requirements, which the customer lacks; this results in unnatural uncertainty in accommodating all requirements. As the model lacks any overlapping steps, so it does not support any sample version of the program for the customer. Advantage: The waterfall model serves as a useful process model in situations where problems are fixed and work is to proceed in a linear manner. Limitations: It does not bridges the communication gap due to which user is subjected to explain the task all at once in the beginning. Very time consuming. Expensive as compared to other models. Does not provide any sample to the user. In case of a technical flaw, the whole system has to be considered as to identify where the flaw lies. The Incremental Model The incremental model combines elements of the waterfall model in an iterative fashion to as calendar time progresses. Followed by a linear sequence, it produces deliverable "increments" of the software. (McDermid, 1993) An incremental model is used as the core product and is considered as a first increment after which the plan is developed for the next increment. The plan addresses the modification of the product towards betterment of needs of the customer along with the delivery of additional features and functional enhancements. The incremental process model like other evolutionary approaches is iterative in nature but unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment. (Pressman) Early increments are stripped down versions of the final product. Advantages: Incremental model is useful in the case when staffing is unavailable for a complete implementation by the business deadline established for the project. Increments can be planned to manage technical risks. Limitation: The whole project depends upon the "core product", and if in any case it is halted or bugged the whole system comes down. RAD Model (Rapid Application Development) Rapid Application Development Model emphasizes a short development cycle with a "high-speed" adaptation of the model. (Pressman) RAD achieves rapid development by using a component based construction approach. RAD employs tools, techniques, and methodologies designed to speed application development. (Stair, 2001) RAD employs extensive use of JAD (Joint Application Development) process for data collection and requirement analysis. Like waterfall model, RAD adapts the same approach of the phases. RAD supports "parallel working" on different systems. Advantages: The main benefit of RAD upon other models is its capability to finish the task in an efficient manner followed by an efficient speed because of its "parallel working" system. Each major function can be assigned to a separate RAD team, which after its completion can be integrated into "one-piece" software. Limitation: In case of large projects sufficient human resources are required. In case of improper modularization, component building will be problematic. RAD is inappropriate in conditions where technical risks are high. Prototyping Prototype modeling acts, as a demonstration of system needs to be developed. As the prototype or demo system is further defined, feedback is elicited from users (Harbison, 1997) Thus, the domain models, reference requirements, and reference architecture are continually validated. The prototype or demonstration system development process provides further validation of these requirements and models, and identifies needed refinements. Prototyping employs an iterative approach to the system development process. During each iteration, requirements and alternative solutions to the problem are identified and analyzed, new solutions are designed and a portion of the system is implemented. Users are then encouraged to try the prototype and provide feedback. Advantages: Reduced deadline pressure. Prototyped products tend to result in a better user interface (Pressman) Prototypes result in reduced cost. Prototypes help developers find and specify user requirements, which improve the quality and completeness of requirements. Prototypes help bridge the requirements-specifications communication gap. Limitation: It can be problematic in the situation where the customer after viewing the prototype considers it to be the final version, satisfies and demands a few more changes without analyzing upon the back end development complications. Spiral Model A spiral model is divided into framework of segments encompassing different activities, each segment is represented by a set of activities. Spiral model is the outcome of the combination of features of Waterfall model and Prototype model. However it possesses an additional feature of "Risk identification, analysis and assessment". Due to which it is often termed as "risk-driven process" model. As the name suggests, it works in a spiral, with a continuous loop inside out followed by a clockwise direction. The model uses prototyping thereby enabling the designer to apply prototyping at any stage if required. Advantages: If applied properly, it reduces risks to a greater extent due to which problems related to risks are solved. The spiral model follows a more realistic approach then other models. Employed in large and complex projects. Limitations: Risk factor requires equal management and consideration, in case of neglecting or underestimating risk assessment, severe problems occur. Because of the risk involvement, one may find it difficult to convince the customer in adoption of Spiral model. Iterative Model The project is divided into various small phases to be operated independently by various team designers. Iterative model is the actual implementation of Waterfall model, due to which it is termed as "mini waterfall model". The reason behind is simple as it implements waterfall process in various phases or chunks. Each phase provides feedback to the user, and only upon approval it proceeds to the next phase. Advantages: Faster feedbacks resulting in quicker delivery of project. Overcoming the major problems of waterfall model, it upholds its advantages resulting in a greater flexibility and versatility. Immediate production of software products. Limitation: The only disadvantage could be from the "feedback", as user might feel uncomfortable or get irritated in replying continuous feedbacks. System Building Phase Depicts the phases of "unified process" in five phases i.e., Inception, elaboration, construction, transition and production. Bridging the communication gap between designer and user, it enables the designer to identify the business requirements of the user and plan the architecture layout accordingly. A "first cut" executable system is developed for user convenience. The facility of "Beta testing" is provided to the user. Upon building a system, defects are analyzed and measures taken to repair identified defects. Advantages: The distribution of equal workflow across all phases enables it to finish the development in less time. Customer is contacted and approval for the next phase is acquired every time. Due to the lack of communication gap between designer and customer, it minimizes the possibilities of errors. It is tried to keep the system as user friendly as possible. Limitation: In case of user unfamiliarity about the system, problems are encountered. RAD vs. Waterfall Model RAD composes of several shorter cycles. Waterfall model is a sequential approach with one whole cycle. Shorter cycles quickens the process of Waterfall model is time consuming. project development. "Parallel" working makes it easier to Waterfall model works in a single sequential develop, with the flexibility to add or manner due to which it follows the upgrade any new changes. traditional linear approach, which makes it difficult to upgrade the system unless it is completed. Time saving Time consuming Cost saving Expensive Iterative vs. Waterfall Model Iterative model is the complete It is the most traditional form of SDLC. enhancement of waterfall model, due to which it is often called as the "mini waterfall model". It is the latest form of waterfall model. It employs waterfall model in each and Waterfall model has one linear phase to follow. every phase. Each phase is capable to provide and It requires a lot of patience as it is slow receive immediate feedback to/from paced and feedback is only received once the user. when the entire development is completed. Time saving Time consuming Cost saving Expensive Spiral vs. Waterfall Model Spiral model is the enhancement of Waterfall model is the primary traditional waterfall model, therefore it is a linear model. combination of set of activities. Less time consumption in More time consumption. development. More secure model due to the risk It does not provide any additional security. factor. A more flexible approach It does not provide any flexibility. Following "prototype" approach It does not provide any prototype. it gives the user a freedom to choose from among several prototypes. Feedback is needed at every phase. Feedback is not needed until and unless the development is completed. Cost saving Expensive Prototype vs. Waterfall Model Provides a sense of "user-friendliness" It does not support prototyping at all. to the user, by developing a prototype and giving the opportunity to user to test /try it. A more flexible approach. A traditional inflexible approach. In case of system halt or any bug, the In case of any difficulty the whole iteration is taken into consideration and process has to be started again. repaired, instead of revising the whole system. Time saving. Time consuming Cost saving Expensive The End-User System Development Life Cycle The most common model used today involves the primary effort undertaken by a combination of business managers and users. Information System (IS) professionals encourage users by offering guidance and support. Technical assistance, communication of standards and the sharing of best practices throughout the organization are just one of the ways IS professionals work. (Stair, 2001) While comparing different SDLC models with the traditional model, one can easily judge the variations followed by enhancements from time to time. The waterfall model is the oldest one, similarly the prototype and RAD models are the extensions of waterfall model, and finally the user-end model, which is the latest, and is an augmentation of the RAD and prototype model. All these models are used in according to different variations of user requirements depending upon formal or informal approach. User Involvement Many factors contribute to the problems of delivering computer-based systems. The Standish Group (Johnson, 1995) reports reasons for project failure that include lack of user involvement, lack of executive management support, poorly stated or incomplete requirements, and politics. Individual developers report problems ranging from insufficient memory to cultural shock. In order to avoid misunderstanding between user and designer, the following set of points should be considered: A complete range of control given to the user Design interaction modes that help the user to get through without indulging into unnecessary actions. Provide the user with the best of choices for interaction. Freedom to interrupt or undo any action or sequence of actions. Technical and internal work should be hidden from the user. A complete user-friendly interaction should be given to the user. Avoid too much burden of "do's" and "don'ts" to the user Provide visual clues to the user Make available the "reset" option for the user. Define shortcuts. The interface should have grounds of the real world paradigms. Deliverables at each stage of Traditional SDLC Systems Investigation Phase Result: Systems Investigation Report The primary outcome of systems investigation is a systems investigation report, which summarizes the results of a systems investigation and the process of feasibility analysis with recommendations of a course of action. Systems Analysis Phase: Result: System Analysis Report After going through the process of data collection (Identifying sources of data, performing data collection), data analysis (data modeling, activity modeling) and requirement analysis (asking directly, critical success factors, the IS plan, requirements analysis tools) systems analysis concludes with a formal systems analysis report, which covers the following aspects: Strengths and weaknesses of the existing system from a user's perspective. Functional requirements. Organizational requirements. A description focusing upon the goals of new information system in problem solving. Systems Design Phase Result: The Design Report After deciding the logical and physical design along with the request for proposal documentation the design report is prepared highlighting the technical descriptions of system design. These descriptions include details about the system outputs, inputs, and user interfaces as well as all hardware, software, databases, telecommunications, personnel, and procedural components and the way in which these components are interrelated with each other. The design report also includes several design alternatives along with financial options to evaluate and select a system design. Systems Implementation Result: The system is installed and ready to operate Before system installation, the following tasks are carried out: Hardware acquirement from an Information systems vendor Software acquirement (decision to make or buy) Database acquirement User preparation Hiring and training Data conversion Data installation Testing, startup and user acceptance. Systems Maintenance and Review Result: System upgradation as and when required Two types of review are performed: Event driven reviews Triggered by a problem or opportunity such as a bug or a new market for products. Time driven reviews Performed after specified amount of time such as a review every six months or a year. Decisions made to continue or abort a system development Decisions are taken on the ratio of the following consequences: 1. User uncertainty about requirement. 2. Bug identification. 3. Failure to repair the bug. 4. Skeptical attitude of the designer about system performance. 5. Difficulty in customization. 6. Unable to meet user requirements. 7. System flexibility for upgradation. Further situations could be critical success factors, too much vagueness in the systems analysis report, improper guidelines in user and stakeholder requirements and objectives undefined. The most important factor in making a wise decision is financial options: While evaluating and selecting a system, monthly costs are considered. Restrictive rental agreements. High initial investment. Additional cost of maintenance. Expenses like taxes and insurance means a lot while taking decision. In situations, which are doubtful to designers, it is better to abort development due to the fact that "to abort today and face a loss is better than to abort tomorrow and suffer a heavy loss" References Baker L. Eva & O'Neil F. Harold. 1994, Technology Assessment in Software Applications. Lawrence Erlbaum Associates: Hillsdale, NJ. Dewan M. Rajiv & Dewan Sanjeev. 1995, Managerial Incentives and the Value of Information Systems Timeliness: Journal of Organizational Computing. Volume: 5. Issue: 3. Harbison Karan & McGraw L. Karen. 1997, User-Centered Requirements: The Scenario-Based Engineering Process: Lawrence Erlbaum Associates: Mahwah, NJ. McDermid, J. 1993, "Software Development Process Models" in Software Engineer's Reference Book, CRC Press. Pressman S. Roger, Software Engineering: A Practitioner's Approach, Sixth Edition Stair M. Ralph & Reynolds W. George. 2001, Fundamentals of Information Systems. Read More