Software Engineering 3156Fall 2001 Section 1

17-Sep-01

Class #3: Life Cycles, XML, and Tools

Phil Gross

2

Administrivia

Recitations M: 5:30-6:30 CEPSR 415 T: 2:30-3:30 CEPSR 415 Except next Monday, 24 September

– 6:15-7:15 IAB 410

Would Friday be better?

3

More Admin Stuff

Groups– Proposals in by tomorrow night– Advantages of the disadvantaged

Tight schedule

4

Review

Standard Model Teams

5

Standard Model

Requirements Specification Design Implementation Integration Maintentance Retirement

6

Requirements

What are we doing and why? Interviews

– Getting a problem specification out of busy, threatened, very-much-not-programmer types

– Difficult to simulate in a course, so we’re skipping

Prototypes and negotiation Metric: requirements volatility

7

Specification

Creating the contract What it will do, not how Detailed, so duration and cost can be

estimated Classical: DFD, FSM, Petri Nets OO: Use cases, class modeling, state

diagrams

8

Design

Fill in the “How” Interaction diagrams

– Sequence– Collaboration

Interactions determine actions Determine object clients Create detailed design

9

Implementation

Pick a language: C, C++, Java, Ada, COBOL, LISP, FORTRAN, Standard ML, Forth, PL/SQL, Assembly, etc.

Programming standards: comments, meaningful variable names, named constants, etc.

Black-box and Glass-box testing

10

Integration

Top-down finds design faults early Bottom-up finds operational faults early and

isolates them So, “Sandwich Integration” does both at once Product and acceptance testing

11

Maintentance

Corrective (fix problems) Perfective (improvements) Adaptive (environment changes) Difficult, important, programmers hate it Carefully designed processes are critical

12

Maintenance Costs Money

Lots and lots of money Far and away most expensive component When doing cost-benefit analysis, anything that

cheapens maintenance generally wins

13

Retirement

Diminishing returns from patching old code At some point better to rip up and start fresh

14

Note What’s Not A Step

Testing Documentation Supposed to be continuous Particularly Documentation

15

Capability Maturity Model

Not a life-cycle model Set of strategies for improving the software process

– SW–CMM for software– P–CMM for human resources (“people”)– SE–CMM for systems engineering– IPD–CMM for integrated product development– SA–for software acquisition

These strategies are being unified into CMMI (capability maturity model integration)

16

SW–CMM

A strategy for improving the software process– Put forward in 1986 by the SEI – Fundamental idea:– Improving the software process leads to

Improved software quality Delivery on time, within budget

– Improved management leads to Improved techniques

Five levels of “maturity” are defined– Organization advances stepwise from level to level

17

Level 1. Initial Level

Ad hoc approach– Entire process is unpredictable– Management consists of responses to crises

Most organizations world-wide are at level 1

18

Level 2. Repeatable Level

Basic software management– Management decisions should be made on the basis of

previous experience with similar products– Measurements (“metrics”) are made– These can be used for making cost and duration predictions

in the next project– Problems are identified, immediate corrective action is taken

19

Level 3. Defined Level

The software process is fully documented– Managerial and technical aspects are clearly defined– Continual efforts are made to improve quality, productivity– Reviews are performed to improve software quality– CASE tools are applicable now (and not at levels 1 or 2)

20

Level 4. Managed Level

Quality and productivity goals are set for each project

– Quality, productivity are continually monitored– Statistical quality controls are in place

21

Level 5. Optimizing Level

Continuous process improvement– Statistical quality and process controls– Feedback of knowledge from each project to the

next

22

Summary

23

Key Process Areas

There are key process areas (KPAs) for each level

Level 2 KPAs include:– Requirements management– Project planning– Project tracking– Configuration management– Quality assurance

Compare– Level 2: Detection and correction of faults– Level 5: Prevention of faults

24

Experience

It takes:– 3 to 5 years to get from level 1 to level 2 – 1.5 to 3 years from level 2 to level 3– SEI questionnaires highlight shortcomings, suggest

ways to improve the process

Original idea: Defense contracts would be awarded only to capable firms

25

Experience (contd)

