system development methodology

Views:
 
Category: Education
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

System Development Methodology :

S ystem Development Methodology Prasanth.M

System Development Methodology :

System Development Methodology A system development methodology refers to the framework that is used to structure, plan, and control the process of developing an information system Types of SDM 1.Waterfall model 2.Prototyping 3.Rapid application development(RAD )

Waterfall model:

Waterfall model Project is divided into sequential phases, with some overlap and splash back acceptable between phases. Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time Tight control is maintained over the life of the project through the use of extensive written documentation

PowerPoint Presentation:

Strength: Ideal for supporting less experienced project teams ensuring the adequacy of documentation, quality, reliability, and maintainability of the developed software Progress of system development is measurable. Weakness Inflexible , slow, costly and cumbersome due to significant structure and tight controls Difficult to respond to changes. Changes that occur later in the life cycle are more costly and are thus disco Problems are often not discovered until system testing raged System performance cannot be tested until the system is almost fully coded, and undercapacity may be difficult to correct Requirements inconsistencies, missing system components, and unexpected development needs are often discovered during design and coding. Produces excessive documentation and keeping it updated as the project progresses is time-consuming

Prototyping:

Prototyping Not a standalone complete development methodology, but rather an approach to handling selected portions of a larger, more traditional development methodology . Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. User is involved throughout the process, which increases the likelihood of user acceptance of the final implementation

PowerPoint Presentation:

Strengths: Improves both user participation in system development and communication among project stakeholders. Potential exists for exploiting knowledge gained in an early iteration as later iterations are developed. Helps to easily identify confusing or difficult functions and missing functionality. Encourages innovation and flexible designs. Provides quick implementation of an incomplete, but functional, application. Weakness: Approval process and control is not strict. Requirements may frequently change significantly. Identification of non-functional elements is difficult to document. Prototype may not have sufficient checks and balances incorporated.

Rapid application development(RAD):

Rapid application development(RAD) Key objective is for fast development and delivery of a high quality system at a relatively low investment cost. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. Active user involvement is imperative. Iteratively produces production software, as opposed to a throwaway prototype. Produces documentation necessary to facilitate future development and maintenance. Standard systems analysis and design techniques can be fitted into this framework.

Strengths::

Strengths: RAD produces systems more quickly and to a business focus, this approach tends to produce systems at a lower cost. Engenders a greater level of commitment for stakeholders,both business and technical. Concentrates on essential system elements from user viewpoint. Provides the ability to rapidly change system design as demanded by users. Produces a tighter fit between user requirements and system specifications. Generally produces a dramatic savings in time, money, and human effort.

Weakness::

Weakness: More speed and lower cost may lead to lower overall system quality. Danger of misalignment of developed system with the business due to missing information. Project may end up with more requirements than needed. Potential for feature creep where more and more features are added to the system over the course of development. Potential for inconsistent designs within and across systems. Potential for violation of programming standards related to inconsistent naming conventions and inconsistent documentation. Difficulty with module reuse for future systems .

  Selecting the appropriate methodology :

Selecting the appropriate methodology Clarity of User Requirements : When the user requirements for what the system should do are unclear, it is difficult to understand them by talking about them and explaining them with written reports. Prototyping and throwaway prototyping–based RAD methodologies are usually more appropriate when user requirements are unclear because they provide prototypes for users to interact with early in the SDLC. Familiarity with Technology: When the system will use new technology with which the analysts and programmers are not familiar Throwaway prototyping–based methodologies are particularly appropriate for a lack of familiarity with technology because they explicitly encourage the developers to develop design prototypes for areas with high risks Phased development-based methodologies are good as well, because they create opportunities to investigate the technology in some depth before the design is complete

PowerPoint Presentation:

System Complexity : Complex systems require careful and detailed analysis and design Throwaway prototyping–based methodologies are particularly well suited to such detailed analysis and design System Reliability: Throwaway prototyping methodologies are the most appropriate when system reliability is a high priority, because it combines detailed analysis and design phases with the ability for the project team to test many different approaches through design prototypes before completing the design Short Time Schedules: Projects that have short time schedules are well suited for RAD-based methodologies. This is due to them being designed to increase the speed of development Prototyping and phased development–based methodologies are excellent choices when timelines are short because they best enable the project team to adjust the functionality in the system based on a specific delivery date

    :

Schedule Visibility : One of the greatest challenges in systems development is determining whether a project is on schedule The RAD-based methodologies move many of the critical design decisions earlier in the project to help project managers recognize and address risk factors and keep expectations in check.

authorStream Live Help