Practitioner’s myths:
Myths that are still believed by software practitioners have been fostered by over 50 years of programming culture. During the early days of software, programming was viewed as an art form. Old ways and attitudes die hard.
Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that the sooner you begin writing code, the longer it’ll take you to get done. Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.
Myth: Until i get the program running. I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project – the formal technical review. Software reviews are a “quality filter” that have been found to be more effective than testing for finding certain classes of software errors.
Myth: The only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and a more importantly, guidance for software support.
Sunday, December 21, 2008
Customer myths
Customer myths:
A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing/sales department or an outside company that has requested software under contract. In many cases the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths lead to false expectations and, ultimately, dissatisfaction with the developer.
Myth: A general statement of objectives is sufficient to begin writing programs – we can fill in the details later.
Reality: Although a comprehensive and stable statement of requirement is not always possible, an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements are developed only through effective and continuous communication between customer and developer.
Myth: Project requirements continually change, but change can be easily accommodated because software is flexible.
Reality: It is true that software requirement change, but the impact of change varies with the time at which it is introduced. When requirement change are requested early, cost impact is relatively small. However, as time passes cost impact grows rapidly – resources have been committed a design framework has been established, and change can cause upheaval that requires additional resources and major design modification.
A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing/sales department or an outside company that has requested software under contract. In many cases the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths lead to false expectations and, ultimately, dissatisfaction with the developer.
Myth: A general statement of objectives is sufficient to begin writing programs – we can fill in the details later.
Reality: Although a comprehensive and stable statement of requirement is not always possible, an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements are developed only through effective and continuous communication between customer and developer.
Myth: Project requirements continually change, but change can be easily accommodated because software is flexible.
Reality: It is true that software requirement change, but the impact of change varies with the time at which it is introduced. When requirement change are requested early, cost impact is relatively small. However, as time passes cost impact grows rapidly – resources have been committed a design framework has been established, and change can cause upheaval that requires additional resources and major design modification.
Thursday, December 11, 2008
Manager Myths
Software Myths:
Beliefs about software and the process used to build it – can be traced to the earliest days of computing. Myths have a number of attributes that have made them insidious.
Management myths:
Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets. Keep schedules from slipping, and improve quality.
Myth: We already have a book that’s full of standards and procedures for building software. Won’t that provide with everything they need to know?
Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it adaptable? Is it streamlined to improve time to deliver while still maintaining a focus on quality? In many cases. The answer to all of these questions is no.
Myth:If we get behind schedule, we can add more programmers and catch up (Sometimes called the Monogolian horde concept)
Reality: Brooks [BRO75] said “Adding people to a late software project makes it later.” As new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development. People can be added but only in a planned and well-coordinated manner.
Myth:If I decide to outsource the software project to a third party. I can just relax and let that firm build it.
Reality: In an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsources software projects.
Beliefs about software and the process used to build it – can be traced to the earliest days of computing. Myths have a number of attributes that have made them insidious.
Management myths:
Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets. Keep schedules from slipping, and improve quality.
Myth: We already have a book that’s full of standards and procedures for building software. Won’t that provide with everything they need to know?
Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it adaptable? Is it streamlined to improve time to deliver while still maintaining a focus on quality? In many cases. The answer to all of these questions is no.
Myth:If we get behind schedule, we can add more programmers and catch up (Sometimes called the Monogolian horde concept)
Reality: Brooks [BRO75] said “Adding people to a late software project makes it later.” As new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development. People can be added but only in a planned and well-coordinated manner.
Myth:If I decide to outsource the software project to a third party. I can just relax and let that firm build it.
Reality: In an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsources software projects.
Subscribe to:
Posts (Atom)
