COMS W3156:Software Engineering, Fall 2001

Lecture #4: Lifecycles and Tools

Janak J Parekh

janak@cs.columbia.edu

Administrativia• TA office hours set

– One office hour per TA; they will also be holding group meetings

• Recitation times set (except Friday?)– We saw a lot of you yesterday, that’s a good start– Next Monday: IAB 410, 6:15p-7:15p

• Group proposals due tonight!• Webboard up and running…• Questions: Suhit likes them…

Next class

• Schach, chapter 5; Tools– Go into more detail

• Reading, but won’t be formally covered: Mythical Man Month, chaps 1-8

• Introduction to networking essentials– Ethernet– TCP/IP: addressing, routing, transmission– Socket programming– Lots of cool, real stuff

Today’s class

• Finish up chapter 2: some well-known SE models

• Go over XML one more time, talk about CVS

• Talk about lifecycle models

Problems in software production (I)

• Complexity: a 16-bit “word” can have 216 states (65,536)– Each word multiplies the complexity– Complexity grows much faster than just a linear

scale– Large products difficult to understand– Maintenance is tough

Problems in software production (II)

• Conformity– Perception: software is “easier” to meld than

hardware– Ergo, everyone makes the software do weird

stuff

• Changeability– Either fix or improve existing software

• Invisibility: most software is behind-the-scenes

Problems in software production (III)

• There is no “silver bullet” according to Brooks (the “life sucks” paper)– In other words, we will not improve

software engineering an order of magnitude with new technologies

– Essentially, software is fundamentally difficult to develop, and that is unlikely to change

– Still, Schach points out that productivity is doubling every 12 years

So what do we do?

• Improve the software process

• Several new developments

• CMM: Capability Maturity Models

• ISO, IEC

CMM: 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)

SW-CMM

• Big business for SEI @ CMU

• Schach talks about SW-CMM– 5 “levels” of maturity in an organization– Ranges from nothing to strict process model

adherence

• The idea was for defense contractors to reach appropriate phases

Other software processes

• ISO 9000 series of standards—very broad– Stresses documenting both textually and pictorally

– Only part of a quality system

– Very popular buzzword, required for business with EC and certain US companies

• ISO/IEC 15504: international process initiative, very similar to ISO 9000

• Cost/benefit improvement is striking, but this does require a substantial initial investment

Software Lifecycle Models

• How software is created and evolves

• Most are orderings and processes based on some subset of the seven basic phases we talked about last class

• Can anyone can recall the 7?

Build-and-fix model• The haphazard model; we all know it; we

still do it

• OK on short programs; fails utterly on larger ones

• Maybeprototypes

Waterfall model

• The de-facto model for many decades

• Feedback loops,documentation-driven

• Lots o’ documentation:can’t progress without

• Disadvantage:– Need to be schooled– All written!

Rapid prototyping model

• Similar to waterfall, butrapid prototype for specifications

• Few feedback loops• Prototype != finished

product or design• Waterfall tries to get it

the first time, instead• Can combine the two:

waterfall is proven

Incremental model

• Deliver product piece-by-piece

• Happens often in small business*

• Rapid ROI, lessinitial capital outlay

• Don’t let it degradeinto build-and-fix—what’s the difference?

• Contradictory?

Incremental model (II)

• Attempt to reconcile contradiction-in-terms

• Risky: CodeABitTestABit (CABTAB); no guarantee builds will “fit together”

Extreme programming model (I)

• Somewhat controversial new model• Might be good for rapidly changing designs• Very much a religion amongst proponents;

www.extremeprogramming.org derides classical software engineers

• Software team determines features (“stories”) client wants, do cost analysis on it (requirements/specification)

• Successive builds, client determines features/stories in each build

Extreme programming model (II)• Break build down to small tasks to be done in parallel• Draw up test cases for task• Code task in pairs• Unusual properties:

– Computers in center of room– Client with team at all times– No two-week successive overtime– No specialization– No overall design phase; refactor design during builds

• XP has not yet been proven for larger projects; easy to abuse IMHO

Synchronize-and-stabilize (I)

• Better known as the Microsoft model

• Requirements: interview potential customers, extract features

• Have several builds: critical first, then move down list

• Teams synchronize at end-of-day, test and debug existing work

Synchronize-and-stabilize (II)

• Stabilize at end of each build, fix bugs, then freeze

• Developers gain early insight since working product is made early

• Can do this, as mentioned, if you have really good people and can dictate the design

Spiral model

• Superset of othermodels, with prototype-based risk analysis at each stage

• So why is it calleda spiral model?

Spiral model (II)

• Showscommon stepsat each phase

• You think thislooks complex?Hah…

Spiral model (III)

• Radial – cumulative cost-to-date

• Angular – progress through spiral

• Internal, large-scale software only—no contract

OO Lifecycle Models

• Really an evolution of existing waterfall model: increase iteration (refinement), parallelism, and incremental development offered by object-oriented design

• Fountain, etc.• Avoid CABTAB!

