Skip to main content

Week 4 Lecture


Introduction

During this lecture, we discussed different methods for software development including waterfall and Agile. Waterfall is a rigid way to approach software development. It can be beneficial to projects where there are little to no unknown factors as it is a rigid, structured and organized process

Releasing iteratively is a useful way to approach software development projects when there is an element of uncertainty. It allows for feedback and changes throughout the development lifecycle. 



Required Readings
During the lecture, we reflected in small groups on the readings. A reading which stood out for me this week was the Brooks "No Silver Bullet" paper. I enjoyed the metaphor of the werewolf which was used to describe the complexities associated with SDLC which teams don't envision from the onset of the project.

The paper stresses that investing in good developers is far more important than attempting to find a solution or a "silver bullet".

SDLC projects are so complex, more so than constructing bridges or other physical objects due to the fact that software is much more complex than physical material. You cannot see it, there are many people simultaneously working on different pieces of it etc. Software is inherently complex because it is non-visible.

The papers discusses user driven programming - high level language where the computer does all the rest. Examples of such languages include SQL, C++ etc. Queries enable us to interact with software 





The additional readings for this week focused around objectives v requirements, involving people early to set their sights on the overall goals of the project, visualising what you will create and learning as you go


  

Even though these articles are quite dated, the frustrations still remain today




Discussion During Lecture

A lifecycle is a way of structuring a project. The waterfall model is rigid in that requirements are made at the beginning of the project and cannot be changed during the subsequent stages. Agile however, is like lots of little waterfalls where the team and stakeholders can analyse the project and assess whether fixes need to be made or additional features introduced. Despite my initial view that a business would either choose Agile or Waterfall, The lecturer discussed that most firms are not agile or waterfall, its more "in house", local rules apply.

The lecture also contradicted my previous view that new companies adopt agile type methodologies and only older, established companies would adopt agile. To me, agile seemed like the ideal way to approach the SDLC as I had never considered the need for stabilisation and the fact that waterfall can reduce in lower costs and faster development life cycles.

Finally, we discussed constraints associated with the SDLC. These include:
  • Quality
  • Scope
  • Time
  • Cost


Within Software Development Lifecycle's quality, cost and time are variables which need to be managed whereas scope is usually stabilised pretty early on. An example of scope include requirements.




Comments

Popular posts from this blog

Research Essay

A major assessment component for the Design, Development and Creativity module was conducting a research essay which involved working individually or in pairs. Myself and my partner, Beth conducted our research essay on updating a digital product, the UCD student portal through the introduction of a digital collaboration tool as a core offering for all students studying at the University. This essay involved conducting both primary and secondary research. In terms of primary research, we conducted a questionnaire, interviews and observational research to understand how students currently interact with the UCD student portal and how it can be improved. Once we understood the problems associated with blackboard and how it could be updated by making it a more engaging site, we conducted secondary research, studying existing literature and case studies on the topics of collaboration and utilising collaborative tools. Upon decision on the update required, a usability, requi

The Soul of a New Machine

I thoroughly enjoyed reading Tracy Kidder’s, The Soul of a New Machine, particularly as it tied many concepts discussed during the module together. Topics and themes which stood out for me were Management and the Importance of hard work. The management style visible in the Eagle project was Mushroom Management. That is, management appeared almost absent. The “kids” were given a general idea of work expected of them and then they were expected to complete the work independently. No one knew who to go to and any issues that occurred between the “microkids” and the “hardy boys” needed to be negotiated among themselves. It can be argued that this management style brought out the best in the “kids”. Many of them commented on the level of responsibility they were given, something they would not have received at rival companies, such as IBM. Something which stood out for me was the way that Carl Alsing announced that it was Tom West who built the Eagle. To me, this underlined th

First Lecture

I attended my first lecture for the module Design, Development, Creativity yesterday and I found it fascinating and I am very much looking forward to engaging with the module over the course of the semester. What stood out for me from yesterday's lecture was the activity we carried out in small groups on Buxton's avalanche case. The case described an event whereby friends skiing got caught in an avalanche and one of their friends, Saul was missing. During their avalanche training, the friends were given instructions on which of their survival tools (probe, shovel, transmitter) to use in which order and how to go about the rescue triage (rescuing the most able individuals first before moving on to the least able).Having not followed the sequence of  their training in exact order, the group of friends still managed to save Saul within 10minutes. What stood out for me from this exercise was the fact that systems are complex entities which comprise of many independent factors