Software Development Process and Introduction to Java

1
Software Development ProcessandIntroduction to
Java

• Session 1
• LBSC 790 / INFM 718B
• Building the Human-Computer Interface

2
Agenda

• The software development process
• (10 minute break)
• Java
• (5 minute break)
• Introductions and course description

3
Building User Interfaces

• User interface design (LBSC 795, CMSC 828F)
• What should we do?
• Software design (this course)
• How should we go about it?
• Software implementation (this course)
• How do we actually do it?
• Evaluation (LBSC 795, CMSC 828F)
• Did we do the right thing?

4
Software

• Software represents an aspect of reality
• Input and output represent the state of the world
• Software describes how the two are related
• Programming languages specify the model
• Data structures model things
• Structured programming models actions
• Object-oriented programming links the two
• A development process organizes the effort

5
The Waterfall Model

• Key insight invest in the design stage
• An hour of design can save a week of debugging!
• Three key documents
• Requirements
• Specifies what the software is supposed to do
• Specification
• Specifies the design of the software
• Test plan
• Specifies how you will know that it did it

6
The Waterfall Model
Requirements
Specification
Software
Test Plan
7
The Spiral Model

• Build what you think you need
• Perhaps using the waterfall model
• Get a few users to help you debug it
• First an alpha release, then a beta release
• Release it as a product (version 1.0)
• Make small changes as needed (1.1, 1.2, .)
• Save big changes for a major new release
• Often based on a total redesign (2.0, 3.0, )

8
The Spiral Model
2.3
1.2
0.5
1.1
2.2
1.0
2.1
2.0
3.0
9
Unpleasant Realities

• The waterfall model doesnt work well
• Requirements usually incomplete or incorrect
• The spiral model is expensive
• Rule of thumb 3 iterations to get it right
• Redesign leads to recoding and retesting

10
The Rapid Prototyping Model

• Goal explore requirements
• Without building the complete product
• Start with part of the functionality
• That will (hopefully) yield significant insight
• Build a prototype
• Focus on core functionality, not in efficiency
• Use the prototype to refine the requirements
• Repeat the process, expanding functionality

11
Rapid Prototyping Waterfall
Update Requirements
Write Specification
Choose Functionality
Initial Requirements
Create Software
Build Prototype
Write Test Plan
12
From needs to specification
Design specification
Refine and Revise
Requirements
Task / Work context
Identifying Needs
Users
Task / Work
13
Objectives of Rapid Prototyping

• Quality
• Build systems that satisfy the real requirements
  by focusing on requirements discovery
• Affordability
• Minimize development costs by building the right
  thing the first time
• Schedule
• Minimize schedule risk by reducing the chance of
  requirements discovery during coding

14
Different kinds of requirements

• Functional (capabilities)
• What the system should do
• Historically the main focus of requirements
  activities
• Non-functional (constraints) memory size,
  response time...
• data
• What kinds of data need to be stored?
• How will they be stored (e.g., database)?

15
Are these requirements?

• Attributes
• Appearance
• Concepts (represented by data)
• Behavior
• What it does
• How you control it
• How you observe the results

16
Different kinds of requirements

• Environment or context of use
• physical
• dusty? noisy? vibration? light? heat? humidity?
  . (e.g. OMS insects, ATM)
• social
• sharing of files, of displays, in paper, across
  great distances, work individually, privacy for
  clients
• organisational
• hierarchy, IT departments attitude and remit,
  user support, communications structure and
  infrastructure, availability of training

17
Different kinds of requirements

• Users Who are they?
• characteristics
• ability, background, attitude to computers
• system use
• novice, expert, casual, frequent
• novice
• step-by-step (prompted), constrained, clear
  information
• expert
• flexibility, access/power
• frequent
• can use interface short cuts
• casual / infrequent
• clear instructions, e.g., menu paths

18
Who Sets the Requirements?

• People who need the task done (customers)
• People that will operate the system (users)
• People who use the systems outputs
• People who provide the systems inputs
• Whoever pays for it (requirements commissioner)

19
Rapid prototyping process
Start
Identify needs/ establish requirements
Refine Design Specification
Evaluate
Build Prototype
Final specification
Exemplifies a user-centered design approach
20
(No Transcript)
21
The Requirements Interview

• Focus the discussion on the task
• Look for objects that are mentioned
• Discuss the systems most important effects
• Displays, reports, data storage, device control,
  
