Notice how this incremental develop method is possible and works well in this scenario (situation). How might it work in other circumstances? Is it always a good thing? Would it work in other situations?
What are the dependencies of incremental development. If increments are dependent on the base, and the base changes or is not solid, what does it do to that kind of work in the end?
How would it have worked with the crane group? Some projects start with a code base that works well and can be modified on the edges. This is not always possible for other codebases. It would be really hard for the crane group to come up with that first little increment.
SoilSim would be a third kind of case, where in the beginning they started from scratch, with a big step at the beginning, but at the same time they could proceed at their own pace and mark off increments on their own. Look for something in the crane project where there’s a learning period where you can’t start something right away.
Look for something in the crane project where there’s a learning period where you can’t start something right away.
Why did the Shifting scope worked well in this project. How may this process work out or end up in other situations? Ans. If you look at the requirements, none of them, the features didn't really interfere much with each other vs. other requirements which all depended on each other (soilsim – carbon nitrogen cycle, root engine type requirements). SoilSim models an ecosystem full of dependencies, JLS is a product that fits nicely into these compartmentalized chunks.