Mis Handbook

The MIS Handbook Your first task at your new job is to design a large application for a client. The good news is that you will be working with a team of developers. The bad news is that before your arrival, the client and the developers met, but the meeting ended abruptly when multiple parties stormed out. You have been asked to meet with the client to document business processes as part of the Analysis phase of the SDLC. Unfortunately, you have never heard of the SDLC. Your boss tells you to consult the Project Plan to find the due dates, but you do not know what that is either. You are starting to get the feeling that things are not going so well your first day on the job. About this time, you wish you had paid attention in your systems analysis and design class, rather than setting up your Fantasy Football league. You need the MIS Handbook. Quietly, you pull a beer-stained copy out of your briefcase…what a relief.

Introduction There are two processes to go through when performing systems analysis and design. The first process is Project Planning, which coordinates the activities among all members of the project team and the client. The second process is the Systems Development Lifecycle (SDLC), which specifies the phases in which the project should be tackled. The Project Planning process spans the entire SDLC. In other words, the processes are performed concurrently. The following graphic depicts the processes and how they work together: SDLC Phases Deliverable

Current State Analysis

Requirements Definition

Application Design

Application Development

Implementation

System Overview As-Is Use Cases As-Is Process Flows Known Issues List Project Plan* Risk Assessment I To-Be Use Cases To-Be Process Flows Signoff I Risk Assessment II Functional Design Write-up Site Map Interface Description Screen Prototypes Backend Description Database Design Signoff II Prototype I Prototype II Application Test Documentation Final Demonstration Knowledge Transfer Migration *The project plan is continuously updated and therefore spans multiple phases.

All deliverables for this course should exhibit the highest level of professionalism and will be evaluated as such. Deliverables should be free of typos, grammatically correct, delivered with a cover page, and just generally look sharp. Each deliverable is associated with either the Project

2 Planning process or a phase in the SDLC, and this document uses a mailbox ( ) to signal a deliverable. In order to better understand the processes associated with systems analysis and design, one should first understand the difference between a system and an application. To the lay person, the two terms seem interchangeable. An application is only the software portion of a system. A system includes the integration of people, processes, and technology (hardware and software) to accomplish a goal.

Current State Analysis The current state analysis phase involves collecting information about the current business processes and known issues. It is essential to gather all information before analysis starts. In consultation with the client, the following deliverables should be produced to document the current state analysis: • System Overview • As-Is Use Cases • As-Is Process Flows • Known Issues List

System Overview •

• •

The system overview gives background on the client and an overall description of the project. This document should include the business needs or problems currently faced by the client. In other words, the system overview is the resume for the project. It describes what the business has done in the past, what it is good and bad at doing, and what it wants for its future. Documentation Guidelines – Write-out the overview in one to two pages. Example – The local high school is interested in an online system that will keep track of students’ grades. The mission is to increase communication between students, teachers, and parents regarding grades. The school recently read a study that indicated that grade portals have been proven to achieve this mission. Teachers currently record grades for assignments, projects, and tests in the classic gradebooks purchased at teacher supply stores or in MS Excel worksheets. At the beginning of the quarter, teacher’s obtain the master class lists from the school secretary, which lists all of the students in their classes. The teacher then enters the names in either the gradebook or the Excel workbook. At the end of the quarter, the teacher fills out a grade report form for each class, indicating a grade for each student. It is a Scantron sheet, which is later scanned by the school secretary. At any point during the quarter, students request grade checks of the teacher, and the teacher either issues the grade check verbally or in writing. When parents are interested in students’ progress, they must contact the teacher directly. Issuing grade checks to students and parents has become very time consuming, taking away from time helping students.

As-Is Use Cases •

An As-Is use case is a list of high level functions currently performed in the system. The use case is constructed in conjunction with the client in a session similar to brainstorming – e.g.,

3

•

•

come up with all of the ways the system is used. As-Is use cases are general diagrams which are developed in greater detail in As-Is process flows (described next). The recommended type of diagram to record use cases is a UML use case diagram. Most of the diagrams presented in this document come from the Unified Modeling Language (UML). The UML provides diagrams for all steps in the SDLC. UML use case diagrams show actors, actions (use cases), and the relationships among them. The use case may well be the most famous of all the UML diagrams. Even MIS professionals who have not adopted other portions of the UML, often reference use case diagrams. The UML template in MS Visio may be used to create use case diagrams. UML Use Case Diagram Palette – Actor

a person or object involved in the system Actor

Use Case

Use Case

Relationship

connects an actor and a use case «uses»

Uses

