Software Myths
-
Upload
rajat-bajaj -
Category
Software
-
view
173 -
download
0
Transcript of 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
Motivation
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.
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.
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
Myth # 2: Requirements are fixed
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
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.
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.
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
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.
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.
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.
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.
THANK YOU