Popular in Course
Popular in Computer Information Systems
This 177 page Class Notes was uploaded by Jacinto Simonis Jr. on Saturday October 3, 2015. The Class Notes belongs to CIS235 at California State Polytechnic University taught by ZhongmingMa in Fall. Since its upload, it has received 11 views. For similar materials see /class/218164/cis235-california-state-polytechnic-university in Computer Information Systems at California State Polytechnic University.
Reviews for IntroductiontoObject
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 10/03/15
CIS 235 Midterm Review Coverage 0 Lecture slides 0 Pool questions 0 chapters in the required textbook 2 4 5 13 14 Type of questions 0 Multiple choices similar to quizzes and those in pool questions 0 Truefalse questions similarto those in pool questions 0 Short answer questions for example SDLC four fundamental phases SDLC methodologies such as names diagrams descriptions pros and cons Structural analysis amp design vs OOAD RUP chap 2 4 phases and 9 disciplines Name responsibilities of users analysts designers programmers QA staff Information gathering chap 13 sources for information gathering different techniques of information gathering Project management chap 14 Why IT project fail Two project scheduling methods Gantt chart and critical path model Timeboxing in scope management Use case modeling chap 4 Different associations eg association includes extends generalization Create a user case diagram with given information Generate expanded use case narratives Domain model chap 5 Identify multiplicity Identify associations eg wholetopart and generalization Create a domain model with given information CIS 235 01 Introduction to Object Oriented Systems Analysis and Design Winter 2011 last updated 122011 Basic information Class time Tue amp Thur 3 7 450 PM Class location 98C3004 Textbook Required book ObjectOriented Systems Analysis and Design with UML 2004 ISBN 0131434063 Two supplemental books optional and available in library reserves Systems Analysis amp Design with UML 20 2007 ISBN 9780470074787 2 An Introduction to Obj ectOriented Systems Analysis and Design with UML and the Uni ed Process 2004 ISBN 9780071215107 Instructor and Dr Zhongming Ma contact information Of ce 98C322 Phone 9098693242 Email zmacsupomonaedu Please use this email for ALL your questions The Blackboard email is for receiving your homework not for your questions Of ce hours Tue amp Thur 2 7 3 PM inclass and by appointment Class website Blackboard httpsblackbnard edn Prerequisites Prerequisite CIS 234 with a grade of C or better Course description Introduction to objectoriented systems analysis and design using Uni ed Modeling Language Main topics covered in this class include system development life cycle use case modeling conceptual domain diagrams interaction diagrams and design class models This course also introduces software development team management and fundamentals of so ware testing Learning Objectives 1 Foundational knowledge 0 Understand system development life cycle SDLC and several methodologies of SDLC in particular the rational uni ed process RUP Be able to perform systems analysis tasks such as identifying systems requirements producing requirements de nition generating use case descriptions use case diagram and domain model Be able to perform systems design tasks such as generating sequence diagrams for use cases and producing design class diagram 2 Application Be able to apply your knowledge and perform systems analysis and design tasks for a case 3 Integration Based on what you learned from C18 234 such as objectoriented concepts and fundamental programming skills in systems design be able to identify appropriate classes from given sources such as requirements description use case description and domain model and further to produce sequence diagrams 4 Human Dimensions Work with teammates of your group coordinately in order to produce groupbased deliverables for some project milestones Grading A student s performance in this course will be evaluated in four areas in class quizzes and exercises group projects a midterm and a final exam For this class each area will be weighted as follows 0 In class quizzes and exercises 7 15 0 Projects 7 30 o Midterm test 7 25 0 Final exam 7 30 Projects Each group consists of up to four students All project reports must adhere to the following standards 0 All pages must be computer generated and printed 0 Print your team members names and your team number in a cover page 0 Clearly state each member s work in the report For more detailed requirements see the documents for the project and milestones Late project Each day after a deadline will cost a 20 deduction in grade for the late project and no project will be accepted after two days past due Class participation Regular class attendance is required Participation points will be awarded on inclass pop quizzes and exercises These points cannot be made up if you were not in class Grading appeals You may appeal your grade on any written assignment exam or project within ve days you are given it or it was available to you Any appeal must be computer generated and include the reason for the appeal and any sources that support your appeal The assignment exam or project will be regraded taking in consideration of the evidence and returned to you Cell phones All cell phones and laptops are prohibited during exams You may have cell phones in class when exams are not given but they must be on mute and not answered until the end of the exam Tentat ve class schedule Week Date Topic Chapter l4 1 Introduction to System Development Life Cycle SDLC Supl l 2 16 1 17 Last day to add or to drop classes without course being recorded Fri Last day to drop units and receive refund of State University fee ll l 2 Chap 2 Rational Uni ed Process Text 2 l l 3 Text 13 l 18 Chap 13 Information Gathering Supl 4 3 l20 Chap 14 Managing System Development TeXt 14 Supl 3 4 125 First day to withdraw for serious and compelling reasons permitted by Tue petition only U25 4 Chap 4 Use Case Modeling Text 4 l27 2l Chap 4 Use Case Modeling Text 4 5 23 Chap 5 Domain Models Text 5 2 8 Chap 5 Domain Models Text 5 6 210 QampA 215 Midterm Test 7 217 Chap 6 7 Systems Design Text 6 7 222 Chap 10 Database Interface Text 10 8 Chap 12 User Interface 12 224 Chap 8 Interaction Diagrams Text 8 125 8 Fri First day to Withdraw for emergency reasons permitted by petltlon only 31 Chap 8 Interaction Diagrams Text 8 9 33 Chap 9 Design Class Diagrams Text 9 38 Supplemental content Testing Sup2 13 10 310 Supplemental content Teams Sup2 12 Final Review 11 315 Final project due by 140 PM Final exam 140 340 PM Code of conduct Academic dishonesty is a serious offence and includes 1 Plagiarism is a serious offence Plagiarism is intentionally or knowingly presenting words ideas or work of others as one s own work Plagiarism includes copying homework or any other work that is not one s own N Cheating during exams 7 using unauthorized cheat sheets copying from another looking at another student s exam opening books during closebook exams obtaining advance copies of exams and having an exam regraded after making changes 3 Use of unauthorized study aids such as cell phones Internet or any other materials prohibited by the instructor during closebook exams The University has very clear guidelines for academic misconduct and they will be enforced in this class Student access Cal Ploy Pomona as a learningcentered university is committed to student success Students with disabilities are encouraged to contact me privately or the Disability Resource Center 909 8693333 Building 9 Room 103 to coordinate course accommodations Textbook ObjectOriented Systems Analysis and Design with UML by Stumpf and Teague Chap 13 Gathering Managing and Reporting Information REQUIREMENTS DETERMINATION Requirement A statement of what the system must do or what characteristic it must have During analysis requirements are written from the perspective ofthe businessperson usually called business requirements Requirements are best determined by systems analysts and business people together Requirement Two kinds of requirements Functional requirements Relate directly to a process a system has to perform or information it needs to contain For example the ability to search inventory to report actual and budgeted expenses Nonfunctional requirements Refer to behavioral properties that the system must have such as performance and usability For example the ability to access the system using a web browser Are used primarily in design when decisions are made about the user interface hardware amp software system physical architecture 4 Nonfunctional Requirements Operational 39 Performance Security Cultural amp Political The system should be able to fit in a pocket or purse The system should be able to integrate with the existing inventory system Any interaction between the user and the system should not exceed 2 seconds The system should receive updated inventory information every 15 minutes Only direct managers can see personnel records of staff Customers can see their order history only during business hours The system should be able to distinguish between United States and European currency The system shall comply with insurance industry standards To create a requirement definition The project team determine what requirements are needed Analysts collect information by a variety of information gathering techniques Analysts work with the project team and the business users to verify change and complete the list of requirements and to help to prioritize the requirements Requirements Definition Report Correct Unambiguous Complete Consistent Verifiable Modifiable Traceable Ranked for importance Sample Requirements Definition Functional Requirements 1 Printing 11 the user can select which pages to print 12 the user can view a preview of the pages before printing 13 the user can change the margins paper size eg letter A4 and orientation on the page 2 Spell checking 21 The user can check for spelling mistakes the system can operate in one of two modes as selected by the users Sample Requirements Definition 211 Mode 1 manual The user will activate the spell checker and it will move the user to the next misspelled word 212 Mode 2 automatic As the user types the spell checker will flag misspelled words so the user immediately see the misspelling 22 The user can add words to the dictionary 23 The user can make words as not misspelled but not add them to the dictionary Sample Requirements Definition Nonfunctional Requirements 1 Operational Requirements 11 the system will operate in Windows environments 12 the system can read and write documents in Word RTF and HTMLformat 13 The system will be able to import gif jpeg and bmp files 10 A Bad Requirement Definition Initial Specification Software will not be loaded from unknown sources onto the system without first having the software tested and approved Critigue 0 Ambiguous if the software is tested and approved can it be loaded from unknown sources 0 not Testable it is stated as a negative requirement making it difficult to verify 0 not Traceable a unique identifier is missing Respecification 3452 Software shall be loaded onto the operational system only after it has been tested and approved Gathering Information Most of the information gathered by the development team must come from the users The critical information gathered will be used to Produce requirement definition report Identify use cases and generate use case diagram write the expanded use case narratives and construct the domain model The above underlined items are some of the deliverables in systems analysis 12 Information Sources Documents and displays describing the current system Other publications from the organization such as annual reports and brochures Publications from the industry People especially the users 13 REQUIREMENTSGATHERING TECHNIQUES 14 Techniques for the systems analysts Interviews Questionnaires Joint application development JAD Observation Document analysis 15 Interviews An interview is a conversation in which questions are asked to gather information Components of an interview Select interviewees Prepare for the interview Conduct the interview Summarize and evaluate the interview 16 Selecting Interviewees Based on information needed Often good to get different perspectives Managers Users Ideally all key stakeholders 17 Interviewing Strategies Topdown How can order processing be improved Highlevel Very general How can we reduce the number oftimes that customers return ordered items Mediumlevel Moderately specific i Lowlevel How can we reduce the number of Very specific errors in order processing eg shipping the wrong products Bottomup 18 Post I nterview Interview Notes Approved by Linda Estey Person Interviewed Linda Esley Dirtclot Human Resources Inlerviewer Barbara Wixom Purpose of Inlerview 39 Understand reports produced for Human Resources by the current system Determine information requirements for future system Summary of Inlerview Sample reports of all current HR reports are attached to this report The information that is not used and missing information are noted on the reports Two biggest problems with the current system are 1 The data are too old rthe HR Department needs information within two days of month end currently information is provided to them after a threeweek delay 2 The data are of poor quality often reports must be reconciled with departmental HR database The most common data errors found in the current system include incorrect job level information and missing salary information Open Ilems Get current employee roster r qaort from Mary Skudr39na extension 4355 quoterif 39 calculations used to determine vacation time with M am Skudrna Schedule interview with Jim Wack extension 233 regarding the reasons for data qualitgr problems Delailed Noles See attached transcript Questionnaires A questionnaire is a list of questions to which written answers are requested from several respondents If the questions are asked orally this technique is called a survey A questionnaire is shorter and more highly structured than an interview 20 Questionnaire Steps Selecting participants Using samples ofthe population Designing the questionnaire Careful question selection Administering the questionnaire Working to get good response rate Questionnaire follow up Send results to participants 21 Questionnaires The design of a questionnaire requires great care A person with statistics knowledge should prescribe the procedure for selecting the recipients in order to assure that the sample is representative biased samples telephone survey of 1948 Presidential Election A statistician may also be helpful in interpreting the results after the replies have been tabulated 22 Joint Application Development JAD Allows the project team users and management to work together in intensive workshops to identify requirements It has been used most often to define system requirements and a preliminary system deggn 23 Joint Application Development continued JAD requires Intensive and time consuming participation Careful planning Careful review and approval of the decisions made during the session Realistic expectations from the participants 24 Joint Application Development continued Q Flip Chart Sheets Order Processing Oveniew 39amequot en 5 Scanner I A d LOVEISEZWa 1 Screen for 439 Magnetic Board Overheads 6 1 Open 7 17 Issues 131 Y Q o x 1 Aquot 777 I I Printer i I i r r 7 AS Overhead 39 Projector 39 A41A 25 FIGURE 13 1 25 Joint Application Development continued JAD participants include An executive sponsor An impartial facilitator Ascribe Fulltime participants On call participants Observers Key roles Facilitator Scribe 26 Joint Application Development continued Facilitator activities Keep session on track Help with technical terms and jargon Record group input Help resolve issues 27 Joint Application Development continued JAD helps give users a sense of ownership of the system users understand the technical issues in the development process facilitate decisions because the critical decision makers participate 28 Managing Problems in JAD Sessions Reducing domination Encouraging non contributors Side discussions Agenda merry go round Violent agreement Unresolved conflict True conflict Use humor 29 Observation For gathering information about the as is system Studies show that usersmanagers often don t remember everything they do Checks validity of information gathered other ways Behaviors change when people are watched Document Analysis It provides clues about existing quotasis system Typical documents Memos Forms Reports Training manual Policy manuals 31 Selecting Appropriate Techniques Questionnaires Observation Document Analysis Type of Asis Asis improves As is Asis As is information improves improves tobe tobe Depth of info High Medium High Low Low Breadth ofinfo Low High Medium Low High Info Low Low H ig h Low Low integration User M edium Low High Low Low involvement Cost M edium Low Low Low Low medium medium 32 Systems Development Life Cycle Dr Zhongming Ma 142011 Supplemental book available at library reserves Systems Analysis amp Design with UML 20 2007 ISBN 9780470074787 Analysis amp Design in One Sentence Systems Analysis Is about what identifying gathering requirements and describing written in words and visually by diagrams what the system needs to do Systems Design Is about how providing logical solution for how the system is to be developed So Systems Analysis and Design is NOT about learning software programming 2 Information Systems Information system collects manipulates stores and reports information to achieve a business outcome Examples Information systems for student registration library IRS Custom information system An information system developed for a specific client according to its requirements We learn systems analysis amp design for this type of software project Packaged software It is available offtheshelf such as Microsoft Office Some software packages can still be customized or configured according to specific requirements such as IBM DBZ and SAP ERP systems SYSTEMS DEVELOPMENT LIFE CYCLE SDLC Systems Development Life Cycle SDLC SDLC is the overall process of developing information systems through a multistep process There are many known software development methodologies Four fundamental phases in SDLC gt Planning gt Analysis gt Design gt Implementation Four Fundamental Phases in SDLC Planning 7 N Implementation f N Z SDLC Planning 1 Project Initiation Business users or IT Identify a project Sprint example for project initiation IT in Business Project Marriott Corporation More examples Business users or IT Develop a system reguest Analyst Conduct a feasibility analysis Why should we build this system Project Initiation at Sprint Interview with Don Hallacy President Technology Services Sprint Corporation At Sprint network project originate from two vantage points IT and business units IT projects usually address infrastructure and support needs The business unit projects typically begin after a business need is identified locally and a business group informally collaborates with IT regarding how a solution can be delivered to meet consumer expectations Once an idea is developed a more formal request process begins and an analysis team is assigned to investigate and validate the opportunity This team includes members from the user community and IT and they score out at a high level what the project will do create estimates for technology training and development costs and create a business case This business case contains the economic valueadd and the net present value of the project Of course not all projects undergo this rigorous process The larger the project the more time is allocated to the analysis team It is important to remain flexible and not let the process consume the organization At the beginning of each budgetary year special capital expenditures are allocated for operational improvements and maintenance Moreover this money is set aside to fund quick projects that deliver immediate value without going through the traditional approval process 8 IT in Business Project Interview with Carl Wilson CIO Marriott Corporation At Marriott we don t have IT projects we have business initiatives and strategies that are enabled by IT As a result the only time a traditional quotIT projectquot occurs is when we have an infrastructure update that will lower costs or leverage better functioning technology In this case IT has to make a business case for the upgrade and prove its value to the company The way IT is involved in business projects in the organization is twofold First senior IT positions are filled by people with good business understanding Second these people are placed on key business committees and forums where the real business happens such as finding ways to satisfy guests Because IT has a seat at the table we are able to spot opportunities to support business strategy We look for ways in which IT can enable or better support business initiatives as they arise Therefore business projects are proposed and IT is one component ofthem These projects are then evaluated the same as any other business proposal such as a new resort by examining the return of investment and other financial measures At the organizational level I think of projects as mustdo s shoulddo s and nicetodo s The mustdo s are required to achieve core business strategy such as guest preference The shoulddo s help grow the business and enhance the functionality of the enterprise These can be somewhat untested but good drivers of growth The nicetodo s are more experimental and look farther out into the future The organization s project portfolio should have a mix of all three kinds of projects which a much greater proportion devoted to the mustdo s Elements of a System Request Project sponsor Primary point of contact for the project Business need Reason prompting the project Business requirements Business capabilities the system will need to have Business value Benefits the organization can expect from the project Special issues Anything else that should be considered Bacquound for CD Selections Case A sample System Reguest 10 CD Selections Case CD Selections is a chain of fifty music stores fictitious located in California with headquarters in LA Annual sales last year were 50 million and they have been growing at about 3 to 5 percent per year for the past few years However the firm has been interested in expanding their presence beyond California Margaret Mooney vice president of marketing has recently become both excited by and concerned with the rise of Internet sites selling CDs She believes that the Internet has great potentials but she wants to use it in the right way Rushing into ecommerce without considering things such as its effect on existing brickandmortar stores and the implications on existing systems at CD Selections could cause more harm than good Currently CD Selections has a Web site that provides basic information about the company and about each of its stores eg map operation house etc The Web site was developed by an Internet consulting firm and is hosted by a prominent local Internet service provider ISP in LA The IT department at CD Selections has become experienced with Internet technology as it has worked with the ISP to maintain the site however it still has a lot to learn when it comes to conducting business over the Web As such Margaret is interested in investigating the possibility of creating an ecommerce site that will work with the current systems used by CD Selections A sample System Reguest 11 System Request Internet Order Project Project sponsor Margaret Mooney Vice President of Marketing Business Need This project has been initiated to reach new Internet customers and to better serve customers using Internet sales support Business Requirements Using the web customers should be able to search for products and identify the brickandmortar stores that have them in stock They should be able to put items on hold at a store location or place an order for items that are not carried or are not in stock The functionality that the system should have is as follows Search through the company inventory of products Identify the retail stores that have the product in stock Put a product on hold at a retail store and schedule a time to pick up the product Place an order for products not currently in stock or not carried by the company Receive confirmation that an order can be placed and when the item will be in stock Business Value We expect that our company will increase sales by reducing lost sales due to outofstock or nonstocked items and by reaching out to new customers through its Internet presence We expect the improved customer satisfaction and increased brand recognition due to its Internet presence 12 System Request Internet Order Project continued Business Value continued Conservative estimates of tangible value to the company include 750000 75 of 1000000 in sales from new customers 1875000 75 of 2500000 in sales from existing customers 50000 in sales from customers not facing quotoutof stockquot or nonstocked items Special Issues or Constraints The Marketing Department views this as a strategic system This Internet system will add value to our current business model and it also will serve as a proofof concept for future Internet endeavors For example in the future we may want to sell products directly over the Internet The system should be in place for the holiday shopping season next year Note also see CD Selections Case Studydoc Another sample of System Request is in a file named System Request for Online Admission Systemdoc 13 Feasibility Analysis Guides the organization eg approval committee in determining whether to proceed with a project Identifies the project s risks that must be addressed ifthe project is approved Mayor components Technical feasibility Economic feasibility Organizational feasibility 14 Technical Feasibility Familiarity with application Less familiarity generates more risk Familiarity with technology Less familiarity generates more risk Project size Large projects have more risk Compatibility Difficult integration increases the risk Can we build it 15 Economic Feasibility Development costs Annual operating costs Annual benefits cost savings and revenues Intangible costs and benefits Should we build it 16 Break Even Point S Dol lar 3500000 3000000 2500000 2000000 1500000 1000000 500000 0 0 Costs 39 Benefits 9 7 o G O O 2 3 Breakeven Paint Nears Organizational Feasibility Stakeholders Project champions Organizational management Users Others Is the project strategically aligned with the business If we build it will they come 18 SDLC Planning 2 Project Management Develop work plan Staff the project Control and direct the project Why should we build this system SDLC Analysis 1 Develop analysis strategy 2 Gather requirements 3 Develop a system proposal What should the system do for us Where and when will it be used 20 PWP SDLC Design Develop a design strategy Design architecture and interfaces Develop databases and file specifications Develop the program design How will we build the system 21 SDLC Implementation 1 Construct system 2 Installsystem Implement a training plan for the users 3 Establish a support plan Build the system 22 Putting the SDLC Together Each phase consists of steps that lead to specific deliverables The system evolves through gradual refinement incremental amp iterative Once the system is implemented it may go back into a planning phase for its next revision a followon system or maintenance releases 23 SYSTEMS DEVELOPMENT METHODOLOGIES Systems Development Methodologies A SDLC methodology is a formalized approach to implementing the SDLC Well known methodologies include Waterfall development Parallel development System Prototyping Throwaway Prototyping Extreme Programming Rational Unified Process RU P 25 Waterfall Development Planning Analysis Implementation 26 Waterfall Development It moves forward from phase to phase However it is possible to go backward The key deliverables of each phase are typically very long Advantages It identifies system requirements long before programming begins It minimizes changes to the requirements Disadvantages Design must be completely finished before programming begins A long time elapses bw analysis and delivery of system Lengthy deliverables often result in poor communication important requirements can be overlooked 27 Plan ning Parallel Development Deslgn lmplemenlallon I Subproject 1 5 1 SubprojeCl 2 L Implementation Design Implementation I lmplementallon Subprojecl 3 28 Parallel Development Attempt to address the problem of long delays bw analysis and delivery of system Divides the project into a series of distinct subprojects that can be designed and implemented in parallel There will be a final integration of separate pieces Advantages Reduce the schedule time to deliver a system Disadvantages Still lengthy deliverables Subprojects may not completely independent design made in one subproject may affect another and the integration takes efforts 29 Phased Development Plannlng A 3 15 Ana W5 Analysk Anafysis Implementation Syylam wanton 5 30 Phased Development Breaks an overall system into a series of versions and develops them sequentially The most important amp fundamental requirements are included in the 1st version then design and implement it After version 1 is implemented work analysis design implementation begins on version 2 Advantages Quickly delivering a useful system to users compared with Waterfall or Parallel methodologies Because users work with the system sooner they are more likely to identify additional important requirements sooner Disadvantages Users begin to work with an incomplete system 31 System Prototyping Planning Analysis I System prototype lmplementatlon I l Deslgn I mplementatlnn I System Prototyping Performs analysis design and implementation concurrently to produce system prototype Users and project sponsor provide comments to the system prototype All the three phases are performed repeatedly to generate next system prototype Advantages Very quickly provides a system with which users can interact Helps to more quickly refine requirements Disadvantages Its fastpaced system releases challenge attempts to conduct careful methodical analysis 33 Throwaway Prototyping Planning Design Design prototype Design lmpiementatlon I Implementation 1 Th rowaway Prototyping Also has a prototype called design prototype The design prototype is used to get requirements and interact with the project team It will be throwaway because the prototype is only a mock up not a high quality real system Advantages Allow to refine key issues before a system is built and produce more reliable system Disadvantages May take longer to deliver the final system as compared to prototypingbased methodology 35 Extreme Programming Design Implementation Anallysis I Extreme Programming Based on four core values communication simplicity feedback and courage Analysis design and implementation phases are performed iteratively Better work with small projects less than 10 developers Advantages Very quickly deliver a system with limited features Disadvantages It requires many and frequent communications such as users provide feedback and answer questions bw project team and users thus it is for small projects 37 Selecting the Right Methodology Parallel Phased Prototyping Throwaway Extreme Use u ness for Prototyping Programming Unclear user requirements Unfamiliar technology Complex systems Reliable systems Short time schedule Schedule visibility Poor Poor Good Good Poor Poor Poor Poor Good Good Good Poor Good Good Good Good ExceHent ExceHent ExceHent Poor Poor Poor ExceHent ExceHent ExceHent ExceHent ExceHent Poor ExceHent Poor ExceHent Good Good ExceHent Good Good 38 ObjectOriented Analysis amp Design Uses Unified Modeling Language UML Characteristics of OOAD Use case Driven Use case describes how the user interacts with the system to perform some activity such as placing order register for classes search product Use case is simple because it focuses on only one activity vs activity in traditional methodologies 39 ObjectOriented Analysis amp Design Architecture Centric Underlying software architecture drives the specification construction and documentation of the system Iterative and Incremental Continuous refinement throughout every phase in SDLC 4O Divideandconquer in SDLC 0 Complexity of software projects Software development projects are complex Divideand conquer Breaking a large problem into several smaller but manageable units Warfare philosophy by Sun Tsu in his book quotThe Art of War 500 BC 41 Divideandconquer in Structured AampD Structured AampD vs ObjectOriented AampD Structured analysis amp design Decomposing by function or process hierarchical breakdown on the basis of the function each item performs or is used for Producing subprocesses or breaking a process down into welldefined steps Functions for an library information system Record loans update resources print reports Functions for a class registration system Register class update registration submit classes assign a professor to class assign a classroom for class generate class roster print reports etc 42 More examples of Functional decomposition From Computer Eleairtop Enoyolopedia El 1998 The Computer Language Co Inc GilliM 3 i111 5419 43 ENIERPH JSE LEVEL FUNCTIUN CH iRT iFlan Pmductiun m Plan Mamie Materials Requirements J 53 Receive 65 Periorm timid Mammals The Function Chart decomposes the business functions for a manufacturing company 44 Divideand conquer in OD AampD Obiect Oriented Analysis amp Design Decomposing by concept breaking a large system into progressively smaller classes or objects that are responsible for some part of the problem domain Producing conceptual componentsclasses 39 Concepts for an library information system Book patron librarian library Concepts for a class registration system Student Department Course Section Classroom Professor 45 The Rational Unified Process RUP This methodology is an iterative software development process framework created by the Rational Software Corporation by Jacobson Booch and Rambaugh We ll learn it in this class 46 The Rational Unified Process RUP PHASES DISCIPLINES Inception Elaboration Construction Transition Business Modeling Requirements Design Implementation Test Deployment Configuration and Change Management Project Management Environment 47 THE UNIFIED MODELING LANGUAGE The Unified Modeling Language UML In 1997 UML was published as a standard for describing amp modeling object oriented systems Provides a common vocabulary of object oriented terms and diagramming techniques rich enough to model any systems development project from analysis through implementation UML emphasizes simple models which are more easily understood by its users 49 Unified Modeling Language The principal contributors for UML Three Amigos Grady Booch Ivar Jacobson and James Rumbaugh Software Microsoft Visio download at httpmsdn08e academvcomemsStorefrontHomeaspxcampuscpp cs 0 Version 20 has 14 diagrams in two major groups Structure diagrams Behavior diagrams 50 U M L Structure Diagrams Represent the data and static relationships in an information system Class Object Package Deployment Component Composite structure 51 UML Behavior Diagrams Depict the dynamic relationships among the instances or objects that represent the business information system Activity Behavior state Sequence maChlne Protocol state machine Communication Interaction overview Timing Use case diagrams 52 Learning Objectives Understand systems development life cycle SDLC and its four fundamental phases 0 Be familiar with several SDLC methodologies Be able to choose an appropriate methodology for different situations 53 References Systems Analysis amp Design with UML Chapters 1 and 2 Alan Dennis Barbara H Wixom David Tegarden John Wiley amp Sons Inc ISBN 9780470074787 httpwwwwaterfalsdggnscom20091019softwaredevelopmentlifecycle modelsz httpenwikipediaorgwikiSystems Development Life Cycle httpenwikipediaorgwikiSun Tsu httpwwwpcmggcomencyclopedia termO2542tfunctionaldecompositionamp i4358400a5 54 Stum pf and Teague ObjectOriented Systems Analysis and Design with UML Chapter 14 Managing ObjectOriented System Development Dr Zhongming Ma 12011 IT project failure rate EVEI PIE 50 4096 Succeeded 30 Chalenged 213 Failed 10 913 1994 1996 1998 2000 20432 2004 Source The Standish Group 2006 Chaos Report IT project failure from different sources httpwwwit cortexcomStat Failure Ratehtm Recent Significant IT Failures Hudson Bay Canada 2005 Inventory system problems lead to 333 million loss UK Inland Revenue 20045 345 billion taxcredit overpayment caused by software errors Avis Europe PLC UK 2004 Enterprise resource planning ERP system cancelled after 545 million spent Ford Motor Co 2004 Purchasing system abandoned after deployment costing approximately 400 M HewlettPackard Co 2004 ERP system problems contribute to 160 million loss ATampTV reess 2004 Customer relations management system upgrade problems lead to 100M loss Source Charette Robert N Why Software Fails IEEE Spectrum Online Sept 2005 Why Software Development Projects Fail Projects Success Failure Projects fail because Users fail to communicate requirements completely and accurately Users are not sufficiently committed to the project The project has no top management champion Why Software Development Projects Failcontiued Project budget and schedules are unrealistic Risks are not adequately identified and mitigated According to DeMarco however the chief cause of failure is because Users expectations are inflated and unreasonable Goals of Project Management The primary goal of software project management is a successful outcome for the project This means that the project must Meet users reasonable expectations Performance Be delivered on time Be delivered within budget Project management involves balancing tradeoffs among the Project three ke ro39ect arameters yp 390 Time Budget Goals of Project Management continued Secondary goals of software project management include Identify risks to the project and avoid or mitigate them Identify work breakdown structure Prepare project plans Monitor project progress against the plans Earn and maintain users trust through communication Manage users expectations Risk Analysis A risk is any uncertainty which has a significant probability of preventing the successful completion of a project milestone Three major categories of risk are those associated with Users The development team The project Risk Analysis Risk Assessment RISK 1 The development of this system lilltely will be slowed considerany because project team members have not programmed in Java prior to this project Likelihood of risk High probability ol risk Potential impact on the project This risllt will probabhl increase the time to complete programming tasks by 50 percent Ways to address this risk It is very important that time and resources are allocated to up front training in Java for the programmers who are used for this proiect Adequate training will reduce the initial learning curve for Java when programming begins Additionally outside Java expertise should be brought in for at least some part of the early programming tasks This person should be used to provide experiential knotvledge to the project team so that JAVA related issues of which novice Java programmers would be unaware are overcome More examples of risks Work Breakdown Structure Work Breakdown Structure WBS Is a list of tasks hierarchically numbered Is the backbone of the project plan 10 Work Breakdown Structure Task Number r m Ln r w M 39 f I C39sl rJ r r1 I yo to ho Luna 4 74 quotJmUIIJLU 7 4 Tquot T4 T 7394 3900 Oil 10 Task Name Identify R39EI ICIDI S Review training materials Compare vendors Negotiate with 1rrenclors Develop communications information Disseminate information Create and administer survey Create initial survey Review initial survey Review I339quot Director of IT Training Review by Project Sponsor Revi ew by Rep rese ntat IVE Tra i nee Pilot test initial survey Incorporate survey changes Create distribution list Send survey to distribution list Send followup n39ressage Collect completed surveys Analyze results and choose vendor Build new classrooms Dex el op course options Du ralion Iin weelrsl v rrJrsLJromm Dar Lnuan a Dependenqr quotrd 3quot H1 4 Mr Lu G ILn la I li Slalus Complete Complete In Progress Open In Progress Open Open Open Open Open Open Open Open Open Open Open Open Open Open In Progress Open Project Plan A project plan includes A breakdown of the necessary worktask all tasks in WBS Estimated and actual completion time for tasks The time dependencies among the project tasks Status of tasks key milestones or important dates The assignment of personnel and other resources to each of the tasks 12 Project Scheduling A project schedule is a set of project artifacts or deliverables listed in the sequence in which they are to be produced The units of work in a project schedule are tasks or activities Milestones are marked by the completion of specified deliverables Two project scheduling methods 1 Critical Path Model 2 Gantt Chart 13 Sample Task Task name Start date Completion date Person assigned to the task Deliverables Completion status Priority Resources needed Estimated time Actual time Perform economic feasibility Jan 5 2010 Jan 19 2010 Mary Smith project sponsor Costbenefit analysis Complete High Spreadsheet software 16 hours 145 hours Critical Path Model A critical path model or network shows the sequential dependencies among activities in a project It permits the calculation of the earliest project completion date the activities which will delay the project if not completed on time the critical path 15 Critical Path Model I Use Case Narrative Life Cycle Write Contract for Interaction Diagram Code Test and Domain Model enterStudentIdentifier enterStudentldentifier enterStudentIdentifier enterStudentldentilier Architecture 5 25 3925 5 5 Milestone 15 15 Refine Format of Student Class List d u ration 15 Write Contract for Interaction Diagram Code requestSection requestSection requestSection 5 l Test Register for Classes Use Case 1 15 15 25 1 15 V 15 25 0 requestSection i 25 35 Iteration 1 15 9 Prepare Activity Description Duration No prerequisite checking Total Float FIGURE 141 total float can be delayed without making the project longer 16 Gantt Chart A Gantt chart presents a project schedule as horizontal bars on a vertical time grid It can help communicate the overall features of a project schedule 17 Gantt Chart WEEKS 12 3 4 5 6 7 8 910111213 I WBS1 Summary Element 1 57 complete I WBS 11 ActivityA ri39 75 complete I V sTARTTOSTART I WBS 12 ActMty B Ufm complete I FlNlSHTOgtSTART WBS 13 Activity C ll 50 complete FINISHJOHNISH WBS 14 Activity D 10 complete I l W35 2 Summary Element 2 0 complete was 21 Actlvtty E Bay 001mm I WBS 22 Activity F lS 0 complete I WBS 28 Activity G 0 complete TODAY WBS work breakdown structure 3 2 wks choose n E W Wed 391 f1 08 lf lf39EIB 2M 2108 213926f08 1 1 SDS 24quot 13908 2quot 2 608 312608 11 SIDE 9 03 Gantt Chart Tue 131 4308 Tue 2quot1 1quot03 B arbara Barbara Tue 2 22508 Tue 3J1 SJDS Balbara Tue 21 W08 Tue 222508 Tue 332508 Tue JLWUB Tue 451 08 Tue 42 9quot08 Gantt Chart CoarseGrained Plan Phase Plan Project Architecture Product Approval Review 31 32 Release Iter Iter lter Iter Iter g lt 1 2 3 4 5 V7 V 7 V7 V7 7 7 V 7 I I Start LCO 498 LCA IOC 299 l98 398 598 1298 a J 5 498A f A Design Build 1 Build 2 Review FIGURE 142 FineGrained Plan Iteration Plan 598 Scope Management Timeboxing Is a scope management technique that places meeting a deadline above delivering functionality Steps forTimeboxing 1 Set the date for system delivery Prioritize the functionality that needs to be included in the system Build the core functions of the system Postpone functionality that can t be provided within the time frame Deliver the system with core functionality Repeat steps 3 and 5 to add refinements and enhancements 9601990 21 Prototyping A prototype is a partial or limited version which simulates a proposed system Analysis prototypes clarify requirements with a partial mockup of the system Design prototypes explore system architecture or study system performance Vertical prototypes implement completely a portion of the system Feasibility prototypes study feasibility 22 Textbook ObjectOriented Systems Analysis and Design with UML by Stumpf and Teague Chap 4 Essential Use Cases m Zi iengnm ii LXZEWWM 99 Vi 4 ng iii ii Use Case Modeling Deliverables of use case modeling 1 Use case diagram illustrates the main functions of the system and different kinds of users that interact with it 2 Expanded use case narratives contains additional details about the low level activities for use cases USE CASE DIAGRAM Use Case Diagram Why is it called the use case Writing stories of using a system to help fulfill various stakeholder goals that is cases of use Use case diagram Describe basic functions of the system What the user actor can do How the system responds Consists of use cases and visually shows the system in relation to the actors Use Case Diagram Components in use case diagram 1 m 2 use cases 3 associations 4 system boundary Use Case Diagram 1 Actor An actor is someone or something that interacts with the system The actor generates a system input andor receives system output An actor includes a person computer system or organizations eg credit card verification system course catalog system IRS The name of an actor is a noun or noun phrase A human acting actor is identified by role such as Student Customer Accountant Cashier etc Use Case Diagram Two Types of Actors An initiating actor initiates a use case Thus initiating actors provide system inputs A participating actor is involved in a use case but does not initiate it Thus participating actors receive system outputs Use Case Diagram 2 Use Case A use case illustrates the activities between the system and a user Use cases are building blocks for continued design activities Naming a short phrase beginning with a verb For example Get Patient Information Create Appointment Pay Tuition Register for Classes Use Case Diagram 3 Association Association between a actor and a use case is denoted as a single line in UML Practitioners prefer a directed line to distinguish an initiating actor More complex associations such as between use cases will be introduced later in this chapter 4 System boundary The system boundary is usually the software system itself Use Case UML Notation UML notation for use case diagram actor a named stick figure Actor1 use case an oval containing the use case name association a line between a use case and an actor System system boundary rectangle box not needed ifjust one system 10 Case 1 Dice Game Brief description for Dice Game system In a computer dice game each dice has a face value from one to six Each time a player plays two dice and receives a total face value From the above text we identify Actor Player Functional requirements Player plays dice 11 Case 1 Dice Game Use case naming A use case name is a short phrase beginning with a verb Use case identified Play Dice 12 Use Case Diagram for Dice Game Dice Game Player Case 2 University registration system Brief description for registration system Each department must submit a list of classes scheduled for the term in question by a specified deadline The university class schedule is produced at a predetermined time after the department deadline During a registration period students request the classes they would like to take using the online registration system Each class request contains the student s identifier and the identifiers of the class for which the student wishes to register 14 Case 2 University registration system If that class is not available the student may try to enroll in a different section of the same course or in another class After a student has registered for as many classes as possible up to the maximum number of units permitted the student can print out a class list which shows hisher enrolled classes A professor teaching a class can print a class roster which contains a list of the students names and identifiers The list is ordered alphabetically by the student s last names 15 Case 2 University registration system From the prior text we identify Actors Student Professor Department 0 Functional requirements Department submits class schedule System produces university class schedule Student registers for classes Professor prints class roster For simplicity we ignore other functions like student withdraws classes 16 Case 2 University registration system Use cases use case name starts with a verb Submit class schedule Produce university class schedule Register for classes Print class roster 17 Use Case Diagram for Registration System E Department Submit Department Class Schedule Produce University Class Schedule E Professor Register for Classes E Student Produce Class Roster 18 Case 3 PCS pointofsale system Brief description for POS system A customer arrives at a checkout with items to purchase A cashier uses the POS system to record each purchased item The system presents a running total and line item details The customer enters payment information Then the system requests another system to validate the payment and records the payment The customer receives a receipt from the system and leaves with items The system updates inventory 19 Case 3 POS system Actors identified from the prior text Customer Cashier Payment validation system Functional requirements Cashier checks out items Customer enters payment System requests payment validation System records payment System updates inventory System prints receipt 20 Case 3 POS system Use cases Check out items Enter payment Request payment validation Record payment Update inventory Print receipt 21 Use Case Diagram for POS system POS System Checks out items Cashier Enter payment Customer Request payment validation Print receipt Record payment Update inventory Payment Validation Use Case Elements Relationships Association already introduced documents the communication between the use case and the actors that are associated with the use case Includes between use cases shows the mandatory inclusion of another use case Extends between use cases represents the extension of the functionality of the use case to incorporate optional behavior Generalization allows use cases to support inheritance 23 Associations Between Use Cases Includes one use case w the functionality of another independent use case The included use case is independent of the including use case 0 Includes different use cases share the common actions 24 Associations Between Use Cases Check in Room and Check out Room need to use Set Room Status Check into Room Set Room Status Check Out of Room The arrow is from the including use case to the included use case 25 Associations Between Use Cases 0 More examples of Includes Make New Patient Appointment includes Create New Patient Register Classes includes Verify Student Deposit money includes Verify User Withdraw money includes Verify User Register Guest includes Check Payment Pay Bill includes Check Payment In Visio this includes association is denoted as ltltusesgt2 Associations Between Use Cases Extends a use case is created to extend the functionality of a base extending use case The base use case is dependent on an extended use case The extended use case is independent of the extending base use case Extends A use case is different for special circumstances 27 Associations Between Use Cases For example If a customer is an employee heshe receives an employee discount when checking out If the student is an athlete heshe can enroll in any class during registeration even the class section is full If the patron is a VIP no late fee charged even when heshe returns a book past a deadline 28 Associations Between Use Cases Extension Point Apply Employee Discount Before Step 5 KEN 39 7 st x AVE 7 7 v Extension Point Register Athlete Register NonAthlete After Step 3 l I Extension Point Waive Fine Before Step 3 ltltextendsgtgt ltltextendsgtgt I ltltextendsgtgt ltltextendsgtgt Enfpll ly Register Register P yee Athlete NonAthlete Discount Arrow from the extended to the baseextending 29 Generalization Student is more general than Graduate or Undergraduate Student Or Graduate and Undergraduate inherit from Student Generalization is also referred as an isa relationship Student g it Graduate Undergraduate 30 Notation in Visio Notation under UML Use Case tab in Visio l ltltextendsgtgt l Dice Game i Play Dice A ltltusesgtgt 1 lt Playe Actor Use case System boundary extends and usesincludes change to dashed line from Line Pattern in top menu bar Change to the right arrow for the line end from Line Ends in top menu bar 31 Notation in Visio Notation under UML Static Structure tab in Visio i generalization D note 32 Case 4 Appointment System Brief description of an appointment system If a patient is an old patient he can sign in with his login information such as id and password and then create a new appointment cancel or change existing appointment If a patient is new he must provide more personal information such as address ssn etc so that to create a new patient account Then he signs in and then he can create an appointment cancel or change existing appointment 33 Case 4 Appointment System Actor identified Patient Old patient New patient Use cases identified Sign In Create New Patient Create Appointment Cancel Appointment Change Appointment 34 Use Case Diagram for Appointment System Appointment System Patient Create Appuiniment Cancel Appointment Old Patient i Change Appointment 0 Newguem Create New Paient Use Case Diagram for Appointment System Another Appointment System solution Patient gt i ltltus sgtgt I I 1 i 1 i ltltusesgtgt eands I Did Patient i 1 i l I i 1 i 1 i 1 Cancel Appointment New Patient Use Case Scenarios is a narrative of a single occurrence of a use case It describes specifics of a realworld enactment of the use case can help discover alternative paths through a use case or test the completeness or correctness of a use case narrative For example John registered for class cis 23501 and printed out his registered class list Jane tried to register for cis 23501 but failed because the class was full Sam failed to enroll in any class because he is not a student in good standing 37 EXPANDED USE CASE NARRATIVES Use Case Narratives High level use case narratives to provide an overview of the scope and functionality of a system Expanded use case narratives It shows low level actor39s actions and corresponding system39s responses in sequence which are known as flow of events 39 Expanded Use Case Narratives Precondition A condition which must be true in order for the use case to begin and produce the desired results Postcondition A condition which must be true after the use case has been completed Special Requirements A requirement which is critical to users acceptance and use of the system Flow of Events a sequence of actions of an actor and the corresponding responses of the system Alternative Flow of Events What the system should do in the case of exceptional conditions or errors 40 Use case Register for Classes Actors Student Purpose Register a student for classes and record the student39s schedule Overview A Student requests the sections of class desired for a term The system adds the Student to each section if there is space available On completion the system provides the Student with a list of the classes in which he or she is enrolle Type Essential Preconditions Class schedule must exist Student is known by the system Postconditions Student was enrolled in the section Special Requirements Student must get a system response within 10 seconds Flow of Events ACI39OR ACTION SYSTEM RESPONSE This use case begins when a Student desires to register for classes The Student provides the Student39s 3 Adds the student to the section identifier and a list of the department if there are seats available code course number and section number for each section desired On completion of entry of the section 5 Produces a student class list for requests the Student indicates that the Student the request is complete The Student receives the student t class 5 N 5 9 Alternative Flow of Events Figure 412 Expanded essential use case narrative for Register for Classes 41 Expanded Use Case Narratives Types of Use Cases Amount of information M l l l U E Highlevel overview of Detailed description of issues a issues essential to essential to understanding a understanding required required functionality 5 functionality Highlevel overview of a Detailed description of a E specific set of steps specific set of steps g performed on the real performed on the real system once system once implemented 7 implemented In essential the narrative ignores the specifics of the technology 42 Expanded Use Case Narratives 0 Register class Register Athlete and Register Non Athlete Extension Point Register Athlete Register NonAthlete After Step 3 Register Register Athlete NonAthlete 43 Expanded Use Case Narratives Expanded use case narratives for Register for Classes Flow of Events Actor action System response 1 This use case begins when a student desires to register for classes 2 the student provides his ID 3 checks if the student is an althlete If yes executes Register Athlete use case otherwise executes Register NonAthlete use case Alternative Flow of Events Step 3 Invalid student id entered Indicate error The use case terminates 44 Expanded Use Case Narratives Expanded use case narratives for Register Athlete Flow of Events Actor action System response 1 This use case begins when an athlete student desires to register for classes 2 the student provides a list of department code course number and section numbers 3 Adds the student to the sections 4 On completion of entry of the requests the student indicates that the request is complete 5 produces a student class list to the student 6 The student receives his enrolled class list Alternative Flow of Events Step 3 Invalid department code course number or section number entered Indicate error Return to Step 2 45 Expanded Use Case Narratives Expanded use case narratives for Register NonAthlete Flow of Events Actor action System response 1 This use case begins when a nonalthlete student desires to register for classes 2 the student provides a list of department code course number and section numbers 3 Adds the student to the sections if seats available 4 On completion of entry of the requests the student indicates that the request is complete 5 produces a student class list to the student 6 The student receives his enrolled class list Alternative Flow of Events Line 3 Invalid department code course number or section number entered Indicate error Return to Step 2 No seats remaining Inform the student Return to Step 2 Case 1 Dice Game Expanded Use Case Narrative For each use case producing an expanded essential use case narrative A use case in the use case diagram often comprises several low level events Expanded essential use case narrative for case 1 Use case Play Dice Actor Player Purpose Play two dice to generate a total face value Type Essential Preconditions Two dice exist Postconditions A total face value is generated 47 Case 1 Expanded Use Case Narrative FIOW Of events a twocolumn table listing lowlevel events and system responses to them Actor action System response 1 This use case begins when a player desires to roll two dice 2 The player plays two dice 3 Shows a total face value of two dice 4 On completion of the play the player indicates that the play is complete 5 The player receives the total number 48 Case 2 Registration System Expanded use case narratives Use case Register for classes Actor Student Purpose Register a student for classes and record the student s schedule Overview A student requests the class sections The system adds the student if these is space available On completion the system provides the student with a list of his enrolled classes Type Essential means the narrative ignores the specifics of the technology Preconditions student is in good standing class schedule is available Postconditions student was enrolled in the sections 49 Case 2 Expanded use case narratives Flow of Events Actor action System response 1 This use case begins when a student desires to register for classes 2 the student provides his ID and a list of department code course number and section numbers 3 Adds the student to the sections if seats available 4 On completion of entry of the requests the student indicates that the request is complete 5 produces a student class list to the student 6 The student receives his enrolled class list 50 Case 2 Expanded use case narratives Alternative Flow of Events Step 3 Invalid student id entered Indicate error The use case terminates Invalid department code course number or section number entered Indicate error Return to Step 2 No seats remaining Inform the student Return to Step 2 51 In class exercise Produce a Flow of Events for Submit Classes 52 In class exercise Flow of Events for Submit classes Actor action System response 1 This use case begins when a department desires to submit scheduled classes 2 the department provides ID and information for a list of scheduled courses such as course ids numbers section numbers and description 3 Adds the classes if the deadline is not passed 4 On completion of entry of the requests the department indicates that the request is complete 53 In class exercise Alternative Flow of Events for Submit classes Step 3 Invalid department id entered Indicate error The use case terminates Invalid course id course number or section number entered Indicate error Return to Step 2 Deadline passed Inform the department Return to Step 2 54 Case 3 POS system Expanded use case narratives Use case Check Out Items Actor Cashier Purpose Cashier checks out items Overview A cashier scans bar codes on items the system responds with the item names and their unit prices The cashier can enter quantity for any item if it is greater than one Type Essential Preconditions bar code on item can be recognized system contains information for the item Postconditions a total amount is calculated 55 Case 3 Expanded use case narratives Flow of Events Actor action System response 1 This use case begins when a cashier desires to check out items 2 the cashier scans bar code on an item on the system 3 Shows the item name and unit price 4 The cashier can enter a quantity if the quantity is greater than one 5 Updates the subtotal 6 On completion of item scan the cashier indicates completion 7 Calculate order total and ask for payment 8 The cashier sees the total amount 56 Case 3 Expanded use case narratives Alternative Flow of Events Step 3 Bar code not recognized cashier manually enters the code of the item 57 Case 4 Appointment system Expanded use case narratives Use case Make appointment Actor Patient Purpose Patient makes an appointment as well as changes or cancels it Overview Old patient can make appointment change or cancel appointment after signing in New patient needs to first create an account and sign in to do the same as old patient does Type Essential Preconditions Postconditions an appointment is made changed or cancelled 58 Case 4 Expanded use case narratives Flow of Events Actor action System response 1 This use case begins when a 2 allows patient to sign in or sign on patient starts to use the system 2 The patient makes a choice for 3 Displays functions available for patient sign in or sing on 4 The patient makes a choice for 5 executes Create Appointment use case creating changing or canceling if patient chooses to do so appointment execute Change Appointment if patient chooses to do so execute Cancel Appointment if patient chooses to do so 6 On completion the patient 7 provides a confirmation for the activity indicates completion 8 The cashier receives the confirmation 59 Case 4 Expanded use case narratives Alternative Flow of Events Step 3 If new patient system execute Create New Patient use case 60 In class exercise Appointment System Patient Create Appointment Cancel Appointment Old Patient Change Appointment Create New Patient New Patient Given the use case diagram for appointment system now assume that we need to add a new use case obtain patient insurance information Please revise the diagram 61 In class exercise Old Patient New Patient Appointment System Create Appumtment Cancel Appmmment Change Appointment Create New Pahenl Get nsurance Info Required Skills of Systems Analysts Technical skills Business skills People skills 63 In class discussion Giant Forest Inn Textbook p89 91 in particular the four paragraphs in p90 from quotSpecial Check In Services 64
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'