«extends»

Extends

•

an action the actor will perform

demonstrates a relationship between two use cases in which the start point indicates the including use case and the end point (with arrow) indicates the included use case used to identify when a use case can optionally be extended by functionality in another use case; the start point indicates the extending use case and the ending point indicates the extended use case

Example – Create lectures

Develop assignments Teacher Grade assignments

As-Is Process Flows • •

As-Is process flows show the steps and decision points in the business processes. Of particular interest are the movement of information and materials in a business. One way to represent a process flow is with a diagram. The appropriate UML diagram for this deliverable is a UML activity diagram. An activity diagram represents a sequence of

4

•

actions and decision points. An enhanced version of the activity diagram places each activity in a “swimlane” to make clear which actor performs each activity. UML Activity Diagram Palette – Action State

Action State

an action taken in the flow

Start State

a beginning of a flow; only one start state can be used

End State

an end of a flow; any number of end states are allowed

Transition

indicates the control passing from one object to another

Decision Point

a condition

Fork

the beginning of parallel processes

Join

the integration of parallel processes Swimlane Owner

•

Swimlane

represents ownership or assignment of an object

Artifact

an object involved in the system, such as a server or database

Example –

5

Teacher

School Secretary

Request class list from school secretary

Make copy of master class list

Place class list in mailbox

Pickup class list

Write names of students in gradebook

Enter names of students into spreadsheet

Enter grades in gradebook

Enter grades into spreadsheet

Record final grades

Create formulas to calculate final grades

Place completed gradebook in box

Print grade report and put in box

[One or more students failed.]

[No students failed.]

Receive gradebook

Notify parents Record final grades on master

6

Known Issues List •

• •

Definition – Known issues are people, process, or technology-related topics that bother the client and/or that the client would like to see changed. Known issues may ultimately influence application design. A list of known issues can be the client’s “wish list,” “problem list,” or “FYI’s.” Documentation Guidelines – Compile and record the known issues during discussions with the client. The client will often sprinkle issues in during descriptions of business processes. Example – • • •

Some teachers have tried using specialized software to keep track of grades before, but they were disappointed with its lack of flexibility. Many parents would like to be able to receive weekly or monthly reports on their children’s progress throughout the quarter. The process of transferring schools is very difficult for all parties. The school’s staff would like ideas on how to make this process smoother and easier on everyone from a “paperwork” sense.

Project Planning As mentioned in the introduction, the Project Planning process continues throughout the SDLC and is not therefore a phase. Project Planning is introduced after learning about the business processes in the current state analysis and then regularly is revisited in subsequent phases. Project Planning facilitates communication among the team members and with the client. Without planning, the team will not know what direction it should be moving in. The following deliverables should be produced: • Project Plan (continuously updated in later phases) • Risk Assessment I (updated again in the design phase)

Project Plan •

•

•

The project plan is a map and timeline for the project. The project plan acts as a guiding document throughout the entire SDLC, and it is an integral tool for project managers. The project plan is a dynamic document. It should be revised and reviewed as often as the team designates, and the project manager should update the project plan regularly to reflect progress and changes. The recommended way to record a project plan is with a Gantt chart. A Gantt chart graphically lays out who, what, when, where and how for the entire project. All key deliverables and milestones associated with phases of the SDLC should be included. MS Project is the recommended tool to produce Gantt Charts. Using MS Project’s Project Guide (the wizard), the team can: o Plan and schedule the project's tasks o Build the project's team and assign people to tasks Gantt Chart Palette – Task

an individual work item required to complete the project

7

•

Deliverable

a tangible, verifiable outcome of work done to produce for a project; to be verifiable, the deliverable must meet predetermined standards for its completion

Milestone

an event to be tracked during a project

Resource

a person, piece of equipment, or material needed to complete tasks

Example –

Risk Assessment I •

• •

A risk assessment conveys the potential causes of project failure and the impact of such a failure to all parties involved. This information is extremely important and helps determine whether the project should start or continue. The risk assessment also exposes risks for the purpose of developing a mitigation strategy. This risk assessment should focus on: o Risks arising from team dynamics – e.g., team members not getting along. o Risks arising from the client – e.g., client cannot make decisions. In other words, a risk assessment describes what can go wrong and what can be done to stop things from going wrong. Documentation Guidelines – List the top risks that the team will potentially face during the project. Each risk should have a detailed description and should then be followed by an outline of the steps that will be taken to mitigate it. Example – Risks arising from team dynamics: • The team needs to develop a solid form of communication. • The team is not trained in documentation. Risks arising from the client: • Some of the client’s staff may need extensive training on the application. • There are many potential users for the application, which may complicate its focus. • The client currently does not have a central source of data.

