Overview

As explained in the preface, the sixth edition of Systems Analysis and Design in a Changing World is a a completely new and innovative approach to teaching systems analysis and design.  The intent of this new approach is to provide a much more example based learning opportunity.  As such the entire first chapter is an example of a complete development project from beginning to end.  Obviously, in a single chapter example, not every step is elaborated. However, by going through the entire process, students will be able to obtain a broad overview and a clear perspective of the entire development process. 

The chapter first introduces several basic concepts that are needed to understand systems development.  The first few sections define Systems Analysis, Systems Design, the Systems Development Life Cycle (SDLC), iterative development, Agile development and the six core processes of systems development. 

The remainder of the chapter illustrates the first iteration of a typical development project for the Ridgeline Mountain Outfitters (RMO) Tradeshow system. It divides the project into seven steps, including pre-project activities and then six other development steps. For simplicity purposes, each step is assigned a day, so the project has Day 1 activities, Day 2 activities, etc.  Throughout this set of daily activities, all six core processes are explained and illustrated. Sample models and diagrams are presented to give the students an introduction to some of the major techniques and models that will be taught later in the text. 

At the end of the chapter, there is a chapter case, which has assignments for similar to the RMO Tradeshow system. Obviously the students do not have all the skills necessary to do an error-free complete development. The objective of the case and its assignments, is simply to allow the students to practice going through the entire development process so that they obtain a solid overview of systems development. It is suggested that grading for these assignments be lenient, and credit could even be given simply for completing the assignment, whether it is correct or not. 

 

Learning Objectives

After reading this chapter, the student should be able to:

—  Describe the purpose of systems analysis and design in the development of information system

—  Describe the characteristics of iterative systems development

—  Explain the six core processes of the Systems Development Life Cycle

—  Identify key documents that are used in planning a project

—  Identify key diagrams used in systems analysis and systems design

—  Explain the utility of identifying use cases in systems development

—  Explain the utility of identifying object classes in systems development

 

Software Development and Systems Analysis and Design

—  computer application (app)—a computer software program that executes on a computing device to carry out a specific function or set of related functions

—  information system—a set of interrelated computer components that collects, processes, stores, and provides as output the information needed to complete business tasks

—  systems analysis—those activities that enable a person to understand and specify what the new system should accomplish

—  systems design—those activities that enable a person to define and describe in detail the system that solves the need

Q: What is the basic purpose of a course in systems analysis and design? 

 

Systems Development Life Cycle

—  project—

—  Systems Development Life Cycle (SDLC)—

—  information systems development process—

—  Agile Development

The second section in this chapter is an explanation of the Systems Development Life Cycle (SDLC).  The SDLC defines all the activities required to develop a new system. There are many different versions of the SDLC. This section distills out six core process required for the development of any new system.  In other words, these six core process are common to all types of SDLCs. By understanding these six core processes, students will not only be able to develop new systems effectively, but they will be able to adapt to any other SDLC that they may encounter in industry.  The six core processes are: [Note: These six core processes are used throughout the textbook.]

            1. Identify the problem or need and obtain approval to proceed.

            2. Plan and monitor the project—what to do, how to do it, and who does it.

            3. Discover and understand the details of the problem or the need.

            4. Design the system components that solve the problem or satisfy the need.

            5. Build, test, and integrate system components.

                6. Complete system tests and then deploy the solution.

Q: What is the basic philosophy of Agile development? 

Q: What are the six core processes? A:  See the list above.

 

Introduction to Ridgeline Mountain Outfitters

The next section introduces Ridgeline Mountain Outfitters (RMO). 

 

Iterative Development

—  iterative development—an approach to system development in which the system is "grown" piece by piece through multiple iterations

Finally before the development of the Tradeshow system begins, Iterative Development is introduced.  

Q: What are the key benefits of iterative development? 

 

Developing RMO’s Tradeshow System

—  Subsystem – An identifiable and partitioned portion of the overall system

This development project is designed as a six-day iteration with some pre-project activities to get the project started.  The activities in the pre-project and each of the six days provide the supporting detail for the six core processes for systems development. 

Pre-Project Activities

Pre-project activities are those activities required to get the project approved and started.  The two major objectives are: 

Day 1 Activities

RMO – Supplier Information System:  The first day of an iteration is usually a planning day.  In this project Day 1 will focus on planning the overall project, which is the objective of core process number 2.  There are three activities that are completed: 

Planning the Overall Project and the Project Iterations 

Planning the First Iteration:  

The first step - identify the tasks required for the iteration - is done through the development of a Work Breakdown Structure.  Figure 1-6 is a sample Work Breakdown Structure with specific tasks for the project team and estimates of the time required for each task.  

as shown in Figure 1-7.

 

Q:What is the purpose of a Work Breakdown Structure? 

Q: What is the purpose of a work sequence diagram? 

Day 2 Activities

Fact Finding and User Involvement:  Now that the project and the iteration have been planned, Day 2 initiates actual development work.  Day 2 focuses on systems analysis activities. In particular three activities are required: 

Identifying Use Cases:  Fact finding is usually done by interviewing the users and other stakeholders.  The use cases are documented in a table, as shown in Figure 1-8.  

Identifying Object Classes:  The classes are documented either in a table, as shown in Figure 1-9, or a class diagram as shown in Figure 1-10.  

