Class 6 EMTM 601

1 Roadmap

• Finish Lecture 5 • On Programmers • Clouds • Light Weight Methodologies • Open Source Software • Brooks in Summary • Reliability, Fault Tolerance, Trustworthy Systems • Software Archeology • Outsourcing • Best Practices -> Default Good Practices • $1000 viewgraph(s) • Take Home Final • Reading this session: S Chapter 3, 11 & 12, finish Brooks 2 Log Book

• The Monkey and the Elephant • Yours?

3 TQM

4 ISO Quality System

• ISO set up a series of standards for quality management • ISO 9001 most suited for software - model for quality assurance in design, development, production, installation and servicing • ISO 9004-1 contains guidelines for individual elements of various standards • ISO 9000 process includes third party auditor, with audits every 6 months and reregistration every 3 years - expensive • Necessary for some customers

5 Software Quality Assurance

• Basic idea: improve quality by monitoring software and its development process – Ensure compliance with established standards – Ensure that inadequacies are brought to the managements attention and fixed – They review and audit and must be separate from production – Support of management, have go/no go authority – Must be technically competent • IEEE 730 provides a framework for Quality Assurance plan • IEEE 983 is a complement to 730 and offers further guidelines including implementation, evaluation and modification.

6 NSA and Assurance

• Brian Snow - http://www.acsa-admin.org/2005/papers/Snow.pdf • Some highlights – Very strong use of formal methods, SEI level 5,TSP and PSP – Mutual suspicion – modules auditing and alarming each other’s behavior – same with developers! • Hardware assist, e.g, isolated processor and address space for assured operations • Third party testing and certification programs • A flavor: “No single component, module, or person knows enough about the overall transaction processing system to be able to mount a successful attack …”

7 Reality Check

• The business is software, danger of a shift from developing software to developing processes, but …

• Quality is recognizable

8 Pirsig • Zen and the Art of Motorcycle Maintenance: An Inquiry Into Human Values, Bantam Books, 1974. ISBN:0-535-27747-2

What I (and everybody else) mean by the word quality cannot be broken down into subjects and predicates[…]If quality exists in an object, then you must explain why scientific instruments are unable to detect it[…]On the other hand, if quality is subjective, existing only [in the eye of] the observer, then this Quality is just a fancy name for whatever you’d like […] Quality is not objective. It does not reside in the material world[…] Quality is not subjective. It does not reside merely in the mind. – Robert Pirsig

9 Software Factories

• Applying factory techniques to software development emphasizing process, measurement and reuse (Toshiba’s view) • Software Workbench - integrated environment that supports all workers in factory - includes programming, debugging, configuration, test, requirements, documentation. Project management, quality assurance and reuse • Uses waterfall model • Project is divided into unit workloads with daily and weekly status, tracking actual vs expected, provides feedback and identifies issues • Heavy Quality emphasis • Reuse is the single most critical issue in improving quality and productivity • Quality circles - voluntary groups of works that focus on improving quality, process, …

10 Our Context

• User Experience Design is neither linear nor rigid! HCI Overview

• Motivation for HCI the Benefits • Definition of HCI • Current view of Cognitive Science • User Centered Design • Evaluation • Heuristics Lecture 5!

12 Why spend effort on the UI?

• Increased efficiency • Improved productivity • Reduced errors • Reduced training - strive for game like training • Improved acceptance

13 Definition

• This definition emphasizes the benefits • US Military Standard for Human Engineering Design Criteria (1999): – Achieve required performance by operator, control and maintenance personnel – Minimize skill and personnel requirements and training time – Achieve require reliability of personnel-equipment/software combinations – Foster design standardization w/in and among systems

14 Yet Another Definition

• But then there are other approaches and motivations • Raskin: An interface is humane if it is responsive to human needs and considerate of human frailties – Boot up - that the user should not be kept waiting unnecessarily is an obvious and humane design principle • Note recent efforts to improve – Users should set the pace of interaction – Windows - hitting start to shutdown • Asimov paraphrase: “A computer shall not harm your work or, through inaction, allow your work to come to harm” • A computer should not waste your time or require you to do more work than is strictly necessary

15 Asimov’s Laws of Robotics

• (A soon to be recurring motif that the best interface may be none, with precautions) • 0. A robot may not injure a humanity or, through inaction, allow humanity to come to harm. • 1. A robot may not injure a human being or, through inaction, allow a human being to come to harm, except where that would conflict with the Zeroth Law. • (old 1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.) • 2. A robot must obey orders given it by human beings except where such orders would conflict with the First Law. • 3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

16 Approach to UI

• So how do we get there? • The user interface is the system to the user- not a novel approach, also known as User Centered Design – Cognitive sciences (including “humanities”) * – Artistic Design – Ergonomics * • User Interface is the point of view of the user! Includes hardware and software. Most modern view is USER EXPERIENCE • Do not separate design of functionality from design of interface - remember “User manual first” (combines functionality and interface) attitude to interface development • Overlearning is powerful - sometimes RPN is the right thing! • Mental model (desktop) vs. conceptual model/design model - have to be closely related • First a bit about ourselves

17 The Human Information Processing System - INPUT Atkinson and Shiffrin

Sensory Store

Short Term Memory Repetition Displacement/ Decay Decay/ Displacement

Long Term Memory

Interference 18 Conscious vs. Unconscious (from Raskin, 2000)

PROPERTY CONSCIOUS UNCONSCIOUS Engaged by Novelty, Emergencies, Danger Repetition, Expected events, Safety Used in New circumstances Routine situations

Can handle Decisions Non-branching tasks

Accepts Logical propositions Logic or inconsistencies

Operates Sequentially Simultaneously

Controls Volition(free will) Habits

Capacity Tiny Huge

Persists for 10ths of seconds Decades (lifelong?)

Conscious ≈ STM, Unconscious ≈ LTM 19 Saturated Yet?

20 Stroop Test

Interference between the memory systems What color are the words?

21 Stroop 2

22 Psychological principles

• Working memory (STM) is only around 5 - auditory tasks depend on working memory • Long Term Memory is slow and things may be available but not accessible - multiple coherent cues make it easier • Attention can be overloaded and depends on the state of the individual • Recognition is easier than recall • Remember issues of Just Noticeable Differences, JNDs • Expert Novice distinctions are a factor in enjoyment of the system

