Tuesday, 26 July 2011
Task 4 Part 3 - Practitioner’s Myths
Do you like this story?
Practitioner’s myths:
Myths that are still believed by software practitioners have been fostered by over 50 years of programming culture. During the early days of software, programming was viewed as an art form. Old ways and attitudes die hard.
- Myth: Once we write the program and get it to work, our job is done.
- Reality: Someone once said that the sooner you begin writing code, the longer it’ll take you to get done. Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.
Disscussion : If we were to start writing the codes before proper design and planning, the project would take longer to complete. This is because the programmers are building codes blindly. Having only a rough idea of how it is supposed to work and in the end, in order to amend these mistakes, much more time would be taken.
- Myth: Until i get the program running. I have no way of assessing its quality.
- Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project – the formal technical review. Software reviews are a “quality filter” that have been found to be more effective than testing for finding certain classes of software errors.
Disscussion : Quality assessment can be done throughout project development from the moment the project is accepted by having software reviews. By reviewing software, whole software can be tested for its functionality and quality in one go.
- Myth: The only deliverable work product for a successful project is the working program.
- Reality: A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and a more importantly, guidance for software support.
Disscussion : When creating software, each stage of development should be documented and should be delivered to the client to provide assurance of project development as well as to give them an idea of how the project is going so far. Apart from that, each aspect of the software is documented in order to provide detailed description of how the software works.
Discussion done by : Talib, Lim Jia Hui, Gary Jordan, Shilpesh.
This post was written by: UNITENIAN AUTHORS
Subscribe to:
Post Comments (Atom)
0 Responses to “Task 4 Part 3 - Practitioner’s Myths”
Post a Comment