• Learn where the systems inputs come from
• People, stored data, devices,
• Note any data that is mentioned
• Try to understand the structure of the data
• Shoot for the big picture, not every detail

22
The Specification

• Formal representation of the requirements
• Represent objects and their relationships
• Using a constrained entity-relationship model
• Specify how the behavior is controlled
• Activity diagrams, etc.

23
Rapid prototyping process
Start
Identify needs/ establish requirements
Refine Design Specification
Evaluate
Build Prototype
Final specification
Exemplifies a user-centered design approach
24
Prototyping and construction

• What is a prototype?
• Why prototype?
• Different kinds of prototyping low
  fidelity high fidelity
• Compromises in prototyping vertical horizontal
• Construction

25
What is a prototype?

• In other design fields a prototype is a
  small-scale model
• A miniature car
• A miniature building or town

26
What is a prototype?

• In interaction design it can be (among other
  things)
• a series of screen sketchesa storyboard, i.e. a
  cartoon-like series of scenes a Powerpoint slide
  showa video simulating the use of a systema
  lump of wood (e.g. PalmPilot)a cardboard
  mock-upa piece of software with limited
  functionality written in the target language or
  in another language

27
Why prototype?

• Evaluation and feedback are central to
  interaction design
• Stakeholders can see, hold, interact with a
  prototype more easily than a document or a
  drawing
• Team members can communicate effectively
• You can test out ideas for yourself
• It encourages reflection very important aspect
  of design
• Prototypes answer questions, and support
  designers in choosing between alternatives

28
What to prototype?

• Technical issues
• Work flow, task design
• Screen layouts and information display
• Difficult, controversial, critical areas

29
Low-fidelity prototyping

• Uses a medium which is unlike the final medium,
  e.g. paper, cardboard
• Is quick, cheap and easily changed
• Examples sketches of screens, task sequences,
  etc Post-it notes storyboards Wizard-of-Oz

30
Storyboards

• Often used with scenarios, bringing more detail,
  and a chance to role play
• It is a series of sketches showing how a user
  might progress through a task using the device
• Used early in design

31
Sketching

• Sketching is important to low-fidelity
  prototyping
• Dont be inhibited about drawing ability.
  Practice simple symbols

32
Using index cards

• Index cards (3 X 5 inches)
• Each card represents one screen
• Often used in website development

33
Wizard-of-Oz prototyping

• The user thinks they are interacting with a
  computer, but a developer is responding to output
  rather than the system.
• Usually done early in design to understand users
  expectations
• What is wrong with this approach?

User
gtBlurb blurb gtDo this gtWhy?
34
High-fidelity prototyping

• Uses materials that you would expect to be in the
  final product.
• Prototype looks more like the final system than a
  low-fidelity version.
• For a high-fidelity software prototype common
  environments include Macromedia Director, Visual
  Basic, and Smalltalk.
• Danger that users think they have a full
  system.see compromises

35
Compromises in prototyping

• All prototypes involve compromises
• For software-based prototyping maybe there is a
  slow response? sketchy icons? limited
  functionality?
• Two common types of compromise
• horizontal provide a wide range of functions,
  but with little detail
• vertical provide a lot of detail for only a
  few functions
• Compromises in prototypes mustnt be ignored.
  Product needs engineering

36
Construction

• Taking the prototypes (or learning from them) and
  creating a whole
• Quality must be attended to usability (of
  course), reliability, robustness,
  maintainability, integrity, portability,
  efficiency, etc
• Product must be engineered
• Evolutionary prototyping
• Throw-away prototyping

37
Characteristics of Good Prototypes

• Easily built (about a weeks work)
• Requires powerful prototyping tools
• Intentionally incomplete
• Insightful
• Basis for gaining experience
• Well-chosen focus (DONT built it all at once!)
• Easily modified
• Facilitates incremental exploration

38
Prototype Demonstration

• Choose a scenario based on the task
• Develop a one-hour script
• Focus on newly implemented requirements
• See if it behaves as desired
• The users view of correctness
• Solicit suggestions for additional capabilities
• And capabilities that should be removed

39
Rapid prototyping process
Start
Identify needs/ establish requirements
Refine Design Specification
Evaluate
Build Prototype
Final specification
Exemplifies a user-centered design approach
40
A Disciplined Process

• Agree on a project plan
• To establish shared expectations
• Start with a requirements document
• That specifies only bedrock requirements
• Build a prototype and try it out
• Informal, focused on users -- not developers
• Document the new requirements
• Repeat, expanding functionality in small steps

