Essential Release Skill – Know Your Requirements
Today I share a response from Sue as a representative of those recommending an emphasis on requirements as it pertains to having a successful software release.
Sue Writes:
Coming from a QA perspective, I cannot express strenuously enough how critical requirements gathering and a clear/concise software requirement specification is to the whole process. Not only is it important for the developer to know what to develop, it is equally as important to the QA person so they know what is expected of the programming and how it needs to work to accomplish the goal it is set to achieve.
What some upper management staff often fail to recognize is that there are “levels” of a specification. There is the executive level “I want it to be able to do this”, the end-user level where “it needs to accomplish this”, and the programmer/tester level where everything is document in very great detail to the Nth degree. It is that last level that sometimes gets missed, leaving the programmer to make assumptions and/or decisions on their own. Not only does this leave a lot of room for error, but is the major cause of project/scope creep.
Damian Writes:
[Software Release is] Truly is black art if you don’t get a handle on it.
Check out http://www.red-gate.com/delivery. On my list of to do’s for 2013 😉
I did check out the red-gate offering at Damian’s suggestion. I have followed Red Gate’s products for years, and used them when I could afford them. In the past, I have had to roll my own tools, which is painful, but sometimes easier to sell to management. Red Gate has key components such as integrated version control in SQL Server Management Studio allowing you to version control your database code and change scripts along with the rest of your software. In my opinion, that feature alone is as valuable as gold.
To be fair, there are other Version Control integration tools. Lately I worked with the Team Foundation Server integration.with Visual Studio. It has a lot of cool features, especially when your changes are not to data. But there are some typical Microsoft assumptions that make it not work in my current world. If you have stored procedures or triggers crossing databases, then Visual Studio Team is probably not going to work for your database version control.
Writing your own change control takes a little bit of work. It is rather easy to capture changes since SQL Server 2005 using database triggers. The work is not in capturing the change, but putting together tools to allow you to review the change, and place it into version control as desired. A couple of weekends for a good Windows forms person would get it done. Someone with Visual Studio Add In skills could probably integrate something into Visual Studio or SQL Server Management Studio.
Thanks to all for your valued input. If you would like to get into the conversation, share your thoughts by sending email to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured White Paper(s)
Go Beyond Basic Up/Down Monitoring
read more)