To date we have discussed:

What is systems analysis and what a systems analyst does, were they work, and the skills required

The different systems an organizations maintains

The views of information systems (owner, user, designer, builder)

The building blocks (Data, processes, interfaces, geography) and each stakeholder view of these blocks.

The importance of information systems in creating a competitive advantage for the organization

The chapter starts the SDLC process. But before we do that lets examine what we are providing, we are providing the organization a system and a product.

Service in the sense that is analysis will (hopefully) improve organizational performance and provide that competitive advantage.

Product as we will deliver the computer hardware and software that implements our design.

As such these services and products have a life cycle. For that matter all do with very few exceptions (nails)

The cycle goes like this

• Introduction
• Growth
• Maturity
• Decline

You must take this into consideration when selecting products or services for implementation as well as the phases of the life cycle process.

OK, lets examine how you build a system? This is accomplished through the SDLC. The SDLC is a logical process used to plan, execute and control a systems development project.

Confusion between the SDLC and a methodology

A methodology is the physical implementation of the logical life cycle that incorporates

• Step-by-step instructions
• Individual and group roles
• Deliverables and quality standards
• Tools and techniques to be used for each activity

Some important points

• A true methodology should encompass every stage of the SDLC
• Use several tools and techniques
• Most companies purchase
• Most companies benchmark

The book lays out what is termed the FAST methodology it is important to note that each organization may have their standard methodology. Whatever methodology is utilized it is important to remember why we use one.

• Provides a consistent and repeatable process to develop information systems
• People quit and move to management or onto bigger and better things

  Promotes/enhances the communication process

Now lets examine the eight underlying principles of systems development

Principle 1- Get the owners and users involved

How else can you know the business processes without involving them? YOU CAN'T.

Make sure you tell them up front that the success of the systems development rests on their involvement.

Principle 2- Use a problem solving approach. The classical approach is

• Study and understand the problem or opportunity
• Define the requirements of a suitable solution
• Identify candidate solutions and select the "best" solution.
• Design and/or implement the solution
• Observe and evaluate the solutions impact, and refine the solution accordingly.

Do not eliminate or cut short any of the above steps as you may:

• Solve the wrong problem
• Incorrectly solve the right problem
• Pick the wrong solution

Principle 3- Establish phases and activities

There are five phases to the classical SDLC (page 75)

• Systems planning
• Systems Analysis
• Systems Design
• Systems Implementation
• Systems Support

This chapter provides and overview of each phase.

Couple of things to keep in mind.

• In each phase the analysts and participates define and development the building blocks of the system from their views.
• Each phase is broken into activities and tasks that generally follow a top to bottom approach (sequential order); however, they may overlap.

Principle 4: Establish standards for consistent development and documentation.

Development for the same reasons of choosing a methdolology.

So standards describe

Activities

Responsibilities

Documentation guidelines or requirements

Quality checks

Anyone remember the PDCA or better known as the Shewhart cycle.

Documentation of the project (not just the program code)

Just when you need you memory the most it will fail you

Prevents you from looking incompetent.

Principle 5: Justify systems as capital investments

Two issues:

There are going to several solutions, don't accept the first one or the one you proposed. Remember, you're there to provide the best solution to the client not get yourself promoted (not a bad objective, however you are more likely to reach it by providing a service/product in which you are asked for by name from the client). In order working a knock your socks off service.

You can evaluate for a cost-effective solution that matches your client's requirements.

Principle 6: Don't be afraid to revise scope or cancel:

Remember some clients may expect too much and are not willing to pay for it. You're stakeholders (management will decide or you may need to decide) when to terminate and possibly lose the customer/client.

As the project advances costs may increase as you learn more about the system. You must establish checkpoints (PDCA) in the SDLC, usually at the end of each phase, but it could be before. Essentially all costs are considered "sunk costs" (meaning not recoverable). Management must give a go/no go at each of these checkpoints.

Principle 7: Divide and Conquer

• Super-system

• Subsystems

Principle 8: Design systems for growth and change

Remember the product life cycle discussed earlier

How any project gets started?

Planned- strategic plans, business plan, action plans or some other planning names. In other words someone somewhere took the time to identify a need for the organization.

Unplanned- well it kind of speaks for itself.

In any case a steering committee or someone (depending on the company) must authorize the expenditure of resources (money, manpower etc.) and these must be prioritized.

Generally a company hopefully has some sort of planning methodology that assists them in remaining competitive. This methodology hopefully identifies the external opportunities and threats and the internal strengths and weaknesses of the organization usually accomplished during an environmental scan of the strategic management process. Put in other terms a SWOT analysis.

