Sa handout full by Prisma Dominatus

Page 0 of 133

2014 SYSTEM ANALYSIS AND DESIGN

(Image credit) Sauter, V. L. (2011, January 15). Random (Humorous) Thoughts on Information Systems Analysis -- What We Do . Retrieved from Humor in Systems Analysis: http://www.umsl.edu/~sauterv/analysis/random_analysis_thoughts.html

Jirapon Tanasanti Silpakorn University Page | 0 8/14/2014

System Analysis and Design [436 303]

FORWARD Dear arts students Have you tired of working hard all the time, only to work extra hard when the final exam draws near, then fail to deliver the result? If you have never experience such a torture, I would be very surprise. Anyhow, this course will introduce you to various methods to prevent such “Final-Rush”. System Analysis and Design course (436 303) is a course which teaches you system development life cycle (SDLC). Originally, it is meant for software, or computer related, project development. It allows students to understand necessary steps for doing projects. Students will learn to use tools for doing project plan, analysis and design. This course also features a team project which will put students’ knowledge and skills to a test. This document is a handout for 436 303 System Analysis and Design course, aimed for registered students. Information written in this handout is intended to be studied in combination with class lecture. So, if you have questions, attend the class and ask away!

System Analysis and Design [436 303]

TABLE OF CONTENTS Course introduction ..............................................................................................................1 Why should you learn system analysis and design? ...........................................1 Where to learn more? .................................................................................................2 Course and teaching policy........................................................................................3 Quiz and more quiz .....................................................................................................3 Term paper.....................................................................................................................4 System Development Life Cycle (SDLC) .........................................................................5 Planning ...........................................................................................................................6 Analysis ............................................................................................................................8 Design...............................................................................................................................9 Implementation ......................................................................................................... 10 Support......................................................................................................................... 12 Advantage / Disadvantage of traditional SDLC .................................................. 14 CASE Tools ........................................................................................................................... 17 Planning ................................................................................................................................ 22 Project planning using Gantt chart ........................................................................ 22 PIECES ........................................................................................................................... 28 Feasibility study.......................................................................................................... 33 Analysis ................................................................................................................................. 38 Requirement gathering ............................................................................................. 38 Requirement analysis................................................................................................ 43 Requirement documentation ................................................................................. 45

System Analysis and Design [436 303] Design .................................................................................................................................... 47 Data modeling using ERD ......................................................................................... 47 Process modeling using Data Flow Diagram ....................................................... 52 Process modeling using Flow chart ...................................................................... 58 Process modeling using Sequence diagram........................................................ 61 System design using Use Case diagram ............................................................... 65 Mockup User Interface ............................................................................................. 69 System design using Class diagram ....................................................................... 71 Implementation .................................................................................................................. 79 Water fall model ........................................................................................................ 79 Iterative method ........................................................................................................ 82 Spiral method ............................................................................................................. 84 Rapid Application Development (RAD) ................................................................ 87 Agile method (with Scrum)...................................................................................... 94 Case study.......................................................................................................................... 104 London Ambulance Service.................................................................................. 104 Conclusion ......................................................................................................................... 109 Bibliography ....................................................................................................................... 110 Appendix I Product backlog example ....................................................................... 113 Appendix II LAS case study............................................................................................ 122

System Analysis and Design [436 303]

COURSE INTRODUCTION System analysis and design course introduces students to the world of information system development. This course features system development life cycle and various tools to do system analysis and designs. Students will learn to draw a variety of diagrams and documents. Students will learn about various project management methodologies such as water fall model and agile development which will enable students to be manage their project better. This course also introduce students a new job opportunity for System Analyst. System analyst or, in short, SA is a key person who link all experts to the user and customer. It is SAâ&#x20AC;&#x2122;s job to gather system requirements from the user, analyze those requirements and work together with programmers and other specialists to design and implement a system. SA then bring the finished product to the customer and present it. SA is usually considered front-line specialist who operate with user and back-end specialist. SA is the middle man who takes credits for a job done well and blame for a job not-very-well done. With such challenge and responsibility, SA is usually a very well-paid job. It is an essential role for software companies.

WHY SHOULD YOU LEARN SYSTEM ANALYSIS AND DESIGN? Information technology improves efficiency of works by systematizes them, so that anyone can work efficiently within the system, digitizes them, so that works can be finished with minimal resources and errors. However, most works do not simply systematize themselves. This is where a system analyst or SA comes in. This person analyzes the work and make a system out of it. Then the system design is handed over to an implement team of programmers. Therefore, SA is the person who starts the process. System analysis and design course discuss about SA job, of what to do and how to do it. Page |1

System Analysis and Design [436 303] Say, students are not fancy being an SA. There are other benefits that system analysis and design course can give you. Once such benefits is the knowledge of project planning. If any students refuse that they have never had an experience of the â&#x20AC;&#x153;Workrushâ&#x20AC;? at the last minute before they must hand-in their reports, the instructor would be very surprise for their time management skill. Anyway, most students experienced such cases. SA&D course can provide knowledge of basic project management, so that students can plan ahead and keep track of what they do for the project. This will allow students to prevent such last minute rush. Lastly, this course teaches students about various documents which are useful for project management. These documents are used for communication and making records of things which happened in the project. For example, a group of newly graduated starts a project. Three months pass and one of them leave the team for marriage. A new guy comes. Without appropriate documents, that new guy can hardly know what to do for the team! Team members must sacrifice their own time to actually teach the new guy, so that loss is twofold. Therefore, System Analysis and Design course introduces ways of system design and ways to realize the system. It is also aimed to improve team-working efficiency using some basic project management methods. These are important knowledge for working in real-work working environment.

WHERE TO LEARN MORE? Unlike other information technology school of knowledge, SA&D is not all about protocols. This means you cannot study SA&D from one single specification document like studying IPv4 from RFC791. SA&D is studied by reading many documents and accumulate as much experience as possible. Students who wants to be a system analyst should read more on theory of system analysis and design from related books. These books explain steps and method Page |2

System Analysis and Design [436 303] of analyzing and designing information system. They also show some example of project management and case studies. Apart from those theory and case study, design tools and various diagrams are extremely important because they allow system design to be precise and standardized, so that anyone can understand the same thing without having to argue about which word mean what. Therefore, books about diagrams and Compute Aided Software Engineering (CASE) Tools should be in the reading list too.

COURSE AND TEACHING POLICY As you can see, handouts are in English. This policy aims to prepare students for coming Asean Economic Community or AEC. Students need English skills to survive in upcoming competition. The largest portion of system analysis and design knowledge is also recorded in English. Therefore, English is a crucial skill for this course.

All handouts provided in this course will be in English… …If students cannot read the handout, it is recommended that they attend every lecture which will provided in Thai.

However, the instructor understand students’ situation. Lectures are to be provided in Thai to ensure correct understanding of system analysis and design knowledge. Students must read the handout before class. Any questions from selflearning are to be asked during class. PowerPoint presentations shown in class might not be comprehensible without lecture, do not depend on it. If a student can identify mistakes, such as spelling or grammatical mistake, left uncorrected in the handouts, the student can identify those mistakes to the instructor. A reward is promised at the end of the course.

QUIZ AND MORE QUIZ To ensure students understanding on every lesson, each session begins with pre-test. The test is counted toward grading score. This is designed to stimulate selfPage |3

System Analysis and Design [436 303] learning and also used as attendant check. Then, a post-test is taken before the end of that session. This test is also scored. This is designed to reflect students understanding on themselves and encourage concentration in the session. Be advised, students who wish to withdraw from the course should not rely on some big scores like term-report because it would have been too late to do so. Quiz score is one good indicator of learning performance. If you feel that you are not doing well and your quiz score is down-right bad, you may withdraw without waiting for your big score.

TERM PAPER A term paper must be submitted for this course. Students are to assemble a team of their own. No solo work allowed. A team must consisted of 4 or 5 persons, unless notified otherwise.

Peer review Students have to evaluate their peers after working together. Students who take no part in the work will earn less or no score at all.

The paper is a collection of system development documentation. Basically, you have to develop an information system. Yes, it involve programming. Yes, it is tough. Yes, you have to learn more on programming by yourselves. This is just like real world scenario which you have to work with unfamiliar technologies. Your project should be something small, yet precise, system. Do not pick too large and difficult system. Make notes on your level of expertise on programming. More detail on the project can be found in teaching plan which will be handed at the beginning of this course.  

Page |4

System Analysis and Design [436 303]

SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) Working in business involves doing several tasks to get the job done. For example, shopkeepers sell their goods and buying those which are going out of stock. They keep track of what they have sold and report to store manager for further strategic planning. This example is a store which run on a simple system. Think about a store without any system for a few seconds. Store which has no designated shopkeeper. Customer comes in and does not know what to do. Same goods are sold for different price and once they were out of stock, no one buy them nor even aware of their status. Business cannot survive with such working environment, right? That is the reason system is so important for business. Without system, business cannot go on. With strong system as a foundation, business possess great competitive advantages. System analyst make system out of business. In this course, we focus on making automated-computerized system for business purpose. There are several method for doing so. We start with the traditional method of system development. It is called, system development life cycle or SDLC. A system is similar to a creature. A creature is born, grown, matured, become old and died. A system is born, as an idea. It grows, as the system is designed and implemented. It matures as the system is used. It gets old after business requirements change. Then, it dies after it is outdated or otherwise abandoned. To simplify system life cycle, you develop it and use it. The cycle repeat after the system is outdated. SDLC in theory is a sequence of processes that a system goes through. There are 5 steps (Sattzinger, Jackson, & Burd, 2007). 1. Planning 2. Analysis 3. Design Page |5

System Analysis and Design [436 303] 4. Implementation 5. Support

Planning

Traditional SDLC, like shown above, has Support its advantages and disadvantages. There are other methods for system development such as Rapid Application Development or RAD which fix the disadvantage of traditional SDLC. Implement However, those newer methods are complex FIGURE 1: SDLC and not suitable for beginner. Thus, this handout use traditional SDLC as a guide to system analysis and design.

Analysis

Design

PLANNING If you fail to plan, you are planning to fail - Benjamin Franklin The first step in SDLC is planning. Like any other work in life, SDLC start with a plan which, most of the time, does not guarantee that actual work would go according to plan. However, it is a good practice to have an outline and deadline for the task. Planning in SDLC involves more than making time table. Crucial information is gathered and analyzed in this step. Planning phrase is to: 1. 2. 3. 4.

Identify scope of the system Feasibility study Schedule Identify required resources and budget

Page |6

System Analysis and Design [436 303]

Schedule

Resources Feasibility Scope

First, we need to identify the scope of the system. Find out what are problems which this system is going to fix. How broad the system has to cover. This is the most crucial task in planning phrase because if this step is done wrong, the whole project could become a big waste. It is like a student who writes all kind of stuffs on an answer sheet for an exam but all those stuffs are not related to the question at all, thus getting zero score for the test! After we consider the scope of the project, feasibility study is to be conducted. Feasibility study is a preliminary study of the environment which the system is to be built upon. It sees if the project is likely to succeed. This important study is explained in detail later. Scheduling is another important task in planning phrase. It determines how long the project would take to be fully developed and deployed. List of tasks required by each steps is to be made with rough estimation of time. Large project should have milestone fixed on the schedule too. Lastly, the resources and man power are listed. Along with the tasks shown in schedule, name of people who are responsible for those tasks are specified. List of Page |7

System Analysis and Design [436 303] resources are also assigned to the tasks. This allow project manager to estimate the investment value and see if the budget allows the project to succeed. It is important to know that there is no plan survive the first problem arise during execution. System development plan is also the case. The plan may not be 100% accurate but it provide an estimation of what to expect. SA should not be dishearten from unable to follow the plan exactly as it was written. Instead, SA should come up with a short term plan for current problem and improve long term planning skill next project.

ANALYSIS He suffered from paralysis by analysis. - Harold S. Geneen After a project is planned, it is time to get system development started. However, before we make a system, we must study the way the business works. SA must investigate the original working system. Identify the requirement of the job and people who perform it. There are a few tasks in system analysis. 1. Gather information 2. Analyze system requirement 3. Review alternatives The first time to do is to learn how people currently work. It is also called “Asis” system analysis. This step provide an outline of the current situation of the business. It is important step because without knowing how the system use to work, we cannot make the system that these very people would use. Just like Sun Tzu said in the Art of War, “know your enemies and know yourself, you can win a hundred battles without a single loss”.

Page |8

System Analysis and Design [436 303] Requirement analysis is another important step. It is normal for the “word-be” users to ask for many things those are out of the scope of the system. Users want easy to use GUI. Some users want a lot of information on one screen while others want a big font with less information. All these “wants and needs” are requirement gathered from the previous task. As you may see, some of these requirement are cosmetic. Some are essential. Requirement analysis is the task for SA to structure these requirements and prioritize them, so design team knows what they are going to design. Lastly, SA must communicate with the investor or the management about the analysis. It is important to provide some alternatives, so the management can choose the way the system is developed. It is important to note that analysis can take quite a long time. It may involve SA spending time doing odd jobs in customer office just to learn about the existing system as much as possible. However, SA must keep in mind that the project must not be paralyzed by analysis. This is where the schedule done in planning phrase is so important.

DESIGN Design is not just what it looks like and feels like. Design is how it works. - Steve Jobs Now that the requirements are settled, the system can be designed base on those requirements. Designing a system is a daunting task. It requires much knowledge and experience. Technical knowledge allow more precise design. It is the task which separate coders from programmers. However, Arts students are not expected to design a perfect system, even if such thing exists. This course focuses on how we can communicate those complex designs using various tools and diagrams. Basically, design phrase produce documents explaining these components: Page |9

System Analysis and Design [436 303] 1. Data modeling 2. Process modeling 3. User interface Data model is a model of how a data are supposed to look like. How they flow through the system. Where they are stored and which process take them. Data flow diagram is a tool to communicate data flow direction. Entity relationship diagram is used to explain the way data are store inside a database. Process modeling is a model explaining how the business is performed. It may be step by step direction or overview of business flow. Flow chart is one of the most common tool to explain business process. Sequence diagram is another useful tool for process modeling. Overview of business process may be expressed using use case diagram. Diagrams mention in previous paragraphs are used in both design and analysis phrase. During analysis phrase, these diagrams can be used to visualize as-is system, so that the information about the processes is communicated precisely. During design phrase, too, diagrams are the common language of designers so everyone understand the same thing.

IMPLEMENTATION A good plan implemented today is better than a perfect plan implemented tomorrow. - George Patton The goals of implementation phrase are to actually build a reliable, fully function information system and train all related entities, such as users and the company, to make the most out of the system. All other phrases are preparation for this phrase. These are the goal of implementation:

P a g e | 10

System Analysis and Design [436 303] 1. 2. 3. 4. 5.

Implementation of software Test Data conversion Training Deployment

Implementation is when coders actually write the program. This tasks is when you here words like Java, PHP or SQL. Coders and programmers usually use famous programming languages to order the computers to perform tasks as designed in design phrase. However, that is not always the case. Some system involves more than programming languages. We call them “low level implementation”. “Low level” implies to OSI model which the lowest level, first level, is physical layer. It deals with physical objects like cables. If the project requires special equipment, they are built in this phrase as well. Note that this course focus on software aspect. Students are not expected to make devices. After program is finished, it must be tested. This will ensure that when the system is deployed, no surprise error will comes up. Usually, tests are classified into two groups. The first one is program test which test if the program works alone. The second one is integrity test which test if the program can work as a whole. All tests are to ensure that the program can perform tasks to satisfy users’ requirements as gathered from analysis phrase.

CASE STUDY Do you know why librarian must study MARC? You instructor had a direct experience, which still scarred him deep inside, with it. Once I was working for a group that develop and sell automated library system. We went to implement our system for education institutes. Usually, we migrated the data which were stored according to MARC tags. The task only took half-an-hour for 10,000 books. How ever, we were stuck hard by only 700 books. One day, we implemented a system for a small school. Problem was the school did not have a librarian. School teacher managed the library and she did not use standardize program for that. Turns out that library data were not stored in MARC format. The database was Fox Pro. All data were store in “who knows” fashion by a brand-less software with zero documentation. We could not do data conversion.

What did we do? Yep, 700 books were hand-typed. It took us a whole month of doing nothing but constant typing, It was soul-draining and boring as %?*x!

P a g e | 11

System Analysis and Design [436 303] Before program can be used, the data from previous system may be needed. Data conversion is a task to migrate data from the old system to the new one. This task also clean data from duplication and other anomalies. Now, software is ready to use. Users must be trained to use them. Trained users can reach full productivity faster than untrained users. Do not expect users to know what to do with the program, no matter how easy to use you think it is. Users whose age higher than 35 need more training than their younger counterpart. Also, manual must be provided according to users’ tasks. Lastly, the system is deployed. This is not an easy task. Deployment is the step that hardware and software are brought to working site and installed. These pieces must be connected according to the implementation and design. System integration must be performed before users can use the system. There are many issues regarding deployment which will be discussed later in the handout.

SUPPORT Your most unhappy customers are your greatest source of learning. - Bill Gates Support phrase goal is to keep the system running productively. This means the system must perform its job and users must use it to fulfil the requirements of business. Sometimes, system performs but users do not. Users usually stick with the “good old days” and refuse to use the system. If they face a technical or operational problems when they are working with the program, they would blame the system. Thus,

Production In system development context, the word Production does not mean to make something. It means the situation that the system is being used by expected users. Usually, there are 2 versions of the system. First, is called “DEV” which is used by development team. Then, the “production” which is used by real users.

P a g e | 12

System Analysis and Design [436 303] support is critical for system life cycle. It keeps the system from premature death. These are tasks in support phrase: 1. Maintenance 2. Enhance 3. User support Maintenance is to keep the system up and running. This task mostly concerns about technical aspect of the system such as reboot the WIFI access point when the wireless network is down. Fix bugs which surface in production and manage errors. This is where technical documents become handy because the person providing support may not be the one who write the code and must relies on documents to do the job. No system is perfect when it is shipped. Enhancement allows the system to perform longer than it originally is. Also, business requirements changes, as a matter of fact. For example, once upon a time, mobile phone number system contain 9 numbers with the first two are zero and one (01xxxxxxx). Some years later, phone number increase by one digit. Enhancement such as this allows mobile phone to perform even after the original number is depleted. Thus, the task aim to improve the system to fit new business requirements without re-develop the entire system.

Help desk â&#x20AC;Śis not really a desk. The term refers to technical assistants who guide users to fix their problems via telephone. Why phone? Because when all else fail, phone works. Want to know how they work? Scan the code and watch the VDO (English)

P a g e | 13

System Analysis and Design [436 303] User support allows users to use the system to its maximum potential. A help desk provide assistance to the user is critical for large information system. Some simple problems, such as user cannot connect to the network because a cable is not plugged, are common. As common as they are, they can cause the work to be stalled and business loss. User support is there to ensure the user can use the system to the fullest potential.

ADVANTAGE / DISADVANTAGE OF TRADITIONAL SDLC SDLC is not an old idea. Someone may go as far as calling it ancient. Time pass and people discover many drawbacks of SDLC. There are many theories and methodologies, such as rapid application development or RAD, developed to fulfil what SDLC lacks. However, SDLC is not without advantages. This section lists some advantages and disadvantages of traditional SDLC.

