mythe of the software.

1 management myth.

Myths & Management. Managers with responsibilities like managing software in most disciplines, often under pressure to maintain budgets, keep schedules from slipping, and improve quality. As a person drowning in a straw snap, snap a driver software often believe in a myth software, if the trust will print (even temporarily) reduced. Myth: We have a book full of standards and procedures for building software will not let people give me everything they need to know the reality: The Book of standards may very well exist, but it used? Software practitioners are aware of its existence? Will it reflect modern software engineering practice? Is it complete? Is streamlined to improve time to delivery, while another focuses on maintaining quality? In many cases the answer to all these questions is "no." Myth: My people have state-of-art software, after all, we buy them new computers. Reality: It takes a lot more than last mainframe model workstation or PC, high quality software development. Computer Aided Software Engineering (CASE) tools are more important than hardware to achieve quality and productivity, but most software developers still use them effectively. 

2> Client myths. A client who is a computer software application, a person at the next table, a technical group down the hall, / marketing sales department or an outside company that requested the software under contract. In many cases, the customer believes myths about software because software managers and practitioners improve much misinformation. Myths lead to false expectations (by the client) and ultimately, dissatisfaction with the developer. Myth: A general statement of objectives is sufficient to begin writing programs-we can fill in details later. Reality: a definition of weak up front is the leading cause of failed software efforts. A formal and detailed description of the information domain, function, behavior, performance, interfaces, design constraints, and evaluation criteria are essential. These properties can be determined only after thorough communication between customer and developer. myths 

3> doctor. Myths still believed by doctors of the programs are guided by 50 years of cultural development. During the early days of software development was considered an art form. Old ways and attitudes die hard. Myth: If we write the program and get to work, our work is done. Reality: Someone once said that "The sooner you start writing code, the longer it will take you to get done." Current data ([LIE80] [JON91] [PUT97]) show that between 60 and 80 per cent of all software efforts spent will be spent after it is delivered to the client for the first myth:. Until I get. program "run" I have no way to assess the quality of its reality: One of the mechanisms of effective quality assurance programs can be applied in creating a formal draft technical review reviews Software (described in Chapter 8). a "quality filter" which are found to be more effective than testing for finding certain classes of software defects.