Download The MIS Handbook - Businesses System II | MIS 420 and more Study Guides, Projects, Research Introduction to Business Management in PDF only on Docsity!
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: Deliverable SDLC Phases 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
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.,
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 Swimlane Owner represents ownership or assignment of an object Artifact an object involved in the system, such as a server or database Example –
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 grades in gradebook Record final grades Place completed gradebook in box Receive gradebook Record final grades on master Enter names of students into spreadsheet Enter grades into spreadsheet Create formulas to calculate final grades Print grade report and put in box Notify parents [No students failed.] [One or more students failed.]
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. 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 – Teacher Enter class list Record grade Finalize grade Edit grade View grade «uses» «uses»
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 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
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. 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 Description User(s) Home/Login Allows user to log in to system using username and password Displays any system status notices All Teacher Portal Create assignments and establish their point values Enter or edit student grades for each assignment View students grade in a variety of formats Teachers Student Portal View grades for each class by assignment or averaged for the quarter Students Parent Portal View grades for each child for each class by assignment or averaged for the quarter Parents Administration Create classes and assign teachers to the classes Enter and edit class lists View students grade in a variety of formats 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
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 Entity Key Attribute 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 Relationship symbolizes the relationship between two entities – e.g., one-to-many
Example – USER userid fname lname email password street city state zip hphone wphone cphone ENROLL userid roleid classid ITEM itemid classid name points description GRADE itemid userid pointsearned PARENT id user$userid fname lname email street city state zip hphone wphone cphone ROLE roleid role CLASS classid location time
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
Example – Module/ Test Case Brief Description of Test Case Expected Result Issues/Comments Pass Fail 1 1.1 X 1.2 X 1.3 X 1.4 X 1.5 X 2 2.1 X 2.2 X 2.3 X 2.4 X 2.5 X 3 3.1 X 3.2 X 3.3 X 3.4 X 3.5 X 4 4.1 X 4.2 X 4.3 X 4.4 X 4.5 X 5 5.1 X 5.2 X 5.3 X 5.4 X 5.5 X 6 6.1 X 6.2 X 6.3 X 6.4 X 6.5 X [Application Name] Unit Test Prepared by: Your Team
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 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.
