Process & Tools

Process & Tools

Process

Since my main goals for the project were to apply what I already knew good software engineering practice and to expand my knowledge of new concepts, I put a reasonable amount of consideration into the methodology I would use to complete it. The strict waterfall model of software development has its place, but its not for a small, novel (to me at least) project with just a single person working on it. For this project, an iterative and incremental approach seemed an appealing one. I would set myself strict set of features to implement for a particular release and anything further would be added to a future cycle. In this case, this was the set of features present in the existing implementation. I would iterate on each activity until I felt it was more productive to move onto the next. Once a design version was stable and a matching implementation complete, I would return right back to the initial activity and move through the activities again. Mostly, I wanted to develop my feel for when it was time to finish up an activity and move on to another. I wanted to develop my understanding of the discipline and thinking required to stick to such a scheme. In addition, I wanted to incorporate some other development approaches into the process.

Having studied the UML® system in reasonable depth, I wanted to take the extra step and explore the concept of Model Driven Development (MDD). The appeal of this concept is being able to play around with a design from problem analysis to detailed design without getting too heavily involved in an implementation. The design is fleshed out using graphical and other notation to produce a model of the program that is (theoretically) implementation and language system independent. Theoretically, with the right tools, once the design is stable one can simple generate the skeleton of the program from the model. From there the implementation of all class members is then completed and one should have a fully functional program.

The other main concept of interest I wanted to integrate into the methodolgy used for this project was that of Test Driven Development (TDD). The core principles of this apprach dictate that no functionality is coded until some sort of test for that code has been defined and can be performed.

I found during the course of thinking about process that these two approaches seem to integrate quite smoothly with each other. Of course, the result is quite a heavyweight process that is somewhat at odds with the demands of a relatively small personal project.

One wouldn’t normally bother with such a formal methodology for such a relatively trivial project. The overheads really can’t justify the gains. In this case, the project was really just a vehicle for experimenting with methodology. The actually functionality required by the selected problem was just to add a bit of fun to the experience.

Process & Tools Summary

Process

  • Object-Oriented
  • Iterative & Incremental
  • Model Assisted/Driven Development
  • – The entire static structure of the program was modelled (to varying degrees of detail)
  • – Significant/important desired behaviour was modelled
  • Test Driven Development:
  • – All non-GUI class (including abstract class/interface) definitions were written and completed prior to any functional code being written.
  • – All unit test cases were defined and implemented prior to any functional code being written.
  • – Comprehensive unit tesing of non-GUI code (400+ test ~2x(+) that in assertions)
  • Limited integration testing
  • Ad-Hoc System Testing
  • Comprehensive mocking: All non-GUI classes mocked.
  • Comprehensive code in-line documentation written.
  • – Class definitions documented when first written
  • – Implementation documented during implementation.

Tools

Revision Control: CVS 1.12.13 (Cygwin)
UML Modelling: Visual Paradigm for UML® (Community Edition) 8.2
Language System: C++ (-gnu-C++98)
IDE: Eclipse® (Indigo)
Build Tool: QMake 2.01a
Compiler: GCC (MinGW) 4.4.0
Unit Test Framework: Boost.Test (Boost 1.49)
Mocking Framework: Google C++ Mocking Framework 1.6.0
Code Documentation Comments System: Doxygen 1.6.1 (Cygwin)

Third Party Libraries

  • Qt (4.8.1)
  • Boost (1.49)
Comments are closed.