23 More Principles

• Humans receive more information through visual system and store it spatially -- mental rotation studies, the more rotation, the longer to respond • Humans tend to structure what they see to form cohesive patterns -- 5 Gestalt laws: – Proximity - we tend to group things together that are close together in space – Simularity - we tend to group things together that are similar – Continuation - we tend to perceive things in good form – Closure - we tend to make our experience as complete as possible – Figure and ground - we tend to organize our perception by distinguishing between a figure and a background

24 Proximity

Thanks to Psy280 notes from Toronto!

25 Continuation

http://peace.saumag.edu/faculty/kardas/courses/ 26 GPWeiten/C4SandP/continuity.GIF Figure - Ground

27 Maslow’s PYRAMID

Needs needed SELF to be met - ACTUALIZATION ideas for reinforcers, Self esteem needs given situation Love & belonging needs

Safety & security needs

Basic physiological needs

28 Still More Principles

• Multimodal information is easier to use than single mode (text + image + sound) increasing the richness of memory -- similar to mnemonic tricks such as the method of loci – “depth” of processing • From theory to practice, onto Design

29 PAR

• Is your experience up to PAR? • Perception • Attention • Retention

DESIGN MODEL USER’S MODEL

DESIGNER USER

SYSTEM IMAGE •Gulf of execution - mismatch between users intention and allowable actions “the user and the designer •Gulf of evaluation - mismatch communicate only through the SYSTEM between systems representation system itself” and user’s expectations

31 Task Analysis

• Analyze task within context of use: – The users – The tasks – The equipment (hardware, software, materials) – The social environment – The physical environment

32 The Users: Groupings -1

• Pre school • Grade school • Middle/High School • College to Post Grad • Adult - business use • Adult - home use • Elderly • Special needs

33 Groupings-2

• Computer professionals • Technical professionals and industrial workers • Business professionals and clerical folks • Professionals (doctors, lawyers, architects,…) • Public administrators, police • Instructor, teachers • Research scientists • (loosely adapted from Endres and Rombach, 2003)

34 Experimentation

• Understand the task, understand potential solutions • Try to approximate the task(s) under controlled circumstances • If new techniques use a control and experimental group(s) • Measure everything that may be relevant: error rate, time for various stages, keystrokes, … • Observe, perhaps video tape or think aloud with permission - very time intensive

35 Situated Action and Distributed Cognition

• A simple experiment may not always be diagnostic because: – Complex interactions between people, electronic devices and paper resources – Physical and social resources are intertwined with use of computer and information technologies – Design cannot be separated from patterns of use – Users change plans in response to circumstances • Distributed cognition - knowledge not only in the minds but also distributed in the environment • Therefore users have to be participants in the design process not just experimental subjects (rigid definition): ethnography, longitudinal studies

36 More on Task Analysis

• Agents, work and situation: GOALS, TASKS & ACTIONS • User interface details: – What can the user do with the system? System capabilities – What is dialog and presentation interface • On dialog – Command language, interaction according to a grammar, user has to understand what’s possible - persuades system to do it - UNIX – Menu, complete form, respond to interface - eases memory load, user may not feel in control - MS Windows – Direct manipulation in a space - 3D environments - MATRIX • On representation – Perceptible aspects, includes artist and designer, story boards are helpful

37 Interaction Styles Style Advantages Disadvantages

Direct Visually presents task concepts, easy learning, Hard to develop, requires Manipulation easy retention, avoids errors, encourages graphics display & pointing exploration, high subjective satisfaction device Menu Shortens learning, reduces keystrokes, Danger of many menus, Selection structures decision making, can use dialog slows frequent users, management tools, easy support of error consumes screen space, handling requires rapid display rate Form Simple data entry, modest training, convenient Consumes screen space Completion assistance, use of form management tools

Command Flexible, power users, user initiative, creation of Poor error handling, long Language macros (customizing) training, memorization

Natural Relieves burden of learning syntax Clarification dialog, more Language keystrokes, contest is hard, unpredictable

38 Physical abilities and surroundings

• Anthropometry - basic data about human dimensions (range of dimensions) – Not only static (size of hand) but also dynamic, reach distance while seated, speed of finger presses, strength of lifting, … • Human Factors engineering of computer work stations – Work surface and display support height – Clearance under work surface for legs – Work surface width and depth – Adjustability of heights and angles for chairs and work surfaces – Posture adjustments, arm rests, foot rests, chair coasters – Lumination levels, glare, flicker, noise, air temperature, movement and humidity

39 Relative Dimensions of Average Human Body

40 Standing Posture Data

41 Relativity of design

• Each user and each task should have precise objectives: – Average time to learn – Speed of performance – Error rate by users – Retention over time (frequency of use is a factor) – Subjective satisfaction - surveys satisfaction scale • Tradeoffs: – lengthy learning -> better performance – Rate of errors vs. speed of performance

42 Why spend effort on the UI? (redux)

• Increased efficiency • Improved productivity • Reduced errors • Reduced training - strive for game like training • Improved acceptance • So evaluation determines how well we did

43 Usability Characteristics Evaluation

ISO 9241 Schneiderman Nielsen

Efficiency Speed of performance Efficiency Time to learn Learnability Effectiveness Retention over time Memorability Rate of errors by users Errors/Safety Satisfaction Subjective satisfaction Satisfaction

44 Evaluate User Experience, 5 E’s

DIMENSION KEY NEEDS Design Tactics

Effective Accuracy Focus on places in the interface for potential error and protect against them. Look for opportunities to provide feedback and confirmations Efficient Operational Present only most important information. Work on smooth, direct Speed navigation. Interaction style should minimize actions required

Engaging Attract users Consider what aspects of the product are most attractive and incorporate into design

Easy to learn Just-in-time Step by step interfaces that help users navigate through complex instruction tasks. Provide training in small chunks if possible

Error tolerant Validation Look for places where selection and calculators can replace data entry. Error messages provide opportunities to correct problems

Quesenbery(2003) in Stone, p.109 45 Success Criteria, 5E’s (rational weighting)

$100

46 Evaluation Keys

