Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web...

36
Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010
  • date post

    19-Dec-2015
  • Category

    Documents

  • view

    216
  • download

    3

Transcript of Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web...

Page 1: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Lifecycle Models / SD ApproachesAgile Development ProcessHypertext System TypesWWW OverviewWeb 2.0

CS 1834/1/2010

Page 2: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Pure WaterfallDocument driven process, linearPhases: Requirements analysis, design,

implementation, testing (validation), integration, and maintenance

Review held at the end of each phase to determine if you progress to the following phase

Works well for product cycles where there is:◦ stable product definition◦ working with well-understood methodologies

Con: slow, can be hard to fully define requirements up front

Page 3: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Variant: Sashimi ModelWaterfall with overlapping

phasesAllows project work to proceed

before entire prior phase is complete

Pro: more efficientCon: milestones are more

ambiguous, harder to track progress accurately

Page 4: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Code and FixInformal model: start with

general idea of what to do, then start coding

Advantage: ◦low overhead◦shows signs of progress immediately

Disadvantage: ◦doesn’t scale to large projects◦hard to ensure you develop code

that meets requirements

Page 5: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Evolutionary PrototypingDevelop a prototype, and then iterate

on it until customer and developer agree it’s “good enough.”

Pro: ◦good when requirements are changing, or

not well understood, or if the optimal architecture or design is not well understood

Con: ◦ impossible to predict how long the project

will take up front (but mitigated by customers being able to see steady signs of progress)

Page 6: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Design to ScheduleStaged release, but with a fixed

period of time, so the final stages may never be achieved.

Advantage: ◦ensures that by a ship date, you’ve

implemented the most important desired features

Page 7: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Scrum Process Invented in 1986, hopes to create a new approach to project

management, but became more popular in late 90s Agile is a project management methodology built around the

idea that projects should be completed in smaller chunks to achoeve greater results.

Sprint - a 30-day focused effort moving the team toward fixed goals.

Product Backlog - a constantly prioritized to-do list. Sprint Backlog - a list of the highest prioritized items from

the product backlog Scrum Master- the coach for the product management team

and works to ensure the realization of the goals of the sprint. Product Owner- represents the customer and is responsible

for prioritizing the backlog. Scrum Team- a group of 5-9 people who self-organize and

have joint responsibility for the completed tasks.

Page 8: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

The Scrum Process (1)Creating a backlog

◦Product Owner and Scrum Team meet in order to discuss the priority and items on the Product Backlog.

◦The Product Owner must be able to form the product vision.

◦The Product Backlog then, is a prioritized list of what is required for the project and is ranked with regard to importance.

Page 9: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

The Scrum Process (2)Sprint Planning Meeting

◦ Product manager describes goals of the project and explains backlog

◦ Scrum team selects the items from the product backlog to be completed during the sprint based on priority

Sprint schedule determined, items from product backlog are broken down in tasks and assigned to team (Sprint Backlog)

Sprint becomes (~15 – 30 days), no other tasks are added to backlog

Daily Scrum, 15 minute stand-upSprint Review – once the sprint endsProcess repeats with new list of prioritized tasks

on the Product Backlog.

Page 10: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Hypertext System Types

Page 11: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Three levels of a Hypertext SystemPresentation level: user interfaceHypertext Abstract Machine (HAM) level:

nodes and links Database level: storage, shared data, and

network access Problem: only few hypertext systems are

actually following this model, mostly mixed up

