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.

Comments

Post a Comment

Popular posts from this blog

Systems, systems, systems!

This blog series based on as a series of journal entries will showcase the learning path of a MSc Digital Innovation student. The purpose of the series is to showcase the evolution of knowledge, skills and practices that have been obtained throughout the duration of the module on Design, Development and Creativity. In this week's entry, We will explore the initial thoughts of the areas of systems, showcase my development and the change in my knowledge of the area. So firstly our first exercise of the academic year was to provide the class with what we thought was a system. My response was as a follows, ‘My definition of a system is a network of institutions and processes that are governed by laws that in turn provide a benefit’. So after been asked to define a system, my first idea based on my working experience was to think of a crucial area of society such as the banking sector as a system.The banking sector which provides numerous services to society, have the following inpu...
Read more

Requirements

In this week’s class we looked at the importance of requirements through a practical and theoretical setting. As discussed briefly in my last post Life Cycles: The cycles of life? we explored very briefly the importance of specifications, which are a base of requirements. Requirements are comprised of scope, purpose and a description that will allow the user/client to carry out the specific task that they need address/completed by the product/software programme. The requirements will generally set out the limits and simplifications that are required from the finished product. Requirements will generally consist of goals and scenarios that are required by the finished product and developers are obliged to meet these. The requirements will also look at the risks and deadlines that are a part of the development process. Deadlines are an important aspect as they outline when the product is required and also can determine the cost of the project. It is especially undesirable if the...
Read more