Recently I had a conversation with a young engineer who seemed to be of the opinion that there were better things to do than waste time writing requirement specifications. I asked “Like what?” and in response I heard a list of things which included “triaging bugs.”
“Really, you think that?”
Youngsters today, where do they get these silly ideas from? Perhaps from misguided professors who are hip on all the new great software engineering advances like Agile and Extreme development. I’ve been in engineering for, well, a very long time and have seen a lot of different development processes. The one thing I can tell you, unequivocally, is that if a team doesn’t have a common vision for their deliverable, they are sunk (ask me some day about “brilliant weapons”).
Many of you may be familiar with Sean Liming, one of our MVPs, through his great support in the MSDN forums and previous books on Windows Embedded products. He now has a new book out for Windows Embedded Standard 7 called “Professional's Guide To Windows Embedded Standard 7”. Sean brings his experience in the industry to bear in explaining the Windows Embedded Standard 7 product and how the toolkit works. Along with a high level overview, Sean offers detailed sections on a number of areas including servicing and the embedded enabling features. Sean’s experience also comes in useful as he calls out differences between Windows Embedded Standard 7 and the XPe/Windows Embedded Standard 2009 family of products, making it easier to move to the latest Windows Embedded Standard offering. You can purchase the book at Annabooks website. We already have some copies on our own team.
Happy New Year!
I’d like to take a moment of your time to reflect on the previous year and look ahead to the next year.
By far the biggest thing coming from the Windows Embedded Standard team was the release of Windows Embedded Standard 7.
We’re excited to announce the release of another PowerToy to aid in Windows Embedded Standard 7 development: CBS Package Inspector. CBS Package Inspector allows for the opening up and inspecting of CBS (Component-Based Servicing) packages, so the manifests can be viewed or examined as needed. Information contained in these manifests include the components inside the package(s), as well as any registry keys, dependencies, or settings, among other pieces of information. So what does that mean? Why would this be useful? Here are some scenarios that CBS Package Inspector has been quite useful for us:
To learn more about CBS Package Inspector and to download and use it, please visit the Package Inspector Code Gallery page.
Windows Embedded Standard is a componentized form of Windows that enables the power of Windows to be adopted on embedded devices. The Windows Embedded Standard toolkit allows embedded developers to create custom images of Windows that are tailored to their needs. With these needs, the quality expectations of the toolkit and the customized images are t presented, and embedded developers using this product anticipate that it will be of high quality standards that meet the needs of their own customers. That’s why enforcing software product quality is taken to be a top priority for the Windows Embedded Standard’s development team. At this team, we follow the same standards and processes that the majority of the teams follow at Microsoft when developing their products, and this document will give a summary of some the main test areas that our product undergoes before releasing.
In talking about software quality assurance, you can find that many software testing areas exist. Some are functional while others are non-functional, and some examples of the non-functional areas would be the ones which are referred to as the “ilities” by the authors of the book “How We Test Software At Microsoft”, Alan Page, Ken Johnston and BJ Rollison (a few examples are dependability, reusability, testability ….). In the following sections, we present areas of software testing and briefly discuss it while giving pointers to where you can find more information on the topic. These guidelines are heavily used by the Windows Embedded Standard development team, and we recommend that they be followed accordingly and whenever possible by software development teams.