ADVANTAGES 1. Clear project objectives. SDLC stated clear objective of the project from the start. Affords are invested to study the existing system and the way toward new system. Meetings and communication should make clear of system objectives before development. 2. Clear project requirements System requirements are gathered at the beginning of the development process. Requirements are documents and verified with users and stakeholders. These verifications are essential for legal and financial activities. P a g e | 14

System Analysis and Design [436 303] 3. Progress of system is measurable. SDLC is very clear-cut with each step of work. Phrases sometimes work as milestones. Project manager can specify deadline for each phrase. Documents can be used to identify progress. This advantage also makes SDLC a good â&#x20AC;&#x153;starting pointâ&#x20AC;? for learning system analysis and design.

DISADVANTAGES 1. User cannot see the system in development Can you buy a car without seeing one? SDLC is like buying a car seeing only specification sheets full of numbers and jargons. Developers work behind the scene. Only SA comes to meet the users. This can create a major problem when the product is shipped. If anything was wrong, it cascade, become worse, through the entire cycle. One of the most common thing is misunderstanding between users and developers. This happens more often when SA is inexperience with that particular kind of project. Users tell their requirements to SA. If SA misunderstood the requirement, it would certainly translated into wrong requirement document. Thus, wrong design. 2. Difficult documentation management Documents are used as communication tools in system development. SDLC requires many documents. Some documents are made in many versions. For example, requirement gathering process may produce many requirements. The latest one is to be used as reference. P a g e | 15

System Analysis and Design [436 303] However, the older one cannot be discarded because those requirements may become needed again. Thus, versioning documents is something. Given many of such documents, management is more difficult than it seems. 3. No change (Sorry, Obama.) SDLC provide limited flexibility once the system is designed. If business requirements change during design phrase, the requirement may need to be gathered again. So, SDLC usually limited the users from changing requirements after they have been gathered. SDLC may be old and full of disadvantages. However, it is unwise to disregard any tools only for their disadvantages. Students should discuss with friends to find circumstances which traditional SDLC model works best. Also find situation that SDLC is not the wise choice for system development. Further study on SDLC alternatives and variation allow students to choose the best method of their own system development.

P a g e | 16

System Analysis and Design [436 303]

CASE TOOLS Computer-Aided Software Engineering or CASE tools are software which allows system analysts to do their work efficiently. Basically, it is a set of tools which developer uses to automate software engineering processes such as design and coding. SA uses CASE tools to create diagrams and documents and save in to a repository. CASE tools can identify the completeness of the documents, set and update milestone of the project, and generate program code according to the design in those documents. An example of CASE tools is MySQL workbench. This program allows database designer to design database using crowâ&#x20AC;&#x2122;s feet entity relationship diagram. The program can export the design into SQL code which runs on any MySQL server to create a database by that design. The program can also reverse engineer an existing database, creating a diagram of the current database. Database modification can also be perform via MySQL workbench. From previous example, you can see that CASE tools shorten the time spend on implementation phrase by automatically generate the code. However, CASE tools can perform more than that, such as help manage the project and check document redundancy. Document versioning is another crucial functionality of CASE tool. Test case can also be made to shorten test time. It is important to know that some commercial CASE tools are expensive. It is advised that developers use CASE tools whenever possible but consider budget too. There are many opensource CASE tools. Students are advised to try them. If you can learn to use them, you will save a lot of money in the future.

P a g e | 17

System Analysis and Design [436 303]

diagram tools drawing tools

coding tools

reverse engineering tool

database generator

repository

prototyping tools

test tool

query & report generator

security controller version controller

FIGURE 2: FUNCTIONALITIES OF CASE TOOLS

REPOSITORY Repository is a central collection of project information. Think of it as a harddisk shared by everyone who work on the project. For example, SA in Bangkok gathers requirements from users. SA make a requirement document and save it to the repository. Designers who may be living in India and USA can look at the document and do their work, if they can access the repository from the Internet. Small office enjoys the same benefits like that too. P a g e | 18

System Analysis and Design [436 303]

DIAGRAM TOOLS Diagrams are drawn during analysis and design phrase. Handwritten diagrams are good enough for thinking job. However, those diagrams are also used to communicate between team members. Handwritten documents of any kind can become problematic as they are hard to read. This is why diagram drawer handy. Diagram tool is used to draw diagrams. The biggest advantage of using software to draw diagrams is easy to modify diagram. A wrong drawing can be deleted and redrawn easily. Product of the program is also easy to read because all fonts are standard. Some programs offer more functionalities, which are combination of other CASE tools functionalities like reverse engineering capability.

CODING TOOLS Coding tools is one of the most important CASE tools. Also known as Integrated Development Environment or IDE, coding tool is used to code a program. Basic functionalities of the tools are coloring and formatting the code, so that it is easier to read. Some IDEs offer auto-complete capability, which make programming faster. They may be integrated with other functionalities of CASE tools such as linking to repository and doing version control.

DATABASE GENERATOR Database generators make database implementation quicker. Database generators may be similar to diagram drawer which offers only entity relation diagram capability. Entity relation diagram is used during design phrase. Database generator offers the same benefits as diagram tools. However, database generators can generate SQL code which is used to implement a database. Some tools can connect to database server and implement the code automatically.

P a g e | 19

System Analysis and Design [436 303]

PROTOTYPING TOOLS Prototype is an example of the finished product. Usually, it is used to confirm user requirements by showing a would-be product. Prototype presentation usually based on pre-designed scenario. Presenter shows prototype in step-by-step usage, so that no error occurs. Thus, prototype may be just a small programs or interactive animation. Prototyping tools are tools which assist prototyping a product. These tools allow programmers to make a small programs quickly. Some tools are so easy that SA and users can sit together in front of a computer and do drag-and-drop programing until a prototype is created. For a small project, even a web designer can be used to create a prototype.

QUERY

& REPORT GENERATOR

Query is like a question which user ask a database. The database see to the query and give back the result. Query is made by SQL code written by programmer or database specialist. Basically, query is in form of table. Report is structured query results in form that easier to read by users. Query and report are generated by code. However, software can make the job easier by graphic user interface. Query and report generator allow programmers to drag-and-drop components to create both query and report. Students can easily get their hands on one generator, Microsoft Access.

VERSION CONTROLLER Version controller is very important for system development. Programmers write codes day after day. However, the latest one may not be the best. Some addition code may create bugs on the program. Bad design may destroy the entire design. When that happen, with version controller, the team simply restore the previous version over P a g e | 20

System Analysis and Design [436 303] the latest one. Version controller also allow team manager to know who and when the problematic code be written. Some controller can even merge two files, enable the team to use many coders on the same file.

SECURITY CONTROLLER Security is an important aspect of information system development. Any breech in security during system development may leave the system vulnerable for attacks after it is finished. Hackers may try to leave malicious code in the program. Security controller prevents that. Security controller allows team to control access to the development environment.

TEST TOOL After a program is developed, it must be tested. The test is performed on a single newly produced function. This test is to see if the function, a part of the whole program, works correctly. Other tests are performed to see if the function or program works correctly when it is integrated into a system. Test tool allows programmer to write a formal test for functions and programs. It is important because programmer does not have to write a program to test the function, and need another function to test the test function. Test tool may use graphic user interface to write diagrams. Then, from the diagram, generate test program. Some tools can record user interface integration like clicking. The test can be performed by replaying the recorded activities on tested program.

REVERSE ENGINEERING TOOL Usually, reverse engineering tool is integrated into other tools such as diagram tool or database generator. This functionality allow the existing system to be analyzed and presented in form of diagrams. For example, an existing database, which design P a g e | 21

System Analysis and Design [436 303] documents lost, may be reversed engineered. The result is entity relation diagram of the database. MySQL workbench contains this functionality.

DRAWING TOOLS Drawing tools are used to create graphic components such as images or logos. Without drawing tools, it is almost impossible for a program to contain any image. This is because handwritten image cannot be optimized for program displayed without a form image processing offered by drawing tools. They are also used to draw diagrams which are not used to generate any code. Usually, drawing tools are not as optimized for diagram drawing as diagram generators.

PLANNING The first phrase of SDLC is planning. This is when an idea about a project comes up by someone. The idea may come from system analyst whom was hired by an executive officer. It might come from the executive. To realize the idea, planning is important. Otherwise, ideas may be discussed forever without any implementation. Basically, planning is to answer these questions. What to do? Who will do it? When to start doing it. When will that job is finished. And sometimes, if it is a detailed plan, how to do it. These questions are answered. However, these answer get mess up quickly without a good organizing tool. To organize all these tasks, Gantt chart may be a diagram of choice.

PROJECT PLANNING USING GANTT CHART Gantt chart is a popular tool for planning a project schedule. Designed by Harry Gantt in 1922, Gantt chart receives positive feedback from project managers. It is a simple chart which allow project manager to list tasks, set time table and configure P a g e | 22

System Analysis and Design [436 303] requirements of each task. This results in a table with bars and arrows indicating tasks and requirements as shown in Figure 3. NO. 1 2 3 4 5 6 7 8

Task Choose project topic - Make list of options - Create name list - Vote for topic Write proposal - Group writing - Merge documents Hand-in

Duration Require 2 days 1 day 1 day 1 day 2,3 3 days 1 1 day 1 2 days 6 1 day 5

Sun

Mon

Tue

Date/Time Wed

Thu

Fri

Sat

FIGURE 3: GANTT CHART EXAMPLE

Gantt charts is a simple and effective method of planning works. It is easy to understand. It helps project manager to eliminate waste and idleness. It also help getting things done on time. Gantt charts also clear-cut the work of each team member. It shows who do the most job, who do the least, who rush the most and so on. This allows work-load planning to be fair.

WRITING GANTT CHART These are steps of making a Gantt chart for your project. 1. List all tasks The first step in creating a Gantt chart is to list all the tasks you need to do to get the job done. For example, to make a proposal for your project, you need to do these tasks: a. Choose topic b. Write proposal 2. (optional) list all sub-tasks Different persons list different tasks. For some, Write a proposal does not have any subtask. That is fine. However, making subtask is useful for work distribution. It helps time estimation easier. In case you estimate time is off, less error affect the whole project because it off in a smaller scale. P a g e | 23

System Analysis and Design [436 303] For example, writing a proposal is estimated to use 3 days. If there is a 10% error in the estimation, it becomes 3.3 days. If subtasks are made and each task takes 1 day, 10% error may occur on 1 of the tasks and causes only 0.1 day off the schedule. List of subtasks may look like this: a. Choose topic i. Make list of options ii. Create name list iii. Vote b. Write proposal i. Group writing ii. Merge document 3. Set requirement for each task Also known as determining critical path. Now that you have a complete list of all tasks and subtasks, figure out which tasks must be done first. Obviously, you cannot vote for project topic before getting the list of potential topics. This means “Vote” requires “List of options”. Simply put the required task number in a table. Therefore, the result should look like this. NO Task Require 1 Choose topic 2 Make list of options 3 Create name list 4 Vote 2, 3 5 Write proposal 1 6 Group writing 1 7 Merge document 6 TABLE 1: LIST OF TASKS WITH REQUIRED TASKS

Notice that “Write proposal” does not require 4. This is because to write proposal, just voting for the topic is not enough. All of the first task, not P a g e | 24

System Analysis and Design [436 303] subtask, must be completed. This is an opening just in case some tasks which are not foresee shows up during work, the plan will still be valid. 4. Estimate expected time for each task This is a step where most people make mistakes. Judging a time needed for a job require great skill and experience. You have to be working with the team for so long that you know everyoneâ&#x20AC;&#x2122;s skills and character to make an accurate estimation. Most of the time, novice analyst simply guess. This is not a bad thing, bad thing is not even guess. There is a way to improve accuracy of time estimation for each task. First, you estimate time based on â&#x20AC;&#x153;Best case scenarioâ&#x20AC;? (đ??ľ). Then you estimate time based on â&#x20AC;&#x153;Normal scenarioâ&#x20AC;? (đ?&#x2018;&#x201A;). After that, estimate time based on â&#x20AC;&#x153;Worst case scenarioâ&#x20AC;? (đ?&#x2018;&#x160;). These times are estimation, from previous experience of working with the team and similar project. Then, put all those estimation into equation where đ?&#x2018;&#x2013;đ?&#x2018;Ľ is a likelihood of each scenario and đ??ź is the summation of all đ?&#x2018;&#x2013;đ?&#x2018;Ľ . đ?&#x2018;&#x2013;đ?&#x2018;Ľ is an integer and đ?&#x2018;&#x2013;đ?&#x2018;Ľ â&#x2030;Ľ 1. đ??¸đ?&#x2018;Ľđ?&#x2018;?đ?&#x2018;&#x2019;đ?&#x2018;?đ?&#x2018;Ąđ?&#x2018;&#x2019;đ?&#x2018;&#x2018; đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019; =

đ?&#x2018;&#x2013;đ?&#x2018;? đ??ľ + đ?&#x2018;&#x2013;đ?&#x2018;&#x153; đ?&#x2018;&#x201A; + đ?&#x2018;&#x2013;đ?&#x2018;¤ đ?&#x2018;&#x160; đ??ź

EQUATION 1: EXPECTED TIME ESTIMATION

From example, a task usually takes 2 hours. In the best case scenario, it takes 1 hour. In the worst case, it takes 3 hours. Judging from current workload, it is likely that the team can work real well. Analyst says it is likely to be best case scenario, so đ?&#x2018;&#x2013;đ?&#x2018;? is set to 2. Normal scenario is expected 6 out of 10 times, thus đ?&#x2018;&#x2013;đ?&#x2018;&#x153; is 6. Lastly, worst case may happen but not likely, đ?&#x2018;&#x2013;đ?&#x2018;¤ is 1. Therefore, the formula look like this:

P a g e | 25

System Analysis and Design [436 303] đ??¸đ?&#x2018;Ľđ?&#x2018;?đ?&#x2018;&#x2019;đ?&#x2018;?đ?&#x2018;Ąđ?&#x2018;&#x2019;đ?&#x2018;&#x2018; đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019; =

2(1) + 6(2) + 1(3) 17 = â&#x2030;&#x2C6; 1.89 2+6+1 9

EQUATION 2: EXAMPLE OF EXPECTED TIME CALCULATION

Note that there is no â&#x20AC;&#x153;88 minutesâ&#x20AC;? in project planning. You must convert the decimal to minute by multiply the decimal with 60. In this example, 0.89 Ă&#x2014; 60 = 53.4 â&#x2030;&#x2C6; 54 minutes. Therefore, the expected time for the task is 54 minutes. In case you cannot guess the likelihood of scenarios (đ?&#x2018;&#x2013;đ?&#x2018;Ľ ), simply put đ?&#x2018;&#x2013;đ?&#x2018;&#x153; to 4 and the rest to 1. It is a popular ratio. Another difficulty is to estimate time for each scenario. By popular method, simply estimate đ??ľ and multiply with 1.25 to make đ?&#x2018;&#x201A;. đ?&#x2018;&#x160; is a result from 1.25 times đ?&#x2018;&#x201A;. Do this for all subtasks. Time for main task is usually the sum of all subtasks. Some schools advise that students should add more time to the main tasks. It is optional. The result of this step should look like this: NO 1 2 3 4 5 6 7

Task Choose topic Make list of options Create name list Vote Write proposal Group writing Merge document

Require Time(hour) 5:10 4:00 0:10 2, 3 1:00 1 24:00 1 8:00 6 16:00

TABLE 2: LIST OF TASKS - EXPECTED TIME ADDED

5. Assign responsibilities Unless you do it alone, this is an important step for making good Gantt chart. Assigning responsibility allows team member to know their tasks. P a g e | 26

System Analysis and Design [436 303] All know their workload and their schedule. Therefore, all works should be distributed fairly or, if it is not distributed fairly, under good consent of the person involves. Good people may have to shoulder more workload in a forming team but they will know from the chart that they are indispensable for the team. The result should look like this: NO 1 2 3 4 5 6 7

Task Choose topic Make list of options Create name list Vote Write proposal Group writing Merge document

Require Time(hour) Assign to 5:10 4:00 Boss 0:10 Me 2, 3 1:00 Group 1 24:00 1 8:00 All 6 16:00 Boss & Me

TABLE 3: LIST OF TASKS - EXPECTED TIME ADDED

6. Write the chart This is a simple last step. It is to illustrate the time table using Teamwork stage standard annotations so that In theory, teamwork develop through several steps: everyone can understand. The basic 1. Form 2. Storm is progress must be represented with 3. Norm bar. The bar should not be in dark 4. Perform color because lighter color allow 5. Adjourn people to darken the bar, indicate QR code here is linked to a document on these steps. Read more so you can their progress. Apart from the bar, make team-“work” rather than “me”team can set their own standard. work Different working environment has different standard. For example, parent tasks may be represented using bar, similar to subtasks, in a program. Other program use thick line to P a g e | 27

System Analysis and Design [436 303] indicate parent task. The original annotation can be found in the original book on Gantt chart (Clark & Gantt, 1923). The link to the e-book is in handout reference. The result should be like shown in Figure 3.

PIECES Before any new system to be developed, the existing system should have some problem. Otherwise, if the system is still good, why wastes money on something unnecessary? However, even if there are problems, how do we know that the problems are worth solving? Here enter PIECES framework (Wetherbe & Vitalari, 1994) . The framework is used to analyst problems into categories, so that we know what the big problem is. Each letter of PIECES is an acronym of problem categories. It is one of the most accepted framework for analyzing as-is system. In PIECES framework, analyst see if there are problems with these categories. See to the symptoms of these problems and list them.

P: PERFORMANCE Does performance of the current system need to be improved? Analyst should consider these details: 1. Does the business need more work for the same time limit? 2. Does the business suffers from a longer than necessary delay time between work? Can the delay time be reduced? Many confuse performance with efficiency. So, it is important to note that the term â&#x20AC;&#x153;Performanceâ&#x20AC;? is referred to amount of work done per given time. For example, a high performance car can reach further in less time, aka. It runs faster. Performance does not concern with how much oil it drinks up.

P a g e | 28

System Analysis and Design [436 303]

I: INFORMATION Does the system works with information well enough? Analyst must consider both quantity and quality of information produced by the system. These are samples of the symptoms a system may expresses. 1. Problems with decision making process To see if information system for decision making process works or not, consider some flaws in the system. Are these problems exist? a. Information underflow, more information is needed. b. Information overflow, less information is needed. c. Miss-information, irrelevant information must be eliminated. d. Hard to understand information. Format problems. e. Information comes too late for decision making. 2. Problem with input system Sometimes, data is not enough to be processed into information because input process has problems. These are some problems an input subsystem may face. a. Data is not captured into the system b. Captured data are not accurate c. Data are captured but the process is difficult d. Redundant data 3. Information storage Problems can occur to data storage too. It is critical that analyst does not neglect physical side of the system. These are problems which may occur to data storage. a. Redundant data inside storage b. Stored data are not accurate c. Data are inconsistent d. Data storage are not secured P a g e | 29

System Analysis and Design [436 303] i. Against attack â&#x20AC;&#x201C; data leak ii. Against accident â&#x20AC;&#x201C; data lost e. Storage is not well organized f. Stored data is hard to access

E: ECONOMIC Economic problems affect cost of each process in the system. For example, regularly miss-printed document is a form of economic problem because one document requires two sheet of paper. Economic problems also involves some resources which are not being put to good use. These are problems which often found in manual systems. 1. 2. 3. 4.

