Software Best Practices

Another requirements related idea I like (which I know you already know about) is Tom Gilb's idea of the requirements "landing zone." Some requirements are binary -- the software meets the requirement or it doesn't. But others are "scalar." These are the requirements that...

David, You provide some more good techniques for anticipating changes. Here's how I would summarize them: Component Level Estimating Estimating Best, Worst, Expected Cases Using standard percentages for downstream activities Active risk management to build your contingency Re-Estimating when more...

Hi Jerry, Some good questions! I will do my best to answer... On that project the original estimates were created by breaking down the product into components and then estimating best and worst case effort for code and unit test of each component. My management required a single figure rather than a...

David, My observations is the same as yours -- the high-level requirements are pretty stable. I like your solution of giving the developers the freedom during coding. Of course, your post raises several questions. Are you using this technique on plan-driven projects? If so, how did you account for this...

Change is a very broad term. In my experience the high level requirement (i.e. an online ordering system) is rarely subject to much change. The detail of what has to be delivered changes enormously over time but a lot of this “so called” change is in fact the process of developing a high level requirement...

Change is inevitable on a project. It doesn't matter if you using agile or plan-driven techniques, you must embrace change. Agile embraces change by being very responsive -- they point out that the future is unknown, so they just look to the near term. Plan-driven techniques are used when the customer...