The objective is to match up the strengths to take advantage of opportunities and minimize the threats. Further, it identifies areas that the organization must improve in order to take advantage of an opportunity or counter a threat.

Problems and/or opportunities will result from this analysis. Directives will be issued to do this or that and may become a problem within itself.

There is a useful framework for classifying problems and opportunities, directives. It is called PIECES

• Performance
• Information
• Economics
• Control
• Efficiency
• Service

Answer these questions and place them into a SWOT analysis matrix something like:

We will examine PIECES later and in more detail.

Whatever the method your final output is called a production system.

There are three data stores that you must be familiar with:

• Repository- stores documentation about the system (Required for your project) and contains written memos, reports, user requirements, screens, program and business flowcharts.
• Database- built during the project to identify actual business data about the entities. Not required for the project.
• Program library is where any applications software and programs will be stored once they are written.

Again this is only an overview.

 Look on page 83

• The rounded rectangles are phases
• Thick black arrows are major deliverables

• Thin ones are information/communication flows

• Rectangles are people who you interact with
• Circles are checkpoints (go/no go)

The FAST methodology consists of 8 phases.

• Survey
• Study
• Definition
• Configuration
• Procurement
• Design
• Construction
• Delivery

Key points

• Some are quicker than others
  • Time required depends on the strategy and risk
• They overlap as stated before

Looking at the rest of the chapter as it goes through each phase and identifies the purpose, participates and roles, prerequisites, activities, deliverables,

Post-requisites, impact analysis.

SURVEY PHASE- (2-3 DAYS MAX)

Purpose- answers the question "Is this project worth looking at?" It defines:

the scope

The perceived problems, opportunities, and directives that triggered the project.

Project team and participants

Executive sponsor- the highest level manager who will pay for the project.

Technical sponsor- the highest level manager from the information systems organization who will pay for the project.

Project managers- the managers of the project team. This person is responsible for the staffing, budget and schedule. They are from the organization and will jointly manage the project with the analyst.

Project initial budget

Project schedule

Prerequisites- a requirement

Activities-

• the most important is to define the scope
• the is the project worth the effort
• project plan

Deliverables

• Feasibility assessment and project plan (Initial Study Report)
• Analyst recommendations

• Quick fix
• Enhancement
• New system

• Define the scope for any of these recommendations

Owners checkpoint for next phase there are 4 possible decisions

• Approve the project
• Change the scope
• Reject the project
• Delay the project

Impact analysis- don't skip this phase as the project will fail

• Understand the business problem
• Are they worth solving
• Is the system worth developing

Participates and Roles

• Analyst facilitates
• System users are involved
• Business analysts may be used
• System owners visibility support the effort

Prerequisites

The project and system scope

Activities

• Learning the culture of the organization
• Possibility document the system (complexity issue)
• NOTE: What were identified, as problems may only be the symptoms of a larger problem.

Deliverables

• Business problem statement or feasibility analysis (sometimes called a detailed study report). For clarity use an updated feasibility assessment.
• A presentation should and most likely will be required.
• Define objectives (measurable, specific and time constrained) really serve two purposes.

• Evaluation criteria
• Focuses efforts

Post-requisites and feasibility Checkpoints

Go/no go

• Canceled if problems prove worth not solving
• Approved
• Reduced in scope or increased in budget and schedule and approved

Impact Analysis

• You must have an understanding of the system
• Should be quickly finished as possible
• If this was a planned project you may want to limit your analysis to understanding the system

3. THE DEFINITION PHASE

Purpose

• To identify the DATA, PROCESS, INTERFACE and GEOGRAPHY requirements for the users of a new system.
• Keep it at the business level do not introduce technology or computer alternatives.

Participates and Roles

• Analysts facilitate the definition and prioritization of business requirements.
• System users are essential is identifying processes and clarification information is collected:

• Interviews
• Questionnaires
• Facilitated meetings

• Flowchart a process out the way you understand it then take it to the user. See what the differences are.

Prerequisites

Approved statement of systems objectives

Activities

• Identification of the business requirements as seen by system users in the DATA, PROCESS, INTERFACE and GEOGRAPHY building blocks.

• Model the system
• Prototyping -I know it when I see it

Prioritize requirements

Classified into 3 categories

• Mandatory
• Desirable
• Optional

Deliverables

Business requirements statement

Post-requisites and feasibility Checkpoints

• Project could still be cancelled but not likely
• Schedule and budget will be adjusted
• NOTE: Time boxing- gets the system operational with updates provided at certain time intervals.