41
The Project Plan

• One-page written contract
• Between developer and requirements commissioner
• Goal The problem to be solved
• Product What you plan to deliver
• Scope Available time and personnel
• Method How your rapid prototyping works
• Roles What you expect each other to do

42
Requirements Approval

• Plan on between 12 and 50 iterations
• Adding about 10 new objects per iteration
• Use the project plan to enforce a deadline
• New requirements shrink, but never disappear
• Schedule a formal approval demonstration
• Allow one more iteration to fix any problems

43
What is NOT Rapid Prototyping?

• Focusing only on appearance
• Behavior is a key aspect of requirements
• Just building capabilities one at a time
• User involvement is the reason for prototyping
• Building a bulletproof prototype
• Which may do the wrong thing very well
• Discovering requirements you cant directly use
• More efficient to align prototyping with coding

44
Programming for the Web

• Server-side
• Java servlet, Perl
• Client-side
• Java applet, JavaScript
• Browser plug-ins
• Java application, C, C,

45
The Java Virtual Machine
Keyboard
Mouse
Java Compiler
Java Virtual Machine
bytecode
Java Program
Network
Screen
compile time
run time
Speaker

• A bytecode interpreter running on a real machine

46
Java Features

• Strong support for graphical interfaces
• Includes a rich set of interface objects
• Designed for a networked environment
• Provides easy access to Web pages
• Object-oriented
• Designed to support abstract thinking
• Strongly typed
• You must declare variables before use

47
Naming Things

• Some constants
• 3 (an int), 3.7 (a float), three (a String)
• Declaring a variable
• int numberOfSeats
• Declaring objects
• CommercialFlight flight
• Referring to a variables in an object
• flight.numberOfSeats

48
Operators in Java

• Arithmetic operators
• - /
• Logical operators
• lt lt ! gt gt !
• String operator

49
Statements in Java

• Sequential
• Semicolons are required at the end of every
  statement
• Conditional
• if (i3) else
• Loop
• for (i0ilt10i)
• while (ilt5)
• Braces are optional around a single statement

50
Arrays in Java

• A set of elements
• For example, the number of days in each month
• Each element is assigned an index
• A number used to refer to that element
• For example, x4 is the fifth element - count
  from zero
• Arrays and loops work naturally together

51
Methods in Java

• Defining a method
• int multiplyNumbers (a, b)return ab
• Argument values are local to the method
• Explicitly invoking a method
• multiplyNumbers(b, 7)
• Events invoke a method in response to a stimulus
• Mouse click, mouseover, resize window,

52
Making Java Applications

• Start by defining a top-level class
• public class ExampleApplication
• Create a main method in the top-level class
• public static void main(String args)
• Put statements in the main method
• System.out.println(Hello World!)
• Add more methods to the class as needed
• Add more classes as needed

53
Getting the Java 2 SDK

• Java 2 SDK standard edition version 1.5
• Available free at http//java.sun.com/j2se/
• Runs on Windows, Solaris (Suns unix) and Linux
• Already installed several places on campus
• On the Windows machines in HBK 2105
• Available on WAM and Glue Unix systems
• Over telnet (without graphics display)
• On console in CSS 4352, PG2 and EPSL

54
Main Java 2 SDK Components

• javac
• Compiles Java source to produce bytecode
• java
• Interprets Java application bytecode
• appletviewer
• Interprets Java applet bytecode
• jdb
• Supports typical debugging tasks

55
Getting the Java 2 SDK to Work

• path
• Where to look for javac, java,
• classpath
• Where to look for .class files
• Both can be set automatically
• On WAM and Glue, tap java
• On Windows
• Control Panel-gtSystem-gtAdvanced-gtEnvironment
  Variables

56
Eclipse

• Java integrated development environment
• Integrated editor, execution, and debugging
• http//eclipse.org/downloads/index.php
• Main Eclipse download site-gtBuild 3.0-gthttp
• After installation of Java 2 SDK 1.4.2!
• First practice exercise will get this working

57
Course Organization

• www.takomasoftware.com/UMD/INFM718B/
• Goals
• Communications
• Be sure that you are receiving email from me!
• Syllabus

58
Learning Opportunities

• Class sessions
• Theory, programming, show-and-tell
• Reading
• Primary source for detail (esp. programming!)
• Assignments
• Graded homework, ungraded exercises
• Lab sessions (Lets choose a time now!)
• Help with programming
• Project
• A vehicle for putting it all together