• Plan the evaluation and plan to evaluate frequently • Evaluation early in the life cycle, mockups serve as feedback to requirements and design process • Evaluation later - how well does it meet the users needs (sometimes defer)

47 Star Life Cycle

48 Necessary Information (p38) Focus Information gathered Domain Wider specialist knowledge (context) and specific knowledge for computer system

Users Who they are focus on - primary; consider - secondary

User characteristics Age, sex, IT experience, educational background, motivation, attitude, enjoyment, satisfaction, … Task Characteristics Easy, complex, novel, variable, repetitive, frequent/infrequent, single task or multitasking, time critical, solitary or collaborative. Safety? Physical Environment Noise, stress, comfort, dust, furniture layout, open-plan, hazards, …

Social Environment Work pressure, individual or collaborative, individual offices or open plan

Organizational Environment Mission and aims, attitude to IT, policies, job design, role, management support

User support environment Training, colleagues, keystone users, manuals, support desks, …

Qualitative usability For example, easy to learn, UI intuitiveness

Quantitative Usability Usability metrics

Constraints Cost, timescales, budget ,hardware and software

Trade offs Conflicting/contradictory requirements

49 Evaluation

• Not only in course of design process but as part of the system - throughout process, continually evaluate • BEFORE: scenario based, manual based, story board based - evaluation as prototyping, experimentation • AFTER: (have a prepared baseline of all tasks in previous environment) study and MEASURE how users are doing - in the beginning and at regular intervals – Casual interfaces - kiosks should go quickly: seconds to minutes – Week on task interfaces - telemarketing: minutes to hours – Month on task interfaces - help desk: days • Observe the entire environment before and after for days – Include what is on their desk, tacked to wall and interactions • SATISFACTION AND JOY - what follows are some heuristics to get there

50 Heuristics on the User Interface • If there’s a substantial UI component have full time UI person involved from beginning plus artist/designer – UI person is not converted developer • Avoid Natural Language interfaces • Understand the environment and the users and the types of users – Auditory interface in high noise or long dialog text is not recommended • Test it and observe - prototypes, user manuals, storyboards • Do not stray too far from current interfaces, unless …revolution • Do not be tempted by direct manipulation/”Matrix mode” unless ample time and software/hardware - but be inventive

51 More on UI • Do automate! • Do not ignore the users needs • Do talk to the users • Do understand your user population • Do be predictable • Do use common examples in documentation - Unix Man pages • Do use designers/artists • Do use paper, stickers, job aids, … • Do consider Ergonomics • Do consider special needs • Joy is an important aspect • One unsatisfied customer can hurt more than two satisfied customers can help!

52 Classes of Systems

• Life critical systems - lengthy training periods for error free performance, even under stress – Practice sessions for emergencies – Subjective satisfaction less of an issue • Industrial and commercial uses - issues of reliability may be eased due to cost concerns • Office and Home Entertainment - subjective satisfaction • Exploratory, creative and cooperative systems • Socio-technical systems

53 Cognitive and Perceptual Abilities (we just scratched the surface in our discussion)

• Human cognitive processes • Factors affecting perceptual and motor performance: – Short term memory – Arousal and vigilance – Long term memory and – Fatigue learning – Perceptual (mental) load – Problem solving – Knowledge of results – Decision making – Boredom and monotony – Attention and set (scope of – Sensory deprivation – Sleep deprivation concerns) – Anxiety and fear – Search and scanning – Isolation – Time perception – Aging – Drugs and alcohol – Circadian rhythms Is your user experience up to PAR? 54 Other Psychological Differences

• Personality differences, gender, cultural -- be sensitive to names: Kill, abort, master, slave • Myers-Briggs Type Indicator (example of personality tests): – Extroversion-introversion – Sensing vs Intuition – Perceptive vs Judging – Feeling vs thinking – Matching personality types to professions, example of psychological scales, there are many of them!

55 OPD-2

• Cultural and International Diversity – Respect for tradition vs novelty – Japanese, Chinese may scan screen in different order – Still largely unexplored but important in international market – Sampling of other international issues: • Numeric (,.) and currency formats • Weights and measure • Names and titles • National identification • Etiquette, policies, tone, formality • Government regulations

56 Users and Disabilities

• 1998 amendment to Rehabilitation Act requires Federal Agencies to assure access to Information Technology, including computers and web sites by employees and the public – Keyboard mods – Supporting vision and hearing impaired – Color coding issues – Font size settings – Conversion to Braille and text to speech including description of figures • Plan early .. Computer curb cuts, e.g., in design move on/off switch to front • Packages for learning disabled, e.g., game-like interfaces

57 Information Visualization

• Shneiderman and Plaisant – Overview – Zoom – Filter – Details on demand – Relate - among items – History – extract

58 And So Much More

• Psychology of computer programming • More on ethnography • Psychology of online communities • Computer supported cooperative work • Psychology of embedded device interfaces • Challenges of every new leap in technology • … • On to “micro” software engineering

59 Game Development

• Roles of Game Development: – Producer - person responsible for managing people and processes responsible for the game – Game Designer - overall vision of the game and maintaining it – Level Designer - implements game using content creation tools created by programmers and assets generated by artists – Programmer - tool builder – Game Graphic Artist - know current context but be very broad – Much more “creative” based, developer as tool builder, amenable to software process factoring in this large difference – May (should) become more common

60 Micro Software Engineering

• About the developer • SEI has the PSP, Personal Software Process, a bit about that next class when we discuss XP • Derived from Hunt & Thomas, The Pragmatic programmer: From journeyman to master, Addison- Wesley, 1999. • Nice setup for XP and Open Source discussions next class

61 Axioms • Gets somewhat into the head of the hacker (good sense of word). • Personal Aspirations: – Care about your craft – Sign your work – Think! About your work – Invest regularly in your knowledge portfolio – Don’t think outside the box, find the box (does it have to be done this way?) – Gently exceed your users expectations – Organize teams around functionality; build teams like you build code

62 Axioms - Requirements

• Don’t gather requirements, dig for them • Work with a user to think like a user • DRY - Don’t Repeat Yourself (ambiguity) • Keep knowledge in plain text • Don’t be a slave to formal methods • Prototype to learn • There are no final decisions • Remember the big picture - MULTICS • Use a project glossary • English is just a programming language

