1 / 18

Effective Software Planning and Estimation Techniques

This lecture covers crucial aspects of planning and estimation in software engineering. It addresses the challenges of estimating costs and timelines, highlighting the discrepancies in programmer efficiency and the complexities of methodologies like COCOMO and Function Points. Additionally, the importance of accurate requirements, testing, documentation, and the use of tools such as MS Project and JDOM for handling XML is discussed. This session aims to provide a comprehensive overview for students to understand the nuances of estimating software projects effectively.

gavril
Télécharger la présentation

Effective Software Planning and Estimation Techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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!

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

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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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%)

  10. 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…

  11. 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

  12. 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!

  13. 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

  14. 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

  15. 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

  16. 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

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

More Related