Software Life Cycle & HCI

Introduction

• The focus is on the development of reliable and user-friendly interactive systems
• Integrating user-centered design is key within software development frameworks
• Software engineering manages the technical and managerial aspects of software system development
• The software lifecycle encompasses everything from the initial concept to the final retirement of the software
• This includes all activities that occur from concept to phasing out and replacement
• Human-Computer Interaction (HCI) is integral to every stage of the software life cycle
• Designing user interactive systems involves techniques that are woven throughout the life cycle
• It is not an isolated activity

Software Life Cycle

• Software engineering provides the structure for the development of software systems
• The software life cycle identifies what activities takes place in software development
• This includes ordering these activities in time and applying techniques to complete them

Parties involved in software development

• Customers need products, designers create them
• The roles can be filled by different groups or the same individuals
• The customer commissions the design, the end-user uses the final system
• Customers work with the design team, "user" or "end-user" interacts with the system

Activities in the Life Cycle

• The activities resemble a waterfall
• Each activity flow naturally into the next
• Doesn't capture the actual dynamics between these activities

Waterfall Stages

• Requirements specification
• Architectural Design
• Detailed Design
• Coding and Unit Testing
• Integration and Testing
• Maintenance

Requirements Specification

• The designer and customer define what the system should do (the desired outcomes)
• Involves gathering information about the work environment
• This includes the functions the software must perform, context of operation, and interactions with other products
• Requirements documented in a customer's native language (expressive but less precise)
• Requirements translated into a precise, mathematical-like language for software implementation
• This transformation from natural language to executable language is critical for successful development

Architectural Design

• The focus is on how to achieve specified goals
• The system is decomposed into components through architectural design
• System is broken into manageable parts (sourced from existing software or developed from scratch)
• Architectural design addresses functional roles of each component
• Outlines interdependencies and resource-sharing requirements

Detailed Design

• Refines the architectural component descriptions while preserving their intended behavior
• Multiple refinements may meet the behavioral requirements
• Selecting the best one involves balancing non-functional requirements like performance and usability
• Language used for detailed design should support analysis to evaluate design properties
• Documentation of design options considered, final decisions made, and the rationale behind them is crucial

Coding and Unit Testing

• Detailed design should be structured for implementation in an executable programming language
• Components are coded, then tested based on criteria set earlier
• Automating the coding process from detailed design is a focus
• This is explored through formal methods that view this as a transformation between mathematical representations
• Research focus is on generating tests automatically from earlier outputs ensuring the code performs correctly

Integration and Testing

• Components are implemented and individually tested
• Components are integrated according to the architectural design
• Further testing ensures the integrated system behaves correctly and uses shared resources properly
• Acceptance testing is performed with customers
• This confirms the system meets their requirements for release to the customer
• Certification may be required from external authorities, such as an aircraft certification board
• Regulations like the European health and Safety Act and standards such as ISO 9241 mandate systems
• Must be usable, emphasizing the importance of considering Human-Computer Interaction (HCI)

Maintenance

• Products enter the maintenance phase after release (majority of its lifecycle)
• Maintenance involves fixing errors discovered post-release
• Updating the system to meet previously unmet requirements
• This phase provides feedback to earlier stages informing improvements and adjustments

Verification

• Verification is evaluating software to ensure it meets specified requirements and design specifications
• Focuses on if the system is being built correctly and according to the design and requirements
• Ensuring software adheres to its specifications and design documents
• Identifying issues early in the development process, before full integration or deployment
• Answers the questions of "Are we building the system right?"
• "Does the system meet the design and specification requirements?"

Validation

• Validation assesses whether the software meets the needs and expectations of end-users and stakeholders
• Ensures the right product has been built
• That it performs its intended functions in the real-world environment
• Ensuring the software satisfies user needs
• Ensuring it works in intended real-world scenarios
• Verify that the system is suitable for its intended purpose and provides value to the users
• Answers the questions "Are we building the right system?"
• "Does the system meet the needs and expectations of users?"

Usability Engineering

