V4 BCook Reflections
From SoftwarePractice.org
Brendan Cook's Reflections
One of the things that I learnt during this project is the importance of time management and the usefulness of tools to enable a group of people to better manage their time. The use of the wiki to collaborate on documentation and the subversion (svn) repository to track changes to source code allowed multiple developers to be working on the same sections of the project deliverable at the same time, with little to no risk of losing any of either person’s work, and in the case of svn, a built-in tool to merge multiple changes to the same section of code together.
While we found that these tools enabled us to better manage our time within the group, we also found that the initial guidelines that the group had put in place to govern the addition of changes to the subversion repository severely limited the ability of the group to get changes committed and it was annoying for group members to constantly be having to import changes from other branches to update their work with other peoples’. It was eventually decided that these restrictions were unnecessary, and the ability to back out changes using svn was enough to ensure that changes that were broken did not damage our code base.
Through building the executable prototype, we were able to learn a lot about the process of designing a software system; of taking the system from the initial system narrative to generating use cases and user personas through to building conceptual, execution and implementation architectures. I learned about the process of moving from one stage in this development process to the next, and how the components in each architecture relate to the adjoining steps. We encountered a few problems trying to generate our execution and implementation architectures which needed to be resolved as we got further into the development of these architectures, and had to implement more of the solution for milestone 2. The lack of specific testable attributes in the quality narratives made it difficult for us to test whether our solution in milestone 1 actually met the requirements we have generated for it. This meant that we were unable to adequately confirm, even for ourselves, whether the architecture we were attempting to implement was going to be of an acceptable standard to the user personas and associated quality guidelines that we needed to generate. As a group we needed to redefine the way we tried to generate our quality narratives, and to focus on the specific qualities that we felt needed to be expressed by the narratives, and then how the quality attributes would relate to the stakeholder, rather than writing about stakeholders and not generating adequate and testable quality attributes.
The clarification of our quality attributes exposed problems with our architecture that we felt needed to be resolved. The lack of definition previously discussed in the quality attributes meant that our execution architecture did not adequately comply to the real-time performance constraints that were far more crucial to the project than we had initially expected. The execution architecture needed to be updated, and we adopted the filter architecture as part of this. The use of a defined existing architecture was an important move for our group as it guaranteed us a model that would be able to satisfy our performance requirements given adequately written code.
The other major problem that we felt we did not adequately address early enough on in our architecture design was the devolvement of our execution architecture into one resembling the dreaded ‘blob’ pattern. The use of a server to facilitate communication between the processing and analysis modules, input and output channels and the user interfaces meant that the architecture ended up with all of these modules communicating with the server. This was also mostly solved with the use of the filter pattern, as the architecture could be modified so that the server would communicate with the user interfaces, and would launch each ‘connection’ from an input to an output channel as a separate thread with it’s own set of processing and analysis filters and an input and output channel. This managed to greatly reduce the number of components which required communication with the server, getting us away from the ‘blob’ architecture, and into a proper client-server interaction, with the server simply delegating a task to an autonomous subsystem that only needs interrupting when it is no longer required to run at all.
