Presentation on theme: "Lesson-12 Information System Development-2"— Presentation transcript:
1 Lesson-12 Information System Development-2 Describe four basic alternative “routes” through the basic phases of system development. Describe how routes may be combined or customized for different projects.Differentiate between computer-aided systems engineering (CASE), application development environments (ADEs), and process and project management technology as automated tools for system development.
2 Alternative Routes through a Methodology Model-Driven Development (MDD)Rapid Application Development (RAD)Commercial Off-the-Shelf Software (COTS)Maintenance and Reengineering or hybrids of the aboveTeaching NotesIn this edition, we have formally acknowledged the notion that there can be multiple strategies or “routes” through the traditional phases. Thus, “one size does not fit all projects.”We have included a few of the more common routes, but there are literally dozens of routes and hundreds of variations in many methodologies. A key precept is that, contrary to popular marketing and consulting hype, the routes are merely different implementations of the same basic phases already covered (usually cleverly disguised in proprietary languages and terminology). Different routes emphasize different phases, tools, and techniques.
3 Model-Driven Development Route Modeling is the act of drawing one or more graphical representations (or pictures) of a system. Modeling is a communication technique based upon the old saying, “a picture is worth a thousand words.”Model-driven development techniques emphasize the drawing of models to help visualize and analyze problems, define business requirements, and design information systems.Structured systems analysis and design — process-centeredInformation engineering (IE) — data-centeredObject-oriented analysis and design (OOAD) — object-centered (integration of data and process concerns)Conversion NotesThe model-driven “route” is most typically associated with “methodologies based on structured analysis and design, information engineering (data modeling), or object-oriented analysis and design (use-case, UML, etc.).Teaching NotesIt was not the intent to teach the techniques in this chapter. That is why we elected not to include sample models that the students would not truly understand until they read the modeling chapters themselves.We introduce an “object” color in this slide that will be seen extensively in the object-oriented analysis and design appendices.
4 Model-Driven Development (MDD) Route Teaching NotesThe model-driven approach (with the notable exception of OOAD) is most commonly associated with the “waterfall” approach to system development. While often criticized for its time and effort intensity, model-driven strategies still work well with large and unstructured problem domains.
5 Rapid Application Development Route Rapid application development (RAD) techniques emphasize extensive user involvement in the rapid and evolutionary construction of working prototypes of a system to accelerate the system development process. RAD is based on building prototypes that evolve into finished systems (often using time boxing)A prototype is a smaller-scale, representative or working model of the users’ requirements or a proposed design for an information system.A time box is a nonexpendable period of time, usually days, by which a candidate system must be placed into operation.Conversion NotesThe rapid application development “route” is most typically associated with prototyping, JAD, and incremental or iterative approaches to system development.
6 Rapid Application Development (RAD) Route Teaching NotesThe rapid application development approach is most commonly associated with an incremental or iterative approach to system development. It is very popular for smaller and relatively structured projects in which requirements are fairly well understood from the beginning of the project.
7 Commercial Off-the-Shelf Software Route Commercial off-the-shelf (COTS) software is a software package or solution that is purchased to support one or more business functions and information systems.Conversion NotesThis “route” is new to this edition.This route replaces the “procurement” phase of the previous edition’s methodology.COTS has become extraordinarily important to aspiring systems analysts because an ever-increasing percentage of all information systems are purchased, not built in-house.This edition of the textbook includes new chapters that specifically focus on software procurement and systems integration caused by software procurement.Teaching TipsEmphasize to students that tomorrow’s systems analysts will be as likely to participate in a software package selection and integration as they will in a traditional design-and-construction style project.
8 Commercial Off-the-Shelf (COTS) Software Route Teaching NotesThis slide depicts a typical project to select a software package and then integrate that package into a business (and its other existing information systems).In the chapter, we specifically omitted ERP applications from this COTS route. ERP applications are so large and complex that their vendors typically provide a custom methodology (and consulting) to implement the ERP solution.The COTS route looks more complex because few software packages fulfill 100 percent of an organizations requirements. Thus, a COTS project does not preclude traditional analysis, design, and construction activities to supplement capabilities not provided by the chosen software package.Additionally, most software packages require customization that requires additional requirements analysis, design customization, and programming within the application’s embedded language.
9 Hybrid: Rapid Architected Development Teaching NotesThis is the first of three common hybrids presented in the chapter. It combines front-end RAD with back-end MDD methods.Some experts call this RAAD (rapid architected application development)Hybrid: Rapid Architected Development
10 Hybrid: Multiple Implementation Teaching NotesThis is the second of three common hybrids presented in the chapter. It is based entirely on MDD; however, multiple design/construction/implementation subprojects occur in parallel after the decision analysis phase.The disadvantage of this approach is that because the subprojects are implemented separately and in parallel, the subsystems may not work together as originally hoped. Thus, a full-system integration subproject may be needed at the end to ensure full-system integration.This approach can be useful for large projects with enough staff to assign to the multiple subjects.Hybrid: Multiple Implementation
11 Hybrid: Staged Implementation Teaching NotesThis is the last of three common hybrids presented in the chapter. Once again, as shown, the model-driven approach is used; however, the back-end phases are repeated in succession to produce “versions” of the final information system.Each version can be placed into operation to provide some value to the user community until the next version is released to provide incremental functionality.The illustrated hybrid is used by many independent software vendors (ISVs) as their standard approach to building a software product and then improving it with subsequent versions.Teaching TipAnother variation, not depicted, would allow each version to be developed using a RAD approach.
12 Maintenance and Reengineering Route Teaching NotesThe key point illustrated in this slide is that “maintenance and reengineering” during system operation and support is merely a smaller-scale version of the development methodology that was used to create a system in the first place.Notice that maintenance and reengineering projects do not have to start in the same phase.It is important to recognize that any given phase will not require the same amount of time in a maintenance and reengineering project as it would for a new system development project. Thus, any phase illustrated may require hours or days in a maintenance and reengineering versus days, weeks, or months in a new system development project.
13 Automated Tools and Technology Computer-aided systems engineering (CASE)Application development environments (ADEs)Process and project managersConversion NotesIn this edition, we discontinued the distinction between upper- and lower-CASE technology using those adjectives. Instead, we used more modern terminology as follows: Fifth Edition Fourth Edition CASE upper-CASE ADE lower-CASEAll non-CASE or non-ADE automated tools were classified as “process and project managers.”
14 CASE ToolsComputer-aided systems engineering (CASE) tools are software programs that automate or support the drawing and analysis of system models and provide for the translation of system models into application programs.A CASE repository is a system developers’ database. It is a place where developers can store system models, detailed descriptions and specifications, and other products of system development. Synonyms include dictionary and encyclopedia.Forward engineering requires the systems analyst to draw system models, either from scratch or from templates. The resulting models are subsequently transformed into program code.Reverse engineering allows a CASE tool to read existing program code and transform that code into a representative system model that can be edited and refined by the systems analyst.Conversion NotesIn this edition, the term CASE is restricted to model-driven technology (either forward engineering, reverse engineering, or both).Teaching TipsDifferent CASE tools may refer to their repository as a dictionary or encyclopedia.Some CASE tools maintain a repository at a project-by-project level. Others provide or integrate into a project-independent repository to promote sharing of models and specifications between projects.Most CASE tools interface with one or more ADEs to provide round-trip engineering that supports the full life cycle.
15 CASE Architecture Teaching Tips Map your course’s CASE (and ADE) environment into this diagram to help your students better understand the automated tools that will be taught in your course.
16 ADE ToolsApplication development environments (ADEs) are integrated software development tools that provide all the facilities necessary to develop new application software with maximum speed and quality. A common synonym is integrated development environment (IDE)ADE facilities may include:Programming languages or interpretersInterface construction toolsMiddlewareTesting toolsVersion control toolsHelp authoring toolsRepository linksConversion NotesIn this edition, the term ADE is compatible with both model-driven and rapid application development methodologies. In contemporary literature, it is the basis for all RAD methodologies.Teaching TipsDifferent CASE tools may refer to their repository as a dictionary or encyclopedia.Many ADEs provide links to a repository to support sharing of program code.Most ADEs either interface with one or more CASE tool repositories or they provide rudimentary CASE-like modeling tools within the ADE. This allows developers to integrate RAD and MDD techniques as was demonstrated in the first hybrid route presented earlier in the chapter.
17 Process and Project Managers A process manager is an automated tool that helps to document and manage a methodology and routes, its deliverables, and quality management standards.A project manager is an automated tool to help plan system development activities (preferably using the approved methodology), estimate and assign resources (including people and costs), schedule activities and resources, monitor progress against schedule and budget, control and modify schedule and resources, and report project progress.Teaching NotesExamples of process and project management technology will be covered extensively in Chapter 4.