Software Engineering Flashcards
Define HCI.
- Human-computer interaction researches the design and use of computer technology, focused on the interfaces between people and computers.
Observe the ways in which humans interact with computers and design technologies that let humans interact with computers.
Define a mental model.
- A mental model is an explanation of someone’s thought process about how something works in the real world.
- It is a representation of the surrounding world, the relationships its various parts and a person’s intuitive perception about his or her own acts and their consequences.
- An explanation in someone’s thought process for how something works in the real world.
A mental model is what the user believes about the system at hand
Describe perception and how it is carried out in technology?
- How information is acquired from the environment via our senses
- Obvious implication is to design representations that are readily perceivable
○ Icons should be easy to distinguish and read - use icons and other graphical representations; will enable users to easily recognise their meaning
○ Sounds or synthesized speech distinguishable - Sounds should be audible and distinguishable
○ Touch sensation - tactile feedback - Allow users to recognise and distinguish different meanings
○ Visual groupings can help - Bordering and spacing effective at grouping and finding info
Text should be legible - Text should be legible and distinguishable from the background
- Obvious implication is to design representations that are readily perceivable
What are the advantages and disadvantages in Reading, Listening and Speaking
- User preference
- Reading can be quicker than speaking or listening
- Listening requires less cognitive effort than reading or speaking
- Written language tends to be grammatical while spoken language is often ungrammatical
- Certain disabilities create challenges:
○ Dyslexia - difficulties understanding and recognising written words making it hard to write grammatical sentences and spell correctly.
○ Deaf / Hard of hearing - restricted in the way language is processed - Speaking - Keep the length of speech-based menus and instructions to a minimum.
- Listening - Accentuate the intonation of artificially generated speech voice, as they are harder to understand than human voices
Reading - Provide opportunities for making text large on a screen without affecting the formatting, for people who find it hard to read small text.
What are the usability goals that any system should strive to implement (think of group project) ?
• Effective - How good a system is at dong what its supposed to do
• Efficient - The way a system supports users in carrying out their task
• Safety - Protecting the user from dangerous conditions and undesirable
• Utility - The extent to which the system provides the right kind of functionality that users can do what they need or want to do
• Learnability - How easy a system is to learn to use (users don’t like to spend too much time doing this)
Accessibility - can be used by many different people including those with a disability
What are dark patterns?
- Deceptive approach to UX to trick people into doing things; encourage user to take a path they didn’t mean to take
- Colour theory is manipulated to misdirect language used to confuse rather than clarify and user is exploited to boost company reach or profits.
What are constraints and consistency a system should have?
- Determining ways of restricting user interaction at a given moment
- As much as possible, design the system so the user cannot make a serious error or be able to exit - user error control and freedom -> e.g. Deactivate certain menu options by shading them grey.
Consistent sequence of actions for similar situations, identical terminology for prompts, menus and help screens. Consistent commands used throughout
- As much as possible, design the system so the user cannot make a serious error or be able to exit - user error control and freedom -> e.g. Deactivate certain menu options by shading them grey.
What are the core principles any prototype should have?
- Allow users to
○ Interact with envisioned product
○ Gain experience of using it in a realistic setting
○ Explore imagined uses- A prototype is a limited representation that allows interaction and helps users explore its suitability
○ A series of screen sketches
○ A storyboard i.e. A cartoon-like series of scenes
○ A PowerPoint slide show
○ A video simulating the use of a system
○ A lump of wood (e.g. PalmPilot)
○ A cardboard mock-up
A piece of software with limited functionality written in the target language or in another language.
- A prototype is a limited representation that allows interaction and helps users explore its suitability
Why should a company develop a prototype before developing the real thing?
- Can present examples to stakeholders to hold, interact for advice/feedback.
- Allows developers to verify requirements
Encourages reflection and testing out ideas
- Allows developers to verify requirements
What are the differences between Wireframe, Mockups and Prototypes?
- They are different but there is overlap between them
- Wireframes - are basic illustrations of structure and components of a web page
- Mockups - often close or identical to the actual final web site design and include graphics - generally just image files
- Prototypes - semi functional and generally give the ability to click around and simulate the wat the site will eventually work
What are the differences between low fidelity and high fidelity prototyping?
• Low fidelity - early stages, you should develop paper prototypes - wireframes of screen designs - and walk through these with end users.
○ Pros:
§ Lower development cost
§ Evaluate multiple design concepts
§ Useful for identifying market requirements
§ Proof-of-concept
○ Disadvantages:
§ Limited error checking
§ Poor detailed specification to code to
§ Limited utility requirements established
§ Navigational and flow limitations
• High fidelity - refining the design and develop increasingly sophisticated automated prototypes, which will then be available for users to test.
○ Uses materials that you would expect to be in the final product
○ Prototype looks more like the final system than a low fidelity version
○ Danger that users think they have a full system … Need to manage user expectations.
§ Take too long to build
§ Reviewers and testers tend to comment on superficial aspects rather than content
§ Developers are reluctant to change something have crafted for hours
§ A software prototype can set expectations too high!
Just one bug in a high-fidelity prototype can bring testing to a halt.
What are story boards?
• Used with scenarios to bring more detail and a chance to role play
○ Details how the system will handle certain situations
• A series of sketches showing how a user might progress through a task using the device
○ A series of sketched screens for a GUI interface
A series of scene sketches showing the user performing an activity
What are card based prototypes?
• Index cards (3 x 5 inches)
• Each card represents one screen or part of screen
User steps through the cards pretending to perform a task
What are the pros and cons of the ‘Wizard-of-Oz’ prototyping system?
• Prototyping is evaluated with human interventions to provide the missing functionality.
• Developer is generating the output rather than the system itself - computer remotely controlled by developer
• Pros:
○ You can move very quickly - you can typically make changes, get feedback, and learn from your customer in minutes instead of weeks or months
○ Inexpensive
○ You can find real customers
• Cons:
○ It’s not real - you still have to build something eventually
○ Mixed signals - You may get confused with what the customer really wants
§ Learn to listen well and you’ll eventually learn what feedback to take and what feedback to throw away.
Typically not polished - It can sometimes be difficult to fake a product or service but still make it look polished. This isn’t always a bad thing as it’s easier for people to give you feedback if you don’t have a polished product.
What are the managements problems for prototyping?
• Time
○ Building prototypes takes time
○ Need to be fast - rapid prototyping. Careful this does not lead to rushed evaluation and erroneous results
• Planning
○ Hard to do adequately and cost a design involving prototype
• Non functional requirements
○ Such features sacrificed in prototypes
○ May be critical to product acceptance e.g. Safety
• Contracts
○ Design bounded by contractual agreement on technical and managerial issues
Prototypes are quick to change but this needs to be reflected in the requirements document which serves as the binding development agreement
Describe the what, why and where in HCI evaluation.
• Why - to check users’ requirements and that users can use the product and they like it
• What - a conceptual model, early prototypes of a new system and later, more complete models
• Where - in natural laboratory settings
○ Depends on what is being evaluated e.g.
§ Web accessibility generally evaluated in a laboratory
• When - Throughout design; finished products can be evaluated to collect information to inform new products
○ Evaluations done during design are known as formative evaluations
Evaluations done to assess the success of a finished product are known as summative evaluations
What are the different types of evaluations?
• Controlled settings involving users- usability testing and experiments in labs
○ Evaluation of UI
○ Collecting data through experiments, observations, interviews, questionnaire
○ Conducted in research labs in universities and industry
○ Living Labs - Evaluate people’s everyday lives
• Natural Settings involving users - Field studies, see how product functions in real world cases
○ Evaluate people in their natural settings
○ Observations recorded as notes, audio or video recordings
○ Goal to unobtrusive and not affect what people do
• Any settings not involving the users - Consultants, researchers critique, predict and model through inspection, walkthroughs, models and analytics
○ Inspection methods used to predict user behaviour and identify usability problems
○ Heuristic evaluation: guides design or critique decisions. Critique based on principles and guidelines.
§ Critique gives severity rating 0 = 0 I don’t agree there is a problem and 4 = 4 usability catastrophe
○ Cognitive walkthrough: analysis of action sequences the interface required the user to perform
Analytics : measurement, collection, and reporting of internet data
Evaluation methods can be combined e.g. Lab testing combined with observations in a natural setting to identify the range of usability problems and find how users typically use a product.
What is cross-cultural design?
• Designing technology for different cultures, languages, and economic standings to ensure usability and user experience across cultural boundaries. ○ Language ○ Script and fonts ○ Layout and space ○ Colours ○ Icons and symbols ○ Images and graphics ○ Times and dates Numbers etc ...
What are the issues with cross-cultural design?
• Exported software frequently required modifications to suit:
○ Local customs; laws or conventions
• The development of multiple interfaces is costly
• Age, gender, race, sexuality, class, religion and politics all effect people differently
Important to make generic, and easily modifiable as much of the interface as possible
Describe the three levels of interface specialisation.
• Globalisation
○ Fully available and functional in multiple languages
○ An end goal
• Internationalism
○ A process of multiple localisation for several regions
• Localisation
○ Refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements
○ Developing specific interfaces to meet a particular market
§ Translation - voice and written characters
§ Seamless Integration - Web and back-end system
§ Cultural Elements - Numbers, Measures, Imagery
§ Brand Management - Logos and Interpretation
§ Business Practices - Currency System, Payment Methods
Governmental Regulations - Legal, Import, Tax, Privacy, Electrical, Safety
Things to think about:
• Character sets - e.g. The Latin alphabet, the Arabic and Hebrew character systems
• Date / Calendar formats
• Numeric formats/Time formats/Telephone numbers/ Icons, symbols, graphics
• Name formatting e.g. Surname first then forename or vice versa
• Text Directionality
Currency, Units of measure, Cultural values, Symbols, Aesthetics
Project estimation is an important activity undertaken by a Project Manager. Briefly describe THREE key influences which can contribute to the production of inaccurate estimates.
• Complexity of the proposed application system
• Required integration with existing system
• Size of the system expressed as number of function or programs
• Capabilities of the project team members
• Project’s team’s
○ Experience with the application, the programming language, and hardware
○ Capabilities of the project team members
○ Number of project team member
Extent of programming and documentation standards
Problems with Agile
i. Managing large teams without documentation
ii. Contractual problems - developers unhappy to accept a fixed-price as requirements can creep;
iii. Can’t prepare tests in parallel with implementation as don’t have an independent V&V team (verification and validation)
iv. Maintenance difficult as system changes quickly so often done by large teams which need to be managed and the time from conception to delivery can be a long period of time with planning, designing and documenting the system being crucial.
In contrast traditional software development is often done by large teams which need to be managed and the time from conception to delivery can be long period of time with planning, designing and documenting the system being crucial.
Problems: Plan driven
i. Tries to develop a full set of stable requirements, design etc. And can lead to long development time - not acceptable to many customers
Large amounts of documentation
Describe the Scrum process including the roles within it.
a. Roles: Product Owner, Scrum team, Scrum Master
i. Product Owner - The person that has the final vision of the product, makes business decisions and decides priorities in the sprint backlog
ii. Scrum Team - A group of engineers that will actually build a shippable product by the end of each sprint
iii. Scrum Master - Protects team from distractions and interruptions and teaches people how to use scrum. Also enforces time boxes
b. Process -> Sprint cycle lasts 2-4 weeks. There is
i. Product back log -> a list of all things that need to be done within the project. It replaces the traditional requirements specification artifacts. These items can have a technical nature or can be user-centric e.g. In the form of user stories.
Sprint backlog -> A list of tasks identified by the scrum team to be completed during the Scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story.
Describe what is meant by rapid software development.
- Specification, design and implementation are inter-leaved
- System is developed as a series of versions with stakeholders involved in version evaluation
User interfaces are often developed using an IDE and graphical toolset
- System is developed as a series of versions with stakeholders involved in version evaluation
Describe plan driven development.
- Plan driven approach to software engineering based around seperate development stages with the outputs of these stages planned in advance.
E.g. Planning specifications, design before the project starts
Describe Agile development.
- Specification, design, implementation and testing are inter-leaved and the outputs are decided through a process of negotiation during the software development process.
- 12 principles of Agile manifesto:
○ Highest priority - satisfy customer through early delivery
○ Welcome changing requirements
○ Deliver working software frequently
○ Working software is the primary measure of progress
○ Customer and developers work together
○ Build projects around motivated people
○ Face to face communications important
○ Simplicity
○ Best work emerges from self-organising teams
Team regularly reflects on how they can improve
- 12 principles of Agile manifesto:
Describe the roles in scrum.
- Product Owner (PO)
○ Single person who has the vision behind the product dev
○ Makes a final call on what the priorities of the work are
○ What is top of the list in the sprint back log
○ Makes business decisions focused on what not how and people go through him/her to the team- Scrum Team
○ No hierarchy; 4-9 people ideally; build a shippable product in each sprint; each sprint they improve and collaboration increases between the team - Scrum Master
Has no managerial authority over the team; facilitates team needs without authority. Protects teams from distractions and interruptions; and teaches people to use scrum, good engineering practices, and enforces time boxes.
- Scrum Team
Describe the types of scrum meetings.
• Daily Scrum - Meet daily; 15 minute stand up and report to each other NOT to the PO or SM. What you did yesterday, what you will do today, what problems have you got.
• Sprint Review - Demo potentially shippable product increment to PO and anyone interested. PO declares what is complete and what doesn’t satisfy user requirements.
• Retrospective meeting - At end of every sprint what went well, what can be improved, what have you learned, feedback to each other - teams takes ownership of the process
Refinement meeting - Team and PO look ahead a little at the PBI’s to determine possible candidates and maybe break down for the next couple of sprints.
What are the benefits of Scrum?
- The product is broken down into a set of manageable and understandable chunks.
- Unstable requirements do not hold up progress
- The whole team have visibility of everything and consequently team communication is improved.
- Customers see on-time delivery of increments and gain feedback on how the product works
Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed
What are the problems with agile methods?
- Can be difficult to keep the interest of customers who are involved in the process
- Prioritising changes can be difficult where there are multiple stakeholders
- Maintaining simplicity requires extra work
- Contracts may be a problem as with other approaches to iterative development
Team members may be unsuited to the intense involvement that characterises agile methods
Discuss why it is important to have a code of ethics for Software Engineers.
- Software valuable
- Software key role in all dimensions of life and as professional’s software engineers must conduct their practices at a level of professionalism.
- Society well-being
- Honesty and trustworthy
- Acquire and maintain competency
- Improve others understanding of IT
- Property rights and contributions or others
- Be fair and no discrimination
- Respect privacy
Only access authorised resources
Briefly describe the types of maintenance that can be undertaken when a system has been deployed.
a. Corrective -> maintaining control over day-to-day functions
b. Adaptive -> maintaining control over system modifications
c. Perfective -> perfecting existing functions
Preventive -> preventing system performance from degrading to unacceptable levels
Briefly describe what system re-engineering is and when we would consider using this approach.
Re-engineering takes place after a system has been maintained for some time and maintenance costs are increasing. Re-engineering involves adding effort to make them easier to maintain. The system may be re-structured and re-documented. You use automated tools to process and re-engineer a legacy systems to create a new system that is more maintainable. Re-structuring or re-writing part or all of a legacy system without changing its functionality.
Give TWO advantages of adopting a re-engineering approach.
a. Reduced risk - There is a high risk in new software development. There may be development problems, staffing problems and specification problems.
Reduced cost - The cost of re-engineering is often significantly less than the costs of developing new software.