63 Axioms-Design

• Don’t be a slave to formal methods • Costly tools don’t produce better designs • Design to test • Abstractions in code, details in metadata • Minimize coupling between modules • Some things are better done than described

64 Axioms - Development

• Make it easy to reuse • Eliminate effects among unrelated things (cohesion and coupling) • Program close to the problem domain - design and code in your user’s language • Iterate schedule with the code • Use a single editor well • Use the power of command shells -GUI’s do not always cut it • Always use source code control • You can’t write perfect software - protect your users and your system • Build documentation in, don’t bolt on

65 Axioms-Test

• Crash early - dead program is more instructive than one that limps along • Fix the problem, not the blame • Test your software or your users will • Test early, test often, test automatically • Coding ain’t done until all the tests run • Use saboteur to test your testing - create your own mutants • Find bugs once • Refactor early and often

66 Thought Problems

• You have been asked to design a user interface for a new product in your area - what are your first steps?

• You have been asked to rescue a product in the field that is not performing to expectations and management suspects the user interface because of high training costs and a continuing high error rate. What are your first steps?

67 Software Engineering Knowledge

• SWEBOK, SoftWare Engineering Body Of Knowledge: – Software requirements analysis – Software design – Software construction – Software testing – Software maintenance – Software configuration management – Software quality analysis – Software engineering management – Software engineering infrastructure – Software engineering process

Lecture 6

68 Where are the Clouds?

• Grid – analogy to electric grid • Cloud – analogy to internet – More service application oriented – SOA – Economic rather than technical issues – Open Cloud Manifesto – cloud should be open (broader Internet) • The terms are blurring

69 Grid Job Submit

70 Sun Grid Status

71 Getting Cloudier

• Amazon’s EC2 (Elastic Cloud Compute) is an example of IaaS, Infrastructure as a Service. • Amazon’s parts: – EC2 – Amazon Simple Storage Service (S3) – Amazon Simple Queue Service (SQS) – for grid, not covered – Amazon CloudFront – content distribution network – close to where user is accessing it (video, music, “big stuff”) – Amazon SimpleDB – too simple • Essentially derived from George Reese, Cloud Application Architecture, O’Reilly, 2009

72 EC2

• “Provides API for provisioning, managing and deprovisioning virtual servers inside Amazon cloud” • Xen is VM manager • Amazon Machine Image (AMI) = operating system + prebuilt software – Usually one customizes it and that becomes their MI

73 More EC2

• Storage: ephemeral associated with node and block storage that acts like a SAN – SAN – provides block level storage, can serve as disk arrays • S3 – persistent storage, slow, accessed by web services, think of it as a back-up device (tape). Good place to store machine images • Amazon glacier

74 EC2 Components

Region (US/east) Availability zone

Security Group E-IP

AMI instance Volume

Snapshot

75 Another View

App server

Load Balancer + NID App server

Write ops

Read ops

Database master 76 From There

• Dynamically add more servers using your variant of AMI stored in S3 • Dynamically subtract servers • Erasure coding • Add new capability • Human sourcing – the Mechanical Turk, a variant of cloud sourcing – Requestors (developers) post HITS (Human Intelligence Tasks) and providers complete them – Providers browse among tasks so there is a marketplace 77 Light vs. Heavy

• Heavy, as in heavy in process, what we have been studying • Light well, here’s Jim Highsmith’s take from the Cutter Consortium: “Thin, lean, adaptive, or light- these emerging approaches are thin on process, thick on skills, and focus on people: collaboration, communication and excitement.” • A light methodology provides guidance and boundaries whereas a heavy methodology is prescriptive • A reactionary movement and representative of what was really happening - an attempt to gain some control or at least document what was really happening -- RAD was not the answer (although some consider RAD agile)

78 ASD vs. RSM • Agile Software Development vs. Rigorous Software Methodologies • Key concept in agile methodologies is to embrace change – Agility is a way of life in a constantly emerging and changing response to business turbulence – Improvise – Trusting in one’s ability to respond rather than trusting in one’s ability to plan – Focus on individuals and self adapting their own processes – Chaordic perspective -- chaos to order (product goals not predictable, process not repeatable) – Collaborative values and principles - human dynamics, may be the “soft” sciences but they are the hardest! – Barely sufficient methodology - programming usually adds value, process management usually adds overhead

79 Agile Manifesto

Manifesto for Agile Software Development http://agilemanifesto.org

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

• Customer value • Creating a culture of innovation, creation and rapid delivery • Appealing to skilled, talented staff • Facilitating collaboration, knowledge sharing and decision making • Reducing, time, cost and defect levels significantly.

81 Some Light Methodologies

• Extreme Programming - Kent Beck • Crystal Methods - Alistair Cockburn • Lean Development - Bob Charette • SCRUM - K. Schwaber, J. Sutherland • Adaptive Software Development - Jim Highsmith

82 XP

• XP’s basic premise - coding is THE KEY activity • Geared for small to medium sized teams • Calls for implementing highest priority features first • Customer is integral part of the team • Define smallest code release possible • Programmers accept responsibility for estimating and completing work - feedback • Encourages human contact, incorporates method for staff turnover

83 Underpinnings of XP

• If code review is good, do it all the time, pair programming • If testing is good, everyone will test (unit testing), customers (functional testing) • If design is good, it is every day for everyone (refactoring) • If simplicity is good, we’ll leave system with simplest design that supports the functionality - the simplest thing that can possibly work • If architecture is important everyone does/defines/refines architecture all the time • If integration testing is important then we will integrate and test several times a day • If iterations are important we’ll make iterations really short, minutes and hours, not weeks and months!

84 Differs from other methods

• Short cycles provide early, concrete and continuing feedback • Incremental planning that quickly generates an overall plan that evolves • Responds to changing needs by flexibly scheduling implementation of functionality • Reliance on automated tests to catch defects early, monitor progress and allow system to evolve • Reliance on oral communication, tests and source code to communicate system structure and intent • Reliance on evolutionary design process throughout development • Reliance on close collaboration of programmers with ordinary skills • Reliance on practices that mesh with short term instincts of programmers and long term interests of project

