Cis 206 - the Context for Systems Development

The Context for Systems Development

SDLC | Systems, Data, and People | Routes and Methods | Systems Analysis | Summary | Study Tools

Each week, some personal insights into the subject material will be offered. When work on the milestones begins, this material will be directed at their support. But, for the first few weeks, only some generalities will be discussed.

Note that terms studied can often be used interchangeably and that this is a fairly common occurrence in the IT industry. As a result, some of the terminology used in the lectures may differ somewhat from that in the text. This is intentional and intended to provide a broader background for learning.

In Week 1, the systems development life cycle (SDLC) and the role of the systems analysts in this process will be the main concerns. This material is covered quite well in Chapter 1. However, there are a few salient points that need to be made.

Notice the first page in each chapter of the textbook graphically shows coverage for each of the chapters based on John Zackman's information system framework. The chapter coverage will be graphically highlighted on the framework, similar to a chapter mapping outline. Each chapter in the framework covers a different aspect of the system development process, hence the SDLC. Although Chapter 2 is not specifically covered in the course, more details on the framework can be found in that chapter or on the Web.

SDLC

Back to Top

Chapter 1 does not really discuss the SDLC much. That discussion is necessary in connecting to systems, data, and people (next section).

The SDLC is a process or methodology for developing information systems. This process has four traditional phases: planning, analysis, design, and implementation. All information systems that are developed can have their development classified into all four SDLC steps. But that doesn’t mean that every system was developed with a formal SDLC process in mind. For example, someone may need a quick and dirty program to calculate student grades and develop a Visual Basic program for that purpose. This system exhibits all four of the SDLC processes. On the other extreme, most Fortune 100 companies likely have a formal systems development policy manual that is an extension of the SDLC process. One company has an SDLC manual that is nearly 100 pages long.

So the SDLC process is just that—a process. It can be written, detailed, and codified. It can also be totally informal and never acknowledged.

By saying that systems development is a process, it means that there are activities that are accomplished over time. These activities can be strictly controlled or they can occur with little control. Most organizations like to use strict control because systems tend to be very complicated, and having standardized development processes makes them more likely to succeed. The section in the text that discusses the capability maturity model (CMM) explains that organizations tend to evolve to have better systems development capability over time. The CMM identifies five steps a company can use to identify and measure its development processes. Typically, as an organization goes up the CMM ladder, its development process becomes more formal and complex.

The SDLC is a process by which information systems are developed, used, and then become obsolete. Then, redevelopment of the system starts the SDLC again at the beginning of the four phases. The SDLC is, in a sense, a concept, a framework that can be acted upon within its four phases by one or more possible methodologies. They may have more or fewer steps, but they all fit within the context (boundary) of the SDLC. The methodologies are the practical means of moving through the conceptual SDLC. The methodologies can be very different or similar to each other, but they all move through the SDLC. Sometimes, several methodologies can even be mixed, matched, and customized into a new, unique, standardized way of developing a system within the SDLC, depending on the challenges of developing a system.

So methodologies are not similar, but they all fit within the framework of the SDLC. And they all should support the same principles. However, when searching the Web, it is possible to find that the SDLC is also referred to as a “systems development methodology” (SDM). The textbook will refer to various methodologies—also called model driven analysis (MDA) techniques—that can be used within the framework of the SDLC/SDM. For example, structured analysis and design and object-oriented analysis and design are MDA techniques that can be referred to as methodologies used within the analysis and design phases of any given SDLC/SDM. This means the usage of the term methodology can refer to the entire SDLC/SDM or MDA techniques within the SDLC/ SDM.

Now for a quick review of systems development methodologies principles:

• Both terms, systems development life cycle and systems development methodology, represent the framework for developing a system. Please note that, for the remaining weeks' lectures, we will refer to it as SDLC.
• Model driven analysis techniques and approaches are methods by which systems development activities within the SDLC/SDM are accomplished over time.
• Organizations with complex systems will tend to use formal, standard systems development methodologies.
• As organizations become more advanced in the systems development processes, they increase their CMM level.

Now, on to how it interacts with people.

Systems, Data, and People

Back to Top

At the beginning of each chapter, you will see the author's diagrammatic illustration of the relationship between systems, data, and people. This is an excellent visual tool, so be sure to follow it during the course. For this week, notice how people are involved in the SDLC and for what they are responsible. For example, systems owners determine system scope (what will be included in the system). This seems obvious but can be challenging. Here’s a typical dialogue between an analyst and a systems owner.

Analyst: “So I understand you want a new information system.”
Owner: “Yes, the competition’s got one and we need to stay competitive.”
Analyst: “Okay, so what processes do you envision you want to automate?”
Owner: “Gee, I was hoping you would know; you’re the analyst!”

System owners may have responsibility for the system scope, but they may not have enough knowledge or experience to be able to make intelligent decisions. These cases require the analyst to be a little more creative. The dialogue may go something like this.