6.2. Example processes¶
The following sub-sections outline a selection of different processes. Whichever process is chosen, it should be possible to write about it and evaluate it in the Project Report and show to what extent it was followed.
Code and Test¶
This would be the absence of a process where developers simply code and, hopefully, test the work until something emerges. To repeat what is said in the seminars on this module, this is an unsuitable approach for your project. Do not use Code and Test.
Waterfall Model / Plan-driven¶
The Waterfall Model [1] is a classic approach to software engineering that follows steps to carefully analyse a problem, develop a design before moving to implementation and then testing. Several documents are produced as a natural part of this work.
If this approached is used, there would be:
A Requirements Specification.
Prototypes of some areas to explore issues that are not understood.
A Design Specification, showing links to the set of requirements.
A Testing Specification and Test Plan, showing links to the design elements.
A Plan for how the work will be structured, which might include Gantt charts to specify the dependencies of tasks and identify the milestones.
You would submit these documents as part of your Work. It would also be expected that a supervisor sees these documents during the project.
This is sometimes referred to as ‘plan-driven’, a term used by the Agile community to differentiate itself from approaches such as the Waterfall model.
Spiral Model¶
The Spiral Model [2] is another of the classic Software Engineering processes, that looks at a way to reduce the risk of software development. This attempts to reduce risk by a set of iterations that aim to understand the problem in more detail. It goes through distinct phases which form a spiral as the project adds detail and move towards final development.
Whether there is time to follow this process on a project is open to question.
One interesting idea from the Spiral Model would be that of managing the risks. Exploring areas of risk and trying to minimise them by working on those areas.
Agile¶
This is a general term for several different processes. If a project is using an Agile approach, it should be possible to explain what ‘flavour’ of agile is being used and why. A few typical agile processes are listed in the following sections. They are all group based activities, so you need to consider how these are adapted to work for a single person project.
The key thing to watch out for is that Agile isn’t used as an excuse for no process and just writing code. If an agile process is followed, the minimum it should cover is:
how functionality and associated tasks are identified and how decisions are made on the order of working on those tasks (planning);
how decisions are taken on how to structure the system (design);
how implementation and testing is undertaken;
what elements of review are used to manage the process.
Extreme Programming (XP)¶
If it is important - do it often. This is a key idea behind the use of Extreme Programming [3] . The elements of project planning, analysis, requirements, design planning, implementation and testing are all present, but done in small sections and repeated with increasingly sophisticated software being developed that meets the user’s requirements.
Requirements are represented as stories rather than a detailed specification. Each story is probably written on a card, but this might also be an online tool such as Trello [8] or issues in GitLab. With the story, there should be early thought about what it means to test that the story is complete - which is considering the acceptance tests.
The work is completed in iterations. This represents the heartbeat of the project. An iteration should start with planning what will be done in the iteration and identifying the design. Next, there is development which involves more detailed design, implementation and testing, working in parallel. At the end of the iteration, there is a review of the work produced before starting the next iteration.
If the process is based on XP, then the following should be explained:
What length of iteration will be used? For a project of this length, that should be one or two weeks. Any longer and you aren’t getting regular feedback on progress. One week is probably better for projects on this module.
An individual project won’t use Pair Programming, so there isn’t on-going code-review. How could the student compensate for this?
Will TDD be used? If not, what is the approach to testing? How will that work with the iterations?
When will the iterations run? Is it Monday to Friday? Some teams talk about running Wednesday to Tuesday. Would that work better for MMP?
What level of detail will be used for the release planning? Will there just be one release for the project? That might be practical for a project of this length. How many iterations will there be in the release and what will be done in each iteration?
How will they record requirements, project planning and design decisions so that they be discussed in the Project Report?
Feature-driven development (FDD)¶
FDD [4] could be considered as a “plan-driven” approach and it incorporates elements that we might think of as agile. There is more up-front project planning and some early design.
However, aspects of the design are deferred until later in iterations. The more important features are typically in earlier iterations.
Some students like this approach because it has an amount of up-front planning and design. They also like the iterations rather than the longer period of development in a waterfall-style process.
The project starts by analysis of the problem and generating a model for the data in the system, as a UML diagram. The next step is to specify a set of features for the system. This is followed by a plan about which features will be developed and when they will be scheduled.
Following these setup steps, the development is done in iterations. These involve taking a set of features and working through more detailed design and then implementation and testing. As the iterations proceed, the additional design will enhance the overall model.
If this process is being followed, the following points should form part of the work:
Development of the overall model early in development.
Identification of a feature list and estimates on the time for these features.
A period of planning to decide how these features will be arranged and implemented. The iterations do not have to be the same length, unlike the practice in XP and Scrum.
Demonstration of iterations which do more detailed design for the features and then implementation and testing of those features.
What enhancements are made to the overall model as the iterations proceed?
Are adjustments necessary for the plan during the project? If so, how are they managed?
Note
In previous years, FDD was discussed in the module about Agile Development. It was removed to make space for other content. These notes have been included because FDD may be of interest to some of you as a possible basis for organising your work.
The original material for FDD was hosted by a company called Nebulon. The original links appear to have stopped working in the past year. The reference for FDD, included above, now refers to a Wikipedia page.
Scrum¶
Scrum [5] is a popular approach to software development. It is a more general process to manage projects, and it does not specifically mention software development in its description.
Unlike XP, it doesn’t have specified development practices. For example, a team could choose to use TDD as part of Scrum, or the team might choose an alternative approach to testing.
If this process is being used, the following points should be considered:
Is there a Product Owner? If so, who is it? If not, who will guide the decisions on what should be developed in each Sprint?
How long will a Sprint be? For a project of this length, one or two weeks would be better.
How long will be used for Sprint planning?
How will the product and sprint backlogs be visualised?
Will a tool be used to help with managing the list of stories? For example, Trello and GitLab issues have been used by students in the past. Would that help to manage the tasks in the backlog and assign the tasks to sprints?
What approach will be used for testing in each Sprint?
Will there be a daily stand-up meeting? Whilst this is an individual project, could a few students meet each day to have a daily stand-up meeting as they get ready to work on their project? A student would talk about their work so there would not be shared discussion about one project. However, it can be a source of mutual support. If there isn’t a daily stand-up meeting, is there something else that can be substituted?
Kanban¶
Kanban [6] is really about improving an existing process, and therefore doesn’t look like a full process or methodology. The focus is on visualising the work to be done and reducing the amount of work in progress at one time.
A Kanban board is used to visualise the process. This is often attractive to students, but it can be confused for just having a board that shows the work in progress. Boards that visualise a set of tasks are also used with XP and Scrum, but they are not used in the same way as Kanban would encourage.
Kanban, as described by David Anderson, looks to control the amount of work that is considered as “in-progress”. This chooses to pull work into the process when there is capacity in the team to work on new tasks. Also, if there is a build-up of work at particular stages, the team ‘swarms’ to clear the blockage. Only when there aren’t blockages will new work be called into the workflow. This is different from having iterations. Techniques like Scrum and XP are more about pushing an appropriate amount of work into sprints/iterations.
If Kanban is used, then it should be possible to explain how this is more than just having a list of tasks shown on the board. How does Kanban help you to determine what is worked on now and what is to be done next? How does the process lead to successful completion of a set of features? How are delays handled? Where does design fit? What about testing?
There may be a useful process here for a Major/Minor project, but make sure that this is more than just having a board. If it is only the board that is attractive, it is suggested that another process is more useful. For example, XP can have task boards to coordinate work within an iteration and Scrum has burndown charts to visualise progress.
Test-driven Development¶
In the past, some students have said that they are using TDD [7] as the process. Quite simply, it isn’t a process and this will be said in the MMP lectures. Instead, TDD is a practice that originated from XP. The main motivation for saying that it isn’t a process is that there is no notion of deciding what tasks to do and how to sequence the work - i.e. there isn’t any project planning.
Some students might find TDD useful, whereas others might find it a hindrance and prefer doing testing in a different way.
If adopting TDD, this means an iterative approach to writing tests before writing the implementation. A test is written that should fail because there is no code that already implements the feature. This confirms that the test can identify a failure. The corresponding implementation is added to pass the tests. The test is run again, with all other tests, and the test should pass. There may then be some refactoring if there are obvious ways to improve the design. Then, onto the next test.
Kent Beck, one of the people responsible for TDD, has noted that it is a design technique that helps teams to think through the detailed aspects of the design as features are implemented. On its own, it starts to sound like Code and Test. With other supporting practices in XP, it works as part of a methodology.
TDD may be valid within your project, but as part of a wider process.
Research Process¶
If your project has a research question, your supervisor will guide you with a process that is appropriate for the research issues.
In addition to research issues, you do need to identify and follow a recognisable process regarding the software that is created.
A good observation is that research systems will have code that might yet go on to have a life beyond the original project. So, a responsible approach development on this type of project should manage the software aspects so that it could be handed over to other people.
If you aren’t sure what to choose…¶
It is possible to adapt most of the above processes to be suitable to guide the work to some useful level, except for Code and Test (don’t use) and TDD (not a full process). If you are not sure which process is suitable, then consider one of the following:
FDD
Scrum
FDD¶
If you prefer more up-front planning, FDD could be a reasonable starting point. Think about what would be different if running a single-person project. FDD has multiple roles, so consider which ones are really necessary and how that would be managed on a single person project.
Scrum¶
Alternatively, look at Scrum and think about changes for using it on the MPP. The following paragraphs give one possibility.
At the start, establish a set of stories (a set of things that the software should do). These might be written out on cards or in a free online tool such as easybacklog.com or trello.com. Have a way to manage the tasks.
Take time to make reasonable estimates for each story - try relative sizing of these, e.g. identifying small, medium and large tasks. How many of these might fit in the week of work? If these are too big, split up the stories so that you can make reasonable estimates. If you can’t decide - do you need to do a bit of investigation to find out how challenging things might be?
Choose one-week sprints. Perhaps set the start of the sprint to be the day before your meeting with the supervisor. On that first day, spend an hour or two planning what items from the backlog you will do for the next week. Which are the most relevant to make progress. Select items from the backlog. Have in mind how this fits with what you think might happen in later iterations. In this way, you will have a plan of things that you will work on and can discuss that with your supervisor.
Do the work. At the end of the sprint, allow an hour or so to review what has been achieved. Did you achieve everything? If not, look at why not? Move on to the next sprint.
If things are taking longer than you plan, and they probably will, look at what are the most important stories to work on. Discussions with your supervisor will probably help.