85 A Day in the Life of an XPer

• Stand up meeting begins day • Stack of task cards provides tasks • Invite programmer to be your partner • Develop together - both at the screen, mouse and keyboard concerned with implementation, other more globally • First build tests, run tests • Develop program, assess design, collaborate • Test • Programming pairs evolve design of the system - they can change everything!

86 Four Values of XP

• Communication: unit testing, pair programming, and task estimation cause programmers, customers and managers to communicate • Simplicity - better to do a simple thing today and change later, than a more complicated thing that will not be used • Feedback - unit tests, customers write stories (feature descriptions), programmers estimate -- when all the tests are run you are done • Courage - within the context of the first three values - “go like hell!” However, courage by itself is “just plain, bad hacking!” • Other comments: – XP resembles hill climbing local optimas require large change – Need a real team that respect each other and have passion for what they do

87 Key Aspects of XP

• Whole team - development + customer • Metaphor - everyone use common analogy in discussing the system, e.g., desktop metaphor -Scandinavian School • The Planning Game - specify the next step of development and, as project progresses, provides better and better picture of what will be delivered. User stories lead to development cost estimates, leads to client assigning priorities, leads to evaluating estimates for the next round • Simple design - design should only incorporate at best next iteration - if it becomes complex, refactor • Small releases - every development cycle (~ 2 weeks) client gets new software.

88 Key Aspects of XP - 2

• Customer tests - customer develops acceptance tests based on user stories, automated and used frequently by development team • Pair programming • Test-driven development - test first, add to suite • Design improvement - refactoring and small improvements in design, simple design • Collective code ownership - source code control, “refrigerator in frat house” phenomenon (anything you put in, you should not expect to see next time) • Continuous integration • Sustainable pace • Coding standards

89 Comments on XP

• Some of the old is there - incremental, prototyping, variant of use cases • Takes code reviews, inspections to extreme • Focuses on people • Very experimental • Fun, enthusiasm with discipline!

90 Crystal Programming

• Alistair Cockburn - consultant for IBM • Crystal Light permits developers maximum individual preference • XP assumes everyone is following tight , disciplined practices • According to Cockburn: – XP is more productive through increased discipline but is harder for the team to follow – Crystal Clear permits greater individuality within the team and more relaxed work habits, for some loss in productivity – Crystal Clear is easier to adopt but XP provides better results if the team can handle it – A team can start with Crystal and move to XP, or start with XP and backup

91 Cockburn’s Principles

• Replace written documents with face to face interaction, reduce reliance on written products • Deliver frequent, running, tested slices of the system rather than rely on promissory notes • Different projects have different needs – As staff grows so does need to coordinate communication – As risk increases, increases the need for public scrutiny and decreases tolerance for personal stylistic variations – Some projects depend on time to market, others aim for traceability or legal liability protection --- differ in 9s

92 Thought Problems

• Are lightweight methodologies, agile software development techniques short on process?

• How would you begin to experiment with agile methodologies, what are some of the project/staff characteristics?

93 Open Source Software Cathedral and the Bazaar

• Cathedral - commercial software world, bazaar - linux and open source • Key names: – Richard Stallman - emacs, gnu, Free Software Foundation – Linus Torvalds, linux, open source process, open source license (General Public License (GPL), BSD, Perl’s Artistic) License – Larry Wall - PERL

94 Preconditions for the Bazaar style

• Hard to originate code in this style, test, debug, improve yes – You need to have something running - attractor – It has to run and convince others that it can evolve into something neat in reasonable time • Leader/coordinator of Open Source project does not need to be a great designer but needs to recognize good ideas from other folks: – Robust and simple rather than cute and complicated – Community’s internal market in reputation exerts subtle pressure in self-selecting competent leaders – A bazaar leader must have good people and communication skills

95 Social context for Open Source

• Evolution of software in the presence of a large, active community of users • Programmer time is not fungible - small number of codevelopers obeys Brooks communications links • Programmers cannot be territorial about code, encourage others to look for bugs and improvement XXP! • “while coding remains an essentially solitary activity, the really great hacks come from harnessing the material and brain power of entire communities” • Internet helped • Development of leadership style and set of cooperative customs • Utility function of linux hackers is maximizing in their own eyes satisfaction and reputation among peers and users • Boring is essential - software and documentation • Open source is fun - joy as an asset • Not so easy as to be boring, not too hard to achieve!

96 Homesteading the Noosphere

• Open Source culture: zealotry varies, hostility to commercial software varies • Open source must protect an unconditional right of any party to modify (and redistribute modified versions of) open source software • Taboos of Open Source: – Strong social pressure against forking projects – Distributing changes to a project without cooperation of moderators is frowned upon – Removing a person’s name from the project history is not done without the person’s explicit consent

97 Ownership in Open Source

• Owner of the software project is the person who has the exclusive right to distribute modified versions • How to own: – Start the project - homesteading – Have ownership handed to you - deed transfer – Observe that a project needs work and owner has lost interest- try to find owner to get to have ownership handed to you - “adverse possession”, moves on and improves”

98 Hacker culture as a gift culture

• Excludes crackers and warez d00dz - different culture • Not what you control but what you give away - reputation among peers • Along with sheer joy of making something work • Craftsmanship model as a corollary - still linked to reputation • In hacker culture status is based on critical judgment of peers

99 On Reputation

• Ego is despised, yet system runs on it • One’s work is one’s statement, no one attacks one’s technical competence, emacs bugs not Stallman’s bugs • More prestige in founding a project than working on an existing one • More prestige for innovative rather than me too • Being carried in a major distribution (Red Hat, SuSE) is prestigious • Continued devotion to hard, boring work (debug, write doc) is more praiseworthy than fun and easy hacks.

100 Governance

• Project leader - codevelopers - contributors • Apache has a voting committee • PERL has rotating dictatorship among codevelopers

101 Open Source Resources

• www.opensource.org - jump off point, Halloween papers • SourceForge.net - project pages • Freshmeat.net - products and product announcements • Slashdot.org - fun

102 Microsoft’s response