(see also http://www.useit.com/papers/hypertext_theory/ for the full article)

Page 12: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Database LevelDeals with all the traditional issues of

information storage that do not really have anything specifically to do with hypertext◦store large amounts of information on

various computer storage devices◦keep some of the information stored on

remote servers accessed through a network

◦Performance importantMulti-user access, security, backup, …

Page 13: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Hypertext Abstract Machine (HAM) levelMiddle layerNodes, links, and relations between themKeeps track of attributes related to each

◦Link might have an ‘owner’ or ‘version’ attribute

HAM is the best candidate for standardization of import-export formats for hypertexts

Example of a HAM-level standard is HyTime (1992)

Page 14: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

User Interface LevelDeals with the presentation of the

information in the HAM◦What commands should be made available

to the user, how to show nodes and links, and whether to include overview diagrams or not

◦Example: HAM level of a hypertext defines the links as

being typed. The user interface level might decide not to

display that information at all to some novice users and to make typing information available only in an authoring mode

Page 15: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Nodes Fundamental unit of hypertext Distinction between frame-based vs. window-based systems Frames:

◦ Frames take up a specific amount of space (fixed) on the computer screen no matter how much information they contain (e.g., KMS frames, HyperCard cards)

◦ Since the frame has a fixed size, the user may have to split a given amount of information over several frames if it cannot fit into one.

Window:◦ In contrast, window-based systems require the user to use a

scrolling mechanism in addition to the hypertext mechanisms to get the desired part of the node to show in the window.

◦ Guide and Intermedia are typical window-based systems In practice: Hybrid systems

◦ HyperCard is mostly frame-based but includes the possibility for having scrolling text fields as part of a card.

Page 16: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Links Links are the other fundamental unit of hypertext besides

nodes. Links are almost always anchored at their departure point to

provide the user with some explicit object to activate in order to follow the link.

Can be shown inline or on the side (inline more effective) Explicit vs. implicit links (e.g., glossary) A hypertext link has two ends, can be bidirectional Most frame-based hypertext systems only have links that

point to an entire node◦ When the destination is large, it is an advantage for the user to

have the system point out the relevant information more precisely (Anchor in destination)

Some hypertext systems also have "super-links" to connect a larger number of nodes.

Links can be semantically tagged (e.g., to support better retrieval)

Page 17: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

AnnotationsSpecial link typeFor small, additional amount of

information (similar to footnotes)Allows reader to add extra

linkage without modifying original nodes/links

Another way of doing it is with various forms of highlighting (not really a link, but meta-data can be aggregated and used to support various filtering needs)

Page 18: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Use of sticky-notes to represent annotations. To add an annotation, the user tears off a sticky-note from the pile to the right and places it on the object that needs a comment. Every time this object is displayed in the future, the sticky-note will be there (until the user removes it). Copyright © 1994 by J. Ray Scott, Digital Equipment Corporation

Page 19: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

The InterNote service within IRIS Intermedia provides a quick facility for annotating documents of any type. The top frame of the note window (right) contains the annotator's suggestion of a change in wording. The bottom frame explains the reason for the suggestion. The author of the "Microtubules Introduction" document may now choose to incorporate the change by selecting the marker at either end of the link that connects the note to the document and choosing the "Incorporate Annotation" command. © 1989 by Brown University

Page 20: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Hypertext EnginesMake hypertext easy to useProvide common user interfaceExample for plain engines: “Guide” and

“Hyperties”◦Simple to use, user may only need to do some

low-level formatting (e.g., line breaks)◦Not much control on the UI

Other engine allow user to customize the UI further◦Hypercard (e.g., move fields around, add field,

background graphics), has no default document design

Page 21: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

MonolithicEarly hypermedia systems were monolithic. They included the interface to the user, a

linking mechanism, and an interface to a basic file store in one program.

Examples:◦ Intermedia (run on A/UX 1.1), used lots of resources

(4 MB RAM, 80MB hard drive space, 1989), wasn’t very portable, lack of funding in 1991

◦ NoteCards, develped by Xerox PARC, 1984, notecards connected by typed links, implemented in LISP

◦ KMS, frames interconnected by links, implemented in Pascal / C, 300KLOC, Java-based “Expeditee” system being developed

Page 22: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Open HypertextGoal is to integrate hypertext capabilities with

the rest of the user’s software environment◦ Let apps work with the data as is, but provide ways of

communicating with a shared hypertext mechanism that handles links across applications (or within apps)

Engelbart [1990] defines 3 levels of interoperability◦ 1) interoperability in an individual's information space

(e.g., linking from a phone list to a set of notes)◦ 2) interoperability in a group's information space

(e.g., from one person's file space to a colleague's)◦ 3) interoperability across groups (e.g., linking from

the marketing organization to the manufacturing or product development organizations)

