Analyzing Requirements, Part 5
This class is finishing up, so here’s the last post on it.
The teacher was a good guy but wasn’t too familiar with the subject matter, so he floundered at the beginning and to cover for it he rambled about things that had no bearing on reality. Having taught the section on code access security myself when he was ready to gloss over it, it makes me wonder what other tidbits of information I’m missing out on that he also glossed over due to lack of experience.
The courseware sucked donkey. There were altogether too many questions that had answers you could never have come up with on your own. The idea was there, but the person (or people) who QA’d the book should be fired. Or maybe they need to take the course, too, so they know why they did such a crappy job. Regardless, it made the class a little harder than it should have been, methinks, and that’s never good.
In the end, this whole thing is exactly what I thought it was: “Software Engineering the Microsoft Way.” It’s one more method to pull together and manage software development projects. This one focuses way too much on the planning phase, though, and while it looks good on paper, I can see several shortcomings in it, particularly when scaled down to apply to smaller teams and projects. This one’s best left for the larger stuff - huge product suites, operating systems, etc. I’m so glad this is a test I get to take.
Now we’re just talking about different ways to derive object models for your project. I’ve already had my four years’ worth of training in this one, but I’m listening to see what other people do; it’s always interesting to get an outside perspective.
After that, I’m outta here! Go home and… well, I haven’t planned that far yet. I guess I’ll see when I get there. On to the holidays!