Impact Analysis

Without defining business needs you have done nothing for the customer. Don't get caught up with the technical issues.

• Identify candidate solutions
• Analyze those solutions
• Recommend a target system for design and implementation
• Determine make or buy

Participates and Roles

• System analyst facilitates or application architecture manager
• All owners and users
• Designers

Prerequisites

• Business requirement specifications
• Not detailed they identify

• Inputs
• Outputs
• Databases
• Key functions
• Programs

NOTE: This may have started before the end of the definition phase.

Activities

• First time the system designer perspective was viewed.
• Define candidate solutions
• Evaluate each candidate on the following

• Technical feasibility
• Operational feasibility
• Economic feasibility
• Schedule feasibility

Recommend a candidate

Deliverables

A formal system proposal to system owners. Written and verbal.

Post-requisites and feasibility Checkpoints

• Approved and fund
• Approve and fund one of the alternative systems
• Reject all
• Approve a reduced scope

Impact Analysis

This phase is not always required

• Research the information technology marketplace
• Solicit vendor proposals
• Recommend to management one that meets their requirements
• To identify the time lag between order and delivery

Participates and Roles

• System analyst facilitates
• Information technology vendors
• Users
• owners

Prerequisites

Business requirements from the definition phase

Activities

• Research the marketplace (periodicals and services)
• Information tech vendors
• Organize the business, technology, and relative requirements and establish the mechanisms that will be used to evaluate the technical alternatives.

• Request for Proposal

Deliverables

Technology proposal to system owners to acquire specific hardware and software

Post-requisites and feasibility Checkpoints

• A commercial application that meets all user needs (turn-key system
• No-decision in which case a custom solution is used
• Cancelled project (Doubtful)

Impact Analysis

Optional based on the make/buy decision

• Transform business requirements into a set of technical design blueprints for construction.
• RAD

Participates and Roles

• System analyst facilitates
• Database specialists
• Network specialists
• Computer specialists
• GUI specialists
• System users

Prerequisites

• Business requirements from the definition phase
• Design requirements from the configuration phase

Activities

• Prototyping

• Go through a series of iterations until they evolve into an acceptable design. Going something like this

• Define the base level scope of the first verision
• Define, design, and construct the database (ONLY)
• Define, design, and construct the inputs (ONLY) repeat steps 1-3 until users are satisfied.
• Define, design, and construct the outputs (ONLY) repeat steps 1-2 and 4 until users are satisfied.
• Define, design, and construct the interface. Repeat all steps as necessary
• Design and construct any missing system controls such as security, backup, recovery
• Go to step 1 to begin the RAD cycle for the next version of the system.

The basic idea to RAD is:

1.  get the user involved

2.  accelerate the definition/design/construction processes

3.  reduce the amount of time that passes before the users see a working system

Deliverables

• a technical set of design specifications.
• Database structure
• Structure of the overall application
• Overall look and feel of the user interface
• Structure of the computer network
• Design structures for any complex software to be written

Post-requisites and feasibility Checkpoints

At this point rarely cancelled

Impact Analysis

This phase cannot be skipped

• To build and test the system
• To implement interfaces between the new and old system

Participates and Roles

• System analyst facilitates (lesser degree)
• Database programmers
• Network administrators
• Application programmers
• System users

Prerequisites

Design requirements from the configuration phase

Activities

• Construct the database
• Application programs
• User and system interfaces
• networks

Deliverables

A functioning system; prototypes withstanding which cycles back through the design and defintion phases until a final functional system is acceptable.

Post-requisites and feasibility Checkpoints

The prototype may be implemented

Impact Analysis

This phase cannot be skipped

to install the system

Participates and Roles

• System analyst facilitates
• Entire project team

Prerequisites

Functional system

Activities

• Considers the system builder perspective
• Tests are conducted to ensure system is working properly
• How the new system will be converted

  Abrupt cutover- old system stopped, new one started

  Parallel conversion- both new and old are in operation for some period of time

  Location conversion- location specific

  Staged conversion- each successive version of the new system is converted as it is developed using one of the above factors

• Training individuals
• Developing documentation to aid users
• Post audit

Deliverables

• The production system
• Training and support

Post-requisites and feasibility Checkpoints

Project is complete

• Documentation and Presentations
• Estimation and measurement
• Feasibility analysis
• Project and process management

• Upper case- support the survey, study, definition and design phases (ProCap AIOWin)
• Lower case- detailed design, construction and delivery (and support) phases (Powerbuilder)