Adopting a Software Development Process
There are many flavours of software development process, and different ones suit different organisations. This is where we can help - we have many years' experience in DSDM, RAD, JAD, RUP, OPEN, OOSP and enabling companies to choose, tailor and implement the right process for them.
RUP is currently a popular approach to software development. We have successfully implemented RUP in a number of companies, but have usually found we need to tailor the process and include elements of for example, OPEN, OOSP, Agile Modelling, Crystal and Scrum to meet requirements which cannot be met by RUP.
Are you thinking of tailoring RUP for your organisation and looking for help ? Please phone us on
We also help clients roll their own processes. Commonly, clients may already have a process or procedures in place, elements of which they may want to include in the process they now want to adopt.
We can enable you to develop your own bespoke process that will be used and will deliver. Perhaps you would like to discuss your specific requirements - then please phone us on
Over the years we have spent in software development, we have evolved our own process - Fractal - which we have easily adapted to many clients´ different requirements. Fractal takes a pragmatic approach, but is based on standard technologies and best practice. As such, Fractal, has proved of great benefit to clients who realise they need to adopt a software development process, but also have on-going project deadlines, which they cannot afford to let slip.
Whatever you choose, it is crucial to the success of adopting a software development process that your individual requirements are clearly understood and agreed up front. So the first stage in our approach is to help you define and agree these requirements, against which we can then identify and/or tailor a process to suit your needs. Once your tailored process is agreed, then we can help you implement it and start using it in anger.
Ensuring management buy-in and visible support is also fundamental. We typically establish a direct relationship with senior management, presenting an high-level view of our approach to gain their support, so they can actively promote the project from the top. Several members of our team are experienced at presenting at board level to obtain management buy-in, both financial and technical. We have also found it valuable to maintain visibility to senior management, so at the start of the project we arrange short feedback presentations to coincide with sign-off at the end of each stage of our approach.
Defining the Requirements
How the requirements are arrived at depends upon the culture of the organisation concerned and any processes for providing requirements the organisation may already have in place. Needless to say we encourage as much involvement as possible in the requirements gathering, from senior management to developer.
Our requirements gathering has matured from our own experience and published good process-tailoring practice. The kinds of requirements we look at include :
The approach we take to requirements gathering draws strongly on our elicitation skills and is now optimised for use with various types of organisation so it is a very rapid process. The output from the requirements gathering is documented, circulated to all involved parties for modification, any necessary changes made and then presented to senior management for sign-off.
Meeting the Requirements
We then use the agreed requirements to produce a tailored process that can be used for all future projects, providing uniform deliverables and check points, independent of the nature of the project, but flexible enough to change from being a light-weight to heavy-weight process in a repeatable manner, if required.
During this stage of our approach it is important to have the involvement of any personnel who support existing organisational practices, processes, environments, projects, systems etc that need to be migrated or maintained.
Our output from this stage of the approach is an outline of the tailored process and includes a prioritised delivery plan of the implementation based on the requirements. Once again the deliverable document from this part of our approach is circulated to all involved parties for modification, any necessary changes made and then presented to senior management for sign-off.
An incremental approach, based on the requirements is taken to delivery of the tailored process. If appropriate any tool evaluations should be in place as this part of the approach commences. This ensures that we can test against the relevant tools as we go. As each increment is initiated, more detail will be added, establishing the roles required, ownership of the relevant parts of the tailored process, training and support. Every increment requires testing. Documentation is kept to a minimum, but sufficient to meet the individual organisation's requirements and is written with each increment. Our experience has shown that processes that continue to be used are those which are very much alive. Good training and mentoring with focus on delivery is of far greater value to the people who are going to use the process than large amounts of documentation.
Our recommendation is that the increment testing is based on something real and that some initial projects are identified as the process is implemented. This way the process is kick-started and will get off to an immediate start - the sooner it is used, the sooner it will be accepted and therefore reused, preventing it from becoming shelfware.
The deliverables from this part of the approach will be a documented process tailored for the particular organisation and transfer of the process to the organisation's own staff, enabling them to immediately use the implemented process.