Different software development groups may create their own SDLC criteria, but just about all systems break down into these categories. 1. Gathering Requirements 2. Application Design 3. Coding 4. Testing 5. Maintenance The naming of these stages presumes a natural order, but not necessarily natural progression. For example, if the coding phase produces a lost of faulty code found in the testing phase, it may be necessary to go back. But in general the successful completion of one phase leads to the next. Many companies use these basic steps as a guide, then issue guidelines on how long each phase should take, based on the scope or complexity of the project. When employers say they are looking for SDLC experience, what they are saying is they want someone who knows how to work from a specification and in a disciplined manner (i.e., no hackers). Many programmers write code without a design plan, which may be fine for small or independent projects but can be quite a hindrance in a large, systematic group effort. ------------------ Michael Ernest, co-author of: The Complete Java 2 Certification Study Guide [This message has been edited by Michael Ernest (edited September 11, 2001).]
Make visible what, without you, might perhaps never have been seen. - Robert Bresson
I would disagree a little with Michael's description of the software development cycle. It is true that different people use different terms for the same concept (and vice versa) - one of the hurdles on a project is establishing a common vocabulary. However, the SDLC - as defined in Michael's post - sounds very much like a traditional waterfall cycle - establish a set of requirements, produce a design, implement it, then test it and (the expensive bit) maintain it. However, iterative design processes do not view software development in these terms. To use Unified Process terminology: Inception is not requirements gathering, Elaboration is not requirements or design, Construction is not implementation etc. This is trying to map waterfall concepts on to an iterative model. Of course, software development consists of requirements, analysis, design and testing activities or "discplines", but these do not map directly to phases in a software lifecycle. Instead, the lifecycle of software changes the relative emphasis of these throughout the duration of the project. In addition, each phase consists of several iterations. Apologies if I am misrepresenting Michael's post, but I think it is important (certainly for the IBM exam) to emphasise that the unified process is _very_ different from a waterfall model. regards, paul.