Software Project Management
A list of xUnit testing frameworks is available at:
This list is NOT complete. It omits for example things like HttpUnit (which is an add-on for JUnit for web testing) and jWebUnit, a simpler but less flexible successor to HttpUnit. If you're not sure if there's a xUnit framework for you, try guessing at what it would be called in Google. (Sorry, "cobolunit" had no results.)
Refactoring is a suite of well-defined well-structured techniques for making code cleaner, less redundant, and more reusable.
Martin Fowler keeps the Refactoring Home Page.
Bill Wake (author of Extreme Programming Explored) has an XPlorations site with a number of good essays on refactoring.
Roger Pressman's resource page -- lots of good links
There are quite a few articles on using Use Case Points for estimating project size, all quite similar to what's in the Jalote book). The Ribu thesis is the longest, but the most relevant to Task 3, because of her analysis of student use of UCP.
A predecessor to Use Case Points is Function Points. Function Points are a way of characterizing how complex a system is, even though it hasn't been built yet. FP was first applied to primitive form-based data base applications, and even though it has many adherents today, I never saw any description on-line or in textbooks that showed how to apply FP to modern interactive systems. However, that seems to have changed:
Finally, the following should be very helpful mapping points or SLOCs (source lines of code) to effort:
Estimation tells you how long a project will take. A project plan specifies how the work will be done, what the intermediate deliverables are, how risk will be managed, and so on. There are many good plans, but even more awful ones.
A project plan has to do more than just make sure everything gets built. It has to do so in a way that minimizes risk. That means frequent productive client involvement, early identification of project-killers, and so on.
Some relevant readings are:
Plans have lots of text, but a good chart is worth several thousand words:
The following texts are classics in the field. By no means is this an exhaustive list of the "must-haves" for a software developer's library.
- The Mythical Man-Month by Frederick P. Brooks, Jr.
- A classic, now in a new revised anniversary edition. Why do large software projects fail? And does software engineering have any silver bullets?
- Introduction to the Personal Software ProcessSM by Watts S. Humphrey
- A highly-developed, very meticulous approach to project tracking and estimation, from the perspective of an individual developer. Will definitely make you feel guilty and disorganized.
Note: There's a good summary by Humphrey in "Using a Defined and Measured Personal Software Process" in IEEE Software, May 1996,13(3).- Object-Oriented Software Engineering: A Use Case Driven Approach by Jacobsen et al.
- The inventors of use cases on how to use use cases for requirements analysis and design.
- Programming as if People Mattered by Nathaniel S. Borenstein (Princeton University Press, ISBN 0-691-03763-9)
- An attempt to bring human computer interaction (HCI) issues into software engineering.
- Extreme Programming Explained by Kent Beck
- Extreme Programming is the hot thing in software development right now. Take the iterated development approach of the Unified Software Development Process several steps further. While radical in many ways, it makes a lot of sense to many experienced developers.
The following are some standard texts in software engineering. At least one of them should go on your shelf for reference purposes, in case some asks you about "function points."
- Software Engineering: A Practitioner's Approach, 5th ed. by Roger Pressman (McGraw-Hill)
- This is probably the standard textbook for the field. Massive.
- Software Engineering by Ian Sommerville (Addison-Wesley)
- Another standard text.
An important thing to learn is the difference between refereed journals, magazines, and newsletters.
Unified Software Process:
Extreme Programming (XP):
Links and comments from former C94 student Ryan C. Horner:
This site allows you to search across the domains of the Software Technology Support Center and the Software Engineering Institute (as well as providing many good papers/presentations on the site itself).
This site contains many papers on Software Project Planning Papers.
This particular paper discusses the bottom line of investing in quality and process improvement for software projects.
Kelly Mann has searched high and low for software engineering links:
- Kelly Mann's Ton o' Links
Testing is more than running your program and seeing if it works!
Would you bet your job that your program will never crash, that it will never produce incorrect values, no matter what someone types into it? Would you bet thousands of company dollars or more? Would you bet someone's bank account? Their life? For examples where someone lost these bets, see http://www.softwareqatest.com/qatfaq1.html#FAQ1_3.
- Some Useful Links
- A few I've found recently.
- Case Study: From "Chaos" to "Repeatable" in Four Months by Johanna Rothman
- A nice brief introduction via a concrete example of process improvement, in terms of the first two levels in the CMM model of software development maturity.
- The SEI Capability Maturity Model
- From the software engineering archives -- a good description of the levels of the CMM and the point of the CMM.
- What is a quality use case? by Adolph et al.
- A very readable overview of use cases with examples, including an example of a bad use case. NOTE: The InformIT web site has a lot of good material on a wide range of programming issues. You have to register to see it all, but registration is free.
- SEED-Layout Requirements Analysis
- A nice example of an in-depth requirements analysis in careful, but non-formal, terms.
- Some Brief Diagram Notes
- My own examples of STD's, DFD's, and sequence diagrams, inspired by common student mistakes.
- Rational's UML Overview (PDF)
- A nice description of what some of the basic UML diagrams are for, in what order to develop them, and how it all fits into a software development process.
NOTE: the examples frequently involve design not requirements, e.g., making a class CourseOffering is a design choice. For our purposes, stick to requirements. Only actors, servers, clients, data repositories, systems (e.g., the billing system) should appear in your sequence and collaboration diagrams. Class diagrams aren't that critical for us at this stage.
- Beyer & Holtzblatt's Contextual Design web site for their company, InContext
- This site has links to various short articles on this consulting group's approach to customer-centered design.
For use cases in particular, see the following.
- Practitioner's Guide to Use Case Modeling
- A decent overview with examples.
- Alistair Cockburn's Structuring Use Cases with Goals and Use Cases 10 Years Later
- Cockburn has done a lot of study of use cases and how they're used and misused.
For how use cases lead to an analysis model (a high-level semi-design):
Send mail to
Chris Riesbeck.