Systems Analysis and Design/Introduction

Information Systems Analysis and Design-Development Life Cycle

Businesses and organizations use various types of information systems to support the many processes needed to carry out their business functions. Each of these information systems has a particular purpose or focus, and each has a life of its own. This “life of its own” concept is called the systems development life cycle or SDLC, and it includes the entire process of planning, building, deploying, using, updating, and maintaining an information system. The development of a new information system involves several different, but related activities. These activities, or phases, usually include planning, analysis, design, implementation, and maintenance/support. In other words, SDLC is a conceptual model that guides project management in information system development.

According to author Harold Kerzner, Ph.D. there are sixteen points that will lead to project management maturity:

1. Adopt a project management method and use it consistently.
2. Implement a philosophy that drives the organization toward project management maturity and communicate it to everyone.
3. Commit to developing effective plans at the beginning of each project.
4. Minimize scope changes by committing to realistic objectives.
5. Recognize that cost and schedule management are inseparable.
6. Select the right person as a project manager.
7. Provide executives with project sponsor information and not project management information.
8. Strengthen involvement and support of all appropriate management.
9. Focus on deliverables rather than resources.
10. Cultivate effective communication, cooperation, and trust.
11. Share recognition for project success.
12. Eliminate nonproductive meetings.
13. Focus on identifying and solving problems early, quickly, and cost effectively.
14. Measure progress periodically.
15. Use project management software as a tool; Not as a substitute for effective planning or interpersonal skills.
16. Establish an all-employee training program with periodic updates based upon documented lessons learned.

Information Security in the Systems Development Life Cycle

As NIST (National Institute of Standards and Technology) points out, including security early in the SDLC will usually result in less expensive and more effective security than adding it to an operational system. The following questions should be addressed in determining the security controls that will be required for a system:

• How critical is the system in meeting the organization's mission?
• What are the security objectives required by the system, e.g., confidentiality, integrity, and availability (CIA)?
  • Confidentiality refers to limiting access to information to authorized users only-- "the right people" -- and preventing access by unauthorized ones -- "the wrong people."
  • Integrity refers to the trustworthiness of information resources. It includes the concept of "data integrity" -- namely, that data have not been changed inappropriately, whether by accident or deliberately malign activity. It also includes "origin" or "source integrity" -- that is, that the data actually came from the person or entity you think it did, rather than an impostor.
  • Availability refers to the availability of information resources. An information system that is not available when you need it is almost as bad as none at all.
• What regulations and policies are applicable in determining what is to be protected?
• What are the threats that are applicable in the environment where the system will be operational?

Incorporating Security Into The SDLC (NIST Special Publication 800-64 Revision 2))

This section describes a number of security considerations that will help integrate information security into each phase of the SDLC.

Planning

During this first phase of the development life cycle, security considerations are key to diligent and early integration, thereby ensuring that threats, requirements, and potential constraints in functionality and integration are considered. At this point, security is looked at more in terms of business risks with input from the information security office. For example, an agency may identify a political risk resulting from a prominent website being modified or made unavailable during a critical business period, resulting in decreased trust by citizens. Key security activities for this phase include:

• Initial delineation of business requirements in terms of confidentiality, integrity, and availability;
• Determination of information categorization and identification of known special handling requirements to transmit, store, or create information such as personally identifiable information; and
• Determination of any privacy requirements.

Analysis

This section addresses security considerations unique to the second SDLC phase. Key security activities for this phase include:

• Conduct the risk assessment and use the results to supplement the baseline security controls;
• Analyze security requirements;
• Perform functional and security testing;
• Prepare initial documents for system certification and accreditation;

Although this section presents the information security components in a sequential top-down manner, the order of completion is not necessarily fixed. Security analysis of complex systems will need to be iterated until consistency and completeness is achieved.

Design

During this phase of SDLC, the security architecture is designed.

Implementation

During this phase, the system will be installed and evaluated in the organization’s operational environment. Key security activities for this phase include:

• Integrate the information system into its environment;
• Plan and conduct system certification activities in synchronization with testing of security controls; and
• Complete system accreditation activities.

Maintenance/Support

