Tech Off Thread

2 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Request For Comments (RFC)

Back to Forum: Tech Off
  • User profile image
    zhuo

    Hi,

    I am requesting for some comments on a recent blog of mine about software development methologies. I am just writing what I think with my limited knowledge and I would love to see some comments on my writing.


    http://spaces.msn.com/members/zhuocorporation/

    James Big Smile

  • User profile image
    zhuo

    After 111 and still no comments, maybe it's easier if i paste it here Big Smile
    So here it is..

    I've been reading a fair bit about Software Development Methodologies lately in my time relaxing at home. I thought I should take you through my investigative journey.
     
    I've started my journey revisiting UML. We've all studied UML in university but how many of us have actually applied this to the real world? My own answer to the question is "none, at least out of the circle that I am in contact with". But I thought I should revisit UML to see what new perspective I might gain by fusing my industry experience with theoretical knowledge. Here is a good tutorial on UML for those interested.
     
    I've somehow stumble upon the "Waterfall" model while revisting UML. This branched my investigative journey into "Software Development Methodologies". The software development methodologies that I refer to here can also be called project management methodologies as these are employed to help manage software projects.
     
    The "Waterfall" model is a software development methodology widely used in practice in its varied forms and it is universally taught in all software engineering courses. It emphasises the distinct phases that should be followed in the development of software solutions, these include "Requirement Gathering", "Functional Specification", "Technical Specification", "Design", "Implement", "Test/Fix" and "Maintainance".
     
    Although the "Waterfall" model makes great deal of sense and is used by many organisations in developing information systems, it has many practical disadvantages. An important disadvantage is its inability to respond to business requirement changes. It may be argued that this can be countered with solid requirements gathering right at the start. But in practice, projects employing the "Waterfall" model usually span years which imply greater possibility for changes during its development. Another detrimental disadvantage is that all the processes introduced by the very methodical approach of the "Waterfall" model often leads to process paralysis.
     
    In a big picture, the "Waterfall" model can be regarded as software development on one extreme end of the scale. The other extreme end of the scale is "Agile Software Development", which is becoming increasingly popular in recent years and is being adopted by leading software development firms such as ThoughWorks. Agile Software Development is most popularly manifested through a form called "XP" or "Extreme Programming".
     
    Before I comment on XP, i thought I should reproduce the Agile Manifesto's core values to set the context.
    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan
    As far as I can see it, the Agile Manifesto has outlined the 2 extremes of software development approaches. But do we really have to settle on one of the extremes? Is it even neccessary to have a one size fits all approach to software development? I see continuity between the 2 extremes. Picture the 4 core values described above as 4 sliding bars. Depending on the scale of the project and the skills available in a given team, these 4 sliding bars can be tailored to suit each project.
     
    Take the first core value of the Agile Manifesto "Individuals and interactions over processes and tools" as an example. Take a large team of 200 to 300 developers, how do you manage this team using the Agile approach? How do you treat an individual as an individual in a team of 200+ individuals and yet still achieve efficiency? How do you manage the variability of skill level of 200+ developers using the Agile approach? There may be an answer to all of this. My own answer to all of these question is to "Divide and Conquer" but this still cannot be achieved without relevant processes to manage this division.
     
    Perhaps researchers in area of software development methodology should be looking at ways of identifying appropriate slide bar position based on a set number of parameters rather arguing over which is the better method.
     
    James Big Smile
     

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.