Requirements Definition With a basic understanding of how the business currently operates, the team is ready to work with the client to develop requirements of how the business should operate. The requirements definition phase allows the team members to document client needs. First, identify high level needs and then work in the details necessary to support those needs. Later on, once the application is developed, it will be tested against the requirements developed here.

8 In meetings with the client, the following deliverables should be produced to document the requirements definition: • To-Be Use Cases • To-Be Process Flows • Signoff I

To-Be Use Cases •

• • •

A To-Be use case is a list of high level functions to be included in the application. The use case is constructed in conjunction with the client. To-Be use cases are general diagrams which are developed in greater detail in To-Be process flows (described next). To avoid scope creep, the team should work to narrow the application’s scope to meet the timeline of the project. The team should also suggest creative approaches to meet the client’s needs. Again, the recommended type of diagram to record use cases is a UML use case diagram. UML use case diagrams show actors, actions (use cases), and the relationships among them. The UML template in MS Visio may be used to create use case diagrams. UML Use Case Diagram Palette – see As-Is use cases Example – Enter class list

Record grade

Teacher

Edit grade

«uses» «uses»

View grade

Finalize grade

To-Be Process Flows •

•

To-Be process flows spell out the detailed steps involved in each use case. They describe in detail the triggers, inputs, outputs, and procedural steps that users must take in the use case. o Example triggers: parent phone call, request for final grades o Example inputs: student’s test grade, class list o Example outputs: report card, phone call to parents In other words, To-Be process flows show the sending and receiving of information and materials in a business. As mentioned previously, activity diagrams are used to record process flows, and these diagrams may be created with the UML template in MS Visio. In this deliverable, both primary and alternative activity diagrams may be created. Primary activity diagrams represent the flow when no errors are encountered. Alternative activity diagrams indicate what may go wrong and what happens if it does. For example, a primary activity diagram would show a user logging into an application with a correct username and password. An

9

• •

alternative activity diagram would show what would happen if the username and password were not correct. UML Activity Diagram Palette – see As-Is process flows Example – Ready to record grade

Select class

Select student

Select assignment

Enter points earned

View grade

[Failing grade] [Passing grade]

Notify parents via email

Save grade

Grade recorded

Signoff I •

After the deliverables for the requirements definition phase have been completed, the client should receive copies of all deliverables. After a specified amount of time, the client should either signoff on the document or request changes. The team makes the changes and then asks for the client’s signoff again. In other words, a signoff is the client’s “OK” on the project to date and permission to continue the project.

10

Application Design The preceding phases, current state analysis and requirements definition, focused on the complete system – people, process, and technology. The application design phase, by contrast, focuses exclusively on technology, more specifically just the software which supports the system. In the design phase the blueprints for the development phase (next phase) are drawn up, just as blueprints are drawn up for a house. The following deliverables should be produced during the application design phase: • Risk Assessment II • Functional Design Write-up • Site Map • Interface Description • Screen Prototypes • Backend Description • Database Design • Signoff II

Risk Assessment II •

• •

Risk assessment II performs two functions. First, it updates risk assessment I. What may have been considered risks previously may no longer be considered threatening, and conversely, new risks may have been identified. Second, risk assessment II introduces a new class of risks specifically associated with the application – e.g., insufficient software development skills, scope creep, and lack of development tools. Documentation Guidelines – List the top risks that the team will potentially face during the project. Each risk should have a detailed description and should then be followed by an outline of the steps that will be taken to mitigate it. Example – Updated risks arising from team dynamics: • The team’s work schedules have been conflicting due to personal issues.

•

The team has not pursued documentation training.

Updated risks arising from the client: • Some of the client’s staff may need extensive training on the application.

•

The client currently does not have a central source of data, but has hired data entry clerks to get them up to speed during the implementation phase.

Risks associated with the application: • The current scope of the application is too broad. • The application does not have a server for permanent storage.

Functional Design Write-up •

This deliverable is an overview of the modules that will be developed in the application. A module is logical grouping of application functionality – e.g., logon, record grades, etc.

11

• •

Ideally, modules are constructed so that they are reusable. This involves designing modules that are loosely coupled and therefore may be reused in other applications. Potentially, each use case smoothly transitions into a module. However, many use cases can also be incorporated into one module, or conversely, one use case may break down into multiple modules. In other words, this deliverable makes it clear to the development team how to break up the application. Documentation Guidelines – Some of the questions answered by this deliverable are: o From the requirements listing, how will the application be organized? o What requirements will be kept and what requirements will be left out? Example – Module Name Home/Login