Do not know the cost of a process Do know the cost, but do not know how it comes to that (Untraceable) Cost of processes are simply too expensive There are opportunity to create profit but not yet seized

C: CONTROL Control involves the interaction with the system. This means balancing involvement between human who control the system and the system control over human. These are some instances of problems with control. 1. Not enough control System which offers too little control is a system which people involves have too much freedom to do damages. For example, operating system which allows non-authorized users to tinker with system files is an uncontrollable OS. Just to be clear, another example in manual working environment. Think about a company which average employees can refuse to work any day with whatever reasons. This is an uncontrollable system. These are the problems usually found in information system. P a g e | 30

System Analysis and Design [436 303] a. Data cannot be edited b. Data are compromised, hacked c. Ethic breached on data d. Cannot manage redundant data e. Privacy breached by operator f. Processing error and decision making error 2. Not secured enough Security is neglect. This problems can cause several problems. It can be identified by instances of these behaviors. a. Unauthorized access to facilities b. Unauthorized access to computers c. Unauthorized access to data & information Security is an extremely big issue. This is because if a hacker make it into a system, all other problems can occur. All investments may be wasted in a single strike, and a backdoor is likely to be placed for future atrocities. 3. Too much control & security There are some systems which enforce too much control too. These systems do not allow users to do something alone. For example, to reduce waste printing paper, clerks are not allowed to use printer directly. This can reduce performance of the system. Another vivid example of too much controlled system is, sarcastically, called â&#x20AC;&#x153;bureaucratic red tapeâ&#x20AC;? (Marakas, 2006) such as disaster responding system. The disaster must strike first. Then the region control office must declare disastrous state on the site. Until then, rescue cannot be mounted. The problem can be spotted from these symptoms. a. Bureaucratic red tape slowdown the system b. Inconvenient for user P a g e | 31

System Analysis and Design [436 303] c. Too much control cause delay or loss of work

E: EFFICIENCY Efficiency is amount of work done with given resources. Do not confuse with performance which is amount of work done in a given time. A Car with high efficiency is a car which can reach further with a single tank of fuel, no matter how long it takes. For information system, efficiency problems can be spotted from these symptoms. 1. Either people or machine wasted resources, for no purpose 2. There are wasted supply or material from processes 3. Process need excessive afford, resource or material

S: SERVICE Problems about service affect the quality of service provided by the company. It is a relation between the system and the user. These are symptoms of systems with problematic service. 1. 2. 3. 4. 5.

Inaccurate or unreliable result Difficult to use / Hard to learn Complex user interface Inflexible, non-adaptive to changing situation Difficult interface between systems Sometimes systems must work together. For example, a company send electronic order to its supplier. If system interface between the two is badly done, the order may be inaccurate or totally lost. 6. Bad system coordination Bad interface may occur inside a single system too. This is called bad coordination. For example, a word processing may be running but when a user hit â&#x20AC;&#x153;saveâ&#x20AC;? button, word processing cannot save the file because the disk drive is locked for backup. Thus, the work cannot be save. P a g e | 32

System Analysis and Design [436 303]

TABLE 4: AN EXAMPLE OF PIECES ANALYSIS (MARAKAS, 2006)

From Table 4, problems are listed on the left hand side of the table. Sometimes, number of issues may be listed for reference. Next columns are marked with PIECES letters representing each category of problems. An issue may be marked on one or more categories. The last row is total number of problems from each category. You can see that from the table, performance and information problems is the biggest. This information allows planner and analyzer to know where, in the system, to focus their effort.

FEASIBILITY STUDY Feasibility is likeliness of something to be beneficial or practical (Whitten, Bentley, & Dittman, 2001). Feasibility study is a preliminary investigation perform before the system is to be developed. The result of this study is the fate of the new system. If the result shows that the project is not likely to success, or beneficial enough, the system should not be developed.

P a g e | 33

System Analysis and Design [436 303] Feasibility study should be performed on several topics. The topics can be represented in acronym as TELOS, Technical, Economical, Legal, Operational and Scheduling. However, it is important to know that feasibility study in detail is extremely complex and may require a whole course to do it properly. Feasibility study in this handout is for Information system. If you read about feasibility of construction project or product development, you may find different topics to be considered such as marketing feasibility.

TECHNICAL FEASIBILITY Also known as technological feasibility, is a measurement of how likely the new system is to be successfully developed, used and become beneficial. This study examine the problem of the system and see if technology of the company is good enough to solve it. It should cover the existing technological capability of the company with opportunity from current technological advances. Technical feasibility should be performed after some requirements are reviewed, thus SA knows exactly what technologies may be needed. However, it is not uncommon for a company to conduct preliminary technical feasibility without knowing requirements. This is to learn about current situation of technological readiness of the company. Are the computers alright? Are they good enough for new system? Are our people ready to computerize their works? Is the anti-virus expired? What kind of technology are we capable of using? Those sort of stuffs.

ECONOMIC FEASIBILITY Also known as cost-benefit analysis, is a measurement of cost-benefit of the project. Analyst must look into the return values of given investment. If the cost exceed expected benefit, the project may not be considered feasible. For example, it is not feasible for a SME palm trees growing firm to invest one million, its entire year worth of budget, for extremely high speed internet connection for its employees. The P a g e | 34

System Analysis and Design [436 303] expected benefits could be employees waste more time on Facebook instead of going out and cutting the palm trees. It is important to know that economic feasibility may examine two types of benefits. First is tangible benefits. Tangible benefits can be valued in numbers. For example, 10% reduction in operation cost per billing order is a tangible benefit. Another type of benefit is intangible which cannot be accounted for in number. For example, government may benefit from increased transparency if a new information system is used. Some may try to make intangible benefits into tangible benefits. Analyst should be extremely careful when doing so. It does not make sense to account organization transparency from the number of enquiry. People may simply did not care, so they did not ask. Economic feasibility usually use techniques such as Return on Investment (ROI). ROI is a measurement of money earned versus money invested. For example, given a system which reduce a cost per bill by 1$. The system costs 10,000$. This means the system would become beneficial at the 10,001st bill. Say, the company made, in average, 1,000 bills a day. Theoretically speaking, ROI would be in 11 days. However, the system has a life expectancy of 5 years. It is supposed to generate 1,000 bills a day, for 365 days, for 5 years, plus 1 leap year day. That would be 1.826 million bills. That is 1.826 million $ benefit from 0.01 million $. ROI is calculated using the following equation. đ?&#x2018;?đ?&#x2018;&#x;đ?&#x2018;&#x153;đ?&#x2018;&#x201C;đ?&#x2018;&#x2013;đ?&#x2018;Ą â&#x2C6;&#x2019; đ?&#x2018;&#x2013;đ?&#x2018;&#x203A;đ?&#x2018;Łđ?&#x2018;&#x2019;đ?&#x2018; đ?&#x2018;Ąđ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x203A;đ?&#x2018;Ą đ?&#x2018;&#x2026;đ?&#x2018;&#x201A;đ??ź = đ?&#x2018;&#x2013;đ?&#x2018;&#x203A;đ?&#x2018;Łđ?&#x2018;&#x2019;đ?&#x2018; đ?&#x2018;Ąđ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x203A;đ?&#x2018;Ą EQUATION 3: ROI EQUATION

From Equation 3, the system generates profit of 1,826,000$ and the investment is 10,000$. ROI is 181.6. This means the system generates 181.6 times profit over investment. That is 18160% profit. This is a feasible project to be undertake. ROI is a P a g e | 35

System Analysis and Design [436 303] useful tool for negotiator to convince the investor to pursue the project, as you can see from the calculation result. Lastly, it is important to note that there are many more ways to evaluate economic feasibility. Students can learn more on economic feasibility from business books.

LEGAL AND POLITICAL FEASIBILITY It involves any legal and political resistance or support to the project. This topic is sometimes overlooked in feasibility study. It is a study of any potential resistance to change as often happen in large company with strong employee union. Legal feasibility focuses on any law that the firm is required to comply. For example, an email provider may want to know the most popular password. However, it is not feasible because the law forbid the provider to access password. Legal feasibility mostly are limitations. Probably, the only opportunity provided shown in legal feasibility is from concession, provided the company won the auction. Political feasibility focuses on politics, both internal and external. This must be studied carefully. Organization with a strong employee union may be a stronger resistance to new system than organization with none. This is a normal. Business school has a course called â&#x20AC;&#x153;change managementâ&#x20AC;? to study this phenomenon.

OPERATION FEASIBILITY This is a study of how the solution is to fulfil the requirements. This is because there are several answer to a problem. Many systems may be proposed to solve the problem. Operation feasibility sees into each solution and see if the solution can solve the problem. It is also involve several issues regard operation of the project such as testing and deployment of the solution. P a g e | 36

System Analysis and Design [436 303] Another perspective of operation is how well users react to the system. Unlike politic feasibility which focus on political unit, operational feasibility focuses on individual process or user. For example, Bob may not like a new program but he can use the program to work at roughly similar efficiency and performance. Bob and others joined a union and demand that the new program is not to be used. This is a political obstacle but not operational. Frankly speaking, if Bob quits, new person who simply as good as Bob can use that program.

SCHEDULE FEASIBILITY This feasibility study is to determine if the project will finish in time. It involves all other feasibility studies because everyone has its own schedule. For example, operation feasibility must consider deployment schedule while technical feasibility may need to consider learning schedule for new technology. Basically, analyst must ask a few questions. Does the schedule reasonable? Can we make it? To answer the questions, simply see Gantt chart and ask if it is possible. However, many analysts commit mistake by failure to set a deadline. No deadline for a task is a good way to do a life-long unfinished task. Deadline must be set and it must be reasonable. Failure to complete the work at deadline must result in some kind of consequences. However, the deadline should not be the life line of the project. In case of failure to meet deadline, a new deadline is set, with more accuracy. Any following deadlines should be set at better accuracy too, because analysts have learned from their experiences.

P a g e | 37

System Analysis and Design [436 303]

ANALYSIS The second phrase of SDLC is analysis. It is when the current situation is investigated. The goal of analysis phrase is to learn about the current system and the goals of the new system. Basically, it is like asking “What are we going to do” or “What problems are we going to fix”. Analyst must break down the current system to gain deep understanding on the situation and problems. Analyst must go to the real users and all stakeholders to gather “Requirements”. Those requirements are classified into functional, aka. Important, requirements and non-functional requirements. Documentations are made to ensure formal understanding between all parties.

REQUIREMENT GATHERING Also known as requirement discovery. This is fieldwork! By fieldwork, analyst must go out “in the field”. The goal of the expedition is to: 1. Understand system constraint 2. Understand system procedure and business flow 3. Understand system functionality It is safe to say that analyst should gather as much information on the current situation and the goal of overall system as possible. Analyst must investigate the working condition to make sure that new system will not break the business or interfere with normal business flow. Analyst must investigate business flows so that design and implement team can design new system accordingly. For example, a new system which print bills cannot be developed without the team seeing the bill in the first place. Analyst must get the bill done by the old system. Then, the bill is analyzed for developers to design database accordingly. When the bill is printed from new system, P a g e | 38

System Analysis and Design [436 303] it should contain enough information to serve the goal of the bill done by old system, plus some more information that the new system must fulfil. To do that, analyst may have to employ several techniques.

FIGURE 4: REQUIREMENT GATHERING GOAL AND METHODS

QUESTIONNAIRE One of the most popular information gathering method known to man. Questionnaire or survey is a tool for system analyst to gather user requirements. It is a quick, cheap and relatively easy method compare to other techniques. It can reach more participants. However, it is not without short-comings. Analyst should keep in mind that questionnaire must be done right, otherwise the gathered requirement is not going to be accurate. Table 5 summarizes advantages and disadvantages of questionnaire. Advantages

Disadvantages P a g e | 39

System Analysis and Design [436 303] Easy to prepare Low cost Gather large amount of data Data are numeral Studies can be perform by anyone with little change in quality

Participants may lie Participants may just answer randomly Question may be interpreted differently Bad questionnaire design can affect result Cannot gather some form of information such as emotion or behavior

TABLE 5: ADVANTAGE & DISADVANTAGE OF QUESTIOINNAIRE

INTERVIEWS Interviewing is considered a traditional form of requirement discovery. It is one of the most employed technique. It allows analyst to reach for more facts about users than most of other techniques because analyst must go for a face-to-face interaction with end-users. However, interview is rather difficult to conduct correctly. Bad interview is not only result in inaccurate requirements. It can generate distrust, even hostility, between users and development team and lead to more resistance to change. Table 6 summarizes advantages and disadvantages of questionnaire. Advantages Participants can be motivated to answer more questions Participants feel more involve with the system development (less change resistance) Analyst can re-ask the question if it is unclear or being interpret differently. Non-verbal information can be observed.

Disadvantages Conflict during interview leave bad impression Time consuming Expensive Require high communication skill

TABLE 6: ADVANTAGES & DISADVANTAGES OF INTERVIEW

SAMPLING DOCUMENTS , FORM AND DATABASE Sampling documents is for an analyst to get samples of documents, form, database, demo program and screenshots of the existing system. This method allows analyst to see the output of each process of the existing system. It is particularly useful P a g e | 40

System Analysis and Design [436 303] for design team especially for database design. It also allow analyst to gain access in some inaccessible information such as data structure of document ID, which is useful for backward compatibility. Advantages Can get inaccessible information Do not suffer from research bias Can collect large amount of data Low cost

Disadvantages Time consuming Cannot be performed without existing system Require great analyzing skill Good sampling require statistical sample size

TABLE 7: ADVANTAGES & DISADVANTAGES OF SAMPLING DOCUMENTS

OBSERVATION Analyst may choose to observe working condition first-handed. Observation is a powerful requirement discovery technique. Analyst visits the working site and observes working condition without any interfering at all. This allows analyst to tap into untold information. Advantages Can collect event data such as when does something happen Can collect data even if user does not want to Data is more accurate, it is what they do rather than what they think they do

Disadvantages Susceptible to observation bias Hawthorne effect – when people perform better when being observed Does not give insight of “why” people do something.

TABLE 8: ADVANTAGES & DISADVANTAGES OF OBSERVATION

JOINT APPLICATION DESIGN (JAD) Joint application design is a technique first developed by IBM (Marakas, 2006). This technique requires analyst to bring all stakeholders to a meeting outside their working environment. This allows them to focus on new system development. P a g e | 41

System Analysis and Design [436 303] JAD is not a simple meeting. It is a highly structured one because analyst need to get as much requirement as possible in one session. People rarely has a same schedule for meeting. A session should include at least people from this list. 1. Meeting facilitator Facilitator keeps meeting agenda and resolve conflict. However, it is important that facilitator do not contribute any idea or suggestion. 2. User User is the representative of all end-users, at least a group of users. All groups of user should participate too. 3. Manager Manager represent management perspective of the system. 4. Project sponsor Represent all parties responsible for funding and supporting of development process. 5. Analyst Observe the meeting to gather untold information such as behavior and change of emotion. 6. Scribe Take notes of the session. 7. IT staff Contribute technical feasibility and technological limitation of the system. Advantages Disadvantages Decrease time for gathering requirement Participants must prepare for the session, from different parties separately otherwise no idea can be shared Change for parties to share their views Participants must really represent the problem, otherwise wrong requirements are gathered Combination of many methods All limitations of meeting apply to JAD TABLE 9: ADVANTAGES & DISADVANTAGES OF JAD

P a g e | 42

System Analysis and Design [436 303] As time pass, there are many more techniques such as prototyping presentation. New techniques are not covered here. These techniques are part of newer method of system development such as agile method. This handout use SDLC as an outline, therefore those techniques are not discussed in general. They are discussed when other methods are explained. Now, using previously mentioned techniques, requirements are discovered. Next step is to classify them into groups that help designers, who work on the next phrase, understand them.

REQUIREMENT ANALYSIS Freshly gathered requirements are not in any form near “easy-to-understand”. What you get from requirement gathering process is a bunch of questionnaires buried under a pile of interview logs and sampled documents. Some of them are not useful. Some may lead to misunderstanding. It is analyst’s job to sort them out and organize them, so they can be useful. This job is requirement analysis. Requirement analysis involves reading those notes and discard something which are not relevant with the system. After that, requirements are listed. They must be prioritized because system development cannot fulfil every request from the users. It will likely lead to uncontrollable budget. Thus, analyst must see which requirements are functional and which are non-functional.

FUNCTIONAL REQUIREMENT Functional requirements are essential for the system. It is the requirements which the system must perform or support. As the name implies, it is the function of the system. These requirements are about business flow, input, process and output. They are usually clear-cut and expressed in phrase like “the system should…do this…do that”. For example, the system should accept barcode from the scanner. P a g e | 43

System Analysis and Design [436 303] Examples of requirements which are not functional requirements are â&#x20AC;&#x153;the system should be user friendlyâ&#x20AC;?. This example is not clear and cannot be included in functional requirements.

NON-FUNCTIONAL REQUIREMENT Non-functional requirements are something apart from functional requirements. This type of requirements has many sub type. By classifying them into subtypes, designers can work with them without confusion. Non-functional requirements are: 1. Technical requirement This type of requirement related to hardware and software. Some system must be developed using specific standard or programming language for backward compatibility and coordination between systems. For example, some programs must be developed using light-weight programming language because the computer which is going to run it is not powerful. 2. Performance requirement This type of requirement is about workload which system have to handle. Its efficiency, performance, throughput and respond time. Analyst usually use maximum load. For example, try figuring out how many search query Google have to support in a single day1. That is performance requirement. 3. Usability requirement Usability is how much user can use the system. This type of requirement is about user interface, support and documentation. For example, some systems are required to print braille alphabet for the blind. 4. Reliability requirement Reliability is the durability of the system. System with high reliability performs every time it is used. Lower reliability causes more system crashes. It also 1

Google search supported more than 5,000,000,000 search queries a day (in average) in 2012.

P a g e | 44

System Analysis and Design [436 303] related to the time it takes for the system to recover from a crash. Some books keep this requirement with performance requirements 5. Control and security requirement This requirement is about control over the system. For example, some output should be shown only to the manager while some can be shown to anyone. It is also about preventing damages to the system and the data stored in it. It is about authentication, authorization, backup and restore procedure. Some systems may require data encryption during communication too. It is important to note that both functional and non-functional requirements are required. Both must be met. However, some requirements can be put in lower priority. These are cosmetic requirements such as colorful button with sparkling flower on it. Depend on the user and goal of the system, these requirements may not actually required. User just wanted it.

REQUIREMENT DOCUMENTATION Requirement documentation is also called requirement statement. This document is to be validated with stakeholders, to make sure every party share the same understanding of the system. This requirement document may become part of a contract, in specification section. The document itself must be stored in a repository for design team to access. It is usually written in formal report manner. Writer should keep the message simple, use simply words and make it easy to understand. These are list of section which should be included in the document. 1. Project description Project description is an overview of the project. It should include a complete list of stakeholders, sponsors and development team. 2. Plan P a g e | 45

System Analysis and Design [436 303]

3. 4. 5.

6. 7.

Plan is represented in a time table or Gantt chart. Other documents from planning phrase may be included here. Objective Objective of the system as the stakeholders require. Constraint Constraint which analyst have found during requirement discovery. Requirement A full list of requirements. The list must be organized so that designer can understand them easily. Proposed system Outline proposed system which should be discussed with stakeholders. Design document (if already done it) Some parts of the program may be designed by analyst and/or stakeholders such as data model, system model or process model gathered from JAD sessions. These designs should be included in the document.

