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 :
Its 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 Grants 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.