V4 MHigham Reflections
From SoftwarePractice.org
Matthew Higham's Reflections
My learning experiences for Software Architecture have been valuable, and thought provoking. So far in all software design tasks I have had to undertake, not much thought was given to the architecture of said software. Usually, I would begin writing the software and then figure out how to join all the modules together later. This subject has forced me to look at the architecture before even starting the development.
Starting out with a system narrative, we were able to derive key stakeholders and matched their needs to capabilities found within the narrative. We then went about identifying who these stakeholders actually were by developing personas which were captured in narratives. I found this exercise almost enjoyable as I tried to envision myself as the stakeholder and come up with situations in which the system interacted with them. One area, in which we glossed over, quality attribute narratives, ended up being detrimental to our original designs, as flaws which should have been exposed were not. When we finally fixed these quality attributes, we were able to better understand the needs of the system and change our architecture appropriately.
I learnt about the creation of architectures, and their importance in designing a system. The methods in which you design the architecture, as well as ways to test the feasibility of the architecture were passed on to me, and were utilised during the project. Using use-case maps to diagrammatically display system behaviour was extremely important when trying to test a system against the desired outcomes. These diagrams also allowed a better understanding of how the system should work in different circumstances, making the code considerably easier to write.
In terms of the design process, we needed to constantly update our architecture for the entire duration of the project. Whenever a new feature or component was found to be required due to analysis of stakeholders and narratives, then this was reflected in the architecture. Another important factor in the continual improvement of our architectural design was the lessons learnt from creating the two prototypes. One of the major outcomes of the first prototype was the inclusion of a pipe-and-flow architectural pattern in part of our architecture. This enabled us to realise the real-time requirements in the architecture. Also, we were able to move further away from a ‘blob’ pattern which appeared by accident in our initial architecture.
Time management is an important factor for me. With my first two years of university, my time management skills were appalling. Consequently, my results from those first three semesters were a credit average. During my work experience, I learnt the importance of time management. This lead to better performance and a high distinction average last semester. I have taken these skills and further refined them this semester, and this subject has enabled this further refinement. I organised the group to start working on sections of the milestones as early as possible. After deciding on who should write which sections, I then wrote my sections and had completed those well before the agreed deadline. This gave me plenty of time to complete any other tasks that were required.
Collaborative social interaction was an important factor during the course of this subject. As these assignments were in a group format, being able to work effectively with the given team was essential. We found it easiest if we worked on major areas, such as creating the conceptual architecture, as a group. However, in other areas we found that it was more efficient to do the work individually, and have the other team members review the work. The use of collaboration tools (such as SVN and the wiki) allowed multiple team members to edit sections of work at the same time. This was invaluable, as other methods could result in work overlap, and therefore time wasted on waiting, or doing work already being done by someone else.
