Design Priorities

[swatts]

Hello there my designer chums.

Every now and then we get asked to do a code/design review on a project. 99.9999% of the time this is because the project has gone really badly wrong, and by code/design review they actually mean "can you rescue the project for us?". But on the assumption that it is a review that they want I started thinking about a useful document.

An important point to understand is that a design review and a code review are very different processes. Ideally the design review should be completed before too much code is written (demo and feasibility code are the exceptions). The outputs from this are an acceptance that the design is appropriate to everyone involved in the process. Whereas a code review is a confirmation that the code has been written to acceptable standards and this will be prior to release (or in sometimes prior to incorporation into the project) 

The reason for this type of documentation is primarily to help the design process, enforce and remind about standards and give traceability to any decisions or exceptions. 

Anyways I was asked to go and do a code review of a project and I thought that in the spirit of enlightenment that I should review the code against the customers criteria rather than SSDC's standards. The inspiration for the questionnaire came from Arnoud de Kuijper's Use Case wheel.

By grading the project, we should be able to ascertain review criteria that are important to the customer. This is pretty much my first draft of the questionnaire and here is where you come in.

Are there any other questions that can be asked?. Also looking at the headings I feel some clarification is needed. But in the spirit of conversation I thought I'd put it out there and see what occurs.

There's no time limit so add questions and comments any old when.

Next year in the spirit of open source, I will be releasing all of our processes and documents to the wide world.

Lots of Love

Steve

[FabiolaDelaCueva]

Hi Steve,

This reminds me of something I read on the book The Agile Samurai book by Johnathan Rasmusson. 

If you don't have time to read the whole book, I recommend the product inception section, I believe anyone working on software projects should read it, regardless if you are following Agile or not. You can get an idea of what this is by reading Johnathan's blog post.

Specifically related to your form is the section where he describes the Trade-off sliders (point 9 on the blog post), he does it from ON to OFF, you do it from Least to Most, or from lowest priority to highest priority. It is the same idea, the most important thing to remember when filling one of these forms is that not everything can be highest priority. So there should be some limit on how many can be at highest priority and not two forces can be at highest priority. I believe the author uses sliders, because the scale is more fluid, having sliders means that you might put one of your items in the list closer to 1 and the next one closer to 2, this helps with getting the sliders to be in different numbers. 

We get asked to conduct software audits, code reviews, process reviews, etc. One thing that we have learned is that it is important to define what is it that you are measuring, against what you are measuring it and how will you measure it. 

For example, if you are measuring if the code is readable, you have to measure it against a style guideline and a good way to measure it is by using VI Analyzer tests.

Regards,

Fab

[swatts]

Thanks for that link Fab.

That is a very nice article (suffering blog envy now!).

I'm going to have to invest in that book I think. Ordered from http://www.hive.co.uk as this supports local booksellers (rather than amazon who don't pay their taxes!)

I was going to make a sliding scale VI as a demo, perhaps I should think on it a bit more.

[joerg.hampel]

I cannot add much other than that I agree with Fab: I liked the Agile Samurai a lot (I think I bought it after Fab mentioned it somewhere?)

[FabiolaDelaCueva]

Joerg,

I might have mentioned it before, your comment reminded me that I had not added it yet to the LabVIEW Champions reading resource center. Just added it!

Steve,

Glad you liked it and I hope you find it useful. 

Regards,

Fab

[SercoSteveB]

Hi Steve

One thing that occurs to me is the validity of a one person review.  Any review is likely to improve the quality of an application but I wonder how closely matched our questionaires\priorities would be if you and I reviewed the same application?

Steve

[swatts]

Hi Steve,

I would be aiming the review at the person paying the bills I think. So the questionnaire would be presented at a meeting of interested parties and they would be asked/guided into what's important. I could then review it on their priorities.

Steve

[SercoSteveB]

I like the questionaire, it is a good way to break the review down, and your customer could always add something that isn't specifically listed when completing the questionaire.  

My comment was about the actual review.  I think you get a more rounded review using multiple reviewers. 

[swatts]

Ah gotcha,

I completely agree, I'm very much a proponent of group-thinking, I think there is nothing better than a multi-pronged attack on a problem.

A very good example was when NI used to do the Systems Architects Reviews. The customer would pay a good sum of cash to get a review and generally the Sys Architects would concentrate on performance. Without asking the question is it to specification (or adequate). They would also be under pressure to find something. It became a difficult exercise for all involved.

I like lists as a way of guiding the hand......