Software product success.
Seriously.
There’s a crazy deal being offered by Axosoft. Buy a 5-user version of their $500 software suite for $5, but the offer expires February 24th. The link to buy the software is here – and only available on blogs. Axosoft is trying a social marketing experiment to see if they can promote their products and brand via the blog universe. It isn’t clear at what hour the offer expires, so you might want to get it on the 23rd.
Should we test our software? Should we test it more?
The answer to the first question is almost invariably yes. The answer to the second question is usually “I don’t know.”
We write a lot about the importance of testing. We have several other posts in our series on software testing. How do we know when we should do more automated testing?
We’ve presented an example of the software development process across several posts over the last two weeks. In this post we tie them all together, showing the steps in process order.
The Lost Garden has an outstanding post by Danc – Software Development’s Evolution towards Product Design.
Danc writes about how the software development process has evolved over the years. He characterizes this evolution in four distinct phases.
Background:
In our previous post, Sample use case examples, we created two informal use cases. The use cases were written to support product requirements defined as part of a project to reduce test suite maintenace costs. In this post, we will define functional requirements that support these use cases. This process is an example of using structured requirements, applied to a small real world project.
We talked about informal use cases a while ago in our use case series. Over a series of posts, we are demonstrating the process of defining a software product. The next step, and subject of this post, is the creation of informal use cases to support the defined goals for the software.
This post is a follow-up to our previous case study on incorporating unit testing into an existing team’s development environment. The case study is based on a real solution that has already started reaping rewards for our client, and is gaining momentum. We’re now looking at making it easier for the development team to maintain this test suite, and proposing some extensions – including a form of tagging.
In the Foundation series article on software processes we introduce a definition of software process as three steps – (decide, develop, deliver). That article will provide some contextfor this discussion, which dives more deeply into the three steps (decide, develop, deliver).
One of the key points that enables James’ approach is “tight collaboration†between the program manager and the developers. He talks about the miracles that can happen when you have this, as conversations can cause time to miraculously appear in the schedule. And his use of the toaster analogy is spot on.