(BQ) Part 2 book Essentials of systems analysis and design has contents: Designing the human interface, designing databases, systems implementation and operation.
www.downloadslide.com Designing the Human Interface Chapter Objectives Tetra Images/Getty Images eight After studying this chapter, you should be able to: ■ ■ ■ ■ Explain the process of designing forms and reports, and the deliverables for their creation ■ ■ ■ Apply the general guidelines for formatting forms and reports Format text, tables, and lists effectively Explain the process of designing interfaces and dialogues, and the deliverables for their creation Describe and apply the general guidelines for interface design, including guidelines for layout design, structuring data-entry fields, providing feedback, and system help Design human-computer dialogues, including the use of dialogue diagramming Discuss interface design guidelines unique to the design of Internet-based electronic commerce systems 264 # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 264 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 264 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com Chapter Preview . . . Analysts must complete two important activ- blocks for designing all forms and reports We ities in the systems design phase, as i llustrated present guidelines for formatting information in Figure 8-1: designing the human interface and for designing interfaces and dialogues and designing databases Here, you learn guide- Next, we show you a method for representing lines to follow when designing the human- human-computer dialogues called dialogue computer interface In the first section, we diagramming Finally, we close by examin- describe the process of designing forms and re- ing various human-computer interface design ports and provide guidance on the deliverables issues for Internet-based applications, specifi- produced during this process Properly format- cally as they apply to Pine Valley F urniture’s ted segments of information are the building WebStore Systems Planning and Selection Systems Implementation and Operation SDLC Systems Analysis Systems Design ✓ Designing the Human Interface Designing Databases FIGURE 8-1 The systems design phase consists of two important activities: designing the human interface and designing databases 265 # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 265 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 265 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com 266 Part IV Systems Design Designing Forms and Reports Form A business document that contains some predefined data and may include some areas where additional data are to be filled in; typically based on one database record Report A business document that contains only predefined data; it is a passive document used only for reading or viewing; typically contains data from many unrelated records or transactions System inputs and outputs—forms and reports—are produced at the end of the systems analysis phase of the SDLC During systems analysis, however, you may not have been concerned with the precise appearance of forms and reports Instead, you focused on which forms and reports needed to exist and the content they needed to contain You may have distributed to users the prototypes of forms and reports that emerged during analysis as a way to confirm requirements Forms and reports are integrally related to the DFD and E-R diagrams developed during requirements structuring For example, every input form is associated with a data flow entering a process on a DFD, and every output form or report is a data flow produced by a process on a DFD Therefore, the contents of a form or report correspond to the data elements contained in the associated data flow Further, the data on all forms and reports must consist of data elements in data stores and on the E-R data model for the application or else be computed from these data elements (In rare instances, data simply go from system input to system output without being stored within the system.) It is common to discover flaws in DFDs and E-R diagrams as you design forms and reports; these diagrams should be updated as designs evolve If you are unfamiliar with computer-based information systems, it will be helpful to clarify exactly what we mean by a form or report A form is a business document containing some predefined data and often includes some areas where additional data are to be filled in Most forms have a stylized format and are usually not in simple rows and columns Examples of business forms are product order forms, employment applications, and class registration sheets Traditionally, forms have been displayed on a paper medium, but today, video display technology allows us to duplicate the layout of almost any printed form, including an organizational logo or any graphic, on a video display terminal Forms on a video display may be used for data display or data entry Additional examples of forms are an electronic spreadsheet, computer sign-on or menu, and an automated teller machine (ATM) transaction layout On the Internet, form interaction is the standard method of gathering and displaying information when consumers order products, request product information, or query account status A report is a business document containing only predefined data; it is a passive document used solely for reading or viewing Examples of reports are invoices, weekly sales summaries by region and salesperson, and a pie chart of population by age categories We usually think of a report as printed on paper, but it may be printed to a computer file, a visual display screen, or some other medium such as microfilm Often a report has rows and columns of data, but a report may consist of any format—for example, mailing labels Frequently, the differences between a form and a report are subtle A report is only for reading and often contains data about multiple unrelated records in a computer file On the other hand, a form typically contains data from only one record or is, at least, based on one record, such as data about one customer, one order, or one student The guidelines for the design of forms and reports are similar The Process of Designing Forms and Reports Designing forms and reports is a user-focused activity that typically follows a prototyping approach First, you must gain an understanding of the intended user and task objectives during the requirements determination process During this process, the intended user must answer several questions that attempt to answer the who, what, when, where, and how related to the creation of all forms or reports, as listed in Table 8-1 Gaining an understanding of these questions is a required first step in the creation of any form or report # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 266 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 266 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com Chapter 8 Designing the Human Interface 267 T A BLE 8-1 : Fundamental Questions When Designing Forms and Reports Who will use the form or report? What is the purpose of the form or report? When is the form or report needed and used? Where does the form or report need to be delivered and used? How many people need to use or view the form or report? Understanding the skills and abilities of the users helps you create an effective design Are your users experienced computer users or novices? What is their educational level, business background, and task-relevant knowledge? Answers to these questions provide guidance for both the format and the content of your designs Also, what is the purpose of the form or report? What task will users be performing, and what information is needed to complete this task? Other questions are also important to consider Where will the users be when performing this task? Will users have access to online systems or will they be in the field? How many people will need to use this form or report? If, for example, a report is being produced for a single user, the design requirements and usability assessment will be relatively simple A design for a larger audience, however, may need to go through a more extensive requirements collection and usability assessment process After collecting the initial requirements, you structure and refine this information into an initial prototype Structuring and refining the requirements are completed without assistance from the users, although you may occasionally need to contact users to clarify some issue overlooked during analysis Finally, you ask users to review and evaluate the prototype; then they may accept the design or request that changes be made If changes are needed, repeat the constructionevaluate-refinement cycle until the design is accepted Usually, several repetitions of this cycle occur during the design of a single form or report As with any prototyping process, you should make sure that these iterations occur rapidly in order to gain the greatest benefit from this design approach The initial prototype may be constructed in numerous environments, including Visual Basic, Java, or HTML The obvious choice is to employ standard development tools used within your organization Often, initial prototypes are simply mock screens that are not working modules or systems Mock screens can also be produced from a word processor, computer graphics design package, or presentation software It is important to remember that the focus of this phase within the SDLC is on the design—content and layout How specific forms or reports are implemented (e.g., the programming language or screen painter code) is left for a later stage Nonetheless, tools for designing forms and reports are rapidly evolving In the past, inputs and outputs of all types were typically designed by hand on a coding or layout sheet For example, Figure 8-2 shows the layout of a data input form using a coding sheet Although coding sheets are still used, their importance has diminished because of significant changes in system operating environments and the evolution of automated design tools Prior to the creation of graphical operating environments, for example, analysts designed many inputs and outputs that were 80 columns (characters) by 25 rows, the standard dimensions for most video displays These limits in screen dimensions are radically different in graphical operating environments such as Mac OS or Windows where font sizes and screen dimensions can often be changed from user to user Consequently, the creation of new tools and development environments was needed to help analysts and # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 267 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 267 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com 268 Part IV Systems Design FIGURE 8-2 The layout of a data input form using a coding sheet Source: Reprinted with permission of Microsoft SYSTEM PROGRAM PROGRAMMER Customer Information Entry STAN DATE 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 C U S T OME R – – – – – – – – I N F O RMA T I ON – – – – – – – – – – – C U S T OME R NUMB E R : NAME : ADDR ESS : C I T Y : S T A T E : Z I P : 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 programmers develop these graphical and flexible designs Figure 8-3 shows an example of the same data input form as designed in Microsoft’s Visual Basic.Net Note the variety of fonts, sizes, and highlighting that was used Online graphical tools for designing forms and reports are rapidly becoming the standard in most professional development organizations Deliverables and Outcomes Each SDLC activity helps you to construct a system In order to move from phase to phase, each activity produces some type of deliverable that is used in a later activity For example, within the systems planning and selection phase of the SDLC, the baseline project plan serves as input to many subsequent SDLC # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 268 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 268 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com Chapter 8 Designing the Human Interface 269 FIGURE 8-3 A data input screen designed in Microsoft’s Visual Basic.Net Source: Reprinted with permission of Microsoft activities In the case of designing forms and reports, design specifications are the major deliverables and are inputs to the system implementation and operation phase Design specifications have three sections: Narrative overview Sample design Testing and usability assessment The narrative overview provides a general overview of the characteristics of the target users, tasks, system, and environmental factors in which the form or report will be used Its purpose is to explain to those who will actually develop the final form, why this form exists, and how it will be used so that they can make the appropriate implementation decisions In this section, you list general information and the assumptions that helped shape the design For example, Figure 8-4 shows an excerpt of a design specification for a customer account status form for Pine Valley Furniture The first section of the specification, Figure 8-4A, provides a narrative overview containing the information relevant to developing and using the form within PVF The overview explains the tasks supported by the form, where and when the form is used, characteristics of the people using the form, the technology delivering the form, and other pertinent information For example, if the form is delivered on a visual display terminal, this section would describe the capabilities of this device, such as navigation and whether it has a touch screen and whether color and a mouse are available In the second section of the specification, Figure 8-4B, a sample design of the form is shown This design may be hand-drawn using a coding sheet, although, in most instances, it is developed using standard development tools Using actual development tools allows the design to be more thoroughly tested and assessed The final section of the specification, Figure 8-4C, provides all testing and usability assessment information Some specification information may be irrelevant when designing certain forms and reports For example, the design of # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 269 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 269 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com 270 Part IV Systems Design FIGURE 8-4 A design specification for a customer account status form for Pine valley furniture: A The narrative overview containing the information relevant to developing and using the form within PVF B A sample design of the PVF form C Testing and usability assessment information Source: Reprinted with permission of Microsoft (A) Narrative overview Form: Users: Task: Customer Account Status Customer account representatives within corporate offices Assess customer account information: address, account balance, year-to-date purchases and payments, credit limit, discount percentage, and account status System: Microsoft Windows Environment: Standard office environment (B) Sample design (C) Testing and usability assessment User-Rated Perceptions (average 14 users): consistency [1 = consistent to = inconsistent]: sufficiency [1 = sufficient to = insufficient]: accuracy [1 = accurate to = inaccurate]: … 1.52 1.43 1.67 a simple yes/no selection form may be so straightforward that no usability assessment is needed Also, much of the narrative overview may be unnecessary unless intended to highlight some exception that must be considered during implementation Formatting Forms and Reports A wide variety of information can be provided to users of information systems, ranging from text to video to audio As technology continues to evolve, a greater variety of data types will be used A definitive set of rules for delivering every type of information to users has yet to be defined because these rules are continuously evolving along with the rapid changes in technology Research conducted by computer scientists on human-computer interaction has provided numerous general guidelines for formatting information Many of these guidelines undoubtedly will apply to the formatting of all evolving information types on yet-to-be-determined devices Keep in mind that designing usable forms and reports requires your active interaction with users If this single and fundamental activity occurs, you will likely create effective designs For example, the human-computer interface is one of the greatest challenges for designing mobile applications that run on devices such as the iPhone # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 270 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 270 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com Chapter 8 Designing the Human Interface 271 In particular, the small video display of these devices presents significant challenges for application designers Nevertheless, as these and other computing devices evolve and gain popularity, standard guidelines will emerge to make the process of designing interfaces much less challenging General Formatting Guidelines Over the past several years, industry and academic researchers have investigated how information formatting influences individual task performance and perceptions of usability Through this work, several guidelines for formatting information have emerged, as highlighted in Table 8-2 These guidelines reflect some of the general truths of formatting most types of information The differences between a well-designed form or report and a poorly designed one often will be obvious For example, Figure 8-5A shows a poorly designed form for viewing a current account balance for a PVF customer Figure 8-5B is a better design, incorporating several general guidelines from Table 8-2 The first major difference between the two forms has to with the title The title in Figure 8-5A (Customer Information) is ambiguous, whereas the title in Figure 8-5B (Detail Customer Account Information) clearly and specifically describes the contents of the form The form in Figure 8-5B also includes the date (October 11, 2015) the form was generated so that, if printed, it will be clear to the reader when this occurred Figure 8-5A displays the account status and customer address, information that is extraneous to viewing the current account balance, which is the intent of the form, and provides information that is not in the most useful format for the user For example, Figure 8-5A provides all customer data, as well as account transactions and a summary of year-to-date purchases and payments The form does not, however, provide the current outstanding balance of the account, leaving the reader to perform a manual calculation The layout of information between the two forms also varies in balance and information density Gaining an understanding of the skills of the intended system users and the tasks they will be performing is invaluable T A BLE 8-2 : Guidelines for Designing Forms and Reports Guideline Description Use meaningful titles Clear and specific titles describing content and use of form or report Revision date or code to distinguish a form or report from prior versions Current date that identifies when the form or report was generated Valid date that identifies on what date (or time) the data in the form or report were accurate Include meaningful information Only needed information displayed Information provided in a usable manner without modification Balance the layout Information balanced on the screen or page Adequate spacing and margins used All data and entry fields clearly labeled Design an easy navigation system Clearly show how to move forward and backward Clearly show where you are (e.g., page of 3) Notify user of the last page of a multipage sequence # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 271 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 271 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com 272 Part IV Systems Design Difficult to read: information is packed too tightly Vague title Easy to read: clear, balanced layout No navigation information Clear title Summary of account information No summary of account activity Clear navigation information B A FIGURE 8-5 Contrast of a poorly designed and a well-designed form: A A poorly designed form for viewing a current account balance for a PVF customer B A better design, which incorporates several general guidelines from Table 8-2 Source: Reprinted with permission of Microsoft when constructing a form or report By following these general guidelines, your chances of creating effective forms and reports will be enhanced In the next sections, we discuss specific guidelines for highlighting information, displaying text, and presenting numeric tables and lists Highlighting Information As display technologies continue to improve, a greater variety of methods will be available to highlight information Table 8-3 lists the most commonly used methods for highlighting information Given this vast array of options, it is important to consider how highlighting can be used to enhance an output without being a distraction In general, highlighting should be used sparingly to draw the user to or away from certain information and to group together related information In several situations, highlighting can be a valuable technique for conveying special information: ■ ■ ■ Notifying users of errors in data entry or processing Providing warnings to users regarding possible problems, such as unusual data values or an unavailable device Drawing attention to keywords, commands, high-priority messages, and data that have changed or gone outside normal operating ranges Highlighting techniques can be used singularly or in tandem, depending upon the level of emphasis desired by the designer Figure 8-6 shows a form where several types of highlighting are used In this example, columns clarify different # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 272 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 272 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com Chapter 8 Designing the Human Interface 273 T A BLE 8-3 : Methods of Highlighting Blinking and audible tones Color differences Intensity differences Size differences Font differences Reverse video Boxing Underlining All capital letters Offsetting the position of nonstandard information categories of data; capital letters and different fonts distinguish labels from actual data; and bolding is used to draw attention to important data Highlighting should be used conservatively For example, blinking and audible tones should be used only to highlight critical information requiring the user’s immediate response Once a response is made, these highlights should be turned off Additionally, highlighting methods should be consistently selected Font size, intensity All capital letters FIGURE 8-6 A form in which several types of highlighting are used Boxing Intensity differences # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 273 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 273 Source: Reprinted with permission of Microsoft C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 9:05 PM www.downloadslide.com 442 Index Project reports, reviewing, 102–103 Project repository, 45, 222–223, 226, 233 Project scope statement defined, 130 example, 130–131, 131f overview, 40, 89, 119, 130–131 Project workbooks, 80–81, 81f, 91 Prompting cues feedback, 287 Prototyping advantages of, 44 as alternative to SDLC, 44 defined, 44 in determining system requirements, 167–168 in dialogue design, 292–293 flowchart, 44 in forms/reports design, 267 in rapid application development, 45–47 website evolution, 173 Purpose, 32, 33f Q Quick reference guides, 368 R RAD (rapid application development), 45–47, 185 Range control, 330 Rapid application development (RAD), 45–47, 185 Recontextualization, software reuse, 66 Recovery testing, 364, 386, 386t Recurring costs, 124, 125f Recursive foreign keys, 322 Recursive relationship association, 400 defined, 233–234, 322 example, 401f represent relationships, 322 Reengineering processes, 169–170, 382 Refactoring, 424 Reference guides, 368 Referential integrity, 318, 330–331 Relational database model, 313–314 Relations defined, 314 merging, 322–323 normalizing, 322 transforming E-R diagrams into, 318–322, 323t Relationships aggregation, 404 association, 400–402 binary (See Binary relationships) cardinality in, 234–235 conceptual data modeling and SDLC, 224f customer, 80 defined, 232 degrees of, 233 DFDs and forms/reports, 266 E-R [See E-R (entity-relationship) diagrams] in E-R diagram transformation, 318–322, 323t extends, 398 generalization, 402–404 network diagrams, 87, 101–102 recursive (See Recursive relationship) ternary (See Ternary relationships) unary (See Unary relationships) Release descriptions, 369 Repeating group, 232 Report defined, 266 generated, 162, 164f paper vs electronic, 277–278 project, 102–103 See also Forms and reports design Repository, 45, 222–223, 226, 233 Request for proposal (RFP), 63–64 Request for quote (RFQ), 63 Requirements, system determining (See System requirements, determining) use-case modeling, 396–399 See also Conceptual data modeling; Process modeling Resources, 96 Resources, project planning, 85–86 Response time, 63 Return on investment (ROI), 126, 128t Reusing existing software, 64–67 Reverse engineering, 382 Reviews, postproject, 93 RFP (request for proposal), 63–64 RFQ (request for quote), 63 Risk assessment, 88–89 ROI (return on investment), 126, 128t Rules, decision table, 202 S Sample designs, 269, 270f, 279 SAP, 36 SAP AG, 59 Schedule feasibility, 128 Scope determination, 40, 89, 129–130 See also Project scope statement Scribes, 165 SDLC See Systems development life cycle (SDLC) # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 442 Title: Essentials of Systems Analysis and Design, 6/e Z05_VALA6614_06_GE_INDX.indd 442 Search engines, reregistering with, 383 Secondary key, 313, 334 Second normal form (2NF), 315, 316–317 Security testing, 364, 386, 386t Sequence diagrams, 396, 406–408 Sequential file organization, 334, 335f, 337t Servers, 36, 36f Simple design, 424 Simple message, 407 Single-location installation, 364, 365f, 366t Slack time, 99, 100 Smartphone app, 387 Software application testing, 359 See also Testing Software companies, 58t Software engineering process, 31 Software help components, 371–372 Software sources, 54–71 cloud computing, 60 comparison of, 61t enterprise solutions software, 36, 59–60 in-house development, 55–56, 61 IT services firms, 57–58 open-source software, 60–61 outsourcing, 56–57 packaged software, 61–64 Petrie’s Electronics, example from, 69–70 prepackaged software, 58 reuse, 64–67 systems acquisition, 55–56 SourceForge.net, 61 Source/sink, 185–186, 189 SSR (system service request), 76 State, defined, 404 State, of objects, 399 State diagrams, 396, 404–406 State transition, 404 Static structure chart, 401, 402f Status information feedback, 286–287 Storage, software reuse, 65–66 Story Cards, 422–423 Stress testing, 364, 386, 386t Stub testing, 360t, 361 Style sheet-based HTML, 297–298 Subclasses, 402–404 Subsystems, 32, 33f, 34–35 Superclasses, 402–404 Support, defined, 370 Supporting users, 357, 370, 372–375 Synchronous message, 407 Synonyms, defined, 324 Syntax checking, 360t, 361 System administrator’s guide, 369 System audits, 377 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 8:30 PM www.downloadslide.com Index 443 System documentation, 367–370 analysis, 160–163 audience of, 356, 369 automatic updating of, 382 as criterion for packaged software, 63 defined, 367 deliverables and outcomes, 357 effect on maintenance, 379 internal/external, 367 overview, 42–43 preparation, 369–370 process of, 356 types of, 367–368 user, 360–362, 367, 369–370 System features, 245–247 System feedback, 286–287 System librarian, 381 System requirements, determining, 150–179 in Agile Methodologies, 420–423 business process reengineering, 169–170 data modeling questions, 227, 228t deliverables and outcomes, 153–154 direct observation of users, 159–160, 165t disruptive technologies, 170, 171t document analysis, 160–163 example, 170–174 interviewing, 154–159 joint application design, 163–167 in object-oriented modeling, 397 process of, 152–154 prototyping, 167–168, 173 System requirements, structuring, 154 See also Conceptual data modeling; Process modeling Systems, 32–36, 38–44 application software, 30 cohesion, 35 components, 32 coupling, 35 decomposition, 33–35 defined, 32 environment, 32–33 modularity, 35 See also Systems development life cycle (SDLC) Systems acquisition See Software sources Systems analysis in object-oriented modeling, 395–396 overview, 40–41, 43, 151f system requirement determination (See System requirements, determining) system requirement structuring, 154 (See also Conceptual data modeling; Process modeling) Systems analysis and design approaches to, 36–38, 44–47 (See also Agile Methodologies) core concepts, 30–32 history of, 55–56 role of systems analyst in, 37–38 systems development life cycle, 38–44 [See also Systems development life cycle (SDLC)] Systems analysts defined, 37 design strategy influences, 244–245 job market, 37 role in coding, testing, and installation, 356 role in project initiation and planning, 118, 119f role in support, 374–375 role in systems development, 37–38 skills needed, 37, 38f, 152–153 Systems design designing databases (See Database design) designing human interface (See Interface design) in object-oriented modeling, 396, 409–410 overview, 41, 43t, 265f Systems development life cycle (SDLC) Agile Methodologies’ approach to, 419 defined, 38, 39f evolutionary model, 39–40, 39f maintenance activities within, 357–358 overview, 38–40 phase 1, 40 (See also Systems planning and selection) phase 2, 40–41 (See also Systems analysis) phase 3, 41 (See also Database design; Interface design; Systems design) phase 4, 41–44 (See also Systems implementation and operation) project management, 73f vs rapid application development, 46f steps, 29f Systems development methodology, 38 System service request (SSR), 76 System shut down, 366–367 Systems implementation and operation, 352–394 in Agile Methodologies, 425–426 coding (See Coding) configuration management, 381 # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 443 Title: Essentials of Systems Analysis and Design, 6/e Z05_VALA6614_06_GE_INDX.indd 443 documentation (See System documentation) example, 384–387 implementation failure, 375–376 installation (See Installation) maintenance (See Systems maintenance) in object-oriented modeling, 410 overview, 41–44, 43t, 353–354, 353f project closedown, 92–94, 376–377 support, 357, 370, 372–375 testing, 359–364 (See also Testing) training, 357, 370–372 Systems integration, 36 Systems maintenance adaptive, 378, 378t automated development tools in, 382 configuration management, 381 controlling requests for, 380–381 corrective, 377–378, 378t cost of, 378–379 deliverables and outcomes, 358–359 example, 383–384 factors affecting, 378–379 measuring effectiveness of, 379–380 perfective, 378, 378t preventive, 378, 378t process of, 357–358 types of, 377–378 for web sites, 382–383 Systems planning and selection, 112–149 deliverables and outcomes, 117–118 examples, 145–147 overview, 40, 43t, 113f project identification and selection, 114–118 project initiation and planning (See Project initiation; Project planning) reviewing the baseline project plan, 135–138 Systems thinking, 37 System testing, 360t, 361 T Tables, designing, 275–277 Tangible benefit, 122 Tangible cost, defined, 123 Task Cards, 423 Task responsibility, 133f Technical feasibility, 128 Techniques, software engineering, 31 Ternary relationships in conceptual data modeling, 234, 234f in database design, 320–321 in object-oriented analysis/design, 401f C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 8:30 PM www.downloadslide.com 444 Index Test cases, 362–363, 384–385 Testing acceptance, 363–364 alpha, 363–364, 386, 386t beta, 363, 364, 386 defined, 361 deliverables and outcomes, 355–356 in eXtreme Programming, 419 functional, 361 integration, 360t, 361 mock client, 363–364 module, 361 overview, 42 performance, 364, 386, 386t process of, 355, 359, 361–363 recovery, 364, 386, 386t security, 364, 386, 386t software application, 359 software before purchase, 64 stress, 364, 386, 386t stub, 360t, 361 system, 360t, 361 systems analyst role in, 356 types of tests, 359–360 unit, 360t, 361 walkthroughs, 360, 360t Testing harness, 363 Text formatting, in forms and reports, 274, 275f Third normal form (3NF), 315, 317 Time value of money (TVM), 124–128 Timing, of data-flow diagrams, 197 Tools, software engineering, 31 Top-down data modeling, 227 Top-down project initiation, 115–116, 117f Total slack time, 100 Toyota, 170 Training programs, 42–43 Training users, 357, 370–372 Turnkey systems, 59, 61–64 TVM (time value of money), 124–128 support of, 357, 370, 372–375 training of, 357, 370–372 understanding skills of, 267, 269–270, 271–272 User’s guide, 368–369 U V UML (Unified Modeling Language), 396, 409f, 410 Unary relationships association, 400 defined, 233–234, 322 example, 401f represent relationships, 322 Unified Modeling Language (UML), 396, 409f, 410 Unit testing, 360t, 361 University system, 34f Usability assessment in forms/reports design, 269–270 in interface/dialogue design, 279, 282t, 292–293 Use case defined, 396 designing with a sequence diagram, 408 Use-case diagram, 397 Use-case modeling, 396–399 User documentation, 367, 369–370 Users acceptance testing by, 363–364 direct observation of, 159–160, 165t involvement in Agile Methodologies development, 47, 420–421 involvement in participatory design, 47 role in rapid application development, 46 Vendors, software, 63 View integration, 308, 323 Visual Basic, 36 # 153198 Cust: Pearson Education / OH / CHET Au: Valacich Pg No 444 Title: Essentials of Systems Analysis and Design, 6/e Z05_VALA6614_06_GE_INDX.indd 444 W Walkthroughs, 135–138 action list, 137, 137f defined, 135 guidelines for conducting, 360f individual roles, 135 meeting activities, 138 PVF WebStore, 141 review form, 135, 136f testing, 360, 360t Warning messages, 287 WBS (work breakdown structure), 84 Weak entity, 232 Web sites interface design, 294, 296t maintenance of, 382–383 See also Pine Valley Furniture Company (PVF Company) WebStore, examples from Well-structured relation (or table), 314–315 Workbooks, project, 80–81, 81f, 91 Work breakdown, 133 Work breakdown structure (WBS), 84 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 445 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 446 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 447 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 448 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 449 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 450 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 451 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 452 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 453 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 454 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 455 02/12/14 8:30 PM www.downloadslide.com Z05_VALA6614_06_GE_INDX.indd 456 02/12/14 8:30 PM ... : 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 programmers develop these graphical and flexible designs Figure 8-3 shows an example of the same data input form as designed... Valacich Pg No 28 2 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 28 2 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/ 12/ 14 9:05 PM... Valacich Pg No 27 2 Title: Essentials of Systems Analysis and Design, 6/e M08_VALA6614_06_GE_CH08.indd 27 2 C/M/Y/K Short / Normal DESIGN SERVICES OF S4carlisle Publishing Services 02/ 12/ 14 9:05 PM