The document discusses several common software development myths. It is written by a group of 7 software engineers. The myths discussed include: 1) that clients know exactly what they want, 2) that requirements are fixed, 3) that quality can't be assessed until a program is running, 4) that adding more people fixes schedule slips, 5) that security is only a cryptography problem, 6) that a tester's only task is to find bugs, 7) that testing can't begin until development is fully complete, and 8) that network defenses alone can provide protection. The document aims to dispel these myths and provide more accurate perspectives.

1. SOFTWARE MYTHS
Group Members:
1. Rajat Bajaj (Leader )
2. Prateek Gupta
3. Sajay Jay Singh
4. Shubham Dhawan
5. Sahil Aggarwal
6. Vineet Singh Rawat
7. Simranjeet

2. Motivation

3. Why should we avoid myths?
 Software myths propagated misinformation
and confusion.
 Software myths propagate false beliefs and
confusion in the minds of management, users
and developers.
 Myths lead to false expectations and
ultimately develop dissatisfaction among the
users.

4. Myth# 1: Client know
Everything
 Customers tend to talk about features, not what
they truly need.
 People often don’t know what they want.
 Client does not understand the technicalities
 We tend to use jargon and assume clients
understand the terminology.

5. Myth # 1: Example
 Client Say:
 I need a software which will allow me to select
multiple options at one time and I need Radio-
Button ??
 What Project Manager will say:
 Either he can accept or better ask for what client
want to do
Client usually tell the Solution not the
Requirement

6. Myth # 2: Requirements are
fixed

7. Myth # 2
 While Project is underway new changes are
requested leading to
Change Request – Scope Creep and this
is Normal
 At time what we deliver in the end is totally
opposite what we make
as prototype – Throwaway Prototype

8. Myth # 3: 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.

9. Myth # 4: When schedules slip, just
add more people
 If there is too much work for the current team, just
enlarge it.
 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.

10. Myth # 5:Software security is a
cryptography problem
 Security is a system property, not a thing.
 Crypto can neither find nor eradicate bugs and
flaws but sometimes it can temporarily obscure
them.
 As but one example, if I find a SQL injection in
your app that talks to an encrypted database, do
you think I'll get back encrypted data or plaintext
data?
 Software security is about integrating security
practices into the way you build software, not
integrating security features into your code

11. Myth # 6: A Tester's only Task is to
Find Bugs
 Testers are domain experts of the particular
software.
 Developers are only responsible for the specific
component or area that is assigned to them but
testers understand the overall workings of the
software, what the dependencies are, and the
impacts of one module on another module.

12. Myth # 7: Testing cannot be started if
product is not fully developed.
 Testing depends on source code but reviewing
requirements and developing test cases is
independent from the developed code
 Iterative or incremental approach as a
development life cycle model may reduce the
dependency of testing on fully developed
software.

13. Myth # 8: Network defenses will
protect us
 Myth: Software security vulnerabilities are
neutralized by network defenses (such as routers
and application firewalls) so we can defend against
most attacks at the network level.
 Reality: Many network security controls assume that
software is secure instead of actually protecting the
enterprise against software security failures
 For example, if properly used, SSL can create a
private tunnel between a user and a server
application. It does little to protect the business
however if the user is malicious and the application
processing his or her data is vulnerable.

14. Myth # 8 Continues…
 Even good application firewalls that can
correctly identify many straightforward SQL
Injection or Cross Site Scripting attacks cannot
defend against business‐logic security
vulnerabilities or buffer overflows that might
reside in software that is processing user input.

15.  THANK YOU