Assignment 1 task 4 (complete)

Software Management Myths, Customer Myths & Practitioner Myths.

   Myth is defined as "widely held but false notation" by the oxford dictionary. We can also say that myth is an unproved or false collective belief. As in other fields software arena also has some myths to demystify.

    Pressman describes a number of common beliefs or myths that software managers, customers, and developers believe falsely. He describes these myths as "misleading attitudes that have caused serious problems." 

     Primarily, there are three types of software myths, all the three are stated below: 

1.  Management Myth

2.  Customer Myth

3.  Practitioner/Developer Myth

 

Management Myth

Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, if those beliefs will lessen the pressure (even temporarily). Some common managerial myths stated by Roger Pressman include:

 

• Development problems can be solved by developing and documenting standards. 

Standards have been developed by companies and standards organizations. They can be very useful. However, they are frequently ignored by developers because they are irrelevant and incomplete, and sometimes incomprehensible. 

• Development problems can be solved by using state-of-the art tools. 

Tools may help, but there is no magic. Problem solving requires more than tools, it requires great understanding. As Fred Brooks (1987) says, there is no silver bullet to slay the software development werewolf.

• When schedules slip, just add more people 

This solution seems intuitive: if there is too much work for the current team, just enlarge it. Unfortunately, increasing team size increases communication overhead. New workers must learn project details taking up the time of those who are already immersed in the project. Also, a larger team has many more communication links, which slows progress. Fred Brooks (1975) gives us one of the most famous software engineering maxims, which is a myth not a myth, "adding people to a late project makes it later."

 

Customer Myth

 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 (by the customer) and, ultimately, dissatisfaction with the developer. Commonly held myths by the clients are:

 

• Change is easily accommodated, since software is malleable. 

Software can certainly be changed, but often changes after release can require an enormous amount of labor.

• A general statement of need is sufficient to start coding 

This scenario is an exaggeration. However, for developers to have a chance to satisfy the customers requirements, they need detailed descriptions of these requirements. Developers cannot read the minds of customers.

Developer/Practitioner Myth

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. A malpractice seen is developers are that they think they know everything and neglect the peculiarity of each problem.

 

• The job is done when the code is delivered. 

Commercially successful software may be used for decades. Developers must continually maintain such software: they add features and repair bugs. Maintenance costs predominate over all other costs; maintenance may be 70% of the development costs. This myth is true only for shelfware --- software that is never used, and there are no customers for next release of a shelfware product.

• Project success depends solely on the quality of the delivered program.

Documentation and software configuration information is very important to the quality. After functionality, maintainability, see the preceding myth, is of critical importance. Developers must maintain the software and they need good design documents, test data, etc to do their job.

• You can't assess software quality until the program is running.
There are static ways to evaluate quality without running a program. Software reviews can effectively determine the quality of requirements documents, design documents, test plans, and code. Formal (mathematical) analysis are often used to verify safety critical software, software security factors, and very-high reliability software.