TA S K A N A LY S I S A N D M O D E L I N G In Chapter 13, we discussed stepwise elaboration (also called functional
15.3 TA S K A N A LY S I S A N D M O D E L I N G In Chapter 13, we discussed stepwise elaboration (also called functional
decomposition or stepwise refinement) as a mechanism for refining the pro- cessing tasks that are required for software to accomplish some desired func- tion. Later in this book, we consider object-oriented analysis as a modeling approach for computer-based systems. Task analysis for interface design uses either an elaborative or object-oriented approach but applies this approach to human activities.
Task analysis can be applied in two ways. As we have already noted, an interac- tive, computer-based system is often used to replace a manual or semi-manual activ- ity. To understand the tasks that must be performed to accomplish the goal of the Task analysis can be applied in two ways. As we have already noted, an interac- tive, computer-based system is often used to replace a manual or semi-manual activ- ity. To understand the tasks that must be performed to accomplish the goal of the
Regardless of the overall approach to task analysis, a human engineer must first define and classify tasks. We have already noted that one approach is stepwise elab- oration. For example, assume that a small software company wants to build a
Human tasks are computer-aided design system explicitly for interior designers. By observing an inte- defined and classified
as part of task rior designer at work, the engineer notices that interior design comprises a number analysis. A process of
of major activities: furniture layout, fabric and material selection, wall and window elaboration is used to
coverings selection, presentation (to the customer), costing, and shopping. Each of refine tasks.
these major tasks can be elaborated into subtasks. For example, furniture layout can Alternatively, objects
be refined into the following tasks: (1) draw a floor plan based on room dimensions; identified and refined.
and actions are
(2) place windows and doors at appropriate locations; (3) use furniture templates to draw scaled furniture outlines on floor plan; (4) move furniture outlines to get best placement; (5) label all furniture outlines; (6) draw dimensions to show location; (7) draw perspective view for customer. A similar approach could be used for each of the other major tasks.
Subtasks 1–7 can each be refined further. Subtasks 1–6 will be performed by manip- ulating information and performing actions within the user interface. On the other hand, subtask 7 can be performed automatically in software and will result in little direct user interaction. The design model of the interface should accommodate each of these tasks in a way that is consistent with the user model (the profile of a "typi- cal" interior designer) and system perception (what the interior designer expects from an automated system).
An alternative approach to task analysis takes an object-oriented point of view. Object-oriented analysis techniques can be
XRef
The human engineer observes the physical objects that are used by the interior applied during task
designer and the actions that are applied to each object. For example, the furni- analysis. These are
ture template would be an object in this approach to task analysis. The interior discussed in Chapter
21. designer would select the appropriate template, move it to a position on the floor plan, trace the furniture outline and so forth. The design model for the interface
would not provide a literal implementation for each of these actions, but it would define user tasks that accomplish the end result (drawing furniture outlines on the floor plan).
4 In many cases the activities described in this section are performed by a software engineer. Ide- ally, the individual has had some training in human engineering and user interface design.
PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G
15.4 I N T E R FA C E D E S I G N A C T I V I T I E S
Once task analysis has been completed, all tasks (or objects and actions) required by the end-user have been identified in detail and the interface design activity com- mences. The first interface design steps [NOR86] can be accomplished using the fol- lowing approach:
1. Establish the goals 5 ? and intentions for each task.
What steps
do we
2. Map each goal and intention to a sequence of specific actions.
perform to accomplish
3. Specify the action sequence of tasks and subtasks, also called a user scenario,
interface design?
as it will be executed at the interface level.
4. Indicate the state of the system; that is, what does the interface look like at the time that a user scenario is performed?
5. Define control mechanisms; that is, the objects and actions available to the user to alter the system state.
6. Show how control mechanisms affect the state of the system.
7. Indicate how the user interprets the state of the system from information pro- vided through the interface.
Always following the golden rules discussed in Section 15.1, the interface designer must also consider how the interface will be implemented, the environment (e.g., display technology, operating system, development tools) that will be used, and other elements of the application that “sit behind” the interface.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more