Successful Project Completion
29 January 2020 by Chris Woodhams
I have been involved, in one way or another, in delivering software projects for the last 15 years. There have been some successful ones and some not so successful ones. Following some discussions with LabVIEW community colleagues I decided to try and capture the key elements of a project and work out how they are most successfully executed. I am aiming to generate a source of knowledge that can be shared with other people that are involved in completing software projects.
My first effort to gain some insight was at our MLUG meeting in Oct 2019 (see video) where I had a slot to discuss the elements of project delivery. The elements I used for the discussion were as follows;
- Design
- Risk
- Development
- Management
- Documentation
- Commissioning
- Support
Unfortunately we only managed to get through three of the elements, so I need to revisit this at a future event! There was some great interaction from the MLUGers, thanks!
The aim of this post is to summarise that discussion for the Design element of the project, there will be follow up blog posts on the other subjects we covered.
Design is one of the most critical elements of a project and is where the majority of time is spent, not necessarily all in one chunk. There are lots of aspects to design from scope definition and requirements to reviews and testing.
Scope and Requirements Capturing Technique
There were lots of techniques that people shared for capturing the scope and requirements for a project.
- Block Diagram (not a LabVIEW one!) – shows interactions between components and functions within a system, relatively high level, doesn’t go into the detail of functions, just inputs and outputs typically.
- UML State Diagrams – these are used to define the transition between the different states within the project processes. We have used a version of these to define how test sequences work, but it may be more of a hybrid with the Block Diagram.
- User Stories – these were talked about quite a bit during the MLUG session. They are a great way to change the focus from writing requirements to actually discussing them as it forces the designer to write a meaningful sentence about what the function should do. It was also discussed that it provides a good point to return to when additional functionality is requested. A request can be linked to a user story and additional detail added to the story as required.
- Workshop sessions – these were discussed in the context of supporting the writing of proposals, the outputs from which would be used to develop the content of proposals. Face to face sessions around design are critical, whatever approach is taken, design needs to be regularly validated.
Tools to Support Requirement Capture
We had some good discussion on tools for capturing requirements, Requirements Gateway was mentioned, but didn't seem too popular! Excel appears to be quite a dominant tool for this with the addition of bookmarks within the LabVIEW block diagram. There were people using more formal tools such as JIRA, which gives you a comprehensive set of functionality to manage requirements.
Design sign off
We had a good discussion around this with varying approaches to signing off the design. At Argenta our approach is to create a document containing the high level functional design that can then be signed by us and the client. This doesn’t cover the detail of implementation, but does cover e.g. we need to acquire 3 AI signals from a DAQ card with x range and y acquisition rate.
Others in the group were utilising the PO as sign off and other written methods to confirm the design. There were also more formal sign offs that involved a series of stages with each stage having an identified completion gate before progressing to the next stage. Each stage of the process is refining the design and reducing the scope for changes.
Reviews
Reviews form a big part of the progression of a design and can come in many forms as we found in the discussion. Code reviews were common, but done in different ways, some informally through discussions around functionality or architectural decisions. Some sole developers utilised other non-LabVIEW members of the team to review code with. Through discussion of the implementation, even with someone without LabVIEW knowledge can contribute to reviews. In some circumstances it is important to log when code reviews are conducted, a design log is a good way to manage this.
We also touched on functional reviews, which would take place prior to any software being writing and more related to how other aspects of the project would be designed e.g. mechanical or electrical.
There will be a second blog post covering the other two elements of a project that we covered in the October MLUG. I will also be holding a discussion at our MLUG in February to hopefully get through the remaining elements of a project. I would love any feedback or input people have around this topic, the more the merrier!
Back to Blog listings