In this phase, systems are in place and operating, enhancements and/or modifications to the system are developed and tested, and hardware and/or software is added or replaced. The system is monitored for continued performance in accordance with security requirements and needed system modifications are incorporated. The operational system is periodically assessed to determine how the system can be made more effective, secure, and efficient. Operations continue as long as the system can be effectively adapted to respond to an organization’s needs while maintaining an agreed-upon risk level. When necessary modifications or changes are identified, the system may reenter a previous phase of the SDLC. Key security activities for this phase include:

• Conduct an operational readiness review;
• Manage the configuration of the system ;
• Institute processes and procedures for assured operations and continuous monitoring of the information system’s security controls; and
• Perform reauthorization as required.

Disposal Usually, there is no definitive end to a system. Systems normally evolve or transition to the next generation because of changing requirements or improvements in technology. System security plans should continually evolve with the system. Much of the environmental, management, and operational information should still be relevant and useful in developing the security plan for the follow-on system. The disposal activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future, if necessary. Particular emphasis is given to proper preservation of the data processed by the system so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies for potential future access. Key security activities for this phase include:

• Build and Execute a Disposal/Transition Plan;
• Archive of critical information;
• Sanitization of media; and
• Disposal of hardware and software.

SDLC Phases

Planning

Planning the system requires the user to define what the problem is. The planning may also include how the user would like to solve the problem. Defining the scope of the problem is also important in this stage as well. Defining the scope helps to prevent the project from scope creep. Once the problem is determined, and one or more solutions have been selected, planning to implement the solution begins. Multiple scenarios may be enacted to determine the best course of action for implementing the system.

Course of action should be well documented and take into consideration a schedule showing anticipated start and completion times of activities (milestones) leading to the objectives, knowing expenditures required to achieve objectives, scheduling regular status reviews (are we on course?), anticipating any organizational restructuring to accommodate the objectives, anticipating and planning for mitigation of risks that may hinder achievements, implementing policies and procedures for decision making, and defining a standard level of performance.

Within the planning according to the John Sazinger "five of the main activities must exist" as he explain in his book the fives activities should include:

• Define the problem
• Produce the project schedule
• Confirm project feasibility
• Staff the project
• Launch the project

Why do plans fail? Some of the many reasons are:

• Goals/specifications are not understood.
• Objectives are too extensive for the time allotted.
• Budgets were not accurate.
• Project is understaffed or under skilled.
• Status reviews were not scheduled or insufficient.
• Poor morale (no commitment).

One of the most difficult decisions in planning is to know when to pull the plug on a project. This will require an effective control and monitoring system. If you cannot monitor a system you cannot control it. No organization wants to admit failure but there may come a point when a project can no longer be salvaged. This is especially critical with Information Technology projects because of rapidly changing technologies. Most managers are reluctant to prematurely terminate a project as careers and egos are at stake. The fallacy of sunk costs may play a role as well. The result is that projects continue beyond the point of no return. To avoid this problem, monitor and control systems must be put in place early during the planning stage. It is critical to define and enforce milestones where a project will be terminated if necessary. A saving grace is that because a project is terminated it doesn't make it a complete failure. Excessive cost are saved for the organization and management can walk away with lessons learned that can be applied to the next project. In general there are two types of monitoring "INFORMAL" and "FORMAL". Informal are typically general meetings, email, and observing. The formal include status reports, scheduled milestones, audits, reviews, and benchmarks. The formal reviews are generally more costly and are used during system development processes. Both systems can be used in combination and involve the questions: "what performance metrics to use" and "how often do reviews occur"? Attention and energy must be focused on identifying and correcting out-of-control processes.

Analysis

The analysis phase involves gathering requirements for the system. At this stage, business needs are studied with the intention of making business processes more efficient. The system analysis phase focuses on what the system will do in an effort that views all stakeholders, as viable sources of information. In the analysis phase, a significant amount of time is spent talking with stakeholders and reviewing the stakeholder’s input. Common stakeholders for IT projects are:

• Architecture office
• Testing & certification office
• Records management team
• Application support group

