Studies have shown that much of the cost in software projects is spent on testing,debuggi ng, etc , those this area need most attention than other areas such as requirements, specification,d esign,etc?
Software design life-cycle
Collapse
X
-
Originally posted by thatosStudies have shown that much of the cost in software projects is spent on testing,debuggi ng, etc , those this area need most attention than other areas such as requirements, specification,d esign,etc?
I think those two things go hand in hand. Good requirements, design, planning, and specs can help provide better codding, hopefully less bugs and errors.
There is a lot of time and money spent testing because you want to work out all the bugs and problems before you turn the project over.
You don't want to turn something over that you haven't tested properly and still has a lot of bugs. -
Specification lays out what the software should do. The results of testing lay out what the software actually does. I guess managers and users are more interested on what the software does rather than what it was supposed to do.Originally posted by thatosStudies have shown that much of the cost in software projects is spent on testing,debuggi ng, etc , those this area need most attention than other areas such as requirements, specification,d esign,etc?Comment
-
I do not think that you can just highlight testing/debugging as the part of a project where you will spend the most time and money.Originally posted by thatosStudies have shown that much of the cost in software projects is spent on testing,debuggi ng, etc , those this area need most attention than other areas such as requirements, specification,d esign,etc?
Development should be seen a process. The specification and requirements are just the start. Testing can be seen as something that should be a continual activity throughout the process. A lot of money also needs to be spent elsewhere to produce "quality software" (how we measure the quality of software is another discussion...). Coding standards, code reviews, analysis tools (e.g. flexelint et. al.), training, etc. all help reduce the number of bugs in the application, but only if these tools and procedures are implemented in a meaningful way.
Eventually debugging is the consequence of finding problems in the software and normally these problems are found via testing. The worst case scenario is where you end up at the end of a project and need to enter a huge bug-fixing / stabilisation phase. This is when debugging and testing costs really rocket.
I personally think that a good overall balance (i.e. where you spend time during the whole development cycle) for software development is provided by following an iterative process, such a RUP (Rational Unified Process). This kind of approach has been proven to save time and money and when implemented properly leads to better software.
HTHComment
Comment