P a g e | 46

System Analysis and Design [436 303]

DESIGN Design phrase is where the creativity fully takes place. It is the phrase that programmers, not mare coders, work. Design team work closely with system analyst, who gathered requirements for their design. To design an information system, extreme understanding of programming is a must. You should be able to think like a programmer to do it effectively. However, for people with less experience on programming, it is also possible to work with them. There is a joke about programmers who have a hard time talking with human beings. This trait of programmers can be overcome using standardized diagrams, which all programmers should understand. Being able to use these diagrams, thus, is extremely important for system analyst. This is because analyst is the person who bridge between programmers and users.

DATA MODELING USING ERD

Entity relationship diagram or ER diagram is a data model to describe relational database structure. It is a standard tool for communication between database designer and programmer who implements a database. It is critical for people who need to communicate with database specialist to understand ER diagram.

CHEN’S VS CROW’S FOOT There are two types of ER diagram. First is called Chen’s diagram. Second is Crow’s Foot diagram. These two types of ER diagram are used for different purposes.

For students who also study Database management course, ERD section is shamelessly copied to here. You do not have to read it twice!

P a g e | 47

System Analysis and Design [436 303] Both has its advantages and disadvantages. Their appearances are being compared in Figure 5. StudentID

SubjectID Student

Name SubjectID

Student PK StudentID Name FK SubjectID

study Chen’s ER diagram

study

Subject SubjectName

Subject PK SubjectID SubjectName

Crow’s Feet ER diagram

FIGURE 5: COMPARE CHEN'S DIAGRAM (UPPER) & CROW'S FOOT DIAGRAM (LOWER)

Chen’s diagram is proposed by Peter Chen (1976)3 in an attempt to establish a unified view of data. It is a great tool for conceptualize data to see how each set of data interact with others, which in turn making information. This type of ER diagram could be found in design documentation. However, it does not provide a good communication with programmer who implements a database. Crow’s Foot ER diagram is more implementation oriented. Crow’s Foot ER diagram is widely used in both design and implement documents. It got its name from the line which describes relationship between entities. The end of a line shows cardinality of instances. It tells how many times a record in one entity shows up in the linked entity. That line ends with either single straight line

http://www.csc.lsu.edu/~chen/pdf/erd-5-pages.pdf

P a g e | 48

System Analysis and Design [436 303] or expands into three lines which look like bird’s foot. How it comes to be crow’s foot is not known. Crow’s foot diagram is the main focus of this course. It is important to note that Chen’s diagram is a great tool for conceptualize relational data model. However, in an aspect of this course which involve some implementation, Crow’s Foot diagram suits better.

CROW’S FOOT DIAGRAM Crow’s Foot diagram can be drawn using a set of standard notation. In relational database, designer group data into a group of entity, Entity name also known as table. Then, link those entities together Student using relationships. After that, cardinality and modality PK StudentID is marked to the relationship. In this section, each Name notation is explained. FK SubjectID

ENTITY Entity is drawn as a table. This is a reason why an entity is also called a table by programmers. In an entity, there must be these information. 1. 2. 3. 4.

Name of an entity Attributes of the entity Primary key of the entity (PK) Foreign Key (FK)

Attribute name Key indicator PK = Primary key FK = Foreign Key Blank = non-key FIGURE 6: NOTATION FOR ENTITY

Sometimes in a design process, entities are left with only Name of an entity because listing all attribute would have consume too much time. A complete entity is shown in Figure 6. P a g e | 49

System Analysis and Design [436 303] Note that naming attribute could be controlled by naming convention which is agreed upon by design and development team. This naming convention is extremely useful in implementation process because it helps distinguish different elements. For example, a student entity may be named “tblStudent” to show that this object is a table. A view could be made by joining tblStudent with other table and named “viewStudent”. With two different name (tblStudent and viewStudent), programmers do not confuse when try to insert data into the database. It is also important to note that some DBMS is case sensitive which means lower case “a” and upper case “A” are different. Finally, do not name anything in a database using any language except English. Naming and entity, for example, using Thai language introduce the system to countless technical problems.

RELATIONSHIP

Entity

perform 1:1

Entity

Relationship is drawn in a line perform linking two entities. The line could be Entity Entity 1:M solid or dotted line, each express different perform relationship. The important part of the Entity Entity M:M line is the head. A single line express “one” relationship on that particular FIGURE 7: NOTATION FOR RELATIONSHIP entity. “Crow’s foot” line express “many” relationship on the particular entity. Therefore, a line with one end ends with straight line while another end ends with crow’s foot express one-to-many relationship. Relationships are shown in Figure 7. Most of the time, conceptual relationship is noted on top of the line to explain the relationship during a design phrase. However, in implementation phrase, those notes might present.

P a g e | 50

System Analysis and Design [436 303]

CARDINALITY AND MODALITY 1 and only 1

Entity Cardinality and modality is a part of Entity 1 and only 1 relationship line. Cardinality is the 1 or many Entity relationship between entities. It can be 1- Entity Zero or 1 1, 1-M or M-M. This is cardinality. It Zero or many expresses how many times one record Entity Entity Zero or many from one entity shows up in another entity. Modality, on the other hand, FIGURE 8: NOTATION FOR CARDINALITY AND MODALITY express how many records must be in an entity for a record in other entity can be formed. For example, a citizen can marry someone. Therefore, we got a citizen entity with name, surname and other attributes. Then, we got marriage entity with both parties name, surname, date of marriage and other data. A citizen can only hold only one marriage status at a time. Therefore, citizen and marriage has cardinality of 1-1. This is also called 1-1 relationship because cardinality is a degree of relationship. However, a marriage cannot happen if there is no citizen. This leads to modality of 1 in citizen entity. Citizen can live without getting married. This leads to modality of 0 in marriage entity. Therefore, a full relationship between these two entities is expressed as 1-1 relationship with “one and only one” citizen to “Zero or one” on marriage.

Figure 8 shows notation of cardinality and modality. You may notice that “zero or many” is also marked by dashed line relationship. This is called unidentifying relation. Identifying and non-identifying relation is different by the requirement of relationship between entities involved. If a relationship requires both side to have at least one particular attribute from another table, that relationship is identifying. In implementation, this usually results in including a foreign key from that particular table to the primary key of its pair. On the other hand, unidentifying relationship does not P a g e | 51

System Analysis and Design [436 303] require an entity to have the attribute. In implementation, that foreign key is not set as required and not included into the set of primary key. Note that these identifying relationships are constrains to the database. A constrained database is more false tolerant but less flexible.

PUT ALL INTO ACTION Try to write some basic ER diagram using notation you have learned from this session. This part of the handout give you a few example data for practice (all plural nouns are made singular for the sake of example). 1. 2. 3. 4. 5.

Computer and part Employee and employer Teacher and student Boyfriend, girlfriend and the Gig (More than friend, less than boy/girlfriend) Student and course in university

It is important to note that ER diagram is a set of standard communication protocol. Right or wrong in this setting is the use of notations. The actual design can be different by perspectives, but the design must correctly answers business logics of the case. Therefore, exercises given in this handout do not come with solutions. However, if students want to know how the instructor would have written ER diagram for these topics, check out instructorâ&#x20AC;&#x2122;s website4.

PROCESS MODELING USING DATA FLOW DIAGRAM Data modeling is a process which programmers design how the data, and information, are to be handled in the system. Data may need to be stored in the

https://sites.google.com/site/jirapontanasanti/ Go to page for Database management course and find solution of handout 5.

P a g e | 52

System Analysis and Design [436 303] system for further analysis. Database must keep them but how are the system going to handle the data? How data going to flow from one computer to another, or one person to another. These things are essential for system design and to do it, programmer may choose to use Data Flow Diagram (DFD).

DATA FLOW DIAGRAM DFD is a graphical representation of the flow of data through a system. It shows the data, the process which took the data and the storage of the data. It uses standardized shapes and pictures to represent these data and processes. Programmers know the meaning of these shape, which is why programmers can communicate with each other without confusion about the design. This diagram is very useful for both process modeling. DFD consists of 4 major shape as listed in Table 10. Represent Process External agent Direction of data flow Data storage TABLE 10: SHAPE USED IN DATA FLOW DIAGRAM

A circle represent a process. Process is something which data goes in and comes out as information. The information may not be used by human, rather they are used by other processes. For example, a point of sales system may have a discount function. The user input full price of the goods, plus discount percentage. Input process then

P a g e | 53

System Analysis and Design [436 303] send the data into discount process which reduce the price. Then, the information which is reduced price are send to print the bill as shown in Figure 9.

Sale person

Price Discount rate

POS

Price Discount Discount rate

Sell price

Billing Bill

database Customer

FIGURE 9: EXAMPLE DFD DIAGRAM (SHOWING PROCESSES)

From Figure 9, you can see that processes are represented with circle. A circle always has at least an arrow in. Otherwise, it is weird to have a process which is unused. It also has at least one arrow out. Process with no arrow out is an abnormal process which should not be included in design or implementation. Rectangular shape represent an external agent. External agent is anything that are not included in the system. Usually, they are people. Special characteristic of rectangular shape is that it can produce output and can get input. Unlike process, which is represented by circle, external agent may produce only output and not require any input. It may be the opposite, get input but not provide output, too. However, it must has at least one flow from/into it. Otherwise, it is not necessary for the system and should not be included in the diagram. Arrows represent flow of data. An arrow has a text on it. The text explains what kind of data is being send through that flow. It is important that the flow of data is explained because without explanation, the diagram is ambiguous.

P a g e | 54

System Analysis and Design [436 303] Lastly, data storage is represented by doubled line, or open end block, with the name of storage written in the middle between those lines. Storage of a system is usually a database. However, it may be other kind of data repository too. It is important to note that data storage must not be accessed directly by external agent. This is greatly important. Any data flow into data storage must be from a process. Direct flow of data from external agent breaks most system. Before we finish with data flow diagram, what will happen if a large system is to be written down in a single DFD? For example, try write down a single data flow diagram for a pizza company with multiple branches. Most people cannot find paper large enough to accommodate all information. This is why DFD is often written in levels. Now, let’s try making data flow diagram as a practice. Figure 10 shows an example of DFD.

LEVEL OF DATA FLOW DIAGRAM Data flow diagram starts at a level called “Context diagram”. This is the top most level of data flow diagram. It shows how users connect to the system. This level usually has only one process which is named the system itself.

FIGURE 10: CONTEXT DIAGRAM OF LIBRARY BOOK BORROWING SERVICE

After context diagram, the high level number is, the more detail it contains. Level 1 contains main processes and the flow of data between them. Each process may be marked with number, so readers can make reference in case of similar or closely resembled name. Level 2 is the detail of those processes. Level 3, 4 and so on P a g e | 55

System Analysis and Design [436 303] are the finer detail of any processes which are needed to be detailed. Figure 11, Figure 12 and Figure 13 show examples of level 1, 2 and 3 DFD respectively.

FIGURE 11: LEVEL 1 DFD OF LIBRARY BOOK BORROWING SERVICE

FIGURE 12: LEVEL 2 DFD OF LIBRARY BOOK BORROWING SERVICE

P a g e | 56

System Analysis and Design [436 303]

FIGURE 13: LEVEL 3 DFD OF LIBRARY BOOK BORROWING SERVICE

The last level of data flow diagram is called level 0. It is the summary of all levels squeezed into one diagram. Therefore, level 0 is usually large and complex. Its goal is to explain all connections and shared processes of the entire system.

P a g e | 57

System Analysis and Design [436 303]

FIGURE 14: LEVEL 0 DFD OF LIBRARY BOOK BORROWING SERVICE

Data flow diagram is a very useful tool for data modeling and communication between analyst and programmer. However, as you may see, data flow diagram does not explain instruction of each process. It only explain where input come from and where output go to. Programmers usually need to know that but do not work with only that. Thus, another diagram is needed to show instruction of a process. The simplest diagram for the job is flow chart.

PROCESS MODELING USING FLOW CHART Flowchart or work flow diagram is another useful diagram for communication between programmers and analysts. It explains step-by-step instruction with condition of each steps. It is one of the easiest diagram and one of the simplest. Therefore, it is also useful for communication between analyst and users. Flowchart, like DFD, uses shapes to represent system entities. This handout focus on basic shapes which are oval, rectangular, diamond, arrow and parallelogram P a g e | 58

System Analysis and Design [436 303] or tilted block. Other shapes such as waved block are not included for simplicity. If student need more advance flowcharts lesson, it may be supplemented as time permits.

FLOW CHART SYMBOLS

Start Study Take Exam

First shape is oval shape. Oval shape indicates Get F? the beginning and the end of the process. The ? second shape is rectangular shape or box. A box No represents a process. Third shape is the diamond. A diamond represents condition checking. It is End important that two arrows flow out of a diamond. Each arrow must have a mark either Yes or No (may be True or False).

Yes

One mistake that beginners make is drawing one diamond for cases at once. It is important to know that each diamond must contain only one condition. This gives programmer a guide of which condition holds highest priority and must be checked first. The shapes mention on previous paragraphs are standard shapes. However, as flowchart is used, it has been developed. Many organization improve the basic version into their own flowcharts. These newly developed flowcharts contain many shapes and are interpret differently. It is important for a student to learn at least one standard. This course focuses on basic flowchart only. However, some noteworthy flowchart standards are introduced too.

P a g e | 59

System Analysis and Design [436 303]

FIGURE 16: FLOWCHART CHEAT SHEET FROM BREEZE TREE SOFTWARE

P a g e | 60

System Analysis and Design [436 303]

FIGURE 17: MICROSOFT VISIO FLOWCHART SHAPES

Figure 16 is an example of flowchart symbol list from Breeze Tree Software which is a program for drawing flowcharts. Figure 17 is from Microsoft Visio, another famous diagram drawing tool. Try to compare the two and see the differences. Some shapes are free for drawer to assign meaning such as shown in Figure 17, custom 1 to custom 4. Figure 16 contains some shape related to obsoleted technologies such as punch card. Therefore, these two standards are used in different situation. This is why students should learn at least one standard, yet open for other standards as well.

Flowchart can be used in combination of data flow diagram and other diagrams. The goal here is to explain the system during analysis and design phrase. Therefore, if a process in DFD required detail explanation of the algorithm used in the process, flowchart could be used for the job.

PROCESS MODELING USING SEQUENCE DIAGRAM The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. Much like the class diagram, developers typically think sequence diagrams were meant exclusively for them. However, an organization's business staff can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. Besides documenting an organization's current affairs, a business-level sequence diagram can be used as a requirements document to communicate requirements for a future system implementation. During the requirements phase of a project, analysts can take use cases to the next level by providing a more formal level P a g e | 61

System Analysis and Design [436 303] of refinement. When that occurs, use cases are often refined into one or more sequence diagrams. An organization's technical staff can find sequence diagrams useful in documenting how a future system should behave. During the design phase, architects and developers can use the diagram to force out the system's object interactions, thus fleshing out overall system design. One of the primary uses of sequence diagrams is in the transition from requirements expressed as use cases to the next and more formal level of refinement. Use cases are often refined into one or more sequence diagrams. In addition to their use in designing new systems, sequence diagrams can be used to document how objects in an existing (call it "legacy") system currently interact. This documentation is very useful when transitioning a system to another person or organization.

FIGURE 18: SEQUENCE DIAGRAM SHAPES

SEQUENCE DIAGRAM SYMBOLS Figure 18 shows some shapes used in sequence diagram. It is drawn using Microsoft Visio, therefore the shape is Microsoft standard. Like other diagrams, sequence diagram may be drawn in many styles, each with minimal differences. For example, some standard use stick man as shown in Figure 19 to represent an actor. P a g e | 62

System Analysis and Design [436 303] An important shapes of sequence diagram is the actor. It may be written in bold human body as shown in Figure 18, or a stick man as shown in Figure 19. Some styles use big black cycle as an actor. The key is the actor usually positioned on the most left hand side of the diagram. It represents a user. There is a dotted line under an actor icon. The line is a timeline with early at top and late at the FIGURE 19: ACTOR SYMBOL bottom. Another important shape is a process. It is represented by a box with the processâ&#x20AC;&#x2122;s name in it. This shape is similar to the actor but it is used to represent a program or function. Dotted line under process icon is a timeline as well. Each timeline is connected with arrows. An arrows represent a flow of message such as input. There are two types of arrows. The first type is input message which is a normal arrow. This arrow has two subtypes. The first subtype is an arrow with full blacken head like the first arrow in Figure 18. This type of arrow represent synchronous message. Synchronous message blocks all other operation until the message is processed. The second subtype is a full arrow with stick head. The stick head is similar to the second arrow in Figure 18. This subtype arrow represent asynchronous message. Asynchronous message allows program to perform other operation which the message is being processed. An example of asynchronous message is an error dialog. Another type of arrow is dotted arrow which represent a result or return value of a function. A return arrow is also shown in Figure 18. Note that all arrows are marked with texts explaining the connection between two entities. An input arrows is marked with the name of a function or an activity. It is usually followed by a set of parentheses. Inside the parentheses is a list of parameters, or information which the process requires to perform its task. Return arrow, however, does not accompany with any parameters. P a g e | 63

System Analysis and Design [436 303] The last shape is a thick line which rides on actor and process timeline. The thick line represent an active state of the actor or process. Object must be active before it can send or receive messages. Some sequence diagram does not use this shape at all and cannot show whatever the actor must be using the program or not. Sequence diagram also contain a container. Container represent a loop. A container must have a name describe its meaning such as a loop or a reference. A loop is a reoccurring process. A reference means the full information in the container must be queried from other document, may be because it is too big to be put inside one page. Examples of containers are used in Figure 20.

FIGURE 20: AN EXAMPLE OF SEQUENCE DIAGRAM

P a g e | 64

System Analysis and Design [436 303]

SYSTEM DESIGN USING USE CASE DIAGRAM A use case is an activity the system carries out, usually in response to a request by a user of the system. The objective of use case diagram is to identify all elementary business processes that the system must support (Sattzinger, Jackson, & Burd, 2007). It is a goal of a user. Similar to many other diagrams, a user is called an actor in the diagram. Sometimes, an actor is not a user but a role of the user.

USE CASE DIAGRAM SYMBOLS Symbols or shapes set in use case diagram is probably the simplest of all diagram in this course. The first shape is an actor which is represented by a stick man. The second shape is oval. Oval represents a use case or an activity. An actor is linked with an activity with a line. The line represent association between the actor and the use case. These three symbols, stick man, oval and line, are the main symbols for use case diagram. Additional symbols are added to use case diagram as the diagram is being used. A new addition is a dotted line which represents â&#x20AC;&#x153;includeâ&#x20AC;? (in the diagram is written like this: <<include>>) relationship between activities. Frequently during the development of a use case diagram, it is reasonable for one use case to use the services of a common subroutine. For example, when a book is being borrowed from a library, borrower profile must be checked. The same goes when the book is

FIGURE 21: USE CASE DIAGRAM WITH <<INCLUDE>>

P a g e | 65

System Analysis and Design [436 303] being returned. Therefore, both borrowing and returning processes require user profile check process. The user profile may be included to two use cases with a dotted line as shown in Figure 21. Drawing a use case diagram 1. Identify the actors of the system. These actors are roles of users, do not use names of users. Designer and analyst may invite users for a role playing to gather all actors needed for the system. Note that other systems can be actors too. 2. After all actors have been identified, list all goals of those actors in the system being developed. Goals are tasks performed by an actor to get the business done. For example, a salesperson is an actor in a system. The salesperson processes a sale order. Thus, â&#x20AC;&#x153;Process sale orderâ&#x20AC;? is a goal of actor salesperson. Additional technique can be used to identify all use cases that may be left overlooked. This technique is called CRUD for Create, Read, Update, and Delete. It is a technique widely used for programming. The CRUD are activities a database system is capable of doing. Therefore, actors who interact with data must perform one or more of these activities. For example, salesperson must create a sale order. Given CRUD, we know that the salesperson may have to update, read and delete that sale order too. However, it may not be the case with delete. Salesperson may not be allowed to delete a sale order without manager approval. This is something to ask the user about their policy of work.

USE CASE DETAIL DESCRIPTION Use case diagram is useful for realizing the overall interaction between users and systems. However, it does not portray much details on each interaction. Therefore, P a g e | 66

System Analysis and Design [436 303] further explanations for usersâ&#x20AC;&#x2122; goals are needed. This is why analyst should make use case detail description card. A detail description card is document about a particular use case. The purpose of the card is to give enough details for the developer to understand business flow of the use case. The information on the card include: 1. Use case name:

the name that appears on use case diagram. Using different name leads to confusion. 2. Scenario: What this use case does. 3. Trigger: What starts this use case? 4. Brief Description: Short explanation about the case. 5. Actors: Related actors whom linked to the use case in diagram. 6. Related Use Case: Sometimes use cases are linked. List the related use cases in this section. 7. Stakeholders: List of actors or entities related to this use case. Also provide their association with the use case. 8. Preconditions: Required steps before beginning of the use case. 9. Post-conditions: Result of the use case. 10. Flow of activities: Describe business flow or step of work in this use case. Flow is grouped by the active entities. For example, one side is the actor and another side is the system. 11. Exception: Describe conditions which will cease or avoid the use case. Use case detail description card should be written in one sheet of paper per use case. Longer than that and it becomes hard to read and organized. If some use case lacks certain topics, they can be omitted. An example of use case detail description card is shown in Figure 22. P a g e | 67

System Analysis and Design [436 303]

FIGURE 22: USE CASE DETAIL CARD (SATTZINGER, JACKSON, & BURD, 2007)

P a g e | 68

System Analysis and Design [436 303]

MOCKUP USER INTERFACE Use interface (UI) is also known as Wireframing. It is the face of a system. Good UI design allows users to make the most out of the system while bad design, no matter how beautiful and artistic it looks, hinder usefulness. Therefore, UI design must be validated by various parties. For example, designer design a UI and send it to a programmer. The programmer provide feedback on if the UI is feasible. The UI may be presented to the user to get feedback before coding can continue. The goal of mockup UI is to communicate with the stakeholders about how the finished product will look like.

DRAWING UI MOCKUP Unlike many other diagram, UI mockup is not standardized. It is more like a drawing. Most UI mockup is similar of a screenshot of a finished program. There are many tools for UI mockup such as MS Visio and Balsamiq Mockups. These tools provide â&#x20AC;&#x153;look and feelâ&#x20AC;? of the finished program when the working prototype is not yet developed or finished. UI mockup tools usually provide several images of icons and containers. A designer drag the graphic to a drawing area to create a graphic user interface. Students are advised to try Balsamiq web demo to see how UI mockup tool works. Student will also see the differences of tools. For example, Balsamiq features drawing-like style while Visio features realistic screenshot-like style. Figure 24 and Figure 25 shows mockup user interface by Microsoft Visio and Balsamiq mockup, respectively.

FIGURE 23: LINK TO BALSAMIQ WEB DEMO

P a g e | 69

System Analysis and Design [436 303]

FIGURE 24: MICROSOFT VISIO USER INTERFACE MOCKUP

FIGURE 25: BALSAMIQ MOCKUP USER INTERFACE

User interface design is an extremely complex subject. It is important that designer considers system requirement thoroughly. P a g e | 70

System Analysis and Design [436 303]

SYSTEM DESIGN USING CLASS DIAGRAM Class diagram is used to describe design structure of a program which is developed under Object Oriented Programming or OOP technique. Note that Arts students are not required by this course to be able to master OOP. However, according to the goal of this course namely ability to communicate with specialists, students should know at least a little bit of class diagram. The explanation in this handout is provided by Microsoft Visual Studio online tutorial (Microsoft, 2013). Figure 26, Figure 27 and Figure 28 shows class diagram with number bullets in it. Each number is explained in the adjacent table. To fully understand class diagram, students must understand OOP keywords such as association (line), aggregation (white diamond) and composition (black diamond). Students can learn more about OOP from many OOP programming books.

FIGURE 26: UML CLASS DIAGRAM

P a g e | 71

System Analysis and Design [436 303] Shape Element 1 Class 1 2 3 4 5 5a

6 7

Description A definition of objects that share given structural or behavioral characteristics. Classifier The general name for a class, interface, or enumeration. Components, use cases, and actors are also classifiers. Collapse/ Expand If you cannot see the details of a classifier, click the expander control at upper-left of the classifier. You might also have to click the [+] on each segment. Attribute A typed value attached to each instance of a classifier. To add an attribute, click the Attributes section and then press ENTER. Type the signature of the attribute. Operation A method or function that can be performed by instances of a classifier. To add an operation, click the Operations section and then press ENTER. Type the signature of the operation. Association A relationship between the members of two classifiers. Aggregation An association representing a shared ownership relationship. The Aggregation property of the owner role is set to Shared.

Composition

We can see this association as a word “has”. The relation is considered from the line side to diamond side. From Figure 26, it is “Menu has MenuItem(s)”. An Association representing a whole-part relationship. The Aggregation property of the owner role is set to Composite.

We can see this association as a word “is part of” or “is a”. The relation is considered from the diamond side to the line side, opposite to aggregation association. From Figure 26, it is “OrderItem is part of Order”. Association Name The name of an association. The name can be left empty. Role Name The name of a role, that is, one end of an association. Can be used to refer to the associated object. In the previous illustration, for any Order O, O.ChosenMenu is its associated Menu. Each role has its own properties, listed under the properties of the association. Multiplicity Indicates how many of the objects at this end can be linked to each object at the other. In the example, each Order must be linked to exactly one Menu. * means that there is no upper limit to the number of links that can be made.

P a g e | 72

System Analysis and Design [436 303] 9

Generalization

The specific classifier inherits part of its definition from the general classifier. The general classifier is at the arrow end of the connector. Attributes, associations, and operations are inherited by the specific classifier. Use the Inheritance tool to create a generalization between two classifiers.

FIGURE 27: UML CLASS DIAGRAM - PACKTAGE STRUCTURE

Shap e 10 11 12

Element

Description

Interface A definition of part of the externally visible behavior of an object. Enumeration A classifier that consists of a set of literal values. Package A group of classifiers, associations, actions, lifelines, components and packages. A logical class diagram shows that the member classifiers and packages are contained within the package. Names are scoped within packages so that Class1 within Package1 is distinct from Class1 outside that package. The name of the package appears as part of the Qualified Name properties of its contents.

P a g e | 73

System Analysis and Design [436 303]

13 14

You can set the Linked Package property of any UML diagram to refer to a package. All the elements that you create on that diagram will then become part of the package. They will appear under the package in UML Model Explorer. Import A relationship between packages, indicating that one package includes all the definitions of another. Dependency The definition or implementation of the dependent classifier might change if the classifier at the arrowhead end is changed.

FIGURE 28: UML CLASS DIAGRAM - INTERFACE REALIZATION

Shap e 15

Element

Description

Realization The class implements the operations and attributes defined by the interface. Use the Inheritance tool to create a realization between a class and an interface. Realization An alternative presentation of the same relationship. The label on the lollipop symbol identifies the interface. To create this presentation, select an existing realization relationship. An action tag appears near the association. Click the action tag, and then click Show as Lollipop.

In this class, student must understand the meaning of the box, namely the class, in class diagram. This understanding gives ability to understand OOP designer and programmer during their communication. P a g e | 74

System Analysis and Design [436 303]

P a g e | 75

System Analysis and Design [436 303]

INTRODUCTION TO OBJECT ORIENTED PROGRAMMING First, letâ&#x20AC;&#x2122;s understand how program works with computers. A program is a set of instruction to a computer or machine. The computer takes the instruction and perform exactly what the program tells it to. You can think about it as a recipe for making an omelet. Program is a recipe and the computer is a cook, a really dumb cook who cannot think about anything but follow most basic instruction. The cook, computer, gets the recipe, program, for making an omelet. The first instruction is to crack the eggs. However, the cook does not know how to crack the eggs, so the cook refer to another recipe, egg cracking techniques. Then, the cook does not know how to pick up the eggs, so refer to another recipe, picking eggs. This is how program works. The higher level program gives logic command to the computer while low level instruct the computer for more hardware-oriented tasks. Computers today still work like this. As you can see, computers work on command. Therefore, program is created in sequenced lines of code. However, some code are used time and time again. For example, the code that command monitor to render a mouse cursor. This creates an idea called functional programming. Functional programming allows programmer to write a set of code called function. Then, that function is called whenever needed. Thus, reduce amount of overall codes. However, as a program grows, a lot of functions are created and become disorganized mess. Then, an idea of Object Oriented Programming begins to show. OOP is an idea that all programming entities should be considered an object, not as mere function. An object has its properties or attributes. It also has some functionalities or method. This idea allows same object to be recycled. It also organizes functions and variables.

P a g e | 76

System Analysis and Design [436 303] An example of OOP view is a car. A car is an object. It has its color, engine and doors. It can accelerates and decelerates. Figure 29 shows a class diagram of car. Note that methods are followed by (). If the methods take any parameters, they are entered into those parentheses.

FIGURE 29: CAR CLASS

Now that a car is designed in a class, programmer can make an instance of it and use it inside his program. A class like car is not useable. It is a design, like a blue print. Programmer can use it as a car or inherit the class for his newly custommade car. The idea of inheritance allow programmer to improve the existing class while maintain some degree of compatibility between the two classes. Figure 30 shows a new class called Truck. It FIGURE 30: INHERITANCE is linked to car class by an arrow. The arrow shows that Truck is an inheritance of Car. This means Truck as all properties of Car namely color, engine and doors. It also contain methods from car namely accelerates() and decelerates(). However, Car does not contain loadingSize property like Truck. This allow programmer to write only the truck and does not have to reinvent the wheel of the car class. It is also open for many other programming techniques which are not covered in this course. Students who interested in OOP is encouraged to learn more from OOP books. Now, the program is a group of object oriented code. The computer does not have to perform a long task. Rather, it follow a short recipe in an object then move on to other objects. Some objects may have been loaded into memories recently and no P a g e | 77

System Analysis and Design [436 303] more loading required. Try to see Figure 26 and identify the relation between classes. You can see that an order contains many items (linked by black diamond to show composite association). Phone order is a type of order, therefore inherit order. Lastly, the menu consisted of many menu items (linked with white diamond to show aggregate association). Students may confuse between aggregate and composite association between classes. These relations are similar in the term that objects are part of another object. Aggregate association is when both class can survive without enclosed inside another class. For example, a menu has menu items. Menu items may be placed outside menu such as near a food model. Another example is room and table. Table can exist without a room. Thus, the relation is linked with white diamond on room class side. Composite association is when the objects must be contained inside another object. The container is on the black diamond side. For example, order contain order items. However, order items cannot be kept without writing it down on an order. Order items also does not have any meaning without order because no one knows who orders them. These ideas of OOP is critical for coding. Association like aggregate and composite may seems unnecessary for user to understand. However, for programmer and coder, it tells them where to put the code. Remember that programming is a code in sequence. Association like composite tells programmer that the container must be initialized before the composites. The composite objects should be deleted after the container is deleted, to free memory, while for aggregate objects it is not the case.

P a g e | 78

System Analysis and Design [436 303]

IMPLEMENTATION Implementation phrase is when all designs are put together in code. This is when programmers storm their skill to make fully functional information system out of all designs documents and diagrams. You can think of all other phrase as a bridge to this one. However, to write all programs at once is not effective. There are many software development methodology, also known as framework, which can improve implementation performance. Basically, these methods can be categorized into predictive and adaptive methodology. Water fall

Spiral

Iterative

Predictive

RAD

Adaptive FIGURE 31: PREDICTIVE AND ADAPTIVE SOFTWARE DEVELOPMENT LIFE CYCLE

WATER FALL MODEL Planning Analysis Design Implementation Support

FIGURE 32: WATER FALL MODEL CONCEPT

Waterfall model is also known as traditional SDLC model. Waterfall model development is performed in steps. Traditional waterfall model does not allow water, or active phrase, to go against gravity, or backward. Therefore, the traditional water fall P a g e | 79

System Analysis and Design [436 303] model always push forward. There is no going back to recollect additional requirements after analysis phrase. This constraint applies to all other phrases.

CRITICISM Waterfall model is one of the first model for system development. It is old and weathered with many harsh criticisms. The biggest problem of the model is its nonadaptive characteristic. Waterfall model is hardly used in its pure form from the fact that not many developers can completely finish all works in any phrases. In the matter of fact, developers and analysts always accidentally leave some issues behind when the project is moving on to other phrases. This is due to project size and complexity. Changing and hidden requirements are the biggest problem in waterfall model. Users always tell their requirements in ambiguous, sometimes mysterious, ways. Thus, it is impossible to avoid changing requirements or discovering all hidden requirements. However, waterfall model does not allow active phrase to go back. Therefore, the project is destined to fail. Despite all criticisms, waterfall model value lies in its rigid structure. The structure of waterfall model is a foundation of many methodologies developed after it. The phrases are clear-cut and good as study materials. It also analyze system development tasks into easy-to-understand unit.

VARIATION â&#x20AC;&#x201C; REVERSE WATERFALL MODEL Waterfall model is good for rigid project which is fully specified by contract. However, contracted project usually allow the system to be modified to support changing requirements. Therefore, waterfall model must adapt to survive in system development world. The first variation of waterfall model is reverse waterfall model.

P a g e | 80

System Analysis and Design [436 303]

Planning Analysis Design Implementation Support FIGURE 33: REVERSE WATERFALL MODEL

Reverse waterfall model is simply a waterfall model that can take a step back at a time. For example, during design phrase, analysts may recollect requirements in case they change. It is important to note that reverse waterfall takes only one step backward. If a waterfall is brought back to the first step, it is not reverse waterfall. It is re-work, the case that all prior works have failed and the development team need to start fresh again.

VARIATION â&#x20AC;&#x201C; OVERLAP WATERFALL MODEL Planning Analysis Design Implementation Support FIGURE 34: OVERLAP WATERFALL MODEL

Overlap waterfall model is a water fall model that any phrase may be continued even after the project has been moved to another phrase except when the project enters support phrase. This means that planning phrase is never considered finished until the system is delivered. Same thing apply to other phrases except support. In P a g e | 81

System Analysis and Design [436 303] other word, if the project requires any changes in planning, analysis or design, it can be done without violating the model. Some of you may think about overlapping the entire project. For example, letting people do design during analysis could save a lot of time, doesnâ&#x20AC;&#x2122;t it? No. System development tasks are not so independent that any tasks can be performed at any time. Design cannot be performed without knowing the problem. Implementation will be full of bugs without a proper design. This dependency is a constraint that prevent overlap waterfall to overlap the entire SDLC.

ADVANTAGES AND DISADVANTAGES Advantages Simple / Easy to learn Easy to manage Good for stable project Clear milestone Easy to document

Disadvantages User canâ&#x20AC;&#x2122;t verify product early on High risk Poor for long project Cannot change requirement Coders are practically unemployed until implementation phrase In conclusion, waterfall model may not be good for practical used. It is great for learning SDLC. It may be used, in its variation form, for stable project. However, the drawbacks of waterfall model is it cannot adapt to changes. And things are always change. Reverse waterfall and overlap waterfall add more adaptability to the model. However, a step backward is not enough for ever-changing project. This leads to other methods called iterative method and spiral method.

ITERATIVE METHOD Also known as incremental development. Evolved after waterfall model, iterative method improve adaptability by adding more waterfalls into the equation. Iterative method allows developers to perform multiple waterfall for a single project. P a g e | 82

System Analysis and Design [436 303] This allows the project to accommodate changing requirements as well as deliver results. Since additional features can be added in the next iteration, iterative method usually takes less time in a cycle. The cycle is repeated again and again until the project is fully delivered. Figure 35: iterative model conceptFigure 35 shows the concept of iterative model. Planning Analysis Design Implementation

Planning

Support

Analysis Design

Planning

Implementation Analysis

Support

Design Implementation

Supp ort FIGURE 35: ITERATIVE MODEL CONCEPT

Iterative model enjoy highly successful implementation. Many variations are develop using its outline. RAD methods such as Agile method use this template with huge success. The core principle is that the most important or functional requirements are to be done in the first iteration. The less urgent and newly discovered requirements are to be done in the next iterations.

CRITICISM Iterative model carries the some disadvantages. Since it is a repeated waterfall, the cost required for the model is higher than a single waterfall. It is more difficult to P a g e | 83

System Analysis and Design [436 303] manage because there are many iterations before the project is fully delivered. The longer a programmer leaves a program, the more difficult to pick up and continue coding. Not to mention redesign and recode a portion of the program. It is similar to a writing you wrote five years ago and when you come back to read it, you can barely understand your thought back then. Therefore, documentations must be emphasized. Another problem with iterative model is that to plan for each iteration, you need to understand the whole project. Analyst must know which features are the most risky and must be done quickly in the very first iteration.

ADVANTAGES AND DISADVANTAGES Advantages Quickly & periodically produce result Less damage from changing scope and requirements Easier risk management than waterfall, the most risky done first Easier to implement smaller iteration Good for mission oriented project

Disadvantages Harder to manage than waterfall More resource is required for many iterations Designing iterations require knowledge of all system life cycle Not good for small project Need good risk analysis

Despite disadvantages, iteration model becomes a fundamental model for many system development methodologies, particularly RAD methodologies. It delivers result to the user fairly quickly. It is adaptable to changes. Therefore, it is suitable for extended project.

SPIRAL METHOD Spiral method or spiral model is a system development methodology which share some similarities with waterfall model and iterative model. For one, it consists of all phrases in waterfall model. These phrases are perform in order as well. It is also P a g e | 84

System Analysis and Design [436 303] has some kind of iterative characteristic. However, iterations are not totally cut-out like in iterative model. They are continual. Figure 36 displays a concept of spiral model.

Prototype Planning

FIGURE 36: SPIRAL MODEL CONCEPT

Spiral model start with overall project planning. It is important to plan the number of cycles needed to complete the project, otherwise there is a high chance that the spiral will never come to an end. This number of cycle can be changed as needed but it must be planned because changes affect financial aspect of every project. Risks are managed in this step too. The most risky should be performed first. After overall planning, the project proceed to analyze and design phrase. At the end of the phrase, a prototype should be presented to the users. Then, it is implementation phrase and integration phrase. After the first cycle is completed, the program should be evaluated. The team plan for next spiral. The new spiral should add the missing features and enhance the delivered one to better suit user requirements. This usually results in higher cost for the development team, therefore it is like a spiral which outer cycles are bigger than the inner ones. The spiral continues until the project is fully delivered. P a g e | 85

System Analysis and Design [436 303]

PROTOTYPE A prototype is a great tool for system developers to communicate with various parties. A prototype is an example of the finished program or the system. This can be mocking prototype, a graphical drawing of a program with a sample scenario, or working prototype, an operable program which is working but not complete for real world work. A prototype is used extensively in spiral and iterative model. It aids requirement discovery. After users see the prototype, they usually give hidden requirements which they have assumed the system will have at the first requirement gathering. For example, users may suggest that the text on the menu is too small and they want it bigger. Modifying a prototype is easier than the real system. Therefore, it can be used to confirm requirements of the users.

ADVANTAGES AND DISADVANTAGES Advantages Good for changing requirements User verify result through prototypes Requirements are verify in all spiral Risky tasks can be done in first spiral

Disadvantages Hard to manage The end of project may not be seen Not good for small / stable project Complex documentation

Spiral methodology is great for project with high risks because it is adaptable, similar to iterative method. However, it is even harder to manage than iterative method because it is continual. This also results in complex documentation with no concrete ending of an iteration. It is not good for small project because the project may end after the first spiral, make it a normal waterfall model. Another big disadvantage of spiral model is that the spiral may go on forever. This could be a result of bad planning or changing requirements. Unlike iterative method which each iteration can be cut to an end, spiral method cannot be cut out. P a g e | 86

System Analysis and Design [436 303] Furthermore, a new spiral consume more and more resources than the last spiral. This adds to difficulties of management and can leads to failure of a project.

RAPID APPLICATION DEVELOPMENT (RAD) Rapid application development or RAD is a new concept of system development life cycle. It is due to the changing world with competitive nature of digitalized and globalized business. System analysis and design must be fast adaptable to ever-changing nature of business. RAD emerged with enterprise scale information system. It also serve large scale information system which has new users all the time such as WEB 2.0 applications, such as Facebook or YouTube. Waterfall model is a sure way to fail on these projects. Iterative and spiral model can make it. However, the company developing the system cannot gain as much from the project as it should be. Therefore, a new way of system developments are needed and RAD is the answer. Planning & preliminary study

Analysis & Design

Implementation

Cutover FIGURE 37: RAD CONCEPT

P a g e | 87

System Analysis and Design [436 303] Figure 37 shows a concept of RAD method. The key phrases are still resemble waterfall model. However, the planning phrase is cut to only one phrase. Analysis and design phrase is merged. Analysis and design with implementation act like iterative model result in working prototypes for each iteration. Then, the project is deployed in cutover phrase. The key change in RAD is to enable user participation more deeply into system development process. RAD usually use JAD session to allow user to take active part in system development life cycle. This allows RAD to merge analysis and design phrases into one. Users help developer analyses the system and also help during design. Another key of RAD is the cutover phrase. Compare to traditional models which end with support phrase, RAD compresses all tasks into one single phrase. Data conversion, testing, deployment, training and transition are all performed at once. This reduce time for system delivery.

LEAN METHOD Lean method is developed on two principles, lean manufacturing and lean IT. Lean principle is originated from business management school. It crosses the border to IT school after extensive success in manufacturing such as demonstrated by

LEAN FACTORY Lean methodology has been implemented with extraordinary success in businesses. One of the examples is Toyota motor manufacturing plants. Think about it, you wake up in the morning and walk to your work place. You reach it at 8:00 AM and you see a truck coming as you enter the facility. That truck turns around. Put its end at a large gate. Big rolls of steel are carried out and into the factory. Then all goes the cranking and working sounds of robots and machines. You park your car and walk into your office. Watch monitoring panels. Yell at those who donâ&#x20AC;&#x2122;t do their job properly and when you walk about your lunch, you see a finished car being carried out of another end of the factory. At the same time, another truck carrying steel rolls come in. It changes place with the last one which just left. In case you are not impressed, think of it this way. A roll of steel becomes a complete car within hours! It is a beautiful management system. Every segment works in harmony. All people know their job. They know what is expected from their job and they grow more skillful every time they perform the task. Even a rookie do the work right the first time they get their hand on the job. Thatâ&#x20AC;&#x2122;s lean. No waste.

P a g e | 88

System Analysis and Design [436 303] Toyota. In case you have never been to Toyota manufacturing plant before, I expressed my impression of it in the lean factory panel. A video on YouTube showing Toyota factory can be linked to by QR code in Figure 385. A simplify lean principle is explained in Figure 396. In system development life cycle, lean is more like a philosophy than actual development model like SDLC. It consists of 4 principles. 1. Eliminate wastes Lean is literally â&#x20AC;&#x153;no fatâ&#x20AC;?. Lean methodology is like a horse with 100% pure muscle. The goal of lean method is to eliminate wastes. No unnecessary task to be performed. No delay or waiting time in development process. No unclear requirement. No repetition. No slow communication. Someone even joke that lean accept no bureaucracy.

FIGURE 38: TOYOTA FACTORY AS LEAN EXAMPLE

FIGURE 39: ANIMATION ON LEAN PRINCIPLE

2. Emphasize learning Lean requires great skill set. It is important for the team to learn quickly. This is why analysis and design phrases are combined. With user integration, developers can learn business process quicker than waiting for system analyst to summarize all requirements for them. Development process must go through test as soon as it is written, so the developer get feedback quickly and learn immediately. 5 6

Can be accessed at http://youtu.be/cYFB1rKHdqo Can be accessed at http://youtu.be/wfsRAZUnonI

P a g e | 89

System Analysis and Design [436 303] 3. Delay decision making System development can involve many changes and uncertainty. Therefore, delaying decision making can reduce risks substantially. To do so, the team must produce many options. This open the decision maker for wider decision making scenario and therefore reduce risks. 4. Accelerate delivery As known as “just in time” delivery, lean production accelerate production to meet delivery schedule. This results in shorter iteration. Many iteration means the team has many chances to communicate with users, results in amplified learning. 5. Strengthen teamwork Teamwork is essential for lean method because the team need to work together in harmony for the model to work out. The team must put the right person on the right job in order to make “just in time” delivery possible. The team must share mutual trust for delayed decision making to be possible. Harmonious teamwork also allow waste to be at minimum and the production flow perfect. 6. Integrate user Lean principle encourage “demand pull” from the customer. Lean development also encourage user to pull the development toward their direction. This is why lean method involve many iterations. User must be integrated into every iteration to share their requirement. They must work closely to the developers. In case there are any changes in system

P a g e | 90

System Analysis and Design [436 303] requirements, the developers know quickly because the users are there with them. 7. See big picture Team members must has a deep understanding in lean principle. This allows them to know their part in a bigger team. Large information system usually involve many development teams and other parties. Without common sense of development model, the team cannot work in harmony. Therefore, team members must know that they are parts of lean software development.

ADVANTAGES AND DISADVANTAGES Advantages High efficiency

Disadvantages Highly dependent on teamwork and commitment of team members Quick product delivery Users must know exactly what they want before development can begin Facilitate team learning Difficult to manage right Lean method is extremely effective. The model itself become fundamental of many modern system development methodologies. However, it is extremely difficult to pull off right. It is particularly difficult for manager because the whole process must all be systematic. It is also require great team to work together seamlessly. They must dedicate themselves to the team. Otherwise, they may just left in the middle of the project and wrack the whole process. Lastly, user who “pull” the product must know exactly what they want before the process can begin. Otherwise, changing can cause wastes during development. Lastly, lean software development is summarized in this short quotation. “Think big, act small, fail fast; learn quickly” - Mary and Tom Poppendieck P a g e | 91

System Analysis and Design [436 303]

EXTREME PROGRAMMING Extreme programming or XP is one of RAD models. It is a methodology that gain much success and much failure. XP done wrong is no better than blind coding. The core of XP is to eliminate design phrase and get start with coding immediately. Now, you see why it becomes notorious, right? Figure 407 shows the concept of XP development.

FIGURE 40: EXTREME PROGRAMMING CONCEPT

XP prioritize most important code to be coded first. If the project is stopped before it is completed, there is a high chance that the product is still functional. Therefore, XP eliminates “big design upfront”. This results in less to no documentation at all. However, it is extremely adaptable because coding phrase is long and any changes affect implementation immediately. XP is famous for the concept of “pair programming”. Pair programming is to put two programmers in front of one computer. It is one of the most productive, yet ridiculous, setting for programmers. Let’s face it. When you work with computer, the most wasteful time spend is on Facebook and email, right? Having another person right next to you, staring at your Facebook, is not something very good for you. Programmers, too, are less likely to waste time on something else rather than work, if there are someone right next to him.

(Wikipedia, 2013)

P a g e | 92

System Analysis and Design [436 303] Now, you have a pair of programmers in front of a computer. There is no design, except the vague imaginary picture of the system in your head, just put the user between the pair and start programming. This is why XP is called extreme programming. It is development methodology that the user and the programmer develop the system together. It requires programmer with exceptional skill to be able to code something right there, right then. Any changes in requirements are handled in front of the computer. Larger team involves more users and such programmers. Therefore, great cooperation tools are needed and CASE tools are essential. Despite its scary face, XP enjoy its share of success. With skilled programmers, XP is a useful tool. In your working life, you may find some programmers who always do XP without knowing it.

ADVANTAGES AND DISADVANTAGES Advantages Extremely quickly deliver results Suitable for project with ridiculously close deadline and high risk User can verify result In-time feedback

Disadvantages Require great developer skills Require great involvement from users Lack, if not none, documentation Can lead to contract problems

XP is quick moving development model. Figure 40 shows that release plan is marked by â&#x20AC;&#x153;monthsâ&#x20AC;?. This means that XP usually finish the whole system development in a few months. Tests are perform in a matter of minutes and programming performance is evaluated in seconds. This offer a lot of advantages. XP is good for short project with tight deadline. It is also good for project with high risk. This is because any changes show up quickly and can be fix in time. However, it is not good for prolonged project because there is little to no documentation. If a programmer dies from heart attack, the project suffers great lost. P a g e | 93

System Analysis and Design [436 303]

AGILE METHOD (WITH SCRUM) Agile method is currently one of the most successful RAD methodology. It is highly adaptive and incorporate some aspect of lean principle. It allows the team to improve their skills while keeping track on work. Agile method focuses on 4 aspects, people, communication, product and flexibility. Agile is also famous for its manifesto, which has been translated into many languages. This is the manifesto (Beck, Kent. et al., 2001)8. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more Agile manifesto expresses the important aspect of agile methodology. It focuses on people. Development team is also developed by hard work and continuous learning rather than simply using tools to complete the jobs. Documentation is minimized. The software or the product has higher priority. Customer must be highly

The full manifesto and Thai translation can be accessed at : http://agilemanifesto.org/

P a g e | 94

System Analysis and Design [436 303] involved in the product development. The contract must be kept but it is not as important as having the real user takes part in development. Lastly, agile is adaptive and flexible. The plan may be wasted as time changes, but agile will respond to those changes quickly enough to finish the project.

AGILE PRINCIPLES There are 12 Agile Principles. These principles are a set of guide line concepts that support development teams in implementing agile projects. Agile developers and project managers should keep these principle in mind as they work. 1. User satisfaction is the number one priority. We achieve it through quick and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile method work with changes to improve user's competitive advantage. 3. Deliver working software frequently. Agile takes a few weeks to a few months to finish an iteration. Use as short time as possible. 4. Work together. Business people and developers must work together. This work is daily. It goes on throughout the project. 5. Encourage/motivate individuals. Build the environment and support they need. Once they get motivated, trust them on their job. 6. Use face-to-face conversation. As it is the most effective and most efficient communication. 7. Product is progress. Use working software as a primary measure of progress. P a g e | 95

System Analysis and Design [436 303] 8. Promote sustainable development. Stakeholders, developers, and users should be able to maintain a constant pace indefinitely. They should not be burned out. 9. Always thrive for technical excellence. Good design enhances agility. Good agility makes more satisfaction. 10. Make things simple. Keep the software and development simple. Do not do anything that does not produce value. 11. Use self-organized team. The best architectures, requirements, and designs emerge from selforganizing teams. 12. Team evolves. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

ROLES OF PEOPLE It takes a cooperative team of employees to complete a project. Agile project teams are made up of many people and include the following five roles: Development team: The group of people who do the work of creating a product. Programmers, testers, designers, writers, and anyone else who has a hands-on role in product development is a member of the development team. Product owner: The person responsible for bridging the gap between the customer, business stakeholders, and the development team. The product owner is an expert on the product and the customer's needs and priorities. The product owner works with the P a g e | 96

System Analysis and Design [436 303] development team daily to help clarify requirements. The product owner is sometimes called a customer representative. Scrum master: The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent. A scrum master is sometimes called a project facilitator. Stakeholders: Anyone with an interest in the project. Stakeholders are not ultimately responsible for the product, but they provide input and are affected by the project's outcome. The group of stakeholders is diverse and can include people from different departments, or even different companies. Agile mentor: Someone who has experience implementing agile projects and can share that experience with a project team. The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a higher level.

PROGRESS TRACKING Project progress must be measurable. These are items which can be used to track progress. Product vision statement: An elevator pitch, or a quick summary, to communicate how your product supports the company's or organization's strategies. The vision statement must articulate the goals for the product. Figure 41 is an example of product vision statement. P a g e | 97

System Analysis and Design [436 303]

FIGURE 41: PRODUCT VISION STATEMENT

Product backlog: The full list of what is in the scope for your project, ordered by priority. Once you have your first requirement, you have a product backlog. It is usually a long list of user stories. You can see an example of user story in appendix I. Product roadmap: The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements. Release plan: A high-level timetable for the release of working software. Sprint backlog: The goal, user stories, and tasks associated with the current sprint. Figure 42 is an example of product backlog.

P a g e | 98

System Analysis and Design [436 303]

FIGURE 42: SPLINT BACKLOG

Increment: The working product functionality at the end of each sprint.

AGILE EVENTS Most projects have stages. Agile projects include seven events for product development. These events are meetings and stages and are described in the following list: Project planning: The initial planning for your project. Project planning includes creating a product vision statement and a product roadmap, and can take place in as little time as one day. Release planning:

P a g e | 99

System Analysis and Design [436 303] Planning the next set of product features to release and identifying an imminent product launch date around which the team can mobilize. On agile projects, you plan one release at a time. Sprint: A short cycle of development, in which the team creates potentially shippable product functionality. Sprints, sometimes called iterations, typically last between one and four weeks. Sprints can last as little as one day, but should not be longer than four weeks. Sprints should remain the same length throughout the entire projects. Sprint planning: A meeting at the beginning of each sprint where the scrum team commits to a sprint goal. They also identify the requirements that support this goal and will be part of the sprint, and the individual tasks it will take to complete each requirement. Daily scrum: A 15-minute meeting held each day in a sprint, where development team members state what they completed the day before, what they will complete on the current day, and whether they have any roadblocks. Sprint review: A meeting at the end of each sprint, introduced by the product owner, where the development team demonstrates the working product functionality it completed during the sprint. Sprint retrospective: A meeting at the end of each sprint where the scrum team discusses what went well, what could change, and how to make any changes. P a g e | 100

System Analysis and Design [436 303]

AGILE STEP BY STEP Agile is very different from waterfall model. You can say it is the opposite polarity of traditional SDLC methodology. This section shows you how agile project management is perform in step by step, according to Mark C. Layton (Layton, 2013).

FIGURE 43: AGILE ROAD MAP TO VALUE

Step 1: vision The product owner identifies the product vision. The product vision is a definition of what your product is, how it will support your company or organizationâ&#x20AC;&#x2122;s strategy, and who will use the product. On longer projects, revisit the product vision at least once a year. Step 2: Roadmap

P a g e | 101

System Analysis and Design [436 303] The product owner creates a roadmap. The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements are a large part of creating your product roadmap. On longer projects, revise the product roadmap at least twice a year. Step 3: Release plan The product owner creates a release plan. The release plan identifies a highlevel timetable for the release of working software. An agile project will have many releases, with the highest-priority features launching first. A typical release includes three-to-five sprints. Create a release plan at the beginning of each release. Step 4: Splint plan The product owner, the master, and the development team plan sprints, also called iterations, and start creating the product within those sprints. Sprint planning sessions take place at the start of each sprint, where the scrum team determines what requirements will be in the upcoming iteration. Step 5: Daily scrum During each sprint, the development team has daily meetings. In the daily meeting, you spend no more than 15 minutes and discuss what you completed yesterday, what you will work on today, and any roadblocks you have. Step 6: Splint review The team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product created during the sprint to the product stakeholders. Step 7: Sprint retrospective P a g e | 102

System Analysis and Design [436 303] The team holds a sprint retrospective. The sprint retrospective is a meeting where the team discusses how the sprint went and plans for improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every sprint.

ADVANTAGES AND DISADVANTAGES OF AGILE WITH SCRUM Advantages Good for ever-changing environment Promote teamwork Flexible for developers Result is delivered partially & regularly

Disadvantages Application can be hard to maintain Require good cooperation tools User must involve in development Highly dependent on people because minimum documents are made

P a g e | 103

System Analysis and Design [436 303]

CASE STUDY LONDON AMBULANCE SERVICE London ambulance service or LAS is a classic case study for software failure that makes word-processing-crashes-and-I-havenâ&#x20AC;&#x2122;t-save-my-work or blue screen of death a child prank. LAS software failure turned into catastrophic incident because of its business nature. People dies when ambulance does not get to them in time. According to a study on the project (Johnson, 2003), LASCAD went live on the 26th October 1992. In the month before that date, the system was operated in a semimanual fashion. Calls were taken via the system and paper copies were printed as back-ups to the electronic information. An allocator was assigned to work with a radio operator and a dispatcher. Central Ambulance Control staff could, therefore, override suggested resource allocations when a number of problems occurred. The following list summarizes these problems. It should be noted that the term "exception" is used to describe a wide range of error messages displayed by the system rather than the more usual sense of the word within software engineering: 1. Failure to detect all duplicated calls 2. Lack of prioritization of exception messages 3. Exception messages and awaiting attention calls scrolling off the top of the allocators or exception rectifiers screens 4. Software resource allocation errors 5. Workstation and mobile data terminals lockups 6. Slow response times for certain screen-based activities A number of changes were made to the system in the light of these problems. However, these focused on the management and operation of the software rather than on the bugs themselves. The decision was made to run the system without the manual P a g e | 104

System Analysis and Design [436 303] backup and to extend the scope of the trial from three divisions to cover the entire capitol: "On 26 and 27 October 1992, the computer system itself did not fail in a technical sense. Response times did on occasion become unacceptable but overall the system did what it had been designed to do. However, much of the design had fatal flaws that would, and did, cumulatively lead to all of the symptoms of system failure. In order to work effectively, the system needed near perfect information all of the time. Without this the system could not be expected to propose the optimum resource to be allocated to an incident. There were many imperfections in this information, which individually may not have been serious, but which cumulatively were to lead to system "failure". The changes to Central Ambulance Control operation on 26 and 27 October made it extremely difficult for staff to intervene and correct the system. Consequently, the system rapidly knew the correct location and status of fewer and fewer vehicles. The knock-on effects were: 1. poor, duplicated and delayed allocations; 2. a buildup of exception messages and the awaiting attention list; 3. a slow up of the system as the messages and lists built up; 4. an increased number of call backs and hence delays in telephone answering". As a result of these problems, the Central Ambulance Control resorted to semimanual operation. This was based on the methods that were adopted in the month prior to the 26th and 27th October. The system achieved a certain amount of acceptance. Local stations could override some of the automated allocations. However, shortly after 2am on 4th November the system slowed and then locked-up. Re-booting failed to rectify the problem. This had serious consequences. It was impossible to print out information about the calls that were already in the system. As a result, management had to go back and monitor the voice recordings of incoming calls that had been received in the period immediately before the failure. Once this was done, they then reverted to fully manual operation. P a g e | 105

