By Steve Crouch and Mike Jackson.

How to approach a new software-development project, and what to keep in mind

You will find that development of new code and maintenance of existing code is easier if you adopt best practices that have evolved over many years. Exactly how these practices should be implemented will depend on the nature of your project. If you would like help with best practice, the Software Sustainability Institute can advise you on how to proceed.

In general, there are two guiding principles to keep in mind when approaching a new software development project:

• Be aware of your goal
• Be prepared for change

Why write this guide?

We wrote this guide to give an overview of a subject that we think is important to software sustainability.

Defining your goal

First of all, establish your goals. Your goals will have a number of facets, such as functionality, timescale and cost. Through all further planning, keep these goals in mind because it is easy to lose sight of the original plan during a development project. It is fundamentally important that your goals meet the needs of your stakeholders (customers, users, etc.), and the best way of ensuring this is to include them in the goal planning.

Before committing to delivering any functionality, you must establish deadlines and available resources. Prepare an estimate of the work, and if it appears that your goals are too ambitious, you should re-negotiate. There is little point in agreeing to goals that you know will not be completed on time or in budget. Meet again with your stakeholders, prioritise the most important and achieveable requirements and establish new goals. Other requirements that are outside of your plan should be made optional so that you can work on them if time or funds allow.

When preparing your goals, remeber that some requirements will be harder to satisfy than others. When dealing with risky goals, it is a good idea to manage expectations. Tell your stakeholders which goals are risky: if you cannot achieve them, they will better understand, and if you can achieve them, you will gain extra kudos!

Very few projects - if any - get to completion without a change to the goals. Prepare to be flexible and, if possible, try and predict how to goals will change, and the ways in which these changes can be incorporated into your plan.

Getting to the goal

Do not start developing code without a plan. Find out what the stakeholders want and produce a plan that addresses:

• Design
• Implementation
• Testing
• Documentation

Approach your goals iteratively. If possible, deal with the highest priority and highest risk requirements first. Each iteration should be seen as a mini project, and should produce a testable product. Obtain feedback from the stakeholders on the product. Review the goal with your stakeholders, assess wherther you have met the requirements and, if you have, start the next iteration.

Dealing with change

Change is inevitable. When leading a project, flexibility is key to success. There are many different changes that could occur during the lifetime of a project. The most typical are a change in goals due to a change in stakeholder requirements, a decision is made to refactor the code, or a change in resources such as a developer leaving the project. Software systems do not come into existence instantaneously, so expect the the number and contents of files to change as your system is developed.

The best tip for successfully handling changes is to recognise and deal with them early. You are more likely to successfully handle changes if your development process is incremental, you test frequently, and you maintain good contact with your stakeholders.

And finally

Do not forget to think about the end of the project. What will happen after you have met your goals? If you want to achieve sustainability, it is important that you make your software maintainable. For tips on maintainability, read our guide How to develop maintainable software.

Other factors to keep in mind

Consider developing user stories to highlight requirements, and use cases to highlight design. When documenting the code do not forget that diagrams can be useful. UML is useful for describing object-orientated designs.

Exactly how you should implement this advice depends on the nature of your project. There are many different software development methods (a.k.a. methodologies) that give more specific advice that you may find useful.

Further Reading

User stories and use cases:

• User stories versus use cases

Software development methods:

• An introduction to software development methods