L e s s o n 1 L e s s o n 1
Foundations for Systems Development
ASSIGNMENT 1
Read this assignment introduction. Then, read Chapter 1, “The Systems Development Environment,” on pages 2–25 in your textbook.
What Is Systems Analysis and Design?
Before embarking on a course of study, it’s helpful to know what you’ll be studying. Information systems analysis and design is the process of developing and maintaining an information system, and it’s widely used in enterprise organizations to improve the systems that create and control the data that run daily business operations. To achieve maximum effi- ciency and utility, it’s best to follow a structured approach.
This course will focus on using the systems development life cycle (SDLC) as a conceptual tool. Although the SDLC isn’t the only tool available, it’s one of the most widely used.
Systems Analysis and Design:
Core Concepts
One aspect of improving organizational systems is creating
or acquiring tools and training employees on their use. An
integral part of virtually all enterprise systems is application
software, which is software designed to process data and
support users. Application software, which can range from word
processors to database systems, turns data into information,
which can then be used to further business objectives. Many
types of application software, such as the Microsoft Office suite,
can be purchased off the shelf, but some organizations may
have detailed, mission-specific requirements that necessitate
developing software in-house.
Information systems are more than just the software that employees use, however. Although a systems analyst’s pri- mary responsibility is application software development, to be effective an analyst must understand every piece of the infor- mation system. The other aspects of an information system include
n
The hardware and operating system software that the applications run on
n
Documentation and training materials used to teach and support employee usage
n
Specific job roles associated with the overall structure
n
Security controls
n
Users who utilize the software as part of their job duties Creating an information system requires, among other elements, a solid understanding of the software engineering process.
This process is centered on using proven methodologies, techniques, and tools. Methodologies are sequences of step- by-step approaches to help develop a product, and incorporate several development techniques, which are processes that analysts use to ensure project work is complete, considered, and comprehensible to others. These techniques include interviews and project diagrams. Tools are specific software packages that ease the usage of specific techniques.
Common tools include computer-aided software engineering (CASE) packages.
Systems
The term system is used extensively in the field, but what exactly does it mean? For our purposes, a system is a set of interrelated business procedures or components that work together within a business unit to fulfill a purpose, which is the overall goal or function. Systems have certain character- istics that define them:
n
Components—Irreducible or fundamental parts or collec-
tions of parts that together form the overall structure. A
collection of components is a subsystem.
n
Interrelated parts—One or more parts of the system that depend on one or more other parts to function.
n
Boundary—A division that separates the interior of a sys- tem from its exterior. This division also sets the system apart from its environment, establishes its limits, and contains it.
n
Environment—The external factors that interact and influence the system.
n
Interfaces—Points of contact between subsystems, or between a system and its environment.
n
Constraints—The limits on what a system can do or achieve in its environment, usually specified in terms of capacity, speed, or capabilities. Constraints can be imposed internally or externally.
n
Input—The material or data that’s fed into a system to achieve its purpose.
n
Output—The material or information that emerges from a system to achieve its goals.
Important System Concepts
The aforementioned concepts are invaluable to working as a
systems analyst, but they’re far from the only fundamental
concepts. Knowing how a system can be broken down is
just as important as knowing how one goes together, and
there are several key ideas necessary for a system analyst
to understand. The first of these concepts is decomposition,
or the process of breaking a system description down into
smaller units, either components or subsystems. Decomposition
allows analysts to examine a system in more manageable,
comprehensible chunks rather than trying to examine a com-
plex logical construct. Decomposition aids understanding and
allows attention to be focused on specific areas. In addition,
decomposition—or functional decomposition, as it’s sometimes
known—allows various parts of a system to be examined,
built, and tested at different times, which helps in learning
the inner workings of a system and comprehending its overall
function.
Related to decomposition is the idea of modularity, or sepa- rating a system into pieces of a relatively uniform size, known as modules. Modularity allows a system to be represented in a simpler logical structure, which can be of great help in understanding, redesigning, and rebuilding a system. Along with modularity, analysts should also understand coupling, which is how much the subsystems depend on each other for function. Although interrelatedness is a necessary part of a functioning system, subsystems should be capable of inde- pendent function as much as possible. Tightly coupled
systems have a large chance for failure because any one part depends to a high degree on others. Loosely coupled systems are generally far more fault-tolerant. Finally, cohesion is the extent to which a system or subsystem performs a single function.
A Modern Approach to Systems Analysis and Design
As a systems analyst, your focus will most likely be on systems integration, which allows hardware and software from multiple vendors to function together, and allows sys- tems developed in older procedural languages to work with systems developed in visual programming environments such as Visual Basic. Visual programming environments are used to create user interfaces for client/server systems, where the database or primary application resides on a specialized com- puter, or server, and allows access to multiple machines, known as clients, across a network.
Another approach is to use enterprise-wide systems, which are complex systems constructed from independent system modules that can be chosen and implemented based on the developer’s choices. These systems are designed to handle many tasks instead of focusing on one or two functions.
Due to the ready availability of enterprise systems, in-house
system development is increasingly rare. However, such
development still takes place, so any prospective system
analyst should have an understanding of the analyst’s role in
the development process. Although many job functions have
a hand in systems analysis and design, the role of the system
analyst has the main responsibility for the analysis and design of information systems. As a result, systems analysts have considerable influence on an organization’s operations.
A systems analyst’s primary role is to study the problems and needs of the organization to decide the best combination of people, methods, and information technology to improve operations. Systems analysts also help users and business managers define the requirements for additional or improved services, and as such, are key to the development process.
Due to the range of functions a systems analyst is expected to fulfill, an analyst must foster four primary skill types:
n
Analytical—These skills enable an analyst to comprehend the organization and its functions, identify issues and potential fixes for those issues, and perform problem analysis and resolution. Systems thinking, which allows an individual to see a system as a logical structure and understand the relationships between entities, organiza- tions, and the overall environment as they translate into real-world applications, is a primary example of an ana- lytical skill.
n
Technical—These skills allow an analyst to understand both the potential and the limitations of a technology or set of technologies. Such skills should include the ability to create code in different programming languages, work with various operating systems, and use and configure various hardware platforms.
n
Management—As implied by the label, these skills allow an analyst to properly direct and control projects,
resources (including personnel), risk, and change factors.
n
Interpersonal—Finally, interpersonal skills allow an
analyst to work with others, ranging from end users, to
other analysts, to executive managers. Systems analysts
often must act as liaisons between disparate profession-
als, such as managers and programmers, so the ability
to communicate effectively, as well as to listen actively
and lead meetings, is vital.
Developing Information Systems and the Systems Development Life Cycle
Developing an information system is a lengthy, complex undertaking, so it’s considered a best practice to use a stan- dardized process to conduct all the tasks needed to analyze, design, implement, and maintain an information system. This standardized process, known as a systems development methodology, often follows a life cycle, as many business processes do.
Such a cycle is a systems development life cycle (SDLC), which forms the basis of most common systems analyst work. The SDLC is commonly used for systems development, although it isn’t the only method used. It designates each phase or step in the process, and it defines goalposts and deliverables for every step.
While each organization modifies the SDLC to suit its needs, the basic conceptual model generally can be broken down into four discrete phases. These phases aren’t intended to be strictly linear—in a production environment, some phases may need to be repeated, performed out of order, or done in parallel with other pieces of a given project—but for simplicity they’re presented as such here.
The first phase is systems planning and selection, where the
total information system needs of the organization are ana-
lyzed and ordered, and where a potential project is identified
and arguments for and against its pursuit are presented to
management. In essence, this phase starts with a need being
identified, often from a need to solve existing problems, a
need to perform additional tasks, or an appearance of new
opportunities. The need or needs are organized and written
up by an analyst, along with proposed schedules, and sub-
mitted to decision-making personnel in the organization to
decide if resources will be allocated. At this stage, feasibility
studies are often commissioned to explore the potential effects,
and the proposed system’s scope is examined in light of exist-
ing structures. A baseline project plan is developed, customizing
the SDLC for the organization and specifying the time and
resources needed to complete the project. After the informa-
tion systems department has determined the possibility of
developing the system to address the defined issue in a cost- effective manner, the plan is presented to management for a decision.
After the first phase is completed, the systems analysis phase begins. The current system in place is studied, and potential alternative replacements are proposed. Each subtask and current procedure of the entire operation, from shipping to payroll to machine scheduling, is examined, and the subse- quent analysis is broken into subphases. The first subphase is determining the requirements for the replacement system, or what the users want and need from the system. This task is done through working with the users and evaluating all current systems that will be replaced or affected by the
replacement. The following subphase focuses on studying the requirements and organizing them into a logical structure based on interrelationships, eliminating any discovered redundancies, and creating alternative designs for compari- son purposes. Next, analysts compare the alternatives to see which best meets the proposed requirements within the cost, labor, and technological constraints on the project, and they make a recommendation based on this comparison.
The third phase is the systems design phase. The system selected for development is described in logical terms inde- pendently of the platform, and then it’s translated into the technology-specific details to be used in the system program- ming and construction. The logical design covers the business aspects, or functional units, of the organization, whereas the physical design is the actual specifications used in creating the functional system implementation. These specifications include the computer languages used to program the system software, the database systems and file structures, and the hardware and network platforms, as well as the client/server operating systems.
Once the specifications are completed, based on the logical
design parameters and the aforementioned constraints, the
fourth and final phase of the process—the systems implemen-
tation and operation phase—can begin. In the final phase of
the SDLC, the specifications are used to construct and install
the information system, which is then tested and put into
use. The process begins with coding, or writing the
programs that make up the backbone of the system. Other applications may be installed on top of these programs or alongside them, and at every step, testing—of both individual modules and the system as a whole—is conducted to find and correct errors as efficiently as possible. Because of the demands and issues that can arise from errors found at this stage of the SDLC, planning for this phase should begin as soon as possible.
Implementation also includes creating a user support structure, which consists of the finalized documentation, training programs, help desk, overall support structures, and feedback paths. Some of these are created during implemen- tation, but some of these features, such as documentation, are ongoing efforts from the beginning of the project and should be maintained with care throughout the project life- cycle. Other aspects, such as support, continue as long as the system is being used, so implementation can be consid- ered less of a phase and more an operational condition. As you can see, efficiently and effectively managing implementa- tion is vital.
As important as the implementation subphase is, the opera- tion aspect of the final phase is just as vital. Ongoing
maintenance, patches, and improvements based on changing
conditions and user feedback are necessary for a system to
remain useful and effective, so that it doesn’t become quickly
obsolete. While managing the previous phases of the SDLC
can go a long way toward making the operation subphase
effective and long-lasting, eventually any system is no longer
be able to function as it did, due to changing technology and
shifts in business processes. When a system reaches this
point, the SDLC cycle begins anew. Each phase of the SDLC
is tightly linked to the others, so careful planning and man-
agement is critical from the beginning. Project management
skills and best practices are as much a part of effective sys-
tems analyst work as the SDLC.
Alternative Approaches to Development
Although the SDLC is one of the best-established methods for system analysis and development, it’s not the only one. Other development methods have sprung up that approach the analysis and design process from other angles, and while this course focuses on the SDLC, exploring other approaches is highly recommended. These approaches include
n
Prototyping—Building a scaled-down functional version of the proposed system. This often involves using an auto- mated tool to create the screens, reports, and other parts of a user interface. When prototyping, the analyst builds a preliminary version of the proposed system and then has users work with the prototype and give feedback on what works and what doesn’t. Using the feedback, the analyst refines the prototype and repeats the user test- ing cycle until the users are satisfied with the model.
Prototyping has some clear advantages: it involves users in the analysis and design of a system, and it records the requirements in concrete form, rather than logical abstraction. It can also be used in supplementing the traditional SDLC.
n
Computer-aided software engineering tools—Software packages that provide automated support for certain aspects of systems development. By automating certain aspects of the development process and providing sup- port, computer-aided software engineering (CASE) tools simplify the process and provide discipline to the overall project. CASE tools also allow analysts and developers to access a repository—a centralized database of diagrams, forms, and reports; data definitions and structures;
process flows and other aspects of systems develop-
ment—to save effort and provide standardized methods
and components. Many CASE products are available,
and most suites offer diagramming tools, display genera-
tors to create sample user interfaces, analysis tools,
documentation tools, and code generators, in addition to
a central repository.
n
Joint application design—Joint application design (JAD) is a structured process that uses a series of intensive meetings between users, managers, and analysts to cre- ate or review system requirements. Pioneered by IBM in the 1970s, this method allows the interested parties to work together in creating system requirements over a short time, which provides more effective resource man- agement. It also has the benefit of increasing the chance that all interested parties understand the system’s func- tions and abilities. This approach is common in certain industries.
n
Rapid application development—A method created to reduce substantially the time used in designing and implementing information systems. Rapid application development (RAD) focuses on creating clear user requirements before developing system documents, and using the prototype as a working description of the sys- tem’s needs. This method has the advantages of creating and rebuilding working systems quickly—which is why many consulting firms use this approach—but certain development principles can easily be overlooked in the RAD process. The RAD process is designed to be more streamlined than the SDLC, with emphasis more on prototype development and parallel functions than on planning and design. Iteration is generally restricted to design and development, and RAD systems are usually created in isolation from other systems, meaning syn- chronization with existing systems and standards is limited.
n
Participatory design—A method that focuses on users and improving work experiences. The participatory design process originated in northern Europe, and it reverses the traditional North American command hierar- chy. Using participatory design (PD), systems analysts work for the users, and managers act as advisors rather than controlling the development process.
n
Agile Methodologies—Connected family of development processes, distinctive for abbreviated iterative cycles;
heavy testing; extensive input from users on establish-
ing, verifying, and prioritizing system requirements; and
a programming focus on small teams of highly capable, experienced programmers. This set of methods was developed in North America in the early 2000s and is based on the general principles of using adaptive tech- nologies (which changes with evolving conditions rather than focuses on a set of characteristics common to a defined problem), a focus on people, and a continuously adaptive process. Developed partly as a critique of com- mon engineering practices, Agile Methodologies are people-focused and have gained substantial cachet in many industries.
You should now read the assigned pages in your text- book. Then, return to this point and complete the
following Self-Check. If you answer any questions incor- rectly, review the material. Then, continue with the next section of this study guide.
Self-Check 1
At the end of each section of Structured Systems Analysis, you’ll be asked to pause and check your understanding of what you’ve just read by completing a “Self-Check” exercise.
Answering these questions will help you review what you’ve studied so far. Please complete Self-Check 1 now.
1. True or False? Operating system software is designed to process data and support users in an organization.
2. _______ is the extent to which subsystems depend on each other.
3. In which phase of the SDLC are alternative replacement systems proposed?
__________________________________________________________
4. In the context of system development, what does CASE stand for?
__________________________________________________________
Check your answers with those on page 81.
