Presentation is loading. Please wait.

Presentation is loading. Please wait.

A U Interface & Project Analysis Professor J. Alberto Espinosa Business Analysis ITEC-630 Fall 2009.

Similar presentations


Presentation on theme: "A U Interface & Project Analysis Professor J. Alberto Espinosa Business Analysis ITEC-630 Fall 2009."— Presentation transcript:

1 A U Interface & Project Analysis Professor J. Alberto Espinosa Business Analysis ITEC-630 Fall 2009

2 2 Objectives n Discuss interface analysis n Discuss project and cost estimation issues

3 3 Interface Analysis

4 4 Usability Derives from the industrial engineering field of “ergonomics” – how to design things so they are easy to use. It refers to the “quality of a user's experience when interacting with a product or system … and how well users can learn and use a product to achieve their goals and how satisfied they are with that process... people who use the product can do so quickly and easily to accomplish their tasks” – usability.govusability.gov Other references: http://www.usernomics.com/usability.html http://www.usernomics.com/usability.html

5 5 Interface “ The place at which independent and often unrelated systems meet and act on or communicate with each other ” – Webster dictionary Software Network Software HardwareUserSystem

6 6 User Interface Design Also referred to as “human computer interaction” (HCI) – is what the usability specialists do to build systems that are easy to use. HCI also derives from the field of “ergonomics” often referred to these days as “human factors” to include digital and virtual interaction, in addition to physical interaction. Other references: Cornell Univ: http://ergo.human.cornell.edu/ahtutorials/interface.html Virginia Tech: http://www.edtech.vt.edu/edtech/id/interface/ Carnegie Mellon: http://www.usernomics.com/user-interface-design.html http://ergo.human.cornell.edu/ahtutorials/interface.html http://www.edtech.vt.edu/edtech/id/interface/ http://www.usernomics.com/user-interface-design.html

7 7 Use Case Diagram without Interfaces

8 8 Use Case Diagram with Interfaces Ex.1: 1 Interface per Actor-UC Interaction

9 9 Use Case Diagram with Interfaces Ex.2: 1 Interface for Customer Actor’s Interaction with all UC’s

10 10 Use Case Diagram with Interfaces Ex.3: 1 Interface for Monitor ATM Status UC all Actors

11 11 If the actor is a user: n The interface specification describes how the user interacts with the system – i.e., the “user interface” (UI) – the “human-computer interaction” (HCI) If the actor is an external system: n The interface specification describes how the system interacts with that external system actor – i.e., the “application program interface” (API)

12 12 List of Interfaces Interface NameActor Funds WithdrawalUser Funds DepositUser Account ManagementUser Customer Activity InquiryUser ATM Status MonitorUser Cash ReplenishmentUser Customer Accounts SystemSystem

13 13 Each Interface Has: n A name n A set of “operation signatures” (for HCI and API) indicating: –which data to “get” from the actor with the operation (i.e., Get UserId, Name, etc.) –Which data to “return” to the actor when the operation is complete n A “storyboard” (for HCI only): visual illustration of the sequence of screen designs to complete these operations

14 14 Example of Operation Signatures: Funds Withdrawal Interface n Get data from card magnetic tape Get pass code from customer n Get customer transaction selection (user selects withdrawal) n Get account type for withdrawal n Get amount to withdraw n Return cash, or n Return error message to customer n Return thank you message to customer

15 15 A User Interface Can Be For: n Input into the system by the user for data entry or to query information from the system n A display output (on screen or other output device) by the system to the user n A printed output (on a printer or other output device)

16 16 Diagramming the Interface: with “ Storyboards ” n User interfaces can be diagrammed as “storyboards” n A storyboard is a series of drawings that depict how the system looks at the start of the operation and after each significant change to the look of the interface n Is like a sequence of screenshots that follows the use case execution sequence

17 17 Organization of a Storyboard Storyboard Sequence

18 18 A Bad Interface Storyboard

19 19 What to Include in an Interface Design Specification: n A list of all the interfaces between actors and use cases n For each interface (any actor – user or external system): –Indicate whether the actor is a user (human actor) or an external system –Prepare a list of operation signatures detailing all the data that is passed to/from the system before each operation and the data that is returned from/to the system after each operation n For users (human actors only): –Indicate when/if operations are taking place for data input, display outputs or printed outputs –Prepare a storyboard for all screen input/output displays and printouts –Design the visual interface for all screen input/output displays and printouts n For external system actors (only): –Indicate when/if operations are taking place to input or output data from/to the system

20 20 General Quality Attributes of a User Interface Design n Ease of use n Intuitive use and navigation n Consistency across screens n Simplicity – e.g., no clutter, no information overload, no busy graphics n Exit/cancel options for users n Forgiving n Businesslike appearance n Readable and good color contrast