Page 23: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Fully aware Microcosm viewers. The image viewer shows part of a city map with super-imposed "buttons" on top of the bitmap data for display purposes. The text viewer is based on RTF (rich text format). These viewers have been launched as a result of the user selecting items from the available links box, which is showing links available from the source anchor "Abbey Green." Copyright © 1994 by the Microcosm Group, University of Southampton, U.K.

Page 24: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

General idea is to move hypertext level from the applications and provide a single hypertext service for everything on a user’s computer

Hypertext service then communicates with applications

Major problem is that apps need to be aware to what hypertext system to talk and have a common shared protocol

Page 25: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Spatial HypertextMotivation: users may get confused or lost

when navigating through large networksNoteCards showed map of network structuregIBIS and Aquanet presented visual network of

typed links and nodes where the types are visually distinguished within the map

Map-based hypertext systems implications:◦ Shows interconnectedness explicitly (directed graph)◦ Proximity◦ => Interesting phenomenon: Users avoid explicit

linking but took advantage of the more implicit spatial proximity, also observed in traditional hypertext systems

Page 26: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Benefits of spatial hypertextTakes advantage of people’s considerable visual

recognition and intelligence (e.g., remember where one saw a document)

Facilitates constructive ambiguity (e.g., place a node close but not quite with others can imply some indecision)

Supports emerging problem-solving strategiesReduces overhead in communicating with others

◦ Correlation observed between the number of people sharing an information space and the degree of visual structure apparent in the arrangement

◦ more people => higher degree of perceptual structure

Page 27: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Moving ahead …

Page 28: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

HTML and WWW emerging …mid 90sFirst web browsers (Mosaic, Netscape)Basic HTML not sufficient, therefore

proprietary enhancements“Browser War”Starting 1995 coordination of HTML

standards through World Wide Web Consortium (W3C)◦Members include companies like Microsoft,

IBM, SAP, Opera◦HTML 4.01 (based on SGML), XHTML 1.0, and

XHTML 1.1

Page 29: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

The World Wide Web (WWW)The World Wide Web is a system of hypertext

documents that are viewable by a web browser

Hypertext documents are documents with internal cross- references to other documents

Runs as service on top of the internetOriginally based on three fundamental

mechanisms:

Page 30: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Web 2.0Web 2.0 is a buzzword for describing new

forms of applications and services that are accessible by the web browser such as wikis or weblogs

These applications often have in common a high social component and appealing user interfaces and are based on new interaction models and new document representations that will be discussed among other things in this lecture

Page 31: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

HTML (Hyper Text Markup Language)HTML is not a programming language, it

is a markup languageA markup language is a set of markup

tagsHTML uses markup tags to describe

web pagesElements starting with “<ELEMENTNAME”Followed by attributes name=“value”Elements can comprise text or other

elements <h1 align=“center“>Hello World</h1>

Page 32: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Try it!Tutorial:

◦http://www.w3schools.com/html/default.asp

Page 33: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Basic TagsHTML Headings <h1>, <h2>, …HTML Paragraphs <p>HTML Links

◦ <a href=http://www.foo.com>text</a>

HTML Images◦ <img src=“image.jpg” width=“100” />

HTML Lists◦ <ul>◦ <li>item 1</li>◦ <li>item 2</li>◦ </ul>

Page 34: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

HTML ElementsStart tag, element content, end tag

◦<p>Some Text </a>Syntax

◦Starts with opening tag◦Ends with closing tag◦Element content is everything between

the opening and closing tag◦Some elements have empty content◦Empty elements are closed in the opening

tag (e.g., <BR />)◦Most HTML elements can have attributes

Page 35: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Nested HTML ElementsMost HTML elements can be

nested, contain therefore other HTML elements

HTML docs consists of nested HTML elements

<html>

<body><p>This is my first paragraph</p></body>

</html>

Page 36: Lifecycle Models / SD Approaches Agile Development Process Hypertext System Types WWW Overview Web 2.0 CS 183 4/1/2010.

Some tips …Don’t forget the End TagIn XHTML, XML, and future versions of

all elements must be closedUse lowercase tagsAlways quote attribute valuesUse lowercase attributesUse only legal attributes if possibleUse CSS for styling and appearance,

no <FONT> tag Use Javascript to add interaction