Spaghetti, Six Students & Sticky Tape

This week our class focused on a broad range of topics from design evaluation, team work, software design and design activity mapping.

Our base reading for the week provided a basic foundation for Design systems in the areas of software and the importance of teamwork in this process. The paragraphs below summarise our reading activities.

Large scale software systems are seen to draw around the basis of the simplest aspect of software development, with focus on the Analysis and Coding stage. Royce, 1970 illustrates that coding and analysis are central to software development no matter what the requirements are for the project in mind. Royce, 1970 goes on to add that the failure of systems to include the testing phase so late has financial, time and customer satisfaction issues due to a failure of the model to allow for repair without costing a lot of time and labour. Royce argues that preliminary work by program designers would allow collaboration between relevant departments. Royce illustrates the importance of project documentation, originality and simulation as a crucial role in software systems. Royce concludes his article by stating that customers need to be included in the development process as they can have an impact on the outputs of the systems produced, by taking their requirements into consideration.

Foote & Yoder 2000, argues that the mainframe architecture that is used by programmers for building software system has become so mainstream, that it has been manipulated, changed and used by nearly all programmers, to now reflect a big ball of mud. The basis of this article focusses on references and comparisons to social settings to portray the architecture under which software systems are based on has grown to mirror. The big ball of mud, which has served its purpose very well, reflects in the authors opinion an elongated mess. The author states that the big ball of mud serves its purpose as software focus on functionality and features, as these characteristics allow for uptake and usability. The big ball of mud can be seen to reflect the uses and the purpose of the entire developer community, as it has been altered and used as a centrepiece of developments.

Sawyer, 2004 provides an oversight on software development teams as been a mirror of a complex socio-technical activity. Interaction is required in all areas of the activity to allow. Sawyer discusses different groups of teams that exist in the arena of software development.  These teams take the form of Group, Network and Sequence guidance. All of which have different characteristics and distinct features. Group Guidance’s- places emphasis on good team working skills. Network guidance place emphasis on evaluation contributions and Sequence guidance places emphasis on task specialisation. Each of these three guidance’s allow insight into the workings of software development teams.

Following on from the topic of team work, our next exercise which focuses on teamwork involved the construction of a cantilever, made up of the following materials, a handful of spaghetti, sticky tape, paper and 6 masters students. The result a 91cm cantilever that took 30 minutes to build. The cantilever project, has one crucial and insightful feature, the researcher. The researcher in this project involved one of our group members taking 5 minutes out from our group project to measure the patters and the stage of planning that our project was at on a design activity graph, a picture is included below. So, as we each spent 5 minutes recording our progress on a graph, we had the opportunity to have an outside view of what was going on, (while remaining silent), how things may be done better and most importantly focusing on the work of the team to provide feedback that could in turn spur the team on. Our Design Activity graph which is included below shows our thinking on each part of the problem as the opinion of our researcher.  Covered the topics of five distinct phases, these included scenario thinking, requirement thinking, high-level thinking, medium-level thinking and low-level thinking. These are the basis of our team design graph.  

Above image of Design Activity Graph

So, following on from or completion of the task we were asked to carry out a debrief of the exercise that had been handed to us. We evaluated a number of topics such as what we could have done better, alternative designs, how we decided to build the structure the way we did and where we got inspiration for our design. This provided huge insight into our success and provided an abundance of information that we could use to carry out the task again.

Who could of thought that you could extend spaghetti 91cm off a table?

Bibliography

Foote, B. & Yoder, J. (2000) Big Ball of Mud. IN HARRISON, N., FOOTE, B. & ROHNERT, H. (Eds.) Pattern languages of program design 4. Addison Wesley

Royce, W.W. (1970) Managing Development of Large Scale Software Systems

Sawyer, S. (2004) Software development teams. Communications of the ACM, 47, 95 - 99.