This post originated from an RSS feed registered with .NET Buzz
by Richard Jonas.
Original Post: Passed Exam 70-300
Feed Title: Richard Jonas
Feed URL: http://feeds.feedburner.com/blogspot/ouNA
Feed Description: Richard Jonas's blog about .NET, web development and agile methodologies.
I took the exam 70-300 (Analyzing requirements and defining Microsoft .NET solution architectures) today, and passed with a score of 967. I thought I had answered about 2/3 of the questions correctly, and the other 1/3 I thought had several correct answers which you could make a case for, so I was surprised that so many of my answers must have been in agreement with Microsoft's and my score was this high.
However, these things aren't worth doing unless you learn something. So what did I learn from this?
1) How to take a series of differing views of a system and extract requirements from these, splitting them into business needs, user needs, system requirements and requirements to manage the system when it is operational.
2) How each requirement might impose demands in terms of performance, availability, security, scalability, maintainability, accessibility, deployability or extensibility of the system.
3) How security issues can be considered using the STRIDE model â Iâve thought a fair amount about security before, but I somehow missed this model. Itâs described in more detail here:
Have I been converted to the "Microsoft Solutions Framework" approach? â I'm not sure â I think you do a better job if you find it rewarding, and you find things more rewarding if you are doing them, not planning them. So some aspects of planning are better deferred until later in development.
I also think people are more motivated if they feel personally involved part of a system, and are not an interchangeable resource. The Microsoft approach, by e.g. having coding standards that teams follow and documentation in a similar format across many projects makes you feel like an interchangeable resource who can be moved around different projects. If teams understand requirements and how these might impose demands on the system, they should be more free to develop their own processes to suit the talents of their members.
Previous Topic
1) How to take a series of differing views of a system and extract requirements from these, splitting them into business needs, user needs, system requirements and requirements to manage the system when it is operational.