Once stakeholders have been recognized, the gathering and analysis of the requirements can begin.Requirement gathering must be related to business needs or opportunities. Requirement analysis involves capturing requirements and analyzing requirements. Capturing requirements is communicating with stakeholders to agree on what the requirements are. Analyzing requirements is using standard tools to produce a baseline of the requirements. Once the stakeholders concur on the requirements, the baseline is created and becomes the formal requirement source.

Within this analysis phase, the analyst is discovering and fact finding. Along with meeting with stakeholders,the analyst must meet with end users to understand what the user's needs are and to learn about problems that affect the current system in order to assist with designing a new and more efficient system. There are several activities that must occur within the analysis phase:

• Gather Information
• Define the new system's requirements
• Build prototypes for the new system
• Prioritize requirements
• Evaluate alternatives
• Meet with management to discuss new options

Design

The design phase is concerned with the physical construction of the system. Included are the design or configuration of the network (hardware, operating system, programming, etc.), design of user interfaces (forms, reports, etc.), design of system interfaces (for communication with other systems), and security issues. It is important that the proposed design be tested for performance, and to ensure that it meets the requirements outlined during the analysis phase. In other words, the main objective of this phase is to transform the previously defined requirements into a complete and detailed set of specifications which will be used during the next phase. Some of the activities that need to take place during the design phase are:

• Design the application
• Design and integrate the network
• Design and integrate the database
• Create a contingency plan
• Start a Maintenance, Training and Operations plan
• Review the design
• Articulate the business processes and procedures
• Establish a transition strategy
• Deliver the System Design Document
• Review final design

Implementation

Initiating a project first requires the documenting of needs or requirements. Clear objectives should be developed from this study with reasons for selecting the objectives. Deliverables then need to be documented along with the project scope. Scope can be refined during this initialization process. Assumptions and constraints should also be documented. All stakeholders should be involved in this process. This information will become the projects charter and the basis for initiating the project. The project then follows the PLAN-DO CHECK-ACT cycle (as defined by Shewhart and modified by Deming, in the ASQ Handbook, pages 13-14, American Society for Quality, 1999). The results of each cycle will be linked to the next as input. This process should increase the likelihood of deliverable acceptance.

In order to achieve deliverable of acceptance and meeting of objectives, the new system being built must be tested. Aligned with this, the end users must be fully trained so the company will benefit from the new system. There are five activities that must be performed during the implementation phase:

• Construct software components
• Verify and test
• Convert Data
• Training end users and document the system
• Install the system

Maintenance/Support

Maintenance and support covers all activities that are required once the system is in place. Activities include, but are not limited to:

• Phone support for users
• Physical onsite user support
• Resolving any issues that may arise with the new system
• Providing support materials/tools for users

The amount of support required may be determined based on the system. If it is a large system involving many different departments, maintenance and support may be needed for a longer time. If is a smaller system, maintenance and support may only be needed for a short time.

Systems Development Methods

This section discusses the most popular methods for developing computer-based information systems. A popular, traditional method is called structured analysis, but a newer strategy called object-oriented analysis and design also is used widely. Each method offers many variations.Some organizations develop their own approaches or adopt methods offered by software vendors or consultants. Most IT experts agree that no single, best system development strategy exists. Instead, a systems analyst should understand the alternative methods and their strengths and weaknesses.

Structured Analysis

Structured analysis is a traditional systems development technique that is time-tested and easy to understand. Because it describes the processes that transform data into useful information, structured analysis is called a process-centered technique. In addition to modeling the processes, structured analysis includes data organization and structure, relational database design, and user interface issues. Structured analysis uses a series of phases, called the systems development life cycle(SDLC) to plan, analyze, design, implement, and support an information system. Structured analysis relies on a set of process models that graphically describe a system. Process modeling identifies the data flowing into a process, the business rules that transform the data, and the resulting output data flow.

Basically, the structured analysis technique requires that the developer defines three things: 1) what processing the system needs to do, 2) what data the system needs to store, and 3) what inputs and outputs will be needed in order for the system to work as a whole. In order to see how all these functions work together, the data flow diagram (DFD) is needed to show the inputs, processes storage, and outputs.