• The Halloween documents - response to Open Source, quotes Raymond • Considers Open Source a threat especially in server market (H II - also in desktop) • Commercial quality can be achieved! • To target Open Source, you target a process not a product • Open source is long term credible - you cannot FUD it! • Implementation provides a high visibility showcase for OS • Linux has done well in mission critical commercial environments • Linux can win as long as services and protocols are commodities

103 More Microsoft

• Current count 9 Halloween papers - not all from Microsoft! • From Halloween VIII - “First they ignore you, then they laugh at you, then they fight you, then you win” - Gandhi • Halloween IX SCO + Microsoft??

104 “Sync and Stabilize” Cusmano and Selby (1997)

• Scale up loosely structured teams (3-8 developers) • The “Process” – Vision statement – defining goals of new product – Program managers create functional specification – During development team members revise feature set and details • Sync involves daily builds, Stabilize involves milestones • “Always” a deliverable project

Diversion 105 Revenge of the Hackers

• Again by Eric Raymond • Linux was a watershed • Cathedral and Bazaar - provided language so they could improve their “process” – Hackers loved it around the world • Netscape open sourcing their browser was “the shot heard round the world” – Failure would discredit open source – Mozilla

106 RH - 2

• Origin of “Open Source” and Open Source Initiative • Needed marketing and the “Free Software” movement was a problem – Free = no price & liberty – Association of hostility to IP rights, communism and radicalism was not mainstream IT • Needed Positive Stereo types: 1) pragmatic tales, 2) high reliability, 3) lower cost (not free), and 4) better features

107 RH-3

