You are here

Definition and Objectives of Systems Development

19 January, 2016 - 12:35

Organizations exist in a dynamic environment, and thus, they regularly experience changes in their

  • Legal requirements, such as government reporting.
  • Level and kinds of competition.
  • Technologies, such as data entry devices, bar codes, and radio frequency identification (RFID) tags used to record and process information.
  • Lines of business or kinds of business activities.
  • Management desire for better access to information and improved management reporting.

Review Question

What is systems development?

 

All of these challenges at varying times necessitate changes to organizations’ Information Systems. These changes may either require the creation of new Information Systems or significant modifications to existing Information Systems. Systems development comprises the steps undertaken to create, modify, or maintain an organization’s Information System. These steps, along with the project management concepts discussed below, guide the in-house development of Information Systems (i.e., make), as well as the acquisition of systems solutions (i.e., buy). A term often used synonymously with systems development is systems development life cycle or SDLC. The term systems development life cycle (SDLC) is used in several ways. It can mean:

  1. A formal set of activities, or a process, used to develop and implement a new or modified Information System (referred to below as a systems development methodology.)
  2. The documentation that specifies the systems development process referred to as the systems development standards manual.
  3. The progression of Information Systems through the systems development process, from birth through implementation to ongoing use.

Review Question

What is the difference between systems development and the systems development life cycle (SDLC)?

 

The “life cycle” idea comes from this last view and is the definition that we use in this text. Systems development is also an important—sometimes dominant—component of more comprehensive organizational change via business process reengineering.These terms as well as “systems life cycle” and “systems analysis and design” are also used to refer to the systems development process.

Review Question

What are the systems development objectives?

 

We propose following systems development objectives:

  • To develop information systems that satisfy an organization’s informational, operational, and management requirements. Note that this objective relates to the system being developed.
  • To develop information systems in an efficient and effective manner.

Note that this objective relates more to the development process than to its outcome.

Review Question

What benefits are derived from using a systems development methodogy?

 

Systems Development Methodology

A systems development methodology is a formalized, standardized, documented set of activities used to manage a systems development project. It should be used when information systems are developed, acquired, or maintained. Table 6.1 describes the characteristics of an SDLC. Following such a methodology helps ensure that development efforts are efficient and consistently leads to Information Systems that meet organizational needs.

Systems Development Phases, Steps, Purposes, and Tasks

Figure 6.1 presents the systems development life cycle. The right side of the figure depicts the four development phases: systems analysis, systems design, systems implementation, and systems operation. The bubbles in Figure 6.1 identify the seven development steps undertaken to complete the four phases of development. Arrows flowing into each bubble represent the inputs needed to perform that step, whereas outward-flowing arrows represent the product of a step.

Table 6.1 Characteristics of a Systems Development Methodology
  • The project is divided into a number of identifiable processes, each having a starting point and ending point. Each process comprises several activities, one or more deliverables, and several managementcontrol points. The division of the project into these small, manageable steps facilitates both project planning and project control.
  • Specific reports and other documentation, called deliverables, must be produced periodically during systems development to make development personnel accountable for faithful execution of systems development tasks. An organization monitors the development process by reviewing the deliverables that are prepared at the end of each key step. Many organizations rely on this documentation for training new employees; it also provides users with a reference while they are operating the system.
  • Users, managers, and auditors are required to participate in the project. These people generally provide approvals, often called signoffs, at preestablished management control points. Signoffs signify approval of the development process and the system being developed. Such approvals ensure that users understand the resources needed for the project and believe that the project will have a successful outcome, thus ensuring its acceptance.
  • The system must be tested thoroughly prior to implementation to ensure that it meets users’ needs.
  • A training plan is developed for those who will operate and use the new system.
  • Formal program change controls (see Chapter 8) are established to preclude unauthorized changes to computer programs.
  • A post-implementation review of all developed systems must be performed to assess the effectiveness and efficiency of the new system and of the development process.
 
media/image71.JPG
Figure 6.1 Systems Development Life Cycle 
 

Review Question

What are the systems development phases, steps, purposes, and tasks?

 

Table 6.2 lists the key purposes and tasks associated with the seven development steps (bubbles) shown in Figure 6.1. You should take some time now to review both the table and the figure.

In the past it often took a new system years to move through the initial steps (i.e., bubbles 1 through 5 in Figure 6.1) in the life cycle. Now business moves at “Internet speed” and must develop B2B (business-to-business) and other business infrastructure systems in 90 to 180 days. If they don’t, they may be put out of business or absorbed by organizations that can. 1

media/image5.png

Systems development does not always proceed in the orderly, sequential course suggested by Figure 6.1. Some subset of steps may be repeated over and over until a satisfactory result is achieved. Or, we may undertake certain steps out of sequence. Finally, systems development may be outsourced to consultants or vendors, and personnel from within the organization will be part of the development team to serve as business process experts. The presentation in Chapters 6 and 7 assumes that systems development will be performed by an organization’s own systems development personnel, proceeding as depicted in Figure 6.1. In Technology Insight 6.1, we briefly describe some alternative approaches that may be used. The alternatives discussed there include who will develop the system and how the SDLC (Figure 6.1) might be altered. We also discuss alternative focuses for analysis and design—namely, data, functions, and objects.

 
Table 6.2 Information Systems Development Phases, Purposes, and Tasks
Phase Purpose Tasks
Analysis (bubbles 1 and 2) 2 Define project goals and scope. Study the problem and the users’ requirements. Propose alternative problem solutions.
  Develop specifications for the new or revised system’s functions.
