The MIS Handbook - Businesses System II | MIS 420, Study Guides, Projects, Research of Introduction to Business Management

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 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., 5 School SecretaryTeacher 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.] 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 Deliverable a tangible, verifiable outcome of work done to produce for a project; to be verifiable, the 7 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 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. 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 11 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 12  Example – Home Page Teacher Menu Student Menu Administrator MenuView Grades Record GradesCreate classes Create assignments Add users Parent Menu  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 intended for the design layout of each type of screen. For example what will the home page 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 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. 16  Example – Module/ Test Case Brief Description of Test Case Expected Result Issues/Comments P as s F ai l 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. 17  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.