Software Myths

15
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

Transcript of Software Myths

Page 1: Software Myths

SOFTWARE MYTHS Group Members:1. Rajat Bajaj (Leader )2. Prateek Gupta3. Sajay Jay Singh4. Shubham Dhawan 5. Sahil Aggarwal6. Vineet Singh Rawat7. Simranjeet

Page 2: Software Myths

Motivation

Page 3: Software Myths

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. 

Page 4: Software Myths

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.

Page 5: Software Myths

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

Page 6: Software Myths

Myth # 2: Requirements are fixed

Page 7: Software Myths

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

Page 8: Software Myths

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.

Page 9: Software Myths

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.

Page 10: Software Myths

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

Page 11: Software Myths

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.

Page 12: Software Myths

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.

Page 13: Software Myths

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.

Page 14: Software Myths

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.

Page 15: Software Myths

THANK YOU