-------------------------------------------------------
Design (bubbles 3 and 4) Develop an appropriate system manifestation. Describe desired features (e.g. screen layouts, business rules) in detail.
    Choose software and hardware.
    Write computer program specifications.
    Devise implementation plans, system tests, and training.
-------------------------------------------------------
Implementation (bubble 5) Prepare to begin using the new system. Write, test, and debug the computer programs.
-------------------------------------------------------
Operation (bubbles 6 and 7) Use the new system. Convert to new or revised system.
    Conduct post-implementation review.
    Perform systems maintenance.
 

Technology Insight 6.1

Alternative Development Approaches

Alternatives to the SDLC. The SDLC described in this text epitomizes what is often called the waterfallmethod because the output of each step in the process becomes the input for the next step. This method is often seen as rigidly sequential and therefore works best for routine processes that are well understood and for which requirements can be completely specified in advance. For example, in Figure 6.1 the logical specification flows into SDLC steps 3.0 and 4.0. The assumption is that the user requirements for the new system that are embodied in this specification are completely and accurately specified at that point in the development process.

Rapid applications development (RAD) is a management approach to systems development that employs small teams of highly skilled developers using higher-order development tools, such as ICASE, PowerBuilder, or even Visual Basic, to develop the system iteratively. RAD uses the Joint Application Development (JAD) approach for requirements gathering and prototyping input/output screens, and in 90- to 120-days evolves the prototypes developed during JAD sessions into a running system during the construction phase of the RAD life cycle. This running system partially fulfills user requirements and in the next RAD cycle more user requirements are added to the system. Thus RAD is an iterative process that generates systems that are more effective in meeting user requirements and speeds the process of delivering running systems to the users. For medium-size business applications, the RAD process leads to a sixteen-fold productivity increase over traditional COBOL development and three-fold increase over 4GL developments environments.

An organization can avoid part of the development effort altogether by purchasing the software. Purchasing transfers to the vendor the risk of not completing the program on time and the risk that the program will not meet user needs. This common approach assumes that purchased software represents industry best practices and should meet most of the users’ needs. For example, with enterprisesystems, organizations purchase a system and then configure it to match the organization’s business requirements. We discuss pros and cons of purchased software in the next chapter.

Alternative Approaches to Analysis and Design. In this text we use functional decomposition, a method that focuses on a system’s functions, or processes, and utilizes top-down, hierarchical simplification to derive the new system’s design. The DFDs that we use to analyze a system depict processes, or functions, and the flow of data between them. This approach produces models of systems emphasizing what the system must do; i.e., the activities that must be performed.

There are alternative approaches to analysis and design that focus on either data or objects as their primary building block. Data-structured development is based on the premise that the data make up the fundamental building blocks for a system. As described in Chapter 3, data modeling is an analysis of data conducted to develop a conceptual model of an organization’s data. This conceptual model serves as the basis for the development of all systems subsequently developed by the organization. Because the data model represents the true nature of a system, it is less likely to change than are the applications using the data.

Object-oriented (OO) development regards the world as a set of objects that are related to one another and that communicate with one another. Systems developed using either function-oriented or data-oriented approaches consist of separate programs and data, while object-oriented systems consist of objects that contain both the data and the procedures, or methods, for manipulating the data. For example, to prepare a monthly sales report, a traditional program would include the actions that must be taken, such as accumulate the data, format the data, and print the report. An object-oriented program, on the other hand, would call for the object “monthly sales report.” That object would include the data and procedures necessary to prepare the sales report. The monthly sales report object might itself contain an object designed to sort the data into the required sequence. Any object needing to sort data could use this sorting object. A big advantage of object-oriented programming is reusability. Programs can be built from prefabricated, pretested building blocks—such as the sorting object used by the sales report object—in a fraction of the time it would take to build them from scratch.

Unified Modeling LanguageTM(UMLTM) is a tool often associated with object-oriented development. According to the Object Management Group (OMG) 3, UML is used to specify, visualize, and document models of software systems, including non-object oriented applications. OMG reports that these models ensure that end user needs and program design requirements are met before program coding will make changes difficult and expensive. UML defines twelve types of diagrams to document an application’s structure and behavior and to organize and manage application modules.

Another alternative approach to analysis and design is Extreme Programming. Extreme Programming(XP) is a deliberate and disciplined approach to software development 4 that emphasizes customer involvement and promotes teamwork. XP is characterized by communication among programmers and customers, simple design, early testing, and continuous integration of changes into the evolving system. Recall the current environment for information systems development. XP improves project success and developer productivity when used on risky projects with dynamic requirements, a large category of current development projects.