Remember that the program code is a necessary but not a sufficient deliverable if there is a need to understand decisions taken. Documentation adds to your explanation. However the main purpose of software development is to produce quality software and documentation should serve that purpose. The approach taken to software development, the problem being addressed, contractual obligations and other factors will determine how much to document and what to document.
Keeping a project notebook is a disciplined approach to organising your thoughts and actions as a software developer. Your project notebook is a record of notes, thoughts, drawings, ideas and decisions (and the reasons for taking those decisions) as you work on a project. In its simplest form a project notebook will be paper based, but it could be recorded in files on a personal computer.
For it to be effective, you should keep your project notebook with you at all times, so that you can use it, save it and review it. There is no limit to what you can record in the notebook. For example, you can note down what your users say about their needs, make some preliminary sketches of models or even record telephone numbers and URIs that may be useful while at work.
Whatever you record, you should date-stamp your notes, and review them on a regular basis to ensure that your questions have been addressed and that you have extracted the information that is useful on a given project. You must keep accurate dates and times for the information recorded in your notebook for the following three reasons (all of which relate to traceability):
Allow approximately 30 minutes.
What are the main problems associated with the development of software? You should be able to identify at least six.
Here is our list of problems that affect software development (you may have identified others):
Process models sometimes show only the software-creation activities and exclude software maintenance. What problems are associated with the use of such models?
If maintenance is not mentioned, it is likely that it will not be considered to be an integral part of the overall software process model. This may result in a design that does not take the needs of maintenance into account, and hence a product that is difficult and expensive to change. This is especially likely if time and/or budget are already tight.
What kinds of software system would be best suited to an iterative and incremental development process?
Software systems where the problem can grow incrementally or where it falls naturally into partitions, each of which represents a fairly self-contained unit that could be developed and delivered on its own to provide the users with a useful chunk of functionality, would be well suited to this model. An iterative and incremental approach allows several design issues to be tackled simultaneously and enables the system to be implemented in relatively small steps in order to contain the complexity. Of course, this assumes that the design can be partitioned.
Figure 8 shows a spiral process for software development. Into which quadrant of that figure does each of the seven technical activities of Figure 5 fit? Notice that there is not a one-to-one match.
The analysis, design, implementation and testing activities all fit into the ‘develop and verify a (partial) solution or product’ segment. The analysis activity also overlaps the evaluation quadrant where objectives and risks are analysed. The testing activity overlaps the ‘review and plan’ quadrant. The maintenance, project management and quality management activities (including configuration management) operate in all four quadrants.
It has been said that ‘the maintenance activity begins with the first deliverable of a development project’. What does this imply about the maintenance activity?
This refers to the fact that there could be deliverables, such as requirements documents, that exist prior to any software being built, and these also require maintenance. For example, you might detect errors or inconsistencies in a document that lists the important terms in your users’ domain, or you might have to respond to changes in the environment, which may be due to new regulations or market forces.
OpenLearn - Approaches to software development Except for third party materials and otherwise, this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 Licence, full copyright detail can be found in the acknowledgements section. Please see full copyright statement for details.