ITGumbo: spicing IT up

Why does a requirement to accommodate project requirement changes in the later stage of SDLC arise? Is it due to poor project planning, inept requirement analysis, incorrect implementation, reverse engineering or late customer requirements? eXtreme Programming(XP) is an approach that has been introduced to deal with changes in requirements by effective communication, simplicity, feedback and courage. TDD is an eXtreme Programming method.

Test Driven Development (TDD) is a software engineering technique where code is written for the test cases. I.e. first write a test case, then write a code conforming to the test case, if required rework the code to ensure that the test case is successful. Is TDD unit testing? In unit testing first a unit is made and then it is tested. Unit can be a specification, design element or a code function. Therefore it can be said that in TDD a test case is a requirement for which a code unit is written and tested. If a test case is written for a specification/feature then in order to test it code will be written, this will involve design, coding and testing. Is TDD analogous to other SDLC models?

In my opinion TDD is a model that has been invented to get around difficult steps of SDLC waterfall model. If a developer fails to convert requirements and specifications to design and further in the next step convert design to code then the final product developed will not meet the management and customer expectations. There may be many reasons of failure: incomplete and ambiguous requirements and specifications, lack of expertise, improper project planning, etc. Usability is therefore a technique that must be applied to every SDLC phase. The objective is to test the completeness of one SDLC phase before entering another phase. TDD is reverse engineering, where first test case/code is written to test the requirement/design and then functional code is written to execute the test case. If SDLC processes generate abstract requirement and specifications or design then TDD is based upon more concrete requirements. Test cases convert abstract requirements/design to concrete facts that can be verified and evaluated. Hence TDD is a methodology that is being used to get around the abstraction problem of the SDLC processes.

"Teaching UML is Teaching Software Engineering is Teaching Abstraction" - (Engles, Hausmann, Lohmann & Sauer).

This statement is argued here. Unified Modeling Language (UML) is a language to package concept elements such as class, package, datatype, operations, etc. into models. UML presents visual illustration of the system artifacts and their relationships. Abstraction is required to identify the system artifacts for modeling; abstraction is required to separate metalanguage core constructs and concerns into layers; abstraction is required to partition conceptual areas within layers. UML is a method to construct system models from the core of Model Driven Architecture. Abstraction is a method that is required to construct elements of the common core. Abstraction is a general idea that is not based on a physical, practical data. In software engineering SDLC processes abstraction is the method that is used to simplify and generalize the processes before concrete models can be built. Abstraction is used to list the findings from the cognitive knowledge both tacit and explicit knowledge. The steps to abstraction can be described as:

Usefulness of a system constitutes its usability and utility. Utility is the quality of being useful. Usability is the ease of use. Hence better usability can be designed with well defined utility. There are many definitions of the usability principles. Utility is also defined as one of the design goals for Human Computer Interface (HCI).

PACT analysis is one of the procedures used to determine the utility of an interactive system. The methods used for PACT analysis can be surveys, brainstorming in discussion groups, empirical data collected by heuristic evaluation and cognitive knowledge.