Archive of Software development Articles

No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.

We’ve written before about several characteristics of well written requirements, and one of those characteristics is testability. Ahamad has written an list of 10 tests of requirements, with an emphasis on assessing the testability of the requirements. The testability of the requirement determines if the resultant product can be tested to determine if it meets the requirement.

A client at a large company with large development teams and a long history of waterfall development made a comment: “The only people who are talking about doing this project in Agile are developers who think it will allow them to avoid responsibility.” My client may have been right (that people were saying that) but the developers who were saying it were wrong. Agile increases responsibility - it doesn’t absolve it.

This series is a reprint of an article by Scott Sehlhorst, written for developer.* in March 2006. A recent article on dailytech about “new” methods for software testing points to some very interesting research by the NIST (the National Institute of Standards and Technology) Information Technology Lab. We’ve split the original article into three articles to be more consistent in length with other Tyner Blain articles.

This is part 3 of a 3 part series.

This series is a reprint of an article by Scott Sehlhorst, written for developer.* in March 2006. A recent article on dailytech about “new” methods for software testing points to some very interesting research by the NIST (the National Institute of Standards and Technology) Information Technology Lab. We’ve split the original article into three articles to be more consistent in length with other Tyner Blain articles.

This is part 2 of a 3 part series.

This series is a reprint of an article by Scott Sehlhorst, written for developer.* in March 2006. A recent article on dailytech about “new” methods for software testing points to some very interesting research by the NIST (the National Institute of Standards and Technology) Information Technology Lab. We’ve split the original article into three articles to be more consistent in length with other Tyner Blain articles.

This is part 1 of a 3 part series.

We use actor hierarchies to organize the different users of a system. Different people play different roles, and thus do different jobs. We use different actors to identify and organize those people. When deploying a system globally, we usually discover people that do the same jobs, but do them differently. Incorporating the notion of personas lets us deal with this.

Bill Miller, who writes You Want it When?, a blog focused on improving the way you manage software development and I had a debate over email about outsourcing. We looked at pro’s and con’s, and our discussion centered around the best outsourcing model, and what the ramifications of outsourcing really are. Read on to see the back-and-forth.

A couple weeks ago we wrote about Outside-in Software Development, by Carl Kessler and John Sweitzer. One of their ideas about stakeholders and goals has got us thinking about traceability.

A heuristic evaluation (or heuristic analysis) is a quick, low-cost usability analysis of the design of a user interface. Pareto’s rule tells us that we can get 80% of the results from 20% of the effort. And that’s where discount usability tests like a heuristic evaluation come in to play. Formal, and more detailed usability studies yield better results - but cost more and take more time. A small investment can pay off big with a heuristic evaluation.