Object-Oriented Analysis

Whereas structured analysis regards processes and data as separate components, object-oriented analysis combines data and the processes that act on the data into things called objects. Object-oriented analysis defines the different types of objects that are doing the work and interacting with one another in the system and by showing user interactions, called use cases, are required to complete tasks. Systems analysts use O-O methods to model real-world business processes and operations. The result is a set of software objects that represent actual people, things, transactions, and events. Using an O-O programming language, a programmer then transforms the objects into reusable code and components.

O-O analysis uses object models to represent data, behavior, and by what means objects affect other objects, By describing the objects(data) and methods (processes) needed to support a business operation, a system developer can design reusable components that allow faster system implementation and decreased development cost. Many analysts believe that, compared with structured analysis, O-O methods are more flexible,efficient,and realistic in today`s dynamic business environment. The object-oriented approach has many benefits, they provide naturalness and reuse. The approach is natural because people tend to think about things in terms of tangible objects and because many systems within an organization uses the same objects (i.e. windows, dialog boxes, menus, and buttons) the classes can be used repeatably. Also, O-O analysis provides an easy transition to popular O-O programming languages, such as Java and C++.

Other Development Strategies

In addition to structured analysis and O-O methods, there are other systems development techniques created by individual companies.For example, Microsoft has developed an approach called Microsoft Solutions Framework(MSF).Using MSF, you design a series of models, including a risk management model, a team model, model has a specific purpose and outputs that contribute to the overall design of the system.Although the Microsoft process differs from the SDLC phase-oriented approach, MSF developers do the same kind of planning,ask the same kinds of fct-finding questions,deal with the same kinds of design and implementation issues, and resolve the same kinds of problems. MSF uses O-Oanalysis and design concepts, but also examines a broader business and organizational context that surrounds the development of an information system.

Ad Hoc

Ad hoc, is something that one can use to do a specific task but the process that was used cannot be used for another process. It's like doing some work on the fly no major planning is required. The whole project cannot run at that level. One can use a template to create a project but with Ad Hoc, it is not possible. As whole the term "Ad hoc" means for this purpose only.

Structured / Waterfall

The waterfall model is a popular version of the systems development life cycle approach that is considered farthest to the left on the predictive/adaptive scale for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model (mostly predictive) describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Once a phase of development is completed, the development proceeds (drops over the waterfall) into the next phase and there is no turning back.

The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. This pure waterfall model makes it very difficult because there is no room for error and that is virtually impossible when dealing with humans.

However, on the right side of the predictive/adaptive scale we are able to make modifications in different phases; this is called a modified waterfall model. In the modification waterfall model, phases of projects will overlap influencing and depending on each other. For instance, if the analysis phase is completed and the project moves into the design phase but something was left out in the requirements in the analysis phase making it hard to implement in the design phase then additional project management tasks need to be added causing an overlap.

Efficiency is another reason why overlapping might occur. Some activities depend on the results of prior work. In the project planning phase, there might be some additional project management tasks that need to be added, in the analysis phase, additional analysis activities may be added, and in the design phase, additional design activities may be added. Basically, the modified waterfall model is a more efficient model to use. Today, many information systems and projects are based on the modified waterfall model.

Prototyping

Prototyping is the process of building a model of a system. In terms of an information system, prototypes are employed to help system designers build an information system that is intuitive and easy to manipulate for end users. Prototyping is an iterative process that is part of the analysis phase of the systems development life cycle.

During this analysis phase, prototyping usually referred to as the discovery prototypes are very important because it is geared for understanding the users’ needs. The prototypes are not built for full functionality but are built to see if the prototypes are feasible for what goals the business is trying to achieve. Sometimes, end users are trying to improve on the business processes or simplify a procedure. In any case, by using trial reports and screens will help analysts explain to end users’ how this can update and improve their business procedures. If the business decides to implement new technology, then discovery prototyping can help with whether to implement the new technology and to see if it will align with or will be feasible to the company’s business need.

Prototyping comes in many forms - from low tech sketches or paper screens(Pictive) from which users and developers can paste controls and objects, to high tech operational systems using CASE (computer-aided software engineering) or fourth generation languages and everywhere in between.
Advantages of prototyping include;

• Reduction of developments time and cost
• User involvement
• Quantifiable user feedback
• Facilitates system implementation
• Higher user satisfaction
• Exposure to potential future enhancements for developers

On the other hand disadvantages include;

• Insufficient analysis
• Expectation of ultimate system performance to be the same as the prototype by users
• The temptation of implementation before the final product
• Attachment to prototypes by developers
• Incomplete documentation

The best reason for prototyping is that it lets a programmer work with a client so that the system will satisfactorily meet the client's expectations. However this is a double edge sword. The problem is that most of the time a protype is a clunky, quick approach to solving a problem that will most often need major reconstruction and most programmers are hesitant at best to throw away their code for a new stream line approach. Consequently you end up with code associated with patch after patch that is difficult to maintain. Also the give and take with the client during prototyping may lead to scope creep within the project. Every time you think you are finished there will be some improvement or new functionality suggested. This will stop any sign off on the project. To avoid this make sure that there is a project plan with a noted number of iterations specified and a cut off date for adding new functionality.

Incremental/Iterative

Incremental approach is dividing the project in various [as much as possible] independent parts and developing these sub-parts at the same rate/ different rate and integrating them when ready. Example is development of a social networking website with parts like member registration, sign in, forgot password, member profile, search members, friends list, blog, blog search, photos, photo search and messaging. Depending on the product owners requirements, development team can start with member registration, sign in, member profile and search members.These can be completed and integrated into a common repository as they become ready. Once these parts are ready, next set is picked. It is also possible that all the parts can be simultaneously worked on and integrating them when ready in the central repository.
According to Alistair Cockburn, Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system.

Spiral Model

The spiral model is one of the newer adaptive approaches to the SDLC. Basically, an adaptive approach is a development approach which will include project activities such as plans and models that are adjusted as the project progresses. The spiral model includes several adaptive features that will cycle over and over through the development of the project until the completion of the project.

The spiral life cycle is shown as a spiral model that begins with the planning phase first from the center (inward) of the spiral, eventually working its way outward, over and over again, until completion of the project. The planning phase will include activities such as feasibility study, a survey of user's requirements, overall design choice, generation of implementation alternative, and implementation strategy. The purpose of this phase is to have enough information to build a prototype.

Rapid Application Development (RAD)

Rapid Application Development makes use of tools to facilitate the development of systems to meet aggressive time lines. [1] The key emphasis is to reuse the created working models [prototypes/ models/ user interfaces/ wire-frames] [2] Key objective is to reduce the time spent on analysis, this is achieved by use of working models for design

Modeling

Modeling promotes better understanding of requirements. Visual Modeling helps us understand and organize complex endeavors. Notation plays an important part in any model. It has been said that if you can not document the artifacts of your work, you will probably fail. The Unified Modeling Language (UML) provides a very robust notation, which grows from analysis to design. It is a language used to specify, visualize, and document the artifacts of an object-oriented system under development. You can model just about any type of application running on any type of hardware, operating system, programming language, and network with UML. It is a natural fit for Oject-Oriented languages and environments but you can use it to model non Object-Oriented applications as well.

Object-Oriented Development

Before coding, there should be a understanding on pseudo, algorithm and the high level language(C, C++, C#, Java, etc.) you want to make use of. This will aid you to designing a system for a specific purpose. Modern programming usually requires an object oriented approach to software development. Object-oriented development attempts to use the classifications, relationships, and properties of objects to aid in program development. The object can be any item or concept. The objects contain both attributes and operations that interact to meet a specific need. Attributes are properties that relate to the object and operations are methods or actions that the object can perform to modify itself or data. Access to the data within an object is available only via the objects operation also known as the interface to the object. An object's functionality is bound to the data it uses. You can easily alter the details controlling how the object is implemented to improve performance , add new features, or fix bugs without changing the interface. This allows the other parts of the project to access the object and remain unaltered.

Overview

This book is organized in 5 major units:

• Planning
• Analysis
• Design
• Implementation
• Maintenance/Support

Questions

What are the categories of technology requirements of an information system?