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

Post a Comment

Popular posts from this blog

Iona Technologies

·        Iona was founded in 1991 by Chris Horn, Sean Baker and Anrai O’Toole ·        The company progressed from a Trinity campus company, releasing Orbix in 1992 and going public in NASDAQ in 1997 ·        Trinity College Distributed Systems Group (DSG) was a small group of academics and engineers conducting research and development into the problem of inter-network computing systems, essentially connecting systems which were developed as independent systems to work and communicate with one another ·        Their research was initially supported by Trinity and then the EU ·        They took a brave leap from academic to the commercial world due to the attractive opportunity of industries like banking and telecommunications embracing networks and internets ·        Iona found that their c...
Post a Comment
Read more

Week 2 Design thinking - Build the right thing

This week focused around building the thing right as opposed to building the right thing. Great design has always been concerned with the whole experience of interaction. One of the most interesting topics emerging from the class was prompted by a quote from Alan Cooper. It prompted discussion around what do you get when you cross a computer with a camera? A phone? A plane? With a car? A ship? You get a bigger computer.   The products we use on a daily basis are becoming ever more like software. Allen stressed that we need to develop an annoyance and radar for bad design and an appreciation for superior design. He showed us a variety of good and bad design examples and showed examples of how users will highlight the problems in your products or else they will leave marks e.g. a sign telling the user how to interact correctly with a product / service During the lecture, we also watched a video "Inside IDEO" which followed the IDEO design team revolutionizing the ...
Post a Comment
Read more

Designing a Robot

In week 9, we worked in small groups to create a robot using an instruction manual and upon creating our robot, we were tasked with creating a "run" function so that our robot could drive around and "guard a base." (for the purpose of the class, the base was a large white box) This exercise was great fun, but at times stressful as we were required to create our robot within a short time constraint. To create our robot within the allotted time, my group divided the tasks amongst us. One individual called out the required materials needed and where they were to be placed, one found the necessary materials and two individuals put the robot together. As requested by our lecturer, we switched roles frequently so that each member got experience working on each of the tasks required. Dividing the roles out amongst ourselves enabled us to create our robot more quickly than if we had completed each of the tasks together as a group.
Post a Comment
Read more