COMS W3156: Software Engineering, Fall 2001

COMS W3156:Software Engineering, Fall 2001 Lecture #10: Planning and Estimation Janak J Parekh janak@cs.columbia.edu

Administrativia • v1.0 of the requirements out – fewer changes now • Rose installed as of yesterday – printing problems • Windows Rose access • HW1 due now; HW2 out tonight • Webboard – use it!

Next class • How did we come up with the requirements? • Continue networking discussion

Today’s class • Planning and estimation discussion • Look at MS Project if some time • JDOM • Project: sample XML files

Planning and Estimation • Very hard to do, but we need it • “How much will it cost? Can you stick to it?” • “How long will it take?” • Open-source: “It’ll be released when it’s done” • Rapid prototype/requirements/specifications often insufficient to determine cost estimate • Internal vs. External Cost

Challenges • Human factor • Difference of up to 28:1 between pairs of programmers • Even among average experienced programmers, ratio is 5:1 • Will they stick around? • How to measure product? • Code measures are highly inaccurate, language-specific, comments • KLOC and KDSI

Product size • Files, flows, processes (van der Poel, Schach): data-oriented, but never extended to databases • Function points (Albrecht): deal with various functional abstraction properties • Neither account for maintenance work

Cost estimation • Compare to existing products by experts • Somewhat ambiguous • Worse than real-estate valuation processes • Bottom-up approach • Estimate per low-level component • Total greater than sum of products • Algorithmic • COCOMO

COCOMO • Very sophisticated metric: book only outlines “intermediate COCOMO” • Nominal effort in person-months times 15 multipliers • Aargh! But it worked in the 80’s (within 20%)

COCOMO II • Attempt to accommodate modern software engineering techniques, OO, etc. • Even more complex • COCOMO and COCOMO II are really out of the scope of this course • Although students did it before…

Software Project Management Plan • Not part of the lifecycle, per se: more business-side of things • Work to be done • Resources with which to do • Money to pay for all • Concept of resources and work • IEEE 1058.1 standard

Other issues (I) • Testing: SPMP’s must include a test plan and cost estimates • Object-Oriented Planning: structured planning works, excluding reuse • Reusable components: about 3 times more difficult to build • Training requirements: developers need training too!

Other issues (II) • Documentation: wide variety, but time-consuming: often more time spent on documentation than code; SPMP requires documentation standards • CASE tools • Spreadsheets • MS Project

JDOM • “Java representation of XML document” • Useable with SAX = Simple API for XML and DOM = Document Object Model, but simpler • Comes with Xerces parser built-in (http://xml.apache.org) • May be part of standard Java in near future: on standards track • Allows you to parse XML into a simple Java data structure, edit said data structure, and output XML from it

To use JDOM • Input • Point JDOM at a file, string, URL, InputStream • Tell it to parse (SAXBuilder or DOMBuilder) • Use data structure • Output • Create data structure • Use XMLOutputter to output to String, InputStream, some others • That’s really it: let’s look at Phil’s example

What does this mean for you? • You won’t do planning and estimation; take 4156 if you’re dying to know • JDOM a useful toolkit for handling XML: will probably need for HW2

Project • Sidebar: focus on your stuff, not others’ • Off to XML-example-land

COMS W3156: Software Engineering, Fall 2001