FDD :: The Hydra Experience
[Introduction]
The project was an industry based final year Software Engineering project for Melbourne University Engineering students. The team was made up of 16 students working full time for the university year (approximately 8 months), and aptly named "Hydra". Our client was the CRC for Hydrology, run by CSIRO Land and Water.
The purpose of this discussion was to identify where FDD worked and what we learnt from the project. I've left the project specifics out, but the system we built was an distributed environmental simulation framework (not a typical Line of Business application).
[Discussion]
Problem domain decomposition and modelling process
- Domain modelling process of decomposition, modelling and stepwise refinement was very effective.
- Collaborative design by breaking the modelling team into sub-teams to develop object models then regularly re-synching to produce a team model that was agreed upon by all. This was a lot more effective than conducting modelling by allocating parts of the domain to different team members and reviewing their outputs.
- Does require a good knowledge of UML and object modelling practices. Training was required for those with little experience but generally having stronger team members distributed across the different sub teams allowed the teams to function effectively (and weaker skilled members were able to learn quickly).
Regular delivery of client valued functionality (features)
- We didn?t utilize the real benefits of regular delivery of functionality to the client. Becoming used to regular interaction with the client (and progress updates or informal demonstrations) required a cultural change for both the project team and client alike. The tendency was to wait for large chunks of functionality, or wait for the next few features to come along before updating the client with the progress or demonstration.
- Essentially we didn?t leveraging the visibility of progress that FDD enables, because the concept was new to us. Post implementation, however, we all realised the potential benefits of the visibility.
- Regular (daily) automated build and test (integration and unit regression tests) were very effective. We utilized ANT and JUnit to automate the regular build and regression testing cycles.
- Automated deployment tools would have been useful, in addition to our automated build and test tool suites.
Effective process and methodology is still dependant on the quality of people
- People need to have a solid understanding of what quality is and means to the project. They need to be committed and use initiative for an agile (or any) methodology to be successful.
- Quality should underpin all of the processes used in the project. Heavyweight processes for the sake of processes is against the purpose of agile methodologies.
Risk management is still a key concern
- Need effective risk management processes and risk identification and mitigation must be visible. We were less effective in this area as often identification was made, but the management and mitigation of risks was isolated (no collaboration with those impacted by the risk) or became low priority and were forgotten (usually due to resource constraints).
Documentation should not drive the project but cannot be forgotten
- We at times became document driven rather than product driven.
- We followed IEEE document templates for all of the formal project documentation. A problem with this approach was that we followed the guidelines to literally to the point where the documentation was not really applicable and added very little value.
- Full IEEE adherence was too heavy we found, but if you follow their recommendations you don?t have to directly follow the templates beyond the sections and subsections.
- FDD doesn?t dictate any specific documents that should be produced, but this doesn?t mean they aren?t required! Determine what is necessary to capture the project knowledge. Documents we produced included SQAP, SPMP, SRS, SADD, SDD, SRMP, SCMP, SVVP. Whether this was too much is debatable but it depends on the project. While we created all from scratch some can be re-used in future projects (such as the process documents SPMP, SRMP/RMMMP, SCMP, elements of SQAP)
- Documentation of the object model and code was utilized document generation tools such as JavaDocs and the TogetherSoft modelling tool. Object model was documented in the tool (TogetherSoft) that could generate HTML snapshots for reference purposes.
- The object model view in TogetherSoft was synchronised with the actual code, so there was no effort in updating a model as the implementation code changed; it was always in synch. This allowed accurate implementation model documentation to be generated at will and stored in a readily accessible location (we uploaded to the team website).
Importance of domain modelling involving the development team and domain experts
- Domain modelling was the best way we found to truly understand what the system had to deliver (requirements). It was much more effective than standard requirements analysis and specification. We conducted requirements analysis prior to domain modelling but they should really be performed closely together, once a level of system scope is understood.
- The other important benefit of this process is ensuring that the development team (including designers/architects) understand the domain fully. Because domain experts are involved in the modelling with those who are going to design and build the system it produces a common domain understanding and domain knowledge transfer.
- Those who were part of the domain modelling can then transfer their knowledge to the rest of the development team during the design/build processes.
Involvement of the Chief Architect during Design and Build processes (FDD processes 4 and 5)
- While an overall model, and high level conceptual architecture is developed prior to the design and build processes in FDD, the chief architect must still be heavily involved throughout the implementation. Design decisions and overall model changes can occur in every feature design. These are usually simply adding detail to the model but sometimes are shape (relationship) changes. These decisions and changes must be reviewed and coordinated through the architect as to ensure the will both work and fit with the overall system.
- Design inspections are part of where this takes place primarily, but the important point is that the chief architect must be involved in all of the design decisions during detailed design and build.
[Conclusion]
FDD was the first agile methodology that most of our team had undertaken. There was a learning curve as we determined how to fit FDD to the full SDLC. The best approach was to consult with people that have experience with FDD projects to ensure we were on the right track. While out specific project had a very technical focus, being a simulation framework, the benefits of FDD to a line of business type application were realised. Consistent granular delivery of client valued functionality, ?real? progress reporting and increased quality through the use of the industry best practices that are the foundations of the FDD processes.
