Quality Prioritization

August 12, 2007 by · Comment
Filed under: Process 

Recall that last week, we identified a broad range of areas to consider when we describe overall software quality. It is valuable to appreciate that correctness (or functionality) is just one of perhaps a dozen different attributes to look at for quality, even though in most projects this is the only perspective considered. Finally, we noted that it is important to start with a broad range of attributes (there are several similar ones to choose from) to avoid the possibility of missing an entire perspective of quality. Read more

Quality Taxonomies

August 5, 2007 by · Comment
Filed under: Process 

This is the first of a 4-part series on Software Quality Attributes, where we focus on the Taxonomy of Quality. Read more

Divide and Conquer

August 27, 2006 by · Comment
Filed under: Process, Project management 

In the ideal situation, the process of software development should consist of a series of appropriately selected steps, each of which clarifies some aspect of the system as you proceed from inception to delivery. Done properly, there should be no “and then a miracle happens” steps along the way, as can occur when you dive into the code right after throwing together some concepts on the back of an envelope. Read more

Becoming the Distant Customer

July 3, 2005 by · Comment
Filed under: Process, Teamwork 

Most of the time when we train groups in the area of software requirements issues, they will be taking what they have learned to define requirements and build the corresponding system themselves. They will be working with an external client that isn’t involved in the training, and part of their role is to educate their client why it is worthwhile to spend the time up front so the requirements are in as good a shape as possible. Often the client has no software development savvy at all, and there is a clear distinction between the domain experts (the clients) and the implementation team – the group involved with the requirements training. Read more

Clearly Specifying Quality

December 29, 2002 by · Comment
Filed under: Process, Quality 

One of the most difficult things to do in software development (if observation of projects across the industry is any indication) is clearly specifying the system needs from the quality perspective. Functional specifications are often incorrectly labeled as the complete specification for the system, or attempts at specifying the quality side degrade to untestable statements such as “The system shall be user-friendly.” Worse yet, attempts to simply reuse quality specifications from existing systems can result in serious consequences from under-specification, or unachievable goals from over-specification of quality. Read more

« Previous Page

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    The requirements prioritization portion was especially interesting. I can use this next week with a customer directly.

    — Mike Aksmanovic, MDSI Mobile Data Solutions Inc