ASSIGNMENT OF SOFTWARE ENGINEERING

(CS-724)

Submitted to: Nasir Minhas

Submitted By: Maryam Asghar

12-Arid-2299

Date: October 2, 2013

Subject:

Myths in the field of Software Engineering according to the perception of Customer, Developer and Management.

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 led to false expectations and ultimately, dissatisfaction with the developers.

Myth: 1

A general statement of objectives is sufficient to begin writing programs we can fill in details later.Reality :

 Although a comprehensive and stable statement of requirements is not always possible, an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements are developed only through effective and continuous communication between customer and developer.

Myth : 2

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

 It’s true that software requirement change, but the impact of change varies with the time at which it is introduced. When requirement changes are requested early, cost impact is relatively small. However, as time passes, cost impact grows rapidly – resources have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification.

Myth:3

Software with more features is a better software.

Myth:4

Big teams are better!Reality:Big teams are better for 43 person symphonies, epic movies etc, but not for making pies and software.

Too many cook spoil the pie.

Myth:5 All programmers are the same

All experienced programmers are equally skilled

Reality:

Sackman, Ericson and Grant’s 1965 experiment to show that interactive programming is better than batch programming failed to produce significant results because the effect of the individual variables(use of interactive versus batch submission of job) was drowned out because of individual differences in programmers of equal experience.

Developer Myths. Developers often want to be artists (or artisans), but the software development craft is becoming an engineering discipline. However myths remain:

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) analyses are often used to verify safety critical software, software security factors, and very-high reliability software.

Myth 1: Our customers want the lowest price -- period.Myth 2: We know what our customers want (or don't want).

Myth:

Developers are encoders

Reality

Developers are knowledge workers.

Myth:

Software development is all about coding

Reality

Coding is just a small part of software development.

Software development is all about understanding people.

Myth:

You only need to learn one programming language.

Reality:

Modern programming requires knowledge of multiple languages and technologies.

Myth :

Software development creates voluminous and unnecessary documentation and invariably slows down the software development.

Reality: The more we have documented the software project the more it will be useful and helpful for the upcoming evolvement.

Myth :

One very common myth about reuse is, "The larger your software library, the more reuse you

Reality:

While code library use is common and helpful, most libraries handle only low-level, generic parts, leading to low levels of reuse. In many cases, libraries are built by collecting pieces of potentially reusable code from existing applications and from new developments without enough emphasis on standards for quality, documentation, architecture, and testing. Current library

research is focused on classification, library tools and library interoperability. To get high levels of reuse and consequent high levels of benefits, one needs more than just code or object libraries. One

needs to deal with the careful design of reusable architectures and components that fit together for particular domains and with the systematic introduction and institutionalization of reuse in the development organization.

• Management Myths 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 the Belief will lessen the pressure. 

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 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 these entire question 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 words of Brooks [BRO75]: "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 

Myth : If we 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 project internally, it will invariably struggle when it out sources software project. 

"We already have a book that is full of standards and procedures for building software. Won't that provide my people with everything they need to know?"

– Not used, not up to date, not complete, not focused on quality, time, and money

• "If we get behind, we can add more programmers and catch up"

– Adding people to a late software project makes it later

– Training time, increased communication lines

• "If I decide to outsource the software project to a third party, I can just relax and let that firm build it"

– Software projects need to be controlled and managed

Myth:

Each organization feel that they have state-of-art software development tools since they have latest computer.