• Top down not bottom up marketing to CEOs/CTOs/ CIOs • Raymond as spokesperson - “sound challengingly weird but convey an aura of honesty and simplicity” • More than Linux: – Apache ≈50% of server market Microsoft increasing though (http://news.netcraft.com/archives/web_server_survey.html) – Perl – Sendmail - dominant mail router

108 RH-4

• O’Reilly and his company helped • Key win -- Oracle and Informix offer linux ports, started bandwagon • Halloween Docs gave it credibility - Microsoft was concerned • Titanic - rendered by a roomful of Linux boxes • Beowulf - supercomputer on the cheap, Open Source on cutting edge • Red Hat, SuSE and the rest, proprietary Unix losing share • Watch out for BSD • Desktop versus server

109 Open Source Landscape

Language # of Projects % of Projects • From Code Reading C 8,393 21.2 by D. Spinellis C++ 7,632 19.2 Java 5,970 15.1 PHP 4,433 11.2 Perl 3,618 9.1 Python 1,765 4.5 Visual Basic 916 2.3 Unix Shell 835 2.1 Assembly 745 1.9 JavaScript 738 1.9

110 Open Source Licensing http://developer.kde.org/documentation/licensing/licenses_summary.html license Proprietary Distribution Re- GNU GPL sfw linking distribution compatible with changes GPL Not allowed Not allowed Only with yes GNU GPL Apple public allowed allowed Only with no apple Apache allowed allowed Allowed so no long as apache is not in name BSD allowed allowed allowed Yes(modifi ed) MIT(X11), allowed allowed allowed yes W3C Sun public allowed allowed Only under no Sun public Thought Problems

• You want to become part of the Open Source Movement - How should you begin?

• What steps would be needed to change your current software process to a process more similar to the Software Gaming Industry?

112 Brooks No Silver Bullet (1986)

• Accidental vs. essential (abstract conceptual structures). Suggests: – Exploit mass market - buy vs. build, recurrent theme – Use rapid prototyping for establishing software requirements – Grow software organically (incrementally) – Identify and develop the great conceptual designers • Software projects as werewolves - turning from the familiar to the horrible • There is no silver bullet – Unfair to compare software and hardware – The essence are inherent difficulties, accidents not inherent. Essence is interlocking concepts of data sets + their relationships + algorithms + invocations of functions

113 NSB -2

• Hard part of software is specification, design and testing of the conceptual construct not representing and testing its fidelity • Inherent properties include: – Complexity - scaling software is not simply enlarging size of elements, rather increases # of different elements and their interaction • Math models will not work because you cannot abstract out the complexity - it is part of the essence • Complexity causes: – Difficulty communicating among team members – Difficulty in enumerating all possible states – Unvisualized states resulting in security trap doors – Difficulty in providing overview

114 NSB-3

• Additional Inherent Properties: – Conformity - unlike physics with underlying laws, software reflects the arbitrary complexity of human institutions and systems and conformity to the interfaces of other systems – Changeability - software is constantly subjected to pressures to change: • Successful software is expanded • Exists longer than the machine vehicle for which it is written • Embedded in a changing cultural matrix of applications, machines, laws, organizations, … – Invisibility - hard to visualize in a single space

115 NSB-4

• Breakthroughs solved many accidental difficulties – High level languages – Time sharing and now the network

116 Exciting Products - Brooks

• Great Designers - Yes • Committees - No • UNIX • Cobol • APL • PL/1 • Pascal • Algol • Modula • MVS/370 • Smalltalk • MS-DOS • Fortran

Great designs come from great designers!

117 Great Designers

• Software is a creative process • Ways to grow great designers (too little practiced these days): – Identify top designers early on – Career mentor them – Plot a career development path with apprenticeships and opportunities – Encourage peer interaction with other great designers

118 Larger Tidbits: Reuse

• Programmers reuse their own code (and friends) • Mathematical software is heavily reused but it is a special case • DeMarco - big expense to reuse, Yourdon quotes factor of 2 (1.5 to 3). • Large class libraries, vocabulary is an impediment, simply too many things. Helpful aids: – Examples of composed products (not JAVADOC) – Learn vocabulary by use • After all the critiques, no change in his premise - complexity is our business and it does limit us

119 Chapter 18

• Summarizes all the chapters

120 MMM after 20 years

• Really addresses how people in teams make things • Central argument - conceptual integrity and the architect – System must be conceptually coherent to the single mind of the user, yet designed by many minds – The architect forms and owns the public mental model of the product – Separate the architecture, the definition of the product as perceived by the user(s) from its implementation, this boundary is within the design task, user facing vs implementation facing • Recursion of architects - large projects have a master architect and the master architect partitions the system into subsystems with minimal, easily designed interfaces, each having its own architect • Having a system architect is the single most important step to achieving conceptual integrity

121 MMM - Retro 2

• Microsoft recommends build every night - (we do) • Rapid Prototyping technique - Wizard of Oz • Parnas was right about information hiding – Programmers are most effective if shielded from the innards of modules not their own (all in moderation) – More robust in a design for change (but …) • How Mythical is the Man Month - hardly any projects succeed in 3/4ths of calculated time regardless of how many people are deployed

122 MMM-Retro 3

• How true is Brooks’s Law : adding manpower to a late software project makes it later - most looked for remedies – Add manpower as early as possible – Focus on strategies for incorporating new folks – Brooks: none have addressed the added communication links • People are (almost) everything – Quality of people and their organization and management are the major factors, COCOMO model quality of people is strongest factor – Managers must enhance creativity – Delegating power down

123 Software Engineering Concerns

• Remain the same: – How to design and build a set of programs into a system – How to design and build a program or a system into a robust, tested, documented and supported product – How to maintain intellectual control over complexity in large doses

124 Reliability: vV quote

“The current-available software reliability models are limited in their immediate practical value.” - p 629

125 Bernstein - Fault tolerance

• Acknowledges that software has errors • Goal: Mean Time To Failure, large and Mean Time To Repair, small -- making software available to users in the face of software errors • In the 90’s fault tolerance gave way to high availability, high reliability RAID based systems – Dominant vendors convinced folks this was enough • “Software system development is frequently focused on performance and functional technical requirements and does not address the need for reliability or trustworthiness” • Robustness deals with expected problems, fault tolerance with unexpected problems • Trustworthy software is stable, does not crash with minor flaws and will shut down in an orderly fashion with major flaws

126 Early Approaches

• Initially mimicked hardware fault tolerance techniques • N version concept in software mimics N-way redundant hardware in software – Each module is built with N different implementations, then each module submits its output to a “decider” that determines the correct answer. – Works if programs do not share similar failure modes • Recovery Blocks - transactions are monitored and execution can be “rolled back” – Various things can be done to rolled back transaction including dropping it. • But hardware fault tolerance is predicated on manufacturing defects

127 Software and Manufacturing

• Software faults are usually products of design shortcomings not manufacturing faults – Software manufacturing is configuration, …, i.e., reproduction • Parnas’ Undesired Events paper • As Sha states: – Complexity begets faults – Some faults are easy to find and fix, others are Heisenbugs - a bug whose presence is affected by the act of observing it (intermittent symptoms, debuggers change situation) – Cannot spring for unlimited testing

128 HPC vs. HAC

• High Assurance Controller • High Performance Controller • Application Level - well understood • Application Level - advanced classical, tradeoff performance for technologies stability/simplicity • System Software Level- real time, • System Software Level - high assurance, dynamic and sophisticated no frills OS development features • Hardware level - well established, simple fault tolerant • Hardware Level - standard industrial • System Development and Maintenance - hardware high assurance process • System Development and • Requirements Management- limits Maintenance - standard practices requirements to critical functions and • Requirements Management - essential services, stable and changes emphasizes features and very slowly performance, requirements change relatively quickly

129 Fault Tolerance and Reliability

• Fault Tolerance is the ability of a software system to avoid executing a fault that causes a system to fail • R(t) = e-λt λ is proportional to software complexity, C, and inversely proportional to effort, E. • R(t) = e -kCt/E and assuming duration t =1 and scaling constant k = 1, then R(E,C) = e-C/E , the higher the complexity, the more effort.

130 Reliability

• Can be improved by: – Investing in tools – Simplifying – Do more inspections and testing during development • Code reading, critique • Code reviews, check against requirements • Code inspection

131 Constraints on Design

• Control free interfaces (low coupling) • Software error recovery - exception handling throughout – Fault tolerance provides services consistent with spec after detecting fault - unknown problems – Exception handling contains and eliminates a known problem • Recovery blocks • Limit language features used • Limit module size and initialize memory -- 300 to 500 instructions, smaller too many interfaces, larger too big for one person • REUSE MODULES w/o CHANGE!

132 Moving to Simplicity - Refactoring

• Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure – Improving the design of the code after it has been rewritten – Make it work, make it work right, make it work better – Ultimate goal is to subtract code when adding a feature

133 Increasing Reliability through Rejuvenation

• Rejuvenation - at periodic intervals, application is terminated and restarted at a known, clean state • These are rejuvenation periods where everything is reinitialized • A bug avoidance technique • Usually measured in days and weeks - prevents memory leaks from getting the best of the system • (systematic rebooting)

134 Effort Factors

• Hire good people, keep them • Don’t confuse vocational training with education • Maximize effectiveness of staff, large changes (>100 instructions) and small changes (<5) are error prone • Heuristics: – Design defensively, leave in debug mode – Stress test – Explain all anomalies uncovered, else provisional release – Hold arch reviews • Classical engineering technique - stress a system until it breaks and guarantee it for much less than break point

135 Robustness vs. FT

• Preventing a fault from becoming a failure - remember testing vocabulary • It is fault tolerant iff: – Program can compute acceptable result even if it suffers from incorrect logic – Produces acceptable result even with corrupted data • Robustness deals with expected problems, fault tolerance with unexpected problems

136 Software Archeology

• Trying to understand what was in the minds of software developers using only artifacts left behind • Hampered by the fact that the artifacts were not created to communicate to the future • Only part of what was originally created has been preserved • Relics from different eras (versions) are intermingled • Dynamic and static techniques • Support for refactoring • Browse the workshop! OOPSLA 2001 http://www.visibleworkings.com/ archeology/

137 Outsourcing

• Should you outsource? • Outsourcing strategies • Outsourcing tactics/plan • Cultural issues in outsourcing (and in general distributed development) • (Please contribute/debate)

138 Outsourcing Definition

• Contracting of various information system functions such as managing of data centers, operations, hardware support, software maintenance, network and even application development to outside service providers.

139 Should You Outsource?

• “no one really likes outsourcing, even well run initiatives” (http://www.cio.com ) • Outsourcing in combination with offshoring can get more value and reduce staff • It can be leveraged to improve process discipline • But root causes will still remain - e.g., lousy diagnostics will not make a help desk any better • Privacy, security and reliability concerns must be addressed✔

140 Outsourcing Strategy (Kishore, et.al. 2003)

Low Strategic High Strategic Importance Importance

High Control by Reliance Alliance Service Provider

Low Control by Support Alignment Service Provider

141 Outsourcing Plan

• Do a vendor assessment before contract is signed – Process, Technology, Operations audit (Reliance, Alliance) – Does vendor have privacy policy limiting data sharing – Does the vendor subcontract? – If live feed, proof that there are access controls, identity management and authentication in place • Audit of privacy and security practices • Senior executives must consent to sign a compliance pledge for privacy, security, process, … • Complete due diligence • Outsourcing should not be treated as a simple IT contract but as relationship management

142 Cultural Differences

• Exist in both collocation and virtual collocation • Culture is acquired, it helps people read world signals, artifacts gestures. It molds the way people think and are motivated. • Many kinds of culture - national, regional, organizational, avocational and generational • Affects how projects are formed and managed

143 Dimensions of Culture

• Hofstede (IBM employees) • Hall – Revering hierarchy – Space – Individualism vs. – Material goods Collectivism – Task (Japan, Germany, US) – Friendship (transitory or vs. Relationship (France, lasting) Russia, Netherlands) – Time focused – Agreement – Risk avoidance (Japan, Russia vs US, India) • Low context (US) vs. – Longterm orientation High context cultures

144 Issues

• Team composition: – Short term teams difficult in high context cultures – Attribution of team mates - recognize skills (misattribution of dress in videos) – Motivation- money vs time off • Teamwork – “microstructure of conversations” eye contact, tone of voice (soft, respect; loud, control) – Planning: buy in vs. authoritarion – Decision making: past, present, time/cost/quality – Argumentation styles: democracy versus authority – Use of time: abrupt meetings vs. slow chatty – Virtual collocation (high context need video, IM is an advantage(slowness issue)) – Brainstorm - anonymity – Time of day: (Israel, Sunday-Thursday, French 35 hr week, Holidays)

145 Steps in Collocation

• Awareness of cultural factors • Awareness of specific cultural values • Adjust to suit others, understanding is not enough • Establish a management communication covenant detailing how the team will be managed and how the team will communicates - just as important as agreeing on development rules and conventions!

146 Default Good Practices

• No tool recommendations (or very few) • So many exogenous variables - flexible/ adaptive

147 Process-DGP

• USE AN ARCHITECT THROUGHOUT✔ – This is recently being debated by XPers • REVIEWS & DISCOVERIES✔ • Incremental if you are small or starting out • Spiral if you are large • RAD with embedded IT • All should try an agile method - XP • Development Plan (* Plan) • Adders

148 Requirements - DGP

• One person is responsible and WRITES the requirements - baseline and change control • “ilities” especially reliability and usability (user manual first) • Embellished with Use Cases or Stories✔ • Testers are present • Stakeholders are present • Formally model difficult aspects (text or model rules) • Use WinWin variant with assessment of technical difficult and business priority • Prototype what you do not understand to clarify • Adders?

149 Architecture DGP

• Have one! ✔ • Appoint an architect and have continuity throughout project • 4+1 • Utility, Durability, CHARM • Architecture reviews and discoveries • Tabulate cross products • Adders?

150 Design DGP

• RUP • Boxes and arrows • Ubiquitous language + Model (Agile) • Change control • Patterns✔ • Traceability • Prototypes to answer questions • Adders?

151 Development DGP

• Development Plan✔ • Open Source • Tests in objects✔ • Code Reviews✔ • Advanced Development Environments • Document • Coding Conventions • Buildmeister - frequent builds✔ • Exception Handling • Adders?

152 Test DGP

• Lifecycle • Test set adequacy • Use cases, probability of occurrence • Extreme Testing / Intelligent testing • Test under load • Break it • Reliability /Trustworthiness • Adders?

153 Lifecycle DGP

• Refactoring • Archeology • Anti-regressive maintenance • Experienced, long term, contiguous staff • Updated Documentation • Adders?

154 Other DGP

• It’s about people!! • Post Mortems • Collect and use data - share (Q) • Code Reviews • Source code|text|diagram control • Build, buy, out source decisions early • Superb developers - attractors • Log books • Adders

155 First Class

156 Dystopia/Utopia/Other

Result & http://underthehollywoodsign.wordpress.com/2010/04/18/blade- 157 runner-nearly-three-decades-later-how-a-masterpiece-of- Workplace production-design-left-its-mark-on-los-angeles/ Kerilla $1000

YOU!

158 Good bye EMTM!

• 9 years! • 26 semesters- 155 3 hour lectures! – 601, software engineering 10 semesters – 608, hci, 8 semesters – 604, security and privacy, 8 semesters • 404 students in those classes, there were repeats • Thank You!

159 Challenger

160 References

• Larry Poneman, “Practice safe outsourcing,” http://www.darwinmag.com • Kishore, et.al. “Relationship perspective on IT outsourcing,” CACM, December 2003 • Olson, J.S. and Olson, G.M. “Culture surprises in remote software development teams” QUEUE, December-January 2003. • Brooks • http://www.visibleworkings.com/archeology • Barbacci, et.al., “Quality Attribute Workshops (QAWs), Third Edition, CMU/SEI-2003-TR-016. • Martin Fowler, UML Distilled, Addison-Wesley, 2003.

161 References-2

• Schneiderman, B. Designing the User Interface, 4th edition Addison-Wesley, 2004. • E.S. Raymond: – The cathedral and the bazaar – Homesteading the Noosphere – Halloween papers • Game Developers Association • Body Chart: http://www.mech.utah.edu/ergo/educate/ safety_modules/ctd-anthropometry/

162 References-3

• Kent Beck, eXtreme Programming explained, Addison-Wesley, 1999, isbn = 0-201-61641-6 • http://alistair.cockburn.us/crystal • http://agilemanifesto.org • Steinberg and Palmer, Extreme Software Engineering: A Hands on Approach, Pearson Prentice Hall, 2004, isbn = 0-13-047381-2 • Boehm and Turner, Balancing Agility and Discipline, Addison- Wesley, 2004, isbn = 0-321-18612-5 • Cusumano, M.A & Selby, R.W., CACM, 1997.

163