Teacher Portal

Student Portal Parent Portal Administration

Description • Allows user to log in to system using username and password • Displays any system status notices • Create assignments and establish their point values • Enter or edit student grades for each assignment • View students grade in a variety of formats • View grades for each class by assignment or averaged for the quarter • View grades for each child for each class by assignment or averaged for the quarter • Create classes and assign teachers to the classes • Enter and edit class lists • View students grade in a variety of formats

User(s) All

Teachers

Students Parents School secretaries and principles

Site Map •

•

•

Definition – A site map is a graphical representation of the navigation in the application. Site maps assist in assuring that the site is well organized and therefore usable. In other words, a site map is literally a map of the application – screens are cities in the application and links are roads in the application. The recommended diagram to document a site map is a UML state diagram (formerly called a statechart diagram). It is a best practice to create a site map depicting all screens to be developed and how they will be linked. State diagrams may be constructed using the UML template in MS Visio. UML State Diagram Palette – State

State

represents a screen in the application

Transition

links two screen in an application

Start State

a beginning of a flow; only one start state can be used

End State

an end of a flow; any number of end states are allowed

12 •

Example –

Home Page

Parent Menu View Grades

Administrator Menu

Add users

Student Menu

Teacher Menu

Create assignments

Create classes

Record Grades

Interface Description •

•

•

This deliverable describes what the application will look like. Think about the user interface and the various input and output controls for the application. After reading this document, one should have a very clear picture of how this application will work from the user’s perspective. One may also collaborate with a visual designer to develop this section. In other words, the interface description should outline the look and feel for the application. Documentation Guidelines – Some of the questions answered by this deliverable are: o What technical functionality should be in the design (text boxes, buttons, hyperlinks, etc)? o How will users navigate the application? o How can usability be maximized? o What type of validation will it use? Example – The user interface will be designed very simply, using both words and pictures to describe links and menu items. Main navigation will be through a navigation menu on the left side of the screen. In order to increase usability, the screen will not be cluttered. Required fields will be validated as needed, and validation errors will appear in red next to the field.

Screen Prototypes •

A screen prototype is simply a picture of what the screens will look like. A screen prototype does not have any functionality. It should show the types of graphics/overall look and feel

13

• •

intended for the design layout of each type of screen. For example what will the home page look like? What will first level pages look like? What will second level pages look like, etc. Show at least one example at each level. In other words, make the interface description come to life. Documentation Guidelines – Using MS Visual Studio, construct a prototype for each screen in the application. Example –

Backend Description •

•

•

Definition – This deliverable is written from the information technology professional’s perspective and details the technical “backbone” that will be used to meet the application requirements. It should explain the types of technology that the team will leverage and how it will use them. In other words, the backend description describes what is going on “under the hood” as the application is being used. Documentation Guidelines – Some of the questions answered by this deliverable are: o What development languages, database, hardware platform, etc. will be used? o Why were they selected? Specifically how will these technologies be used to effectively meet the client’s requirements? o What type of security will it have? Example – The application will be developed in ASP.NET using a MS Access database. ASP.NET was selected because it is a web-based application, and MS Access was selected due to its flexibility and ease of use. The application will be based on a server at the client’s office and will be protected by a firewall.

Database Design • • • •

Definition – A database design is a graphical representation of the structure of tables, attributes, and relationships in the database. In other words, draw the plan for the database. The recommended way to document a database design is using an entity relationship diagram (ERD). ERDs may be constructed using the custom ERD template in MS Visio (see professor for details). Tool Guidelines – Create an ERD showing all tables and relationships in the database. Entity Relationship Diagram Palette – Entity Key Attribute

Relationship

Entity

persons, places, things, and events about which the application will collect and store information

Key

a unique piece of information about persons, places, things, and events

Attribute

a piece of information about persons, places, things, and events symbolizes the relationship between two entities – e.g., one-to-many

14 •

Example – PARENT id user$userid fname lname email street city state zip hphone wphone cphone

USER userid fname lname email password street city state zip hphone wphone cphone

GRADE itemid userid pointsearned

ENROLL

ROLE

userid roleid classid

roleid role

CLASS classid location time

ITEM itemid classid name points description

Signoff II •

After the deliverables for the application design phase have been completed, follow the same signoff procedure outlined in the requirements definition phase.

