Software Myths

 software myths

• Software myths propagated misinformation and confusion

• Software myths are belief about software and the process used to build it..

• There are many software myths that are still believe.
• The categories of software myths are as follows: 
• Management Myths
• Customer/User Myths
• Developer/Practitioner's Myths

1) Management Myths:

Managers, who own software development responsibility, are often under pressure to
maintain a software budget, time constraints, improved quality, and many other
considerations. Common management myths are listed below.

1)Myth: The members of an organization can acquire all-the information, they require from a

manual, which contains standards, procedures, and principles;

Reality:

• Standards are often incomplete, inadaptable, and outdated.

• Developers are often unaware of all the established standards.

• Developers rarely follow all the known standards because not all the standards tend to decrease the delivery time of software while maintaining its quality.

2)Myth: Project requirements continually change, but change can be easily accommodated

because software is flexible.

Meaning of state-of-the-art software: The highest level of development, very up-to-date,

the latest and most sophisticated or advanced stage of a technology.

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.

Computer-aided software engineering (CASE) is the domain of software tools used

to design and implement applications.

3) Myth: If the project is behind schedule, increasing the number of programmers can reduce

the time gap.

• Software development is not a technical process like manufacturing.
• As new programmers are added, training must be given to them.

New programmers take longer to learn about the project as compared to those already working on the project.

So, adding more manpower to the project, Further delays the project.

4) Myth: If the project is outsourced to a third party, the management can relax

Reality:

• Outsourcing software to the third party does not understand how to manage and control software projects internally in organization.
• It will not be good for it, so management cannot just relax after outsourcing of software.

2) Customer/User Myths:

• In most cases, customer or users tend to believe myths about the software because software managers and developers do not try to correct the false beliefs.
• These myths lead to false expectations and ultimately develop dissatisfaction among the users.
• Common user myths are listed in below.

1)Myth: Brief requirement stated in the initial process is enough to start development;

detailed requirements can be added at the later stages.

Reality:

• Starting development with incomplete and ambiguous requirements often lead to software failure. Instead, a complete and formal description of requirements is essential before starting development.
• Adding requirements at a later stage often requires repeating the entire development process.

2)Myth: Project requirements continually change, but change can be easily accommodated because software is flexible.

Reality:

• It is true that software requirements may change, but the impact of change varies with the time at which it is introduced.
• When required changes are given in early stage of software development, cost impact is relatively small, but as time increases cost grows fastly.

3) Developers / Practitioner's Myths:

In the early days of software development, programming was viewed as an art, but now

software development has gradually become an engineering discipline. However, developers

still believe in some myths are as follows:

1) Myth: Software development is considered complete when the code is delivered.

Reality:

• 50% to 70% of all the efforts are expended after the software is delivered to the user.
• Practitioner/developers cannot be just free after giving software to customer.

2) Myth: Software quality can be assessed only after the program is executed.

Reality:

 

• The quality of software can be measured during any phase of development process by applying some quality assurance mechanism.
• One such mechanism is formal technical review that can be effectively used during each phase of development to uncover certain errors.

3)Myth: The only product that is delivered after the completion of a project is the working

program(s).

Reality:

• A working program is only one part of software that includes many elements.
• Documentation provides information and guidance for operating software and to know

  more about software.

4)Myth: Software engineering requires unnecessary documentation, which slows down the

project.

Reality:

• Software engineering is about creating quality at every level of the software project.
• Better quality leads to reduced rework. And reduced rework results in faster delivery

  times.

For good quality software documentation is to be prepared after every stage, without

documentation software development is incomplete. It is required to know more about software.