First steps in a new software project

This week I started a brand new project. This time it’s the start of product development, rather than just an internal project to get something running. And it really is new, so everyone is new and we’re setting up everything from scratch.
So this is my list of things to go from nothing to a fully fledged software engineering project.

Step one, getting the right tools installed for everyone off the bat makes things easier later on. Standardise upfront rather than try to merge half a dozen separate ideas about whats best later.
For this team we will be testing a GUI so Rational Functional Tester (RFT) with Rational Team Concert (RTC) is the basic tool set.

This gives us all the project management tools in RTC, plus source control, and easy collaboration. Then when we get as far as something to test RFT will already be there.

RTC is the best tool I’ve used for starting projects, it lets you start capturing requirements and high level ‘stories’ and start hanging individual tasks off of them. Code sharing is very easy, and delivering code changes under tasks makes the project tracking pretty seamless.

Step two, a build server. It’s easy to link into RTC to have a build engine that allows you to schedule builds as frequently as you like. It also allows people to kick off builds of the mainline code plus their ‘local’ changes. So you can build and unit test changes before delivering them to the main codebase. The outline of this can be set up quickly, the detail of full build and kicking off unit tests takes longer but is a top priority.

Step three is a Rational Quality Manager (RQM) server. This can be linked to the RTC server so that it gets notified when builds complete and also allows you to create defects in RTC if tests fail. RTC can then view defects which block test cases. RQM lets you define what environments you will test in, how you will split things into test plans. And makes it easy to start defining test cases and where they will run. Ultimately it can be used to report on test status, with built in dashboards and report generation.

The last step are some test servers which run adapters which connect to the RQM server. For our needs some of these will use a command line adapter, others will use RFT. This allows RQM to kick off tests against the systems and gather the results.

As a set of tools they are not light weight. Requiring at least 4 servers (RTC, RQM, build, test) but then they are a very powerful combination. I don’t expect to have any spreadsheets or hand-crafted chart generation being done by the team. All of the information we require comes straight from the tools, when we report project status we will use the tools not hand-made slides or spreadsheets. I also expect to be able to get tests automated and managed from the start. So no trying to retro-fit automation onto manual tests.

After one week we have RTC setup with the first wave of requirements stories and tasks, and a code base setup with components for our new product. We have an RQM connected and being told about builds. We have the skeleton of a build system. It’s not doing much other than defining the build types we will have, but the framework is in place.

Next week I’ll setup my first test server. Hopefully in a very short space of time we will have everything we need to develop and test a product. Complete with project tracking and reporting, all while most of the team are focussed on what we will produce, not tied up with figuring out infastructure.