System Analysis and Design [436 303] "The Inquiry Team has concluded that the system crash was caused by a minor programming error. In carrying out some work on the system some three weeks previously the Systems Options programmer had inadvertently left in the system a piece of program code that caused a small amount of memory within the file server to be used up and not released every time a vehicle mobilization was generated by the system. Over a three week period these activities had gradually used up all available memory thus causing the system to crash. This programming error should not have occurred and was caused by carelessness and lack of quality assurance of program code changes. Given the nature of the fault it is unlikely that it would have been detected through conventional programmer or user testing." The consequences of these various failures were widely reported in the national and international press. One ambulance arrived to find that a patient had already died and had been taken away by the undertakers. Another ambulance eventually arrived eleven hours after assistance had originally been requested for the victim of a stroke. The Chief Executive of the London Ambulance Service resigned. However, the official report also argued that Coronerâ&#x20AC;&#x2122;s courts had not cited the late arrival of an ambulance as the direct cause of a fatality during any of these failures. Thus, end the catastrophe of LAS software project failure. There are many lessons to be learned here, so that lives are not lost in vain. Figure 44 and Figure 45 shows list of failures categorized by type of failures (Johnson, 2003). A paper explaining the incident can be read in appendix II.

P a g e | 106

System Analysis and Design [436 303]

FIGURE 44: LAS MANAGERIAL FAILURE

P a g e | 107

System Analysis and Design [436 303]

FIGURE 45: LAS OTHER MAJOR FAILURES

P a g e | 108

System Analysis and Design [436 303]

CONCLUSION System analysis and design course introduce various aspect of information system development. Students learn about preliminary studies before information system can be build, or considered to be build. Then, following system development life cycle as a template, students learn various diagrams for analysis and design tasks. Dataflow diagram is used for data modelling, explaining how data flow through the system and how they interact with processes. Entity Relationship Diagram explains how data are stored. Sequence diagrams and flowcharts are for process modelling, explaining how each process works. Sequence diagram also shows how they interact with users and other processes. Use case diagram explains user interaction with information system. Mockup interface is used to communicate between developers, users and designers of how the software looks like. Class diagram is also introduced. It is used for explaining object oriented design. Then, software development methodologies are introduced. Started with traditional SDLC and move toward more adaptive methodologies. Iterative model, Spiral model, Lean software development and Agile with Scrum are software development methodologies worth knowing. Agile, in particular, is extremely popular because of its usefulness. Thus, students learn how information system is made. They learn some diagram drawing and reading skills they need to work with information system development. This knowledge should aid them in future work. Hopefully, they are no longer rushing their project toward the final anymore. P a g e | 109

System Analysis and Design [436 303]

BIBLIOGRAPHY Beck, Kent. et al. (2001). Manifesto for Agile Software Development. Retrieved from Manifesto for Agile Software Development: http://agilemanifesto.org/ Bell, D. (2004, February 16). UML basics: The sequence diagram. Retrieved from IBM.com Library: http://www.ibm.com/developerworks/rational/library/3101.html Bennett, S., McRobb, S., & Farmer, R. (2006). Object-oriented systems analysis and design using UML. London: McGraw-Hill Education. Clark, W., & Gantt, H. L. (1923). The Gantt chart, a working tool of management. Retrieved from Internet Archive: http://archive.org/details/ganttchartworkin00claruoft Geller, S. E. (2013, October 22). The Stages of Teamwork. Retrieved from Safety Performance Solution: http://www.safetyperformance.com/thestagesofteamwork.pdf Hebb, N. (2013, November 11). BreezeTree Software. Retrieved from Flow Chart Symbols Cheat Sheet: http://www.breezetree.com/articles/flow-chartsymbols.htm Hoffer, J. A., George, J. F., & Valacich, J. S. (2008). Modern systems analysis and design. Upper Saddle River, N.J.: Pearson/Prentice Hall. Johnson, C. (2003, March 13). A Case Study in the Integration of Accident Reports and Constructive Design Documents. Retrieved from A First Step Towards the Integration of Accident Reports and Constructive Design Documents: http://www.dcs.gla.ac.uk/~johnson/papers/safecomp_best/ P a g e | 110

System Analysis and Design [436 303] Layton, M. C. (2013, December 13). Agile Project Management For Dummies. Retrieved from For dummies: http://www.dummies.com/how-to/content/agileproject-management-for-dummies-cheat-sheet.html Marakas, G. M. (2006). System analysis & design : an active approach. New York: McGraw-Hill/Irwin. Microsoft. (2013, November 7). UML Class Diagrams: Guidelines. Retrieved from MSDN: http://msdn.microsoft.com/en-us/library/vstudio/dd409416.aspx Mountain Goat Software. (2013, December 13). Product Backlog Example. Retrieved from Mountain Goat Software: http://www.mountaingoatsoftware.com/agile/scrum/product-backlog/example/ Pichler Consulting Limited. (2011, May 10). The Vision Board. Retrieved from Pichler Consulting: http://www.romanpichler.com/blog/product-vision/the-productvision-board/ Sattzinger, J. W., Jackson, R. B., & Burd, S. D. (2007). System analysis & design in a changing world. Boston: Thomson course technology. Sauter, V. L. (2011, January 15). Random (Humorous) Thoughts on Information Systems Analysis -- What We Do . Retrieved from Humor in Systems Analysis: http://www.umsl.edu/~sauterv/analysis/random_analysis_thoughts.html Wetherbe, J. C., & Vitalari, N. P. (1994). Systems Analysis and Design. St. Paul: West. Whitten, J. L., Bentley, L. D., & Dittman, K. D. (2001). System analysis and design methods (5th edition). McGraw-Hill. Wikipedia. (2013, July 26). File:Extreme Programming.svg. Retrieved from Wikipedia: http://en.wikipedia.org/wiki/File:Extreme_Programming.svg

P a g e | 111

System Analysis and Design [436 303] ภักดีวฒั นะกุล, ก., & พานิชกุล, พ. (2551). การวิเคราะห์ และออกแบบระบบ = System analysis and design. กรุ งเทพฯ: เคทีพี. ภัคดีวฒั นะกุล, ก., & กลมกล่อม, ก. (2552). การวิเคราะห์ และออกแบบระบบเชิ งวัตถุด้วย UML. กรุ งเทพฯ: เคทีพี คอมพ์ แอนด์ คอนซัลท์.

P a g e | 112

System Analysis and Design [436 303]

APPENDIX I PRODUCT BACKLOG EXAMPLE9

(Mountain Goat Software, 2013)

P a g e | 113

System Analysis and Design [436 303]

Profiles 

 



 



 



As a site member, I want to describe myself on my own page in a semistructured way. That is, I can fill in predefined fields, but also have room for a free-text field or two. (It would be nice to let this free text be HTML or similar.) As a site member, I can fill out an application to become a Practitioner. As a Practitioner, I want my profile page to include additional details about me (i.e., some of the answers to my Practitioner application). As a site member, I can fill out an application to become a Trainer. As a Trainer, I want my profile page to include additional details about me (i.e., some of the answers to my Trainer application). As a Practitioner or Trainer, when I provide content to the site I want a small graphic associated with the content indicating I’m a Practitioner or Trainer. (For example, Amazon’s “Top 500 Reviewers” approach.) As a trainer, I want my profile to list my upcoming classes and include a link to a detailed page about each. As a site member, I can view the profiles of other members. As a site member, I can search for profiles based on a few fields (class attended, location, name). As a site member, I can mark my profile as private in which case only my name will appear. As a site member, I can mark my email address as private even if the rest of my profile is not. As a site member, I can send an email to any member via a form. As a site administrator, I can read practicing and training applications and approve or reject them. As a site administrator, I can edit any site member profile.

News 

As a site visitor, I can read current news on the home page. P a g e | 114

System Analysis and Design [436 303]  



As a site visitor, I can access old news that is no longer on the home page. As a site visitor, I can email news items to the editor. (Note: this could just be an email link to the editor.) As a site a site editor, I can set the following dates on a news item: Start Publishing Date, Old News Date, Stop Publishing Date. These dates refer to the date an item becomes visible on the site (perhaps next Monday), the date it stops appearing on the home page, and the date it is removed from the site (which may be never). As a site member, I can subscribe to an RSS feed of news (and events? Or are they separate?). As a site editor, I can assign priority numbers to news items. Items are displayed on the front page based on priority.

Courses and Events 



As a site visitor, I can see a list of all upcoming “Certification Courses.” I can page through them if there are a lot. As a site visitor, I can see a list of all upcoming “Other Courses” (noncertification courses). I can page through them if necessary. As a site visitor, I can see a list of all upcoming “Events.” (Events are things such as the Scrum Gathering, conferences, free seminars, etc.) As a trainer, I can create a new course or event. This includes the following information: name, description (HTML), trainer names (multiple selection from a list), start date, end date, venue name (HTML) and address, contact name, contact phone, contact email, a link for more information, and a link to register. For a certification course the name of the class is a dropdown list; for others, it is free text. As a trainer, when I create an Other Course or Event, I am charged a listing fee for that activity. (Note: We’ll need this to tie into credit card processing.) As a site administrator, I can create an Other Course (?) or Event that is not charged a listing fee. This is so that the Scrum Alliance doesn’t charge itself for Scrum Gatherings that it puts on. As a site administrator, I can set the listing fee per Other Course or Event. P a g e | 115

System Analysis and Design [436 303]   

  



As a trainer, I can update one of my existing courses or events. As a trainer, I can delete one of my courses or events. As a trainer, I can copy one of my courses or events so that I can create a new one. When copying it I am asked for the date(s) of the new course or event. As a site admin, I can delete any course or event. As a site editor, I can update any course or event. As a trainer, admin, or editor, I can turn a course into an event or an event into a course (in case it was entered in the wrong category). (Note: making something a Certification Course will probably require selecting the name of the course from the pre-approved list.) As a site visitor, I have an advanced search option that lets me fill in a form of search criteria (country, state, trainer name, date range, word in description, etc.). As a site visitor, when I’m viewing a course I can click on the trainer’s name and be taken to the trainer’s profile. As a site visitor, I can subscribe to an RSS feed of upcoming courses and events.

FAQs   

As a site visitor, I can read FAQs. As a site editor, I can maintain an FAQ section. As a site member, I can do a full-text search of the FAQs. (Maybe we want this for any site visitor?)

Resource 



As a site member, I can download the latest training material and methodology PDFs. As a visitor, I can download presentations, PDFs, etc. on Scrum that I can use. P a g e | 116

System Analysis and Design [436 303] 

....more needed here..................

Jobs 

 



  



As a site member (?), I can scroll through a listing of jobs. (There won’t be enough at first to justify search fields.) As someone who wants to hire, I can post a “help wanted ad”. As a site admin, I need to approve each help wanted ad before it gets to the site. As a site admin, I am emailed whenever a job is submitted (so that I am aware of it and can decide if I want to post it). As a site member, I can subscribe to an RSS feed of jobs available. As a site admin, I can edit and delete help wanted ads. As a site admin, I want jobs to stop publishing on the site 30 days after being posted. (Note: 30 days doesn’t need to be configurable at this point. Hardcoding is fine for now.) As someone who wants to hire, I want to be able to extend an ad for another 30 days (repeatedly) by visiting the site and updating the posting. (Note, I can’t update it 10 times today and extend the posting 300 days today.) As someone who has posted an ad that is about to expire, seven days before it expires I want to be emailed a reminder so that I can go extend the ad. (Note: This means the ad could have an expiration date 37 days into the future, which is fine.)

Articles 



As a site visitor, I want to read a new article on the front page about once a week. As the site editor, I can include a teaser with each article. The teaser shows up on the front page for all to read. As a site member who has read a teaser on the front page, I want to read the entire article. (Note: We want any site visitor to read articles for now.) P a g e | 117

System Analysis and Design [436 303]  



  

 