• Usability engineering introduces specific goals and criteria for evaluating a product's usability
• Emphasizes understanding how usability will be measured based on users' product experiences
• User interface is a critical focus
• Effective usability assessment also requires consideration of the system’s overall functional architecture and users' cognitive capacities
• Usability engineering is constrained by its focus on observable physical interactions
• Usability engineering includes a usability specification
• The specification details attributes that impact usability
• Outlines six specific items for evaluating each attribute (a comprehensive measure of the product's usability)
• Example: usability specification for undo with a VCR

ISO Usability Standard 9241

• ISO 9241 adopts traditional usability categories
• Effectiveness "can you achieve what you want to?"
• Efficiency "can you do it without wasting effort?"
• Satisfaction "do you enjoy the process?"

Metrics From ISO 9241

• Suitability for the task, effectiveness: Percentage of goals achieved, efficiency: Time to complete a task, satisfaction: Rating scale for satisfaction
• Appropriate for trained users, effectiveness :Number of power features used, efficiency: Relative efficiency compared with an expert user, satisfaction: Rating scale for satisfaction with power features
• Learnability, effectiveness: Percentage of functions learned, efficiency: Time to learn Criterion, satisfaction: Rating scale for ease of learning
• Error tolerance, effectiveness: Percentage of errors corrected successfully, efficiency: Time spent on correcting errors, satisfaction: Rating scale for error handling

Problems with Usability Engineering

• Explicit usability metrics are established early in the design process for system evaluation after delivery
• Metrics are crucial for creating usable systems, as they provide empirical data on user performance
• Metrics can be problematic early in the design process when specific user actions and situations are not yet well-defined
• Usability metrics are based on specific user actions
• User actions are in predefined contexts, which may not be available at the design stage
• Setting metrics for VCR functionality assumes certain user errors and solutions (like an undo button)
• This is without addressing the root causes of those errors
• Usability engineering ensures compliance with usability specifications
• However, it does not guarantee overall usability.
• Designers must understand how these metrics genuinely improve user experience
• In the VCR example, reduce number of actions improves usability
• Reducing action steps needs careful evaluation to ensure it aligns with real user needs and behaviors

Iterative Design and Prototyping

• Requirements for interactive systems cannot be fully defined at the start of the software life cycle
• Design features must be built and tested with real users to ensure accuracy
• Testing uncovers any incorrect assumptions, allowing for modifications and improvements
• Iterative design repeatedly cycles through designs, refining and enhancing the product with each iteration
• Iterative design affects requirements specification broadly and encompasses technical and managerial issues in software engineering
• Iterative design uses prototypes, artifacts that simulate or animate some but not all features of the intended system

Prototyping

• Approaches to prototyping include throw-away, incremental, and evolutionary

Throw-Away Prototyping

• Prototype is built and tested
• Design knowledge gained from this exercise is used to build the final product
• Actual prototype is discarded
• Procedure to arrive at a final requirements specification is used

Incremental Prototyping

• Final product is built as separate components, one at a time
• There is one overall design for the final system
• System is partitioned into independent and smaller components
• Final product is released as a series of products
• Each subsequent release includes one more component

Evolutionary Prototyping

• Retains the prototype, which serves as the basis for the next iteration of design
• Actual system is seen as evolving from a very limited initial version to its final release
• This prototyping fits with modifications that will be made during operation and maintenance activity in the life cycle

Prototypes vary in functionality and performance relative to the final product

• They can range from simple animations to fully functional versions
• Useful prototype has realism
• Crucial for accurately testing requirements with real users
• Evaluation conditions should closely match those expected
• Achieving high realism can be costly, so designers need efficient methods and support to create realistic prototypes quickly

Management problems with prototyping

• Building prototypes takes time, can feel like a distraction (Throw-away prototypes)
• Rapid prototyping is important for quick creation and changes
• Differentiate rapid prototyping from rushing evaluations
• Fast development shouldn’t rush the evaluation process
• Can lead to mistakes and reduce the benefits of prototyping
• Project managers lack the experience needed to effectively plan and budget for a design process that includes prototyping
• Important aspects like safety and reliability may be overlooked in prototypes (non-functional elements)
• Important aspects can also affect usability, such as how quickly the product responds
• Prototypes cannot serve as legal contracts, so detailed documentation is necessary to support the iterative design process
• Even though rapid prototyping allows for quick updates, it’s still important to maintain thorough documentation

Techniques for Prototyping

• Includes the use of storyboards, limited functionality simulations, and high-level programming support

Storyboards

• Visual tools used to illustrate interactions and the flow of an application
• Similar to comic strips, where each panel represents a step in the user experience
• Helps visualize user interactions and the overall user journey
• Useful for communicating ideas and scenarios to stakeholders and team members
• Provide a clear, visual representation of user interactions and help in understanding and refining user requirements and workflows
• Limitations do not offer interactive or functional aspects of the system, so they are less useful for testing detailed functionality

Limited Functionality Simulations

• Basic, often non-interactive versions of the software that focus on demonstrating core concepts, workflows, or user interfaces
• Helps stakeholders and users visualize and interact with a basic version of the system to gather feedback on design and functionality
• They can be created quickly
• Useful for early-stage testing and validation of design concepts
• Allow users to explore fundamental features without the need for a fully-developed system
• Limitations might not capture all aspects of user interaction or system performance
• Might not fully represent the final user experience

High-Level Programming Support

• Refers to using high-level programming languages or frameworks to build prototypes
• Prototypes are closer to the final product in terms of functionality and interactivity
• Create a more functional prototype
• Supports in-depth testing and validation of more complex features and interactions
• High-level prototypes can offer a more accurate representation of the final system
• Allows for better testing and user feedback on more comprehensive functionality
• Can be time-consuming and resource-intensive
• Risk of investing too much effort into a prototype that may undergo significant changes.

Design Rationale

• Refers to the reasoning behind the design choices made during development
• Captures why certain decisions were made, alternatives considered and how it aligns with the goals and requirements
• Documenting design rationale is essential
• Design decisions are transparent, justifiable, and can be communicated effectively to stakeholders
• Design rationale is an activity of reflection and documentation throughout the entire lifecycle

Importance of design rationale

• Clarity and Understanding: Provides a clear explanation of why particular design decisions were made
• Justification: Helps in justifying decisions to stakeholders, which is useful when there are conflicting requirements or changes
• Future Reference: Acts as a record for future projects or iterations, making it easier to understand the history of design decisions.
• Consistency: Ensures that design decisions are consistent with the project's goals and requirements
• Issue Resolution: Assists in identifying and resolving design issues by providing a basis for evaluating design choices

Examples of design rationale

• User Interface Design: Reasons related to user feedback, ease of navigation, and alignment with user goals
• System Architecture: Factors like scalability, maintainability, and deployment considerations.

Process-Oriented Design Rationale

• IBIS Method (Issue-Based Information System) structures design discussions
• Central issue/problem, presents possible solutions/positions debated with supporting or opposing arguments
• Creates a hierarchical framework
• gIBIS Visualization (graphical version)
• Represents this structure as a directed graph
• Nodes show issues, positions, and arguments, while connections clarify their relationships
• Variations of IBIS adds elements like design artifacts or enhanced vocabularies for showing how different issues relate
• IBIS and its variations capture and organize the design process by documenting discussions and decisions

Design Space Analysis

• QOC (Questions, Options, and Criteria) analyzes the design space, structures it around questions
• Reflection-Based (unlike IBIS), QOC questions are created through reflection
• Options and Criteria (potential solutions) are evaluated against criteria
• In QOC diagrams, solid lines indicate positives, dashed lines indicate negatives
• Effective QOC analysis requires broad scope, which can be difficult
• Alternate Method DRL (Decision Representation Langague)
• QOC aids documentation, but requires time

Psychological Design Rationale

• Introduces an approach that focuses on understanding the psychological aspects of usability in interactive systems
• Aligns products with user tasks
• Task–Artifact Cycle
• Systems should be designed based on tasks
• After implementation, the system finds new ways to use it, revealing new tasks and problems
• Can improve future design
• Evolution of Tools
• Show how tools evolved to meet a wider range of user needs
• Focus on how design affects user tasks
• Emphasizes the resulting psychological consequence

Psychological design rationale concepts include

• Identifying Tasks: Important user questions
• Creating Scenarios: Explore Tasks
• Reflection and Documentation: Record insights and assumptions after implementation
• Goal: Understand user tasks evolve and use them to enhance future design