21 A U Project Issues

22 22 The System Project and the UP

23 23 The Project Plan n It is based on iterations, per the UP n Define the iteration length n Develop a domain model early n Analyze, design, build, integrate, and test often n Estimate how many (fixed-length) iterations you will need for construction n Decide the order in which things will be built based on Use Case priorities n Try to build the core functionality of the product early (or at least prototype it)

24 24 Estimating Project Effort n Estimate the number of lines of code (LOCs) –Difficult to estimate upfront –Depends on the software language used –Not great for object-oriented systems & CASE tools n Constructive Cost Model (COCOMO)COCOMO –A popular method –Effort estimation based on LOCs estimated –Same difficulties as with LOCs estimation n Use Case Points (UCP) –Similar to function points, but based on Use Case metrics n Function Points (FP) –Estimating effort based on what the software does, not LOCs –Every software function (e.g., a display, report, a data store) has a function count –Then adjusted to function points based on complexity factors

25 25 Use Case Points (UCP) (Rational Software – a new way of estimating effort) n Count Actors and multiply by their weight: –1 for a simple actor (an external system with a well defined interface) –2 for an average actor (an external systems with less defined interface or a person using a simple interface) –3 for a complex actor (people using a more complex graphical interface) n Count Use Cases and multiply by their weight –5 for simple Use Cases (3 transactions or less) –10 for average Use Cases (4-7 transactions) –15 for complex (more than 7 transactions) –A transaction is a set of Use Case steps performed entirely or not at all (i.e., number of paths) n Unadjusted Use Case Points (UUCP) n Adjust for complexity and environmental factors

26 26 Calculate the Technical Complexity Factor (TCF ) FactorDescriptionWeight Rating 0: Irrelevant 5: Essential Weighted Rating T1Distributed system2 T2Response performance objectives1 T3End-user efficiency1 T4Complex internal processing1 T5Code must be reusable1 T6Easy to install0.5 T7Easy to use0.5 T8Portable2 T9Easy to change1 T10Concurrent1 T11Secure1 T12Access to 3 rd parties1 T13User training facilities1 TFactor = Sum of weighted ratings TCF = 0.6 + (0.01 * TFactor)

27 27 Calculate the Environmental Factor for the Team (EV ) FactorDescriptionWeight Rating 0: none 3: average 5: expert Weighted Rating F1Familiar with Rational UP1.5 F2Application experience0.5 F3Object-oriented experience1 F4Lead analyst capability0.5 F5Motivation1 0: none 5: highest F6Stable requirements2 0: unstable 5: very stable F7Part-time workers 0: none 5: all F8Difficult programming language 0: easy 5: hardest EFactor = Sum of Weighted ratings EV = 1.4 + (-0.03 * EFactor) Use Case Points (UCP) = UUCP * TCF * EV

28 28 FYI Only: Function Points (FP) n The traditional way of estimating effort n Count: –Number of user inputs –Number of user outputs –Number of user inquiries –Number of files –Number of external interfaces n Function Count = weight these counts based on their complexity and add them up n Function Points (FP) = adjust for other complexity factors

29 29 Function Count (FC) Item DescriptionCountx Weight = Weighted Count SimpleAvgComplex Number of user inputs346 Number of user outputs457 Number of user inquiries346 Number of files71015 Number of external interfaces5710 Total Weighted Function Count (FC)

30 30 Complexity Factor (CF ) and Function Points (FP) FactorDescription Rating 0: Irrelevant 5: Essential F1Reliability and backup recovery F2Data communications F3Distributed processing F4Performance F5Operate on existing system F6On-line data entry F7Data entry over multiple screens F8Master files updated on-line F9Complex inputs, outputs, files & inquiries F10Complex internal processing F11Code needs to be reusable F12Need conversion and installation F13Multiple installations of the system T14Easy to change and use Complexity Factor (CF) = sum of ratings Function Points (FP) = FC x (0.65 + 0.01 x CF)

31 31 Estimate Effort and Cost from Experience ProjectUCP’sFP’sLOCs Effort (Person- Days Cost per Person- Day Total Cost ATM System60.2245.22xx362$1,200$434,400 Loan Processing System82.3453.21xx443$1,200$531,600 Order Processing System95.2065.22xx563$1,200$675,600 Point of Sale System110.6578.44xx615$1,200$738,000 Etc. ………….. …. …..…. New project (est.)134.30108.77xx $1,200xx


Download ppt "A U Interface & Project Analysis Professor J. Alberto Espinosa Business Analysis ITEC-630 Fall 2009."

Similar presentations


Ads by Google