Profitability– Hughes Aircraft (Fullerton, CA) spent $500K (1987–90)

Savings: $2M per year, moving from level 2 to level 3

– Raytheon moved from level 1 in 1988 to level 3 in 1993 Productivity doubled Return of $7.70 per dollar invested in process improvement

26

Other SPI Initiatives

Other software process improvement (SPI) initiatives:– ISO 9000-series– ISO/IEC 15504

27

ISO 9000

Set of five standards for industrial activities– ISO 9001 for quality systems– ISO 9000-3, guidelines to apply ISO 9001 to software– There is an overlap with CMM, but they are not identical– Not process improvement– Stress on documenting the process– Emphasis on measurement and metrics– ISO 9000 is required to do business with the E.U.– Also by many U.S. businesses, for example, GE– More and more U.S. businesses are ISO 9000 certified

28

ISO/IEC 15504

Original name: Software Process Improvement Capability dEtermination (SPICE)

– International process improvement initiative– Started by British Ministry of Defence (MOD)– Includes process improvement, software procurement– Extends and improves CMM, ISO 9000– Framework, not a method

CMM, ISO 9000 conform to this framework– Now referred to as ISO/IEC 15504– Or just 15504 for short

29

Process Improvement Data

SEI report on 13 organizations in the original study They used a variety of process improvement techniques, not just

SW–CMM

30

Process Improvement Data (contd)

Results of 34 Motorola projects

31

Democratic Teams

Egoless programming Social engineering “Please find bugs in my code” Problem: “I order you all to be egoless”

32

Chief Programmer Teams

Brooks’s approach Chief Programmer Back-up Programmer Secretary Just Plain Programmers

33

Chief Programmer Problems

Chief supposed to be manager and programmer

Back-up Programmer just waiting for Chief Programmer to be hit by a truck– Cf. Vice President of the USA

Secretary does paperwork all day Doesn’t scale to 100 programmers

34

Typical Modern Team

Programmers have a Technical Leader and a separate Team Manager

Manager is administrative only Tech Lead is Technical only Can increase the hierarchy

35

Microsoft Model

Synchronize and stabilize Programmers can do whatever they want, but

have to check in their code on time every day for integration

Lets hackers run (relatively) free Good model for firms that can attract the very

best programmers

36

Extreme Teams

Code in pairs No specialization A writes test cases, then B writes code while A

watches Designed to be turnover-resistant Not for those who don’t like to be watched

37

Your Teams

Probably a mix of democratic and specialized Need to inventory skills of team Probably some manager type is a good idea

– Call people if stuff is late– Watch big picture

Not everyone needs to be coder– Lots of documentation needed

38

More On Project

Three main parts– Client– Server– AI

Each group will work on one of the three http://www.gamasutra.com http://www.gameai.com

39

Client

Graphical tile-based UI Network communication with server Running animations Sending commands from user to server Displaying what the server tells it to Editor mode Untrusted

40

Server

Network communication with client Modeling of entire game world

– Combat– movement

Management of game clock Storage to LDAP server

41

AI

Determine NPC/Monster actions Determine shortest path between points Scripting Conversation

42

Overview

Build-and-fix model Waterfall model Rapid prototyping model Incremental model Extreme programming Synchronize-and-stabilize model Spiral model Object-oriented life-cycle models Comparison of life-cycle models

43

Software Life-Cycle Models

Life-cycle model (formerly, process model) The steps through which the product progresses

– Requirements phase– Specification phase– Design phase– Implementation phase– Integration phase– Maintenance phase– Retirement

44

Build and Fix Model

Problems– No specifications– No design

Totally unsatisfactory

Need life-cycle model

– “Game plan” – Phases– Milestones

45

Waterfall Model (contd)

Characterized by– Feedback loops– Documentation-driven

Advantages – Documentation– Maintenance easier

Disadvantages– Specifications

Joe and Jane Johnson Mark Marberry

46

Rapid Prototyping Model

Linear model “Rapid”

47

Three Key Points

Do not turn into product Rapid prototyping may replace specification phase

—never the design phase Comparison:

– Waterfall model—try to get it right first time– Rapid prototyping—frequent change, then discard

48

Waterfall and Rapid Prototyping Models

Waterfall model– Many successes– Client needs

Rapid prototyping model– Not proved – Has own problems

Solution– Rapid prototyping for requirements phase– Waterfall for rest of life cycle

49

Incremental Model

Divide project into builds

50

Incremental Model (contd)

Waterfall, rapid prototyping models– Operational quality complete product at end

Incremental model– Operational quality portion of product within weeks

Less traumatic Smaller capital outlay, rapid return on investment Need open architecture—maintenance implications Variations used in object-oriented life cycle

51

Incremental Model (contd)

Problems– Build-and-fix danger– Contradiction in terms

52

Incremental Model (contd)

More risky version—pieces may not fit– CABTAB and its dangers

53

Extreme Programming

Somewhat controversial new approach Stories (features client wants) Estimate duration and cost of each story Select stories for next build Each build is divided into tasks Test cases for task are drawn up first Pair programming Continuous integration of tasks

54

Unusual Features of XP

Computers are put in center of large room lined with cubicles

Client representative is always present Cannot work overtime for 2 successive weeks No specialization Refactoring

55

Evaluating XP

XP has had some successes Good when requirements are vague or changing Too soon to evaluate XP

56

Synchronize-and Stabilize Model

Microsoft’s life-cycle model Requirements analysis—interview potential

customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small teams working in

parallel

57

Synchronize-and Stabilize Model (contd)

At the end of the day—synchronize (test and debug) At the end of the build—stabilize (freeze build) Components always work together

– Get early insights into operation of product

58

Spiral Model

Simplified form– Waterfall model plus

risk analysis

Precede each phase by

– Alternatives– Risk analysis

Follow each phase by

– Evaluation– Planning of next

phase

59

Simplified Spiral Model

If risks cannot be resolved, project is immediately terminated

60

Full Spiral Model

Radial dimension: cumulative cost to date Angular dimension: progress through the

spiral

61

Full Spiral Model (contd)

62

Analysis of Spiral Model

Strengths– Easy to judge how much to test– No distinction between development, maintenance

Weaknesses– For large-scale software only – For internal (in-house) software only

63

Object-Oriented Life-Cycle Models

Need for iteration within and between phases– Fountain model– Recursive/parallel life cycle– Round-trip gestalt– Unified software development process

All incorporate some form of– Iteration– Parallelism– Incremental development

Danger– CABTAB

64

Fountain Model

Features Overlap

(parallelism) Arrows (iteration) Smaller

maintenance circle

65

Conclusions

Different life-cycle models Each with own strengths Each with own weaknesses Criteria for deciding on a model include

– The organization– Its management– Skills of the employees– The nature of the product

Best suggestion– “Mix-and-match” life-cycle model

66

XML

Structured form of communication How components will communicate Freeform HTML Grammar and validation DOM and SAX

67

History

First came SGML Then HTML HTML became hugely successful XML is an attempt to recapture most of the

power of SGML, without all the hassle

68

Example XML Message

Note: lots of examples from either http://www.w3schools.com or http://www.w3.org

<?xml version="1.0"?> <note>

<to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body>

</note>

69

Differences From HTML

Stricter All tags closed Tags are case sensitive All attributes must be quoted

– Avoid attributes, except for IDs True tag modifiers

70

Grammar Specification

DTD Schema We’re using schemas

– Much nicer– Consistent: XML themselves

Grammars explain structure to developers Can also be used for automated validation

– Sloooooow

71

XML Tools

Many Apache tools among the most popular

– Open source– C++ and Java versions available– Xerces

DOM: suck into memory, give back tree structure

SAX: parse sequentially, return events

72

More XML

JDOM XSLT SOAP

73

CVS

First, a word on race conditions Two threads within one program Both want to increment a variable Both read One writes The other writes Result: one increment, value clobbered

74

More On CVS

The same can happen with your coding process

Two people working on same piece of code RCS: simple system for versioning and locking CVS: fancier, networkable system for checking

out entire dev snapshots And then selectively committing changes

75

CVS, Continued

No locking Conflicts are marked inside the code You’ll also be notified if checking in a wrong

version