Application Development Working off the blueprints drawn up in the design phase, the application may now be coded. Students are sometimes surprised to see that most of the work in the SDLC occurs prior to coding. However, as in constructing a house, if the plans are correct from the outset, then time and money will not have to be spent later moving walls and patching holes. In fact, the market rewards analysis and design skills more than it rewards programming skills in the same way that architects and engineers earn more than laborers. Many students begin their first job as programmers and then move their way up to become systems analysts. The following deliverables should be produced to document the application development phase: • Prototype I • Prototype II • Application Test

15

Prototype I •

•

Finish constructing the screen prototypes begun in the design phase so that a complete set of screens is linked together. The screens are still not functional. The client is invited to preview the prototype in a walkthrough of the entire application. The goal is to demonstrate to the client that the team is making sufficient progress, is aware of the risks and issues present, and is taking steps to resolve them. In other words, the application looks complete but it still doesn't do anything. Documentation Guidelines – Using MS Visual Studio, construct a prototype for the remaining screens in the application.

Prototype II •

•

Add functionality to the first prototype to complete the application. In this walkthrough meeting, expectations will be much higher than Prototype I. The team should be essentially finished with development and in the midst of application testing. The focus of this meeting will be to discuss progress versus the project plan, issues that are being uncovered in application testing, and remaining work. In other words, finish the application. Documentation Guidelines – Using MS Visual Studio, code the functionality behind all the objects on the screen. Some coding may be done using built in tools and wizards, while other coding will have to be written out.

Application Test The application test deliverable consists of three types of testing.

Unit Test •

This initial stage of application testing is used to test the individual modules on a standalone basis. Each module should be thoroughly tested against its requirements.

Integration Test •

After testing each module individually, an overall test of the application is to be scripted and carried out. This test should be conducted with a representative sample of the client’s data. Issues should be documented and resolved to assure that all modules function in an integrated fashion, and all overall requirements are met.

Acceptance Test •

•

This final test involves turning the application over to the client for final testing and signoff. After an agreed upon amount of time, the client is to provide the project manager with a list of any issues. Upon their resolution, the client is to signoff that all requirements are met. In other words, the application test deliverable involves testing all aspects of the application before finalizing the development. The recommended way to record the application test is to use templates. Templates assure that exhaustive testing was performed and recorded in a consistent manner. Customized MS

16

•

Excel testing templates are available on the professor’s website and are depicted below. Any problems encountered during testing should be reported to the developers. Example –

[Application Name] Unit Test Brief Description of Test Case

Expected Result

Issues/Comments

Fail

Module/ Test Case 1 1.1 1.2 1.3 1.4 1.5 2 2.1 2.2 2.3 2.4 2.5 3 3.1 3.2 3.3 3.4 3.5 4 4.1 4.2 4.3 4.4 4.5 5 5.1 5.2 5.3 5.4 5.5 6 6.1 6.2 6.3 6.4 6.5

Pass

Prepared by: Your Team

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Implementation Implementation involves working the application into the larger system. The goal is to make sure that the application works from both a technical standpoint in the client environment and is accepted by the users. If this phase is not well executed, then users will abandon the application and return to old ways of doing business. Under pressure and close to a deadline, users will revert to what they know best unless they are well trained and have faith in the new application. The following deliverables should be produced to document the implementation phase: • Documentation • Final Demonstration • Knowledge Transfer • Migration

Documentation •

A thorough set of documentation is vital to the training and knowledge transfer process. The application’s documentation should include all necessary information for effective use. It serves as a daily reference for the client, as well as a tool for training new hires in the future. How to perform administration and maintenance functions should be included in the

17

•

documentation as well. In other words, the documentation deliverable describes everything about the application that the user will need to know. Documentation Guidelines – A table of contents should be included in the documentation, and illustrations should be used whenever possible – e.g. show screenshots.

Final Demonstration •

This deliverable involves giving a formal demonstration of the application the client and interested parties. This is the team’s chance to show off all of its hard work and leave a positive final impression. Be sure to emphasize the strengths of the application, concentrating on selling the solution to the business need or problem that it addresses. In other words, show how the team has solved the client's business problem and that the money was well spent.

Knowledge Transfer •

A knowledge transfer is a meeting with the team and the client during which a process of using the above materials to effectively train the client’s users, as well as administrators and other interested personnel, occurs. Anything they need to know about this application in order to use and maintain it should be transferred to them at this time. In other words, teach users how to use and maintain the application.

Migration •

If possible, the application should be moved to the client's production server and all existing data should be migrated to the new application. However, consult with the professor and the client to see if this deliverable is feasible and if so, how it should be accomplished.