Charles Edwards

Software re-use is a worthy and noble ideal to aim for during any development, but why not let's take a bigger picture view of the whole software development environment. Make the goal to set up our process so that as much as possible is re-used on subsequent projects. Here are some thoughts on achieving this.

What’s happened to the links between requirements and tests? How do we know what to test and when? How do we, and the customers, know we got the system being built right? What’s the traceability between the two disciplines?

Although we usually think of configuration management in the context of a software development project, CM also exists in the context of an enterprise. I wondered if taking the twenty principles used for an enterprise architecture framework, we could see just how well configuration management stands up to supporting these general architectural principles in an enterprise context.

There is an age old debate about who's responsible for quality in software. Some people have quality teams, others dedicate quality to testing.

A vendor left me a phone message. He began by thanking me for visiting his booth at a conference at which I was a speaker. He told me that his product was just what I needed and would solve some of my biggest problems. He also assured me that I would benefit in many ways. Finally, he then asked if I would call him back so we could continue the conversation

Software process is becoming more and more important in SCM. Gone are the days of simple configuration managing the source code and software release builds. Now we need to manage versions of the UML models, versions of the requirements, versions of the tests, versions of the iteration plans and be able to create integration streams for all the different disciplines too. Requirement analysts should be able to work on a branch of a use case model, testers should be able to work on a branch of their test model, etc. At the end of an iteration, all of this should be brought together and released as an iteration release, for the process to be properly controlled.

Don't you find it confusing when you go from one company to another and find all sorts of different names for similar roles people play in the IT software development process? I have had heated debates with people only to find we were in violent agreement and it was the use of different terminology that was causing the incorrect interpretation, because we were ultimately both trying to say the same thing. This doesn't only happen with roles and activities on projects but with many different terminologies meaning the same thing!

While many people intuitively feel that we should integrate the development tools we use in our software development environment to better manage the development team, the task of actually doing so can sometimes be as big if not bigger than the software project we are trying to develop. It's hard enough trying to implement individual software development tools while you are in the throes of building software, let alone get multiple sets of these tools to start synchronizing and talking to one another.

Enterprise application integration (EAI) is problem many large organizations facie today. With the emphasis on the integration part of the applications within the enterprise, more recently made even more complex by integrating applications outside of the enterprise. There are business engineering approaches can alleviate many of these problems and have in particular organizations.

Chances are, we have probably all experienced nightmare release procedures. Put it this way, you’d be very fortunate if you hadn’t!  As projects mature, release procedures tend to get better, sometimes far too late in the life cycle of the project, though. The trick is to aim for getting the release management working as early as possible, ideally sometime in the Inception phase. The earlier the release management works, the more stable the architecture will tend to be. Let’s take a look at release managing a “Hello World” candidate architecture as an example of a starting point for the project release management.

Requirements do not equal use cases or UML diagrams only. Use cases are a sub-set of doing requirements. There are also more ways of modeling than just using UML. Obviously it depends on the size of the project you are working on that will dictate exactly what your process will need to create. Let’s look at the bigger team size project and explore in simple terms what we should be doing for requirements and how this interfaces to the rest of the team’s activities.

Software re-use is a worthy and noble ideal to aim for during any development, but why not let’s take a bigger picture view of the whole software development environment. Make the goal to set up our process so that as much as possible is re-used on subsequent projects. Here are some thoughts on achieving this.