Chapter 1 Development Methodologies / SDLC Modern Systems Analysis and Design Seventh Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 1 Development Methodologies / SDLC

Systems Development Life Cycle Outline Systems Development Life Cycle Planning Analysis Design Implementation Maintenance Methodologies

Process of System Development System Development Process a set of activities, methods, best practices, deliverables, and automated tools that stakeholders use to develop and maintain information systems and software. “Every medium to large corporation and every custom software producer will have its own specific life cycle or systems development methodology in place.” (Hoffer) Shift in focus from custom-designed, stand-alone applications to implementing packaged software, such as ERP and data warehousing systems, and integrating outsourced software into the organization’s existing applications. Some textbooks use the term systems development life cycle. We elected not to use that term because it invokes negative connotation for many instructors. Some associate it with a pure waterfall development approach (which we consider unfair). We differentiate between development and operation (sometimes called production). This chapter focuses on development and different methodologies and strategies employed for system development.

Life Cycle versus Methodology System Life Cycle Divides the life of an information system into two stages, systems development and systems operation and support. System Development Methodology A very formal and precise system development process that defines a set of activities, methods, best practices, deliverables, and automated tools that system developers and project managers are to use to develop and maintain information systems and software. No additional notes.

Lifetime of a System A System Life Cycle Conversion Obsolescence LIFE CYCLE STAGE System Development using Methodology System Operation and Support Information Technology Teaching Notes This slide formally differentiates between the life cycle and a systems development methodology that is used to to implement the development stage of the life cycle. A common synonym for “system operation” is “production.”

Principles of System Development Get the owners and users involved. Use a problem-solving approach. Establish phases and activities. Establish standards for development and documentation. Justify systems as capital investments. Don’t be afraid to cancel or revise scope. Divide and conquer. Design systems for growth and change. Proper planning and project management Teaching Tip Minicase #4, Century Tool & Die, has proven very effective for a class discussion of the principles of system development.

Systems Development Life Cycle Series of steps used to manage the phases of development for an information system Consists of five phases: Planning Analysis Design Implementation Maintenance

Planning Analysis Design Implementation Maintenance/Support The SDLC Project identification and selection Project initiation and planning Analysis Determine system requirements (WHAT users want) Modeling possible solutions (HOW to satisfy user needs) Design Logical design Physical design Implementation Maintenance/Support Frontend A D Backend I

Systems Development Life Cycle Phases are not necessarily sequential Each phase has a specific outcome and deliverable Individual companies use customized life cycles Cross life cycle activities Activities that overlap many or all phases of the methodology. Fact-finding Documentation and presentation Feasibility analysis Process and project management

Phases of the Systems Development Life Cycle Planning (a) Project Identification and Selection Two Main Activities Identification of need Prioritization and translation of need into a development schedule Helps organization to determine whether or not resources should be dedicated to a project. (b) Project Initiation and Planning Two Activities Formal preliminary investigation of the problem at hand Presentation of reasons why system should or should not be developed by the organization

Phases of the Systems Development Life Cycle (Cont.) Analysis Determine System Requirements Study of current procedures and information systems Determine requirements Study current system Structure requirements and eliminate redundancies (b) Modeling Possible Solutions Generate alternative designs Compare alternatives Recommend best alternative

Phases of the Systems Development Life Cycle (Cont.) Design (a) Logical Design Concentrates on business aspects of the system (b) Physical Design Technical specifications Implementation Hardware and software installation Programming User Training Documentation Maintenance System changed to reflect changing conditions System obsolescence

Common Development Methodologies and Techniques Structured Development Information Engineering Prototyping Joint Application Design Commercial Methodologies (i.e., STRADIS, Navigator) Agile Service-Oriented Architecture Object-Oriented Development Spiral Model Transform Model Jackson Structured Development Code & Fix Model Participatory Design eXtreme Programming Teaching Notes In 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.

Model-Driven Development Route Modeling 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 that emphasize the drawing of models to help visualize and analyze problems, define business requirements, and design information systems. Structured systems analysis and design — process-centered Information engineering (IE) — data-centered Object-oriented analysis and design (OOAD) — object-centered (integration of data and process concerns) Conversion Notes The 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 Notes It 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.

Structured Development Based on the principles of: Modularization Top-down decomposition Process-driven Structured programming, design and analysis

Information Engineering Data-oriented technique Emphasis on planning Applied to the organization as a whole rather than an ad hoc, project-by-project basis

Expendable (throw-away) prototyping: Principle: a user can tell you better what they DON’T want than what they DO want Expendable (throw-away) prototyping: Discarded after use Used to support the analysis and design phases Evolutionary prototyping: Prototype evolves into the final system Is it a methodology? Rapid application development (RAD) Techniques emphasizing extensive user involvement in the rapid and evolutionary construction of working prototypes of a system to accelerate the system development process.

Joint Application Design (JAD) Users, Managers and Analysts work together for several days System requirements are reviewed Structured meetings

Commercial Off-the-Shelf Software Route Software package or solution that is purchased to support one or more business functions and information systems. Conversion Notes This “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 Tips Emphasize 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.

Improving IS Development Productivity Computer-aided software engineering (CASE) tools Facilitate creation of a central repository for system descriptions and specifications

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.

Argues that engineering and software development are not the same. Agile Methodologies Principles: Focus on adaptive methodologies (not predictive) Focus on people (not roles) Focus on self-adaptive processes (refine and improve development process) Argues that engineering and software development are not the same. Engineering requirements are well understood. Software requirements are not well understood and change continually.

Service-Oriented Architecture Build systems around generic services or specific business functions. Reuse in many different applications. Example: credit check application Any time the business would need a credit check (when adding a new customer, entering a new order, and so forth), the current credit check “service” application would be altered to fit that business function.