ITGumbo: spicing IT up

• Project planning - When a project is conceived it may have a very long list of features that can be implemented and hence a very long development and maintenance life-cycle is planned. During this life-cycle many versions of the product may be released at different time to create revenue. For this reason the features are planned in different releases. But during development life-cycle either the release may get delayed causing an overlap with the schedule of the other release or market requirements may change, due to this reason new requirements may have to be added in already under development product release.

• Inept requirement analysis - Requirement analysis is the most crucial step of the product life-cycle. The required expertise of the development team is determined based on the requirements. Therefore it is required that the team involved in the requirement analysis has the necessary expertise to analyze and study the product feasibility and market requirements.

• Incorrect implementation - The design and development of the product may lead to a stage where it is not possible to implement some requirements either due to lack of resources (time, cost & human resources), inefficient implementation or standards interworking issues that were not discovered in the requirement analysis stage. This may result in change in project requirements for the release.

• Reverse engineering - New requirements may evolve during development stage that can be easily accommodated in the release schedule without any major enhancements in the project design and implementation.

• Late customer requirements - Customer may be the public, stake holder, management, off-shore client, design team or testing team. The changes in the requirements may be introduced due to directives from either of these authoritative agencies.

It is wrong to suggest that XP is the right approach to solve the problem of accommodating requirement change. Encouraging this approach undermines the SDLC process and the value of software engineers. It is like telling a lady that if you cannot bake the bread then buy cookies. It appears as if XP and hence TDD are methods invented to reduce the irritability of the developers and to reduce the responsibility of the requirement analysts and designers. XP is being promoted as an attitude of software engineers for better software engineering. XP is the new name being given to the SDLC iteration model by including requirement analysis, testing, design and coding in TDD. Since the end result is the executable program which is expected to be bug free, hence eXtreme Programming. Also XP is suggested to be the right approach to address risks in the project life-cycle.

I am not arguing against XP approach or TDD method, as we have discussed earlier TDD method must be used with discrimination. Is XP a name given to authorize the failed SDLC waterfall model? It is a new software engineering hype that is not essential on the resume of a software engineer. There are two contradictory statements: good design is essential for XP and design in XP is not one-time thing but an all-time thing. A modular design to which abstraction solving techniques are applied until all abstractions are resolved is a better approach. This is done in the SDLC waterfall model.