CMM is a numeric scale used to “rate” the maturity of a software development process or team. In this context, maturity can be thought of like enlightenment. An immature process is not much different from the old “infinite monkeys” yarn – maybe we get it right, but probably not. A fully matured or enlightened process not only does it right, but improves itself over time. The Software Engineering Institute (SEI) at Carnegie Mellon, my alma mater, created the CMM model in the late 80’s and early 90’s. In this post, we will understand what each level represents.
Software requirements for migration projects
A very common enterprise software project is the replacement of a legacy system – migrating functionality to a new system. This type of project usually has very different constraints than a “new application” project. We will look at the characteristics of migration projects to understand how we should approach them to assure success.
Prioritizing software requirements across releases
When prioritizing requirements for the first release of our software, we’ve stressed the importance of including 100% of the ‘must have’ requirements in the first release of the software. We’ve also used Kano analysis to categorize requirements as ‘must be’, ‘surprise and delight’, and ‘more is better’ requirements. In this post we’ll talk about an approach to allocating these requirements across releases.
Interaction design explained by Alan Cooper
There’s a Clash of the Titans joint-interview posted at FTPOnline between Kent Beck and Alan Cooper called Extreme Programming vs. Interaction Design. It’s 10 pages of back and forth. In short, these icons agree on objectives, and disagree on how to achieve them. They also spend some time (mis)characterizing each other’s positions and defining their own. In this post we will look at how Alan Cooper explains Interaction Design. We would say that he defines interaction design more as a requirements than a design activity.
Top ten tips for preventing innovation
At a recent presentation in Austin by Seilevel about the goals and methods of requirements gathering, a member of the audience asked “What can we do with our requirements to assure innovation?” That’s a tough question with an easy answer – nothing.
What if the question had been “What can we do to prevent innovation?” That’s a better question with a lot of answers.
Definition of NPV – Net Present Value
Net present value, or NPV is the great equalizer of financial analysis.
NPV allows us to compare any two investments and determine which is the better investment.
NPV tells us how many dollars, today, we would be willing to spend to receive money in the future. NPV lets us compare investments that pay back money in very different ways – we can decide if we would rather have $10,000 in one year, or $500 per month for 20 months. Without NPV, the two investments appear to be the same (they both return $10,000), but one of them is better than the other.
Foundation Series: User Experience Disciplines
UX, pronounced you-ex, is the shorthand for user-experience. It represents the science and art of tailoring the experience that users have with a product – in our case, software. UX is a relatively new term, rapidly overtaking HCI (human-computer interface) and CHI (computer-human interface) as the acronym du jour. There are several disciplines within this field, we’ll introduce each of them.
This Software Sucks! – Say Users
You need to read Scott Berkun’s Essay # 46 – Why software sucks (and what to do about it). His content is great, his style is easy and fun, and he has good insights. If his other essays are this good, he goes in the same bucket as Joel Spoelsky and Paul Graham for us. As Berkun points out, we don’t set out to write bad software. Here’s how we can avoid some of the different mistakes.
The code freeze is killing the dinosaurs
The software development process for most companies has a flow – gather requirements, design, implement, test, release. There can be feedback loops, iterative cycles, spirals or waterfalls, but they all have these steps. When teams “freeze the code” and submit to test, they are creating their own mini-ice age and dooming themselves to extinction.