Assignment 1: Task 4

Software myths- beliefs about software and the process used to build it- can be traced to earliest days of computing. Myths have a number of attributes that have made them insidious. So software myths prevail but though they do are not clearly visible they have the potential to harm all the parties involved in the software development process mainly the developer team. Myths have a number of attributes that make them insidious. For instance, they appear to be reasonable statements of facts(sometimes containing elements of truth), they have an intuitive feel, and ther are often promulgated by experienced practitioners who "know the score".


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

1. Management myths- managers with software responsibility, like managers in most displines, are often under pressure to maintain budgets,keep schedules from slipping, and improve quality.A software manager often grasps at their belief in a sofware myth, if that belief will lessen the pressure(even temporarily). Some common manageral  myths stated by Roger Pressman include:

• We have state-of-the-art software developments tools; after all, we buy the latest computers.
• A good manager can manage any projects.

 The managers completely ignore that fact that they are working on something intangible but very important to the clients which invites more trouble than solution. So a software project manger must have worked well with the software development process analyzing the minute deals associated with the field learning the nitty-gritty and the tips and trick of the trade. The realities are self understood as it is already stated how complex the software development process is.

Myth : We already have a book that's full of standards and procedures for buillding software.Won't that provide my people with everything they need to knw?

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 complete? Is it adaptable? Is it streamlined to improve time-to-delivery 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 "mongolian horde " concept).

Reality : Software development is not a mechanistic process like manufacturing. In the word of Brooks [Bro95]: "adding people to a late software project makes it later." At first, this statement may seem counterintuitive. However 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 and let that firm build it.

Reality : If an organization does not understand hot to manage and control software projects internally, it will invariably struggle when it out-sources software projects.

2.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 (by the customer) 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 or requirements is not always possible, an ambigious "statement ob objectives" is a recipe for disaster.Unambiguous requirements (usually derived iteratively) are developed only through effective and continuous communication between customer and developer.

Myth : Software 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 are requested early (before design or codes has been started), the cost impact is relatively small. However, as time passes, the cost impact grows rapidly-resources have been commited, a design framework has been established and change can cause upheaval that requires addtional resources and major design modification.

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

                                         

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 will 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 technical review.Software reviews are a " quality filter" that have been found to be more effective than testing for finding certain classes of software defects.

Myth : The only deliverable work product for a successfull project is the working program.

Reality : A working program is only one part of a software configuration that includes many elements. A variety of work ( e.g. models,documents,plans) provide a foundation for succesfull engineering and more important guidance for software support.

Myth : Software engineering will make us create voluminious and unnecessary documentation and will invariably slow us down.

Reality : Software engineering is not about creating documents. It is about creating a quality product. Better quality leads to reduced rework. And reduced rework results in faster delivery times.

On the whole, realities are always different from the myths. So the myths must be demystified and work should be based on systematic, scientific and logical bases than the irrational myths. The systemic view must be considered to determine the success of any software project its not only the matter of hard skills but soft skills of the developer team also matter to come up with a efficient system. Recognitioan of software realities is the first step toward formulation of practical solutions for software engineering.