What will you do?

• Highly Abbreviated Model (HAM)– No, this doesn’t really exist

• Gain understanding of individual phases

• Don’t have time for feedback loops, risk analysis, refinement, etc.

• Software Engineering should really be 2-semester, but not enough demand

Tool time!

• Two kinds of tools:– Analytical tools/techniques– CASE tools, e.g., real products

• We’ll be discussing these throughout the course, and we’ll be adding our own

Analytical tools

• Three in particular discussed here– Stepwise refinement: identify basic tasks, and

refine the steps involved iteratively– Good general concept useful in many different

engineering phases– Cost-benefit analysis– Metrics (next slide)

• We’ll go into these more next class

The software engineering community has been placing a great deal of emphasis lately on metrics and their use in software development. The following metrics are probably among the most valuable for a software project:

The Pizza Metric

How: Count the number of pizza boxes in the lab.

What: Measures the amount of schedule under-estimation. If people are spending enough after-hours time working on the project that they need to have meals delivered to the office, then there has obviously been a mis-estimation somewhere.

CASE tools (I)

• Computer-Aided Software Engineering

• Quite a few categories; we’ll be dealing with several over the course of the semester

• Scope: tool/workbench/environment

• Not everything fitsprecisely into thisscoping

CASE tools (II): Schachisms

• upperCASE: front-end; lowerCASE: back-end

• Workbenches– Data dictionary: keep track of data in product;

consistency checker– Report and screen generators

• Environments– Full software process– Generally used mostly in large companies/projects

CASE scope

• Programming-in-the-small is what you’ve done: code-compile-run-repeat

• Better way?– Programming-in-the-large: module-level– Programming-in-the-many: team-oriented (both large and

small)– Source editors that can do syntax checking: structure

editor– Automation tools to build: make– Source-level debugging, tracing: gdb, jdb– Versioning and configuration control…

Versioning control

• Versioning: deal with many people and many versions of code– People work on their local computers, yet code

needs to be shared amongst all– Versioning software allows for code to coexist

without overwriting people’s work– Automated: cp, tar, zip doesn’t quite cut it– cvs: we’re getting to this shortly

Configuration control

• Even when versioning is done, a product may be run in many configurations– Schach defines this as a “set of versions” on

files• Set up a “stable” baseline against which variations

are tested

• Freeze code to be altered

– Also actual software configuration

CVS• Concurrent Versions System• www.cvshome.org has the lowdown• Supported on Win32, UNIX and other platforms:

primarily command-line but GUI tools available• Primarily a versioning tool, but has some

configuration control• Based on RCS, a single file-versioning tool—store

“diffs” of each old version• Each file has a unique version number

Before you use CVS

• Need to understand basic UNIX skills (mkdir, ls, chmod, chgrp)

• Set up a repository– Set up a group under UNIX and set permissions on a

directory– “set CVSROOT” or “export CVSROOT” to that dir– “cvs init”

• Set up personal workspaces– “set CVSROOT” or “export CVSROOT”– cvs checkout

CVS (II)

• Versioned files are organized into “modules” (top-level directories)

• Centralized “repository” of files

• Work in local workspace, checkout and commit files from/to repository

• Does not lock files when you checkout: worry about conflicts when you commit

CVS example

CVSROOT

Janak’s workspace Phil’s workspace

client common

MyClient.java <1.1’>Network.java <1.1>

Utils.java <1.2’>

server common

MyServer.java <1.3’>GameBoard.java <1.2>

Utils.java <1.2’>

client server common

MyClient.java <1.1>Network.java <1.1>

MyServer.java <1.3>GameBoard.java <1.2>

Utils.java <1.2>

• So what does this mean?

All the CASE in the world…

• Doesn’t help if you don’t know how to use them: “A fool with a tool is still a fool”

• Therefore, we’re teaching cvs in detail in recitations, and will also cover Rational Rose, a CASE tool for UML-based software development

XML revisited

• XML is a structured text-based data format that can be transmitted over any medium

• We will be using this for communication between the server and the client

• Two basic concepts– XML “grammar”– XML “parsing” and “validation”

Example XML message

• Many sites to see: www.w3schools.com, www.w3c.org (check out XML part 0)

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

<to>Phil</to><from>Janak</from><heading>Thanks</heading><body>I copied this example, but changed the text. :-)</body>

</note>

• Identify the tags here

XML grammar

• DTD vs. Schema– Schema is the new language for specifying XML

– Much more powerful, cleaner (it’s XML)

– We’re using Schema

• Two purposes:– Explain structure to XML writers

– Automatic validation*

• Not for parsing

XML tools and links

• Many, many out there– Check out http://www.w3.org/XML – Apache Project: not just a webserver!

• http://xml.apache.org/ • Xerces parser/validator/generator very popular

• Data structures to hold parsed XML– DOM: a “tree” to hold the result

• JDOM – http://www.jdom.org

– SAX: callback with the data• http://www.megginson.com/SAX/

• XSLT, SOAP