This chapter
This chapter talks about what to do in big projects when you have alreadey layed out the features. They try to write some use cases but it shows that it is a little bit difficult writing perfect use cases just yet. Insead they write what they call scenarios . These help to actually start writing use cases when you’re not quite ready yet. This chapter also talks a little about risk and how you must shift you implementation in such a way that minimizes risk. They also give you three tips to help you figure out where to start. Especially in these big proyects one can feel overwhelmed. It can be difficult to know where to start.
Where to start
The last chapter they layed out a very complex and big problem. We’ve done a very broad analysis of what the application must do but without getting into actuall code. In this chapter they help you decide where to start first once you’ve described the mayor features. Basically there are three tips that the books gives. Start with what’s essential (duh), start with what you don’t understand , start with what you don’t know how to do. The first one can come across as really obvious but it’s important to have in mind. The second what are very self explanatory. If you don’t know how to do something, you should start with that becuase otherwise it can cause you problems in the long run. I’ve experienced this myself. I was in the back-end of the development of a proyect and I didn’t understand how a specific thing worked on the front-end that was relevant for the task. I had to change quite a few things becuase of this afterwards.
Reduce risk
They also talk about a certain key aspect of software analysis. Risk. They say that everything one does in the architectural phase of the project should reduce the risk of the project failing. I can understand why this is very important but I haven’t quite totally understood it. I don’t understant why would that change if you do something first or leave it at the end. If a certain feature is at risk of making your whole project fail what does that have to do with when you do it. If a feature is going to make you fail, it should make you fail wether you do it at the start or at the end right? I don’t know but the book didn’t make it clear.
Scenarios b4 uses cases
When you’re in such a big project like the one in chapter 6 and seven there’s a lot of room for mistakes. And you also feel overwhelmed by the size of the project so it’s hard to go straight into writing use cases. This is probably one of the most useful things of the chapter. To write scenarios of how you’re application will work is useful to start writing use cases.
Cellar Door Blog 