Scribd
Upload
271 views2 pages

Software Myths

This document discusses three types of software myths that propagate misinformation: 1) Management myths include thinking that existing standards manuals provide all necessary development guidance, or that new hardware or tools alone ensure quality and productivity. 2) Customer myths involve unrealistic expectations around requirements, such as believing they can be loosely defined initially or changed easily later. 3) Practitioner myths consist of views that work is complete after initial delivery, or that quality cannot be assessed until a program is running. Addressing these myths helps improve software development practices.

Uploaded by

Praveen Kumar Nalli
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
271 views2 pages

Software Myths

This document discusses three types of software myths that propagate misinformation: 1) Management myths include thinking that existing standards manuals provide all necessary development guidance, or that new hardware or tools alone ensure quality and productivity. 2) Customer myths involve unrealistic expectations around requirements, such as believing they can be loosely defined initially or changed easily later. 3) Practitioner myths consist of views that work is complete after initial delivery, or that quality cannot be assessed until a program is running. Addressing these myths helps improve software development practices.

Uploaded by

Praveen Kumar Nalli
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Software myths are misleading attitudes that have caused serious problems for

managers and technical people alike. Software myths propagate misinformation


and confusion. There are three kinds of software myths:

1) Management myths:
Managers with software responsibility are often under pressure to maintain
budgets, keep schedules from slipping, and improve quality.
Following are the management myths:

 Myth: We already have a book that’s full of standards and procedures for
building software, won’t that provide my people with everything they need
to know?
Reality: The book of standards may very well exist, but isn’t used. Most
software practitioners aren’t aware of its existence. Also, it doesn’t reflect
modern software engineering practices and is also complete.
 Myth: My people have state-of-the-art software development tools, after
all, we buy them the newest computers.
Reality: It takes much more than the latest model mainframe, workstation,
or PC to do high-quality software development. Computer-aided software
engineering (CASE) tools
are more important than hardware for achieving good quality and
productivity, yet the majority of software developers still do not use them
effectively.
 Myth: If we get behind schedule, we can add more programmers and catch
up (sometimes called the Mongolian horde concept).
Reality: Software development is not a mechanistic process like
manufacturing. 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 effort. 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: If an organization does not understand how to manage and control
software projects internally, it will invariably struggle when it outsources
software projects.
2) Customer myths:
Customer myths lead to false expectations (by the customer) and ultimately,
dissatisfaction with the developer. Following are the customer myths:
 Myth: A general statement of objectives is sufficient to begin writing programs-
we can fill in the details later.
Reality: A poor up-front definition is the major cause of failed software efforts.
A formal and detailed description of the functions, behavior, performance,
interfaces, design constraints, and validation criteria is essential.
 Myth: Project requirements continually change, but change can be easily
accommodated because software is flexible.
Reality: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. When changes are requested
during software design, the cost impact grows rapidly. Resources have been
committed and a design framework has been established. Change can cause
heavy additional costs. Change, when requested after software is in production,
can be much more expensive than the same change requested earlier.
3) Practitioner’s myths: Practitioners have following myths:
 Myth: Once we write the program and get it to work, our job is done.
Reality: 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.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy