Scribd Logo
Upload

Welcome to Scribd!

  • 13 views

    Reading Journal No.2: Managing Complexity

    Uploaded by

    nh

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    Reading Journal No.2: Managing Complexity

    Uploaded by

    nh
    13 views2 pages

    Original Title

    Reading Journal2

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    13 views2 pages

    Reading Journal No.2: Managing Complexity

    Uploaded by

    nh

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 2

    Reading Journal

    No.2
    Reference: The Economist/ Business
    Topic: Project

    The software-development industry


    Managing complexity
    Most software projects fail to meet their goals.
    Can this be fixed by giving developers better
    tools?
    Nov 25th 2004 | from the print edition

    ON SEPTEMBER 14th, the radios in an air-traffic control centre in Palmdale,


    California shut down, grounding hundreds of flights in southern California and
    Nevada, and leading to five mid-air encounters between aircraft unable to talk to
    the ground controllers. Disaster was averted because aircraft managed to
    communicate with more distant back-up facilities. But why did Palmdale's radios
    fail?
    A glitch in the software running the system meant the computers had to be re-
    booted every 30 days, and somebody forgot to do so. But software running a
    mission-critical system should not have to be restarted every month. The culprit:
    poor design and no contingency system
    As software has become more and more pervasive in business and government,
    and more complicated, the impact of poor software design has been steadily
    growing. A study earlier this year by the Standish Group, a technology
    consultancy, estimated that 30% of all software projects are cancelled, nearly half
    come in over budget, 60% are considered failures by the organisations that initiated
    them, and nine out of ten come in late.
    A 2002 study by America's National Institute of Standards (NIST), a government
    research body, found that software errors cost the American economy $59.5 billion
    annually. Worldwide, it would be safe to multiply this figure by a factor of two. So
    who is to blame for such systematic incompetence?
    Delays are common in numerous industries—few large infrastructure projects, for
    instance, are completed either on time or on budget. But it is peculiar to software
    that billions of dollars can be spent only for nothing useful to result. 
    At a very basic level, it is the fault of the software engineers who are writing the
    programs, and of their bosses. Even companies that specialise in software
    development suffer from delays and overruns. An obvious example is Microsoft:
    its “Longhorn”, the long-heralded successor to its Windows XP operating system,
    was originally scheduled for launch this year. Longhorn is now not expected before
    mid-2006, and many of its key features have been put off until 2007.
    Summary:
    Many software project fail to deliver because of poor design and no contingency
    plan. A glitch in the software running can cost lots of money. The software
    engineer and their boss are blame for such neglience.
    Personal response
    After reading this article, I realise that to complete project on time and budget, the
    maneger have to estimate and controlling the resources, time and budget and mony
    others complicated thing. It is a series of task and only a minimum error can make
    a bad result

    You might also like