As the site editor, I can add an article to the site. As a site editor, I can set start publishing dates (when teaser appears on front page), old article date (when it disappears from home page), and stop publishing dates (when it's removed from site, if ever) for articles. As a site editor, I want to be able to designate whether or not an article (or for that matter any piece of info) ever makes the home page... some things will not. As the site editor, I have pretty good control over how the article looks (include images and captions, for example). As a site visitor, I want the link from the article teaser to take me directly to the body of the article... not to another teaser setup. As a site editor, I want to be able to indicate whether an article is publicly available or for members only. As a site visitor, I want to be able to read some of your articles. As a site member, I want to have full access to all articles. As a site visitor, I can do a full-text search of article body, title, and author name. As a site visitor, I can subscribe to an RSS feed of articles. (Teasers only?) As a site visitor, I can post comments about articles so that others can read them.

Home Page 



  



As a site editor, I want to have a prominent area on the home page where I can put special announcements, not necessarily news or articles. As a site editor, I'd like to have some flexibility as to where things appear to accommodate different types of content. As a site member, the upcoming courses are what I want visitors to notice. As a site visitor, I want to see new content when I come to the site. As a site visitor, I want to have articles that interest me and are easy to get to. As a site editor, I have ideas on how I want the home page to look and feel. P a g e | 118

System Analysis and Design [436 303] 



As a site visitor, I need to know as soon as I visit what on earth Scrum is, and why it needs an alliance. As a site visitor, I want to know as I glance around the home page what on earth a CSM is and why I'd want to be one. As a site visitor, I want to be able to get back to the home page quickly and easily. As a site visitor, I want to see a list of the most popular items on the site. (Note: Not everything has to be considered. For example, we don’t need to know the most popular profile but it would be useful to a have a "most popular" box that listed the most popular articles, news items, or etc.)

Ratings 



As someone who successfully completed a Certification Course (becoming a Certified ScrumMaster or Certified Product Owner), I am emailed a link to a survey about the course and instructor. As a trainer, I want to be assured that no one can submit the same answers multiple time and skew my results. As a trainer, I am notified about the results of surveys about my classes. (Questions: After each survey? After a set period of time? Does the trainer get an email or just know to go to the site?) As a site admin, I can see the results for each trainer and averages for the class (for all trainers). As a site visitor who is considering attending a certification course, I want to see a trainer’s rating (either for that course or for all of his or her certification courses combined). As a trainer, I want my rating to show up on my profile page.

What Is Scrum? 

As a site visitor, I want there to be a section of the website that teaches me the basics of what Scrum is. P a g e | 119

System Analysis and Design [436 303] 

As a site editor, I can create the content of the What Is Scrum section.

Registry 



 



As a site visitor, I can view lists on the site of all Certified ScrumMasters, Practitioners, Trainers, and Certified Product Owners. (The CSM list has over 5,000 names so a letter-based pagination approach is needed.) As a CSM, Practitioner, or Certified Product Owner, I can have my name listed in the registry without becoming a member of the site. (For example, I take a certification class but never register or let my membership lapse.) As a trainer who has finished teaching a Certification class, I can load an Excel file (first name, last name, email) into the site. I am prompted for the trainer names (I may not have trained alone), certification date, and type of certification (i.e., CSM or CPO). The names are loaded into a pending state and not yet added to the registry. (Note: We could have this charge $50 per person right then.) As a site admin, I can view all classes in a pending state. As a site admin who has received proof of payment from a trainer, I can move people in his or her class from a pending state to the registry. As a new Certified ScrumMaster or Certified Product Owner, once my name has been loaded to the registry I am sent an email welcoming me to the Scrum Alliance and containing instructions on how to register / activate my membership. As a site editor, I can edit the content of the email automatically sent to new Certified ScrumMasters and Product Owners.

Membership 

As a company, I can join the Scrum Alliance by paying a corporate membership fee. This will include uploading items related to corporate membership (e.g., company description, a logo of size x by y).

P a g e | 120

System Analysis and Design [436 303] 



 



As a corporate sponsor, my logo is displayed on a “corporate sponsors” page just like at http://www.agilealliance.org/portal_url/corporatemembers. (Note that the display order on that page is random.) As a corporate sponsor I want my logo to randomly appear on the home page. (That is, it rotates among other corporate sponsors.) As a CSM or CPO who has been approved for Practitioner status (by a site admin reading my submission), I am charged a fee. As someone about to become a trainer, I can pay an annual fee. As a site administrator, I can set the annual fees for members, Practitioners and Trainers. As someone whose membership (of any type) is about to expire, I am sent a reminder and a link through which I can renew. (Note: Think about overlapping memberships and prorating.) As a member with short-term memory problems, I can have the system email me a new password or a password reminder, possibly my username (unless we use email for that), and so on.

For Trainers Only  

As a trainer, I can read information of relevance only to trainers. As a site editor, I can post information in a trainers-only section.

P a g e | 121

System Analysis and Design [436 303]

APPENDIX II LAS CASE STUDY

P a g e | 122

System Analysis and Design [436 303] London Ambulance Service Software Failure Mukhtar Adamu, Abdulhameed Alkazmi, Abdulmajeed Alsufyani, Bedour Al Shaigy, Dominic Chapman, Julian Chappell Abstract - Software projects often fail, which could lead to huge amount of losses in terms of financial resources, lives or time, amongst others. The London Ambulance Service (LAS) Computerized Dispatch System (CAD) Project which spanned for 5 years (1987 - 1992) serves as a good example of a software failure. The Project involved changing from the slower, cumbersome and sometimes unreliable LAS manual dispatch system to a more efficient and fully computerized system. The first attempt (1987 - 1990) failed, after sinking £7.5 million into the project. The second attempt (1992) also collapsed barely 9 days after the system was launched, leading to loss of lives and financial resources. This paper gives an account of the LAS CAD project; identified the problems it encountered and brought out the reasons behind its failure. Our opinions were highlighted and suggestions made. It is believed that this research work will serve as a reference point for avoidance of future software projects failures, considering the complexity of the CAD Project and the catastrophe it caused.

INTRODUCTION

Computerized systems are becoming a key component to the efficient working of organizations. Due to the world becoming a more competitive environment, computerised or automated systems are used to aid organizations become more efficient. As a result of this, series of software projects have evolved over the years, some of which have been successful, where others have failed. The three potential aspects of failure can be due to a number of factors; complete system collapse, going over time and budget as well as failure to provide the correct functionality. Consequences of software failure can result in severe financial loss, time or resources or in extreme cases, all of them. In this report, we will discuss the London Ambulance Service (LAS) Computerised Dispatch System (CAD) which failed in the three aspects, resulting in human and financial losses. The LAS deals with over 2000 calls on an average day with a fleet of 750 vehicles, so their systems are an integral part of their efficiency to deal with emergencies. This system was originally manually operated until in 1987 when an automatic service was introduced. The purpose of this paper is to investigate the implementation of the LAS CAD system as well as its shortcomings. The objectives are to identify the causes of its failure, while recognising what could have been prevented and lessons to be learned in order to prevent the future occurrence of such failure.

II. BACKGROUND: THE LAS IN 1992 Founded in 1930, the LAS is the largest ambulance service worldwide responding to between 2000 and 2500 calls per day with a fleet of 750 vehicles under its disposal. The service covers the greater London area (600 square miles) with the cooperation of the London Fire and Civil Defence Authority and the Metropolitan Police. It compromises of the

Accident and Emergency Service (A&E) and Patient Transport Service (PTS). Ever since 1974 it has become part of the National Health Service (NHS) and is funded by the government. According to the report of the inquiry into the London Ambulance Service (published in February 1993) its budget income for the years 1992/3 was £69.7 million with 2700 staff employed at the time. The LAS carries out the responsibility of answering emergency calls, screening them and then dispatching an ambulance to the incident scene in less than three minutes. Manual Dispatch System and the Need for CAD The LAS had been contemplating replacing their manual system since the early 1980’s, in line with other ambulance, fire and police services. The paper-based, manual system they wanted to replace involved three distinct phases [1]: Call taking – At Central Ambulance Control (CAC) a Control Assistant (CA) writes down the call details on a preprinted form, including the reference coordinates of the incident location, which has to be identified from a map book. The form is placed onto a conveyer belt, together with details of calls from other CA’s, for transport to a central collection point. Resource Identification – At the central collection point, the details are reviewed by another staff member who gives the form to one of the three resource allocators, depending on whether the incident occurred within the North East, North West or South division. The resource allocator is responsible for maintaining a form for each ambulance with information about the location and status of the vehicle; such information is reported by the ambulance’s radio operator. The resource allocator uses this information to decide which ambulance to send to the call. The choice is noted on the form and the form passed to a dispatcher. Resource Mobilisation – The dispatcher would telephone the relevant ambulance station or, if the ambulance is already in the field, would pass mobilisation instructions directly to the ambulance’s radio operator. Appendix A shows the diagrammatical expression of LAS manual operation. This manual system had some clear shortcomings, which a CAD system might address, including: x Finding incident co-ordinates from a map book was time consuming and error prone, particularly given the often distressed calls. x The movement of paper around the control centre was inefficient. x The requirements for maintaining location and status information for ambulances by the resource allocator was labour intensive and time consuming. x Sometimes more than one person would call an ambulance to the same incident. Identification of

System Analysis and Design [436 303] such duplicated calls relied on human judgement and memory and was error prone. x Conformity with prevailing performance standards required that this manual process was to be completed within three minutes, but that is not mostly the case. Components and Functions of CAD A CAD system typically consists of the following components running at the command centre [2]: x CAD hardware and software x Gazetteer and Mapping software x A communications interface x A radio system Additionally, the following components would be attached to ambulances: x Mobile data terminals x Automatic vehicle location system Its functions typically consist of: x Taking calls about incidents x Automatic resource allocation x Communication of incident details to the chosen ambulance x Management and location of suitably equipped and staffed vehicles in order to minimise response times x Production of MIS reports to support longer term resource planning First Attempt A previous attempt had been made to automate the LAS’ dispatch system at a cost of £7.5 million. This project was started in the 1980’s when company called IAL was selected to supply a system without mobile data but with a new radio interface. The specifications were changed in 1989 to include mobile data. The project was abandoned in the autumn of 1990 after it was found that the system would not cope under the expected load. [1]. Second Attempt The second attempt by LAS to design and implement a CAD system began shortly after the abandonment of the first. Key dates [2] were: x Autumn 1990 – to February 1991 – writing of system requirements specification (SRS) x 7 February 1991 – invitation to tender published in the Journal of European Communities x May 1991 – contract to supply the CAD software signed with System Options Ltd. x June and July 1991 – system design specification x September 1991 - contract to supply mobile data equipment with Solo Electronic Systems Ltd. x 8 January 1992 – planned date of original implementation

III. THE INCIDENT On the morning of Monday 26th October 1992 the LAS CAD system went live for the first time. Unfortunately there were

81 known bugs in the system at that time and it had been 10 months since the control room staff were first trained to use the software. The system had 4 primary flaws when it went live; it did not function well when it was given incomplete data regarding the status of the ambulances and the system did not accept errors made that occurred in normal day-today use of a computer system. Furthermore, the user interface had black spots which meant that the user could not see all the information on screen and finally, the most important failure, the system stored incident information even after it was not needed, which caused the system to fill up memory and fail. [3] The first of these problems began to show during the morning rush of calls when it became apparent to all involved in the use of the system that things were about to go wrong. There were a number of duplicate calls being made as the system was losing accepted emergency calls, which lead to a number of distraught callers being kept waiting in the call-queuing system for up to 30 minutes. The system created further delays when dispatching ambulances. It failed to recognise certain roads and routes, which meant the drivers had to revert back to using maps to navigate their way or call the ambulance dispatch. These system errors led to the late arrival of ambulances, or two ambulances turning up at the same time, or worse not at all. [4] By Monday evening, the number of system failures had increased due to the number of new emergency calls which began to overwrite old ones that were not dealt with. There were further delays in the system created by exception messages. An exception message was designed to be generated for the operators when a call had not been acknowledged by ambulance crews and demanded priority action. However, the system created exception messages for all unanswered calls in the system and this swamped the operators due to high volume of exception messages. There was a move to rectify this problem by clearing the exception message queue, which would in theory speed up the system; but in reality just increased the number of lost incidents. This ultimately just increased the number of people calling back, and the vicious cycle began again. By Tuesday afternoon the situation escalated to the point that the system had to be shut down and dispatchers went back to using a combination of computerised call taking methods and locating ambulances manually. This solution, with the additional call taking staff added to each shift, seemed to improve call waiting time. This method of dealing with emergency calls carried on for 7 days until the 4th November 1992 when at 2am the system slowed and locked up all together. Rebooting the system failed to correct the problem, the backup system failed to cut in leaving the control room staff no alternative but to revert back to the fully manual paper based system. The effects of the incident are: Individuals - Claims were made in the press that up to 2030 people may have died as a result of ambulances arriving to late on the scene. One 14 year old boy died of an asthma attack after waiting for 45 minutes, whilst an 83 year old man died before the service reverted back to the old system.[5]

System Analysis and Design [436 303] Social - Under pressure from the media and the public, the British Health Secretary, Virginia Bottomley, announced a Public Inquiry into the system headed by South Yorkshire ambulance chief Don Page. The findings of the inquiry were eventually published in an 80 page report [6] in February 1993, which immediately became the top news item in the United Kingdom and gained international attention. Organizations - Ever since the accident, a lot of organizations showed interest in the case to understand and explore the sequence of events leading up to the incident in an attempt to determine responsibility and how the project might have benefited from a more formal specification of the software system. The case is taught in universities as a typical example of “what went wrong” in Software Engineering. Most computing professions in the UK were aware of the failure of the CAD system deployed by the LAS and took steps to prevent similar experience. [7] Political - John Wilby, chief executive of LAS then resigned within a couple of days and other managers were either dismissed or reassigned. Soon afterwards, a number of MP’s called for a crack squad of IT experts to be set up to investigate IT in the NHS. The BCS president and vice president claimed that the breakdown in the LAS CAD system could have been avoided if “computer people” were trained to professional standards. President Roger Johnson stated that: “The public are entitled to expect that the same professional disciplines apply in IT as in other professions such as medicine and law” [8] Economy - The financial consequences of this incident were not particularly significant in comparison to other reported software failures as it was estimated to have cost between £1.1 and £1.5 million. In contrast, problems with the UK Taurus stock exchange program cost £75-£300 million. The US CONFIRM system incurred losses in the region of $125 million. [9]

IV.

WHAT WENT WRONG

Many factors were responsible for the unfortunate failure of the LAS CAD System as discussed below: Management Problems The CAD System commenced when there was unhealthy working relationship and lack of trust between the staff and management of LAS. Majority of the staff felt that the working conditions were deteriorating and the management style was seen to be bureaucratic and uncaring [10]. Changes in the NHS and appointment of a tough new Chief Executive of LAS led to a massive reorganization and reduction of about 20% in the number of managers. This in turn resulted to exodus of highly experienced staff and increased stress on the remaining managers. LAS management underestimated the enormous task associated with changing from the manual operation of the LAS to a fully computerized system. The program was complex and the speed and extent of change were considered to be aggressive owing to the circumstances LAS found itself at that time [11]. Furthermore, LAS board members were appointed without knowing their

responsibilities, hence, some of their decisions were just rubber stamping [12]. The absence of effective control at the top and inability to manage lower down led to a series of flaws in the project and its eventual collapse. Preconditions of the CAD contract In the contract preconditions, LAS top management set a nonnegotiable date of 8 January 1992 for full implementation by the LAS CAD system [13] , meaning that the contractors had barely 6 months to fully accomplish their task, in which many LAS staff considered the time to be inadequate and inflexible [14]. A member of Systems Option, the leading contractor once said ‘in our contract signed in July 1991, it was stipulated that the system would be introduced in its entirely in January 1992. I don’t believe that was realistic’ [15]. 15nother string which the LAS top management attached to the contract was cost restriction, which was pegged at maximum of £1.5 million. This was just one fifth of the money spent on the failed first attempt of the LAS CAD project. The selection team of the contract had no option than to recommend the lowest bidders out of 35 others. System Option, a small software house was therefore awarded the contract for the supply of the CAD software without any prior experience with similar emergency service system [16]. System Specifications and Design A project committee which comprised of the Systems Manager, Systems Analyst, Control Room Manager and chaired by the Director of Support Services was tasked to develop the SRS for the project [17]. The ambulance crews being key players in the LAS Dispatch System had little involvement in the entire process. It was found that most of the work was done by the Contract Analyst and Systems Manager without official sign-off of the completed SRS [18]. Moreover, LAS top management failed to follow the guidelines of the UK Government project management methodology; the PRINCE (Project in Controlled Environment) in the design and implementation of the project [19]. As a matter of fact, neither the LAS staff nor the system suppliers had prior experience of using the methodology [20]. The CAD system was designed to rely on accurate information on the locations and status of ambulances at all times. However, the effect of imperfect information/communication on the system was not envisaged by the project team. The core software of the CAD system which determines the available resource to attend to a particular incident was designed such that the time taken to allocate a resource will depend on relative distance of an incident scene and availability of potential resources. Hence, the system was bound to be slow in allocating resources at peak times, especially when there are few uncommitted resources. There was no independent software quality assurance team. The project team allowed Systems Option to handle the QA aspect itself, in order to avoid additional cost [21]. Staff Training Staff training was critical to success of the project considering the strained relationship between LAS

System Analysis and Design [436 303] management and its staff who were the key players in the LAS Dispatch System. Even if the system would have been properly developed, its success would still rely heavily on its smooth operation by the LAS staff. Though there was evidence of training, it was not enough, as the staff complained on inadequate training when the Central Ambulance Control Staff received 2 days training to familiarize themselves with the system prior to the initial implementation date [22]. There were several changes to the system design and long delay before its live operation. These reasons made it difficult to achieve a comprehensive and consistent training which was evident, considering the performance of the LAS staff during the live operation, especially the ambulance crew pressing wrong buttons and sending inaccurate status report to the control room. Testing Although there was functional testing of various components, integration testing to ensure that the system can operate together was not carried out. Thus, there was no attempt to test how the system would react to different circumstances such as high call rate, multiple incident reporting, vehicle location problems, falling back to backup servers, etc. The Assistant Director of Operations was quoted in a memo he sent to the Accident and Emergency Team that â&#x20AC;&#x2DC; following the initial operating period of the CAD system, a full review of the radio network capability will be carried outâ&#x20AC;&#x2122; [23]. By implication, live operation of system was to form part of testing procedure. As a result of lack of thorough testing, several avoidable errors occurred when the system was implemented, which would have been detected and corrected during testing. Implementation The failure of the CAD system which came to live operation from 26 October 1992 was as a result of cumulative consequences of associated problems (identified above) that joined together to produce a chain of decline in its performance. The absence of nearperfect information upon which the system relied to allocate the required resource to an incident was a key factor to this decline [24]. The problems experienced during the implementation/live operation are summarized below: [23] [24] x Incomplete software. x Inability of the CAD software to identify and allocate the nearest available resource. x The AVLS not being able to identify all the ambulances in the fleet. x Communication problems among the CAD system, AVLS and Mobile data system. x Slow operation of the system. x Locking up of workstations. x Inaccurate status reporting by ambulance crew when wrong buttons were pressed. x Use of different vehicle by the crew from the one assigned by the system. The diagram of the causes/effects of CAD Systems failure is contained in Appendix B.

V. CONCLUSION

The LAS being the largest ambulance service in the world was founded in 1930 and covered a resident population of 6.8 million and receives between 2,000 and 2,500 calls daily. Prior to its computerization project, it operated manually, where details of an incident call taken by a control assistant is used to ascertain the location of an incident scene through the use of a map book. This information is then passed to a dispatch team who direct the appropriate ambulance to the incident scene through a radio call. Due to the short comings of this manual system, the LAS thought it wise to computerize its dispatch system. The first attempt failed in 1990 after spending ÂŁ7.5 million. The second attempt embarked upon in 1991 also faced serious challenges which eventually led to its collapse on 4 November 1992, barely 9 days after its launch. The project was designed to have Gazetteer and mapping software for location finding. CAD hardware and software for automatic resources allocation and effective communication system between ambulances and central control room for quick passage of instructions and obtaining accurate status of all resources. CAD contract was signed in May 1991 with a consortium of three companies (System Options, Apricot Datatrak and SOLO) systems option (small software house) being the main contractor. Time and financial constraints linked to the contract which affected the outcome and final product. During the development, the system was not properly tested as an entity and the staff were not efficiently trained on the system. These issues were clear when the system was launched on 26th October 1992. The implications of these problems during the launch and use of the system caused incident calls to be lost in the system while a number of calls did not ever reach the ambulances. The CAD system itself was very inefficient in identifying incident locations and reporting the accurate status of ambulances. Hence there was a slow response in dealing with incoming calls which resulted in higher call waiting times, multiple calls, and greater exception message queues. The incident was so frustrating that some ambulances could not locate incident scenes due to incorrect or inaccurate information, which led to loss of life. Growing frustration between patients and ambulance staff due to worsened situation caused loss of confidence in the system. The process was temporarily reverted back to the manual paper based system due to its inefficiency. The CAD system finally crashed on 4 November 1992 as a result of a leftover program code by a programmer, which was the foundation for insufficient memory to the server. In our opinion the CAD system suffered from the strict time and financial constraints. There should have been greater negotiation and communication among the stakeholders regarding the time and financial requirements of the system. There was a breakdown in communication between the management and staff of LAS meaning that not all the stakeholders interests were included in the system. From all indications the staff who are the main actors in the system were insufficiently trained to deal with the complications of the CAD system. The LAS management should have taken upon itself to set training sessions and standards. The system was never tested as an entity meaning

System Analysis and Design [436 303] LAS had no prior knowledge of how the system would appear and how problems would be dealt with. The tight time schedule coupled with continuous modifications of the system did not allow the system developers to carry out sufficient testing. The system would have benefited from an independent quality assurance team working on the system as they would have identified a number of key flaws. Overall, this research could serve a reference point for any future software development project considering the complexity of the project and the way it was implemented; transforming a large emergency system from operating manually to a completely computerized one. The LAS has since been able to computerize its dispatch system and is currently working on improving its efficiency by signing a new contract in 2008 for a newer system to be implemented in 2010. For more details see Appendix C.

[13] S. Flowers. Software Failure: Management

Failure. John Wiley & Sons. 1996, p.57. [14] Anthony Finkelstein, Report of the Inquiry Into

The London Ambulance Service, February 1993. p.5. [15] S. Flowers. Software Failure: Management

Failure. John Wiley & Sons. 1996, p.81. [16] Anthony Finkelstein, Report of the Inquiry Into

The London Ambulance Service, February 1993. p.6. [17] S. Flowers. Software Failure: Management

Failure. John Wiley & Sons. 1996, p.56. [18] Anthony Finkelstein, Report of the Inquiry Into

The London Ambulance Service, February 1993. p.4. [19] S. Flowers. Software Failure: Management

Failure. John Wiley & Sons. 1996, p.62. [20] S. Flowers. Software Failure: Management

Failure. John Wiley & Sons. 1996, p.56. [21] S. Flowers. Software Failure: Management

Failure. John Wiley & Sons. 1996, p.67. [22] S. Flowers. Software Failure: Management

Failure. John Wiley & Sons. 1996, p.75.

REFERENCES

[23] S. Flowers. Software Failure: Management

Failure. John Wiley & Sons. 1996, pp.68-74. [24] S. Flowers. Software Failure: Management

Anthony Finkelstein, Report of the Inquiry Into The London Ambulance Service, February 1993. p.1214. [2] Anthony Finkelstein, Report of the Inquiry Into The London Ambulance Service, February 1993. p.11. [3] Erich Musick, The 1992 London Ambulance Service Computer Aided Dispatch System Failure, 2006. http://erichmusick.com/writings/06/las_failure.html [4] London Ambulance Service Unofficial. http://www.lond.ambulance.freeuk.com/cad.html [5] Brian.Randell, London Ambulance Service, 1992. http://128.240.150.127/Risks/13.88.html#subj1.1 [6] Report of the Inquiry Into The London Ambulance Service, February 1993Report of the Inquiry Into The London Ambulance Service, February 1993. http://www.cs.ucl.ac.uk/staff/A.Finkelstein/las/lascase 0.9.pdf [7] Anthony Finkelstein & John Dowell, A Comedy of Errors: The London Ambulance Service Case Study, 1999, p.1-3. [8] Computer Weekly, 1992. [9] P. Beynon-Davies, Human Error and Information Systems Failure: The Case of the London Ambulance Service Computer-Aided Dispatch System Project. Interacting with Computers, 1999, p.244. [10] S. Flowers. Software Failure: Management Failure. John Wiley & Sons. 1996 , p.64. [11] P. Beynon-Davies, Human Error and Information Systems Failure: The Case of the London Ambulance Service Computer-Aided Dispatch System Project. Interacting with Computers, 1999, p.711. [12] S. Flowers. Software Failure: Management Failure. John Wiley & Sons. 1996, p.79. [1]

Failure. John Wiley & Sons. 1996, pp.39-41.

FIGURE 46: THE DIAGRAMMATICAL EXPRESSION OF LAS MANUAL OPERATION.

System Analysis and Design [436 303]

FIGURE 47: THE DIAGRAM OF THE CAUSES/EFFECTS OF CAD SYSTEMS FAILURE.

System Analysis and Design [436 303]

System Analysis and Design [436 303] Service to introduce new system to handle 999 calls15 December 2008 The London Ambulance Service has signed a contract for a new system to handle 999 emergency calls and send ambulance staff and vehicles to patients. Northrop Grumman has been appointed to design, develop and implement the new computer aided dispatch system, which will be introduced in 2010. Director of Information Management and Technology, Peter Suter, said: “Ever-increasing demand on our ambulance service and a growing population in the capital means that we need an enhanced system to meet future needs and help us improve patient care. “We’re moving away from a one-size fits all service to one where all our patients should get care tailored to their needs, and the new system will play a vital role in helping us to achieve this goal. “It will enable 999 calls to be handled more efficiently and will make it easier to send the right response to patients as quickly as possible.” The system will be designed to deliver a number of other benefits. It will have an improved capability for managing largescale events or major incidents, will be more resilient, and will have greater flexibility to be developed as new requirements are identified. Peter added: “Northrop Grumman has a proven track record in providing computer aided dispatch systems and we look forward to working with them during the next two years to introduce a system that will enable us to continue providing Londoners with high quality care for years to come.”