Note: Students will not understand the techniques of how to identify classes. 

Q: What is the purpose of a list of user cases?

Q: What is the purpose of a table of classes or class diagram? 

Day 3 Activities

The purpose of Day 3 activities is to flesh out the details of each of the use cases identified earlier (in Day 2).  Each use case supports some user work flow, e.g. a sequence of user tasks. It is important to understand the user work flow because in order to define the screens, reports, and system processing 

Questions

Q: What is the purpose of a use case diagram? 

Q: What is the purpose of a work flow diagram? 

Q: What is the purpose of sample screen layouts? 

Day 4 Activities

Day 4 begins the design activities. 

 

Managing the Project: 

 

Q: What is the purpose of a design class diagram? 

Q: What is the purpose of the database schema? 

Q: What is the purpose of the system architectural configuration diagram? 

Q: What is the purpose of the subsystem architectural design diagram? 

Day 5 Activities

Day 5 activities focus on programming the system.  Figure 1-18 illustrates some PHP code for the SupplierView class. 

Day 6 Activities

Day 6 is final testing and deployment.  Figure 1-19 is a flow chart depicting the testing cycle.  Figure 1-20 is a sample final screen from a screen capture of the system as it was programmed. 

First Iteration Recap

Also during the last day of an iteration it is common to do an "introspection" of the iteration to discuss what went well and what problems were encountered. Because there are multiple iterations in an iterative SDLC, the project team has the opportunity to evaluate and improve their internal work processes. 

 

 

Since the objective of this chapter is to provide an example of a complete systems development project, one interesting activity is to ask the students what they would do, i.e. what are the steps, to build a system.  Give an example, such as a patient monitoring system for a dentist, or an inventory tracking system for a small business, and ask them how they would build this system for the owner (who is a good friend).  Be careful to make your example large enough that it is not simply a "cottage industry" single person application where the student just builds something that is already in his/her head. Then you can ask pointed question such as: 

—  How do you find out exactly what the user needs the system to do? 

—  How do you remember what the user tells you about what it must do? 

—  How do you know what information is important to keep? 

—  How do you make sure it does what it is supposed to do?

—  How do you divide up the work, if there are two or more of you working together?  

The chapter has a rather detailed case at the end of the chapter.  You can assign the entire case, or select specific problems out of the case.  The case can be assigned to individuals or to small groups to do.  On the following day, you could allow a few students or groups to present their models.  Remember that the intent of the chapter is to give and example and teach about the entire process of systems development and not about how correct any individual model is.  The students should be able to observe that developing software applications for a third party can be a challenging process.  

 

The danger in this chapter is to become too focused on the individual models or the specific solutions. Keep the focus on the overall process of planning, analysis, design, programming, testing, deployment with the emphasis on Systems Analysis and Design.

For all of the models presented, focus only on the overall purpose of the model. Simplify it as much as possible.  For example work flow diagrams are simply steps of what needs to happen with arrows showing the order of the steps.  Class diagrams are simply the "things" that the system needs to know about and remember.  The attributes are simply the details.  Use cases are simply how the user "uses" the system. 

 

1.  The need to have a development methodology.

Many students today will have experience building simple applications such as a Facebook app or an iPhone app.  These students may not see the need to have a development process with distinct steps, plans, and models.  Often these students built an app they envisioned themselves. Hence they were the client, user, stakeholder, analyst, design, and tester all in a single person. It is very different to build an application where there are multiple users, multiple developers, and multiple testers. Function decisions must be discovered and then remembered, ire. documented, designs must be communicated across multiple programmers, acceptance tests must be coordinated, and so forth.  Trying to build even a medium sized system without a project plan and a development methodology will spell disaster. Some typical questions to ask in this type of discussion might include the following. 

—  What purpose does systems analysis serve?  Is it really necessary?  Why? 

—  Is it important to build models?  What function do they serve?  How do the developers ensure that they understand the requirements?  How do they remember what decisions were made by the user (and themselves)? 

—  Evaluate the six core processes?  Are there better ways to execute a project?  Are the six core processes a minimal set?  Are there things missing that should be added? 

—  How long should we keep documentation and models that were built?  Should  we have external documentation that must be maintained?  

—  Is it important to have a formal SDLC?  What are the alternatives?  How formal should it be? 

 

2.  The effectiveness of iteration and the Agile philosophy

When we get to Chapters 8 and 9 we will discuss various forms of the SDLC and adaptive projects versus predictive projects. However, it is would be an effective classroom technique to begin the discussion with this example. Some discussion questions might include the following. 

—  What does "iteration" mean in software development?  What is the alternative?  What are some advantages of an iterative process?  What are the disadvantages or potential problems with this approach? 

—  This example (Tradeshow system) appears to have sequential steps for analysis, design, and programming within the iteration. Is this the best way to execute a project?  Is there a better way?  Why do you suppose the example presents it sequentially (Day 1, Day 2, etc.)? 

—  What does it mean to use Agile principles for a project?  Is Agile an effective way to execute a project?  What are some of the disadvantages of an Agile approach? 

—  Is it important to do project planning?  How much time and energy should be spent planning the project? Is planning important to an Agile project?  What are some of the dangers of not planning?  Of over planning?