..................... 14 1..... 56 1.................................................................................................................................2................................. 3 NEW IN THIS VERSION 3...........................2.....1 The Linear-sequential lifecycle model......................................................... 11 1.......2 The Incremental lifecycle model ............................8 * * PRINCE2 / Projects in Controlled Environments .......... 34 Introduction ............4 * * DSDM / Dynamic Systems Development Method ..........3 The Evolutionary lifecycle model ......................................................................................... 54 1.. 5 1.... 21 1...................................................................................4 * * JSD / Jackson System Development ............................................. 70 1.............. 19 1.........1.................................................. 24 1.............................................INDEX INDEX .............................2 * * SCRUM ................................................................................... 8 1....... 71 Weaknesses ............................................................................. 71 Strengths................................................. 72 Strengths................................ 36 1...................................................... 72 Introduction ...1...... 7 Strengths............. 74 Project Lifecycles (version 3) 1 / 87 .......... 7 Methodologies ........................................................2................... 74 Weaknesses .........................3 * * SSADM / Structured Systems Analysis & Design Methodology .............................5 * * e-DSDM / Dynamic Systems Development Method . 35 Methodologies .......... 34 Strengths..........1................................ 35 Weaknesses .............. 7 Weaknesses ..................1............ 7 1........................................................2......... 23 1.1.. 71 Introduction .................1 * * Crystal Family......................... 6 1......4 The Spiral lifecycle model ...................1.......... 71 1............1 * * The Waterfall Methodology ..........2...........................5 * * MERISE / Methode d'Etude et de Realisation Informatique pour les Systemes d'Entreprise ............................................... 23 1.2 * * The V-Shaped Waterfall Methodology ......0 ........................ 40 1...6 * * STRADIS Methodology .....................................7 * * YSM / Yourdon Systems Methodology ... PROJECT LIFECYCLE MODELS ..........................................................................1....3 * * XP / eXtreme Programming methodology ......... 7 Introduction ..................................... 1 INTRODUCTION ...1...................................... 36 1.......................................................

.............................. 75 DFD ...................Unified Modeling Language ................................. 80 3...... 79 UML .......................................................................Systems Development Life Cycle........................................ 78 Scope.... 85 Project Lifecycles (version 3) 2 / 87 ........................................2......................... 75 BPMN ................................... 79 Stake holders ............................................. INTERESTING HYPERLINKS .......... 78 Project Plan ....................................................... 78 Project Management Software .............. 75 Best Practices .............................................................. 78 SDLC ........... LEXICON.....................................................Business Process Modeling Notation .................................................................................................Data Flow Diagram .... 77 Project Management ..............................

. The numbers speak for themselves: Eighty percent of IT projects fail and 50% of those are over budget. a prototype can be used just as tool for communication. Programmer. execute. Cost overruns average 189% of original estimates. and methodology to plan. IT professionals are expected to continue with their "regular" job (DBA. Project Lifecycles (version 3) 3 / 87 . Network or Application support) along with managing or taking part in new projects. Many IT professionals lack the basic project management (*) knowledge. in bigger and more complex projects. a combination of two or three of these approaches might be more useful. Only 12% of projects are delivered on time and within budget. In this type of situations.with less. Webmaster. System Admin. or more. or it can be gradually evolved to the final product. training. On the other hand during the design stage prototyping can be used as a method of interaction with users. each iteration can be implemented like a mini waterfall project. Doing the same. Generally. Each method has advantages and disadvantages. The workload on IT professionals has increased dramatically over the past few years.INTRODUCTION The business world is shifting to a new digital economic paradigm and the failure rate of IT projects is staggering. Cost cutting and hiring freezes have NOT diminished the need for IT Projects (in fact it probably has increased the need). or both. That means that 88% are over budget or over schedule. For example in a project that is being developed by using an incremental approach. and control IT projects.

Making the correct Methodology choice and executing its phases properly when building service delivery capabilities during the (e)Business transformation is described in this eBook based on Best Practices (*) and experiences from the writer and his readers. Also you can expand this book by sharing your knowledge. by mailing to christian@gijsels. use a combination of one or more of the following proven methodologies and/or emerging standards below. Thank you. Christian Gijsels Project Lifecycles (version 3) 4 / 87 .com Depending on the client’s needs. You can also use the client’s proprietary Corporate Project Methodology (CPM) or implement a new business analysis and SDLC process matching the specific project/department needs.

1.4.NEW IN THIS VERSION 3. 1.1.2. 1.1.3 * * SSADM / Structured Systems Analysis & Design Methodology A complete overview when and how the SSADM method is used. 1. Project Lifecycles (version 3) 5 / 87 .1.4.5 * * MERISE A complete overview when and how the MERISE method is used.0 We added the following sections to this book: 1.0. 1.2.2 DFD A complete overview about DFDs.9 UML 2.8 * * PRINCE2 / Projects in Controlled Environments A complete overview when and how the PRINCE2 method is used.4 * * JSD / Jackson System Development A complete overview when and how the JSD method is used. 2.4.0 A complete overview about UML 2.1.2 * * SCRUM A complete overview when and how the SCRUM method is used.4.4.4.4 * * DSDM / Dynamic Systems Development Method A complete overview when and how the DSDM method is used. 2.

and reviews their strengths and weaknesses. often a project can fail from the beginning because the project approach is inappropriate for the business goal. It is essential that the business sponsors and project managers be clear in their own mind about how they want to run the project. We can debate the pros and cons of one project lifecycle models over another until we’re blue in the face. but the simple fact is that we will never declare a true winner. corporate culture. These standard models can be adapted to fit the industry issues. To deliver a quality system. The following describes standard project lifecycle models.1. Project Lifecycles (version 3) 6 / 87 . There simply are no silver bullet project lifecycle models that will help every development team deliver every product on time and on budget. it's critical to know the risks facing your project and to use a model that reduces those risks. time constraints and team vulnerabilities which comprise your environment. however. The development approach must factor in the real world constraints and success factors from the start. PROJECT LIFECYCLE MODELS Introduction A business critical decision before a development even begins is selecting the most appropriate project lifecycle model (also called Software Development Life Cycle Models – SDLC (*) ) for success. A 'one size fits all' approach may have the benefit of a familiarity.

Code is produced during implementation that is driven by the design. Strengths Minimizes planning overhead since it can be done up front. Methodologies The linear-sequential lifecycle model comes in a variety of "flavors". architectures and infrastructures. Only the final phase produces a non-documentation deliverable. Weaknesses Inflexible. The V-Shaped Waterfall methodology. In those cases. we will describe the following methodologies: The Waterfall methodology. Its weaknesses frequently make it inadvisable when rapid development is needed. Backing up to address mistakes is difficult.1 The Linear-sequential lifecycle model Introduction The pure linear-sequential lifecycle model performs well for products with clearly understood non changing requirements or when working with well understood technical tools. so it works well for technically weak or inexperienced staff. Each phase produces deliverables required by the next phase in the life cycle. other models may be more effective.1. JSD / Jackson System Development MERISE / Methode d'Etude et de Realisation Informatique pour les Systemes d'Entreprise STRADIS Methodology YSM / Yourdon Systems Methodology Project Lifecycles (version 3) 7 / 87 . Structure minimizes wasted effort. Requirements are translated into design. Testing verifies the deliverable of the implementation phase against requirements.

a review takes place to determine if the project is on the right path and whether or not to continue or discard the project.1 * * The Waterfall Methodology Introduction The waterfall model methodology. the implementation phase begins.1. they are integrated into a working product. the product is tested. this phase typically includes requirements analysis. Phases do not overlap in the waterfall model methodology. After all features described in the design phase are implemented. Once the design is set in stone. documented in 1970 by Royce was the first publicly documented life cycle model. At the end of each phase. each phase must be completed in its entirety before the next phase can begin. Project Lifecycles (version 3) 8 / 87 . The waterfall development process starts with one long design phase that defines the entire project and all of the product’s features. Finally. In the waterfall model methodology.1. The waterfall model followed a documentation driven paradigm. and then it is shipped to customers. The model was developed to help cope with the increasing complexity of aerospace products.

This is where the details on how the system will work is produced. Project Lifecycles (version 3) 9 / 87 . Architects have the ball in their court during this phase and this is the phase in which their focus lies. business logic that processes data. This phase is the main focus of the project management (*) and stake holders (*). This produces a nice big list of functionality that the system should provide. and how the user interface should work. communication.The Steps Step 1: Project initiation At the very top of the waterfall methodology. detailed design (UML (*) is the notation format here) are all part of the deliverables of a design phase. Meetings with managers. Step 4: Design The software system design is produced from the results of the requirements phase. which describes functions the system should perform. as necessary establish controls. stake holders (*) and users are held in order to determine the requirements. Step 2: Planning By carefully planning each work activity. Who is going to use the system? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase. Step 3: Requirements / Analysis Business/User requirements (BPMN (*) is the notation format here) are gathered in this phase. not how it is actually going to do it. The overall result is the system as a whole and how it performs. Architecture. what data is stored and used by the system. you will be better able to recognize safety concerns and issues. and thereby carry out the work more safely. including hardware and software. The initiation step is the first phase of the application development and life cycles during which enough of the application’s requirements and architecture are produced so that agreement can be reached between the development organization and the customer organization regarding the goals and scope (*) of the following phases. you initiate the project.

but high risk in budget and schedule predictability and control. Strengths Simple and easy to use. and this is the longest phase of the software development life cycle. Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase. Weaknesses Little flexibility for scope (*) changes. Clients’ not being able to see the product until it is completely finished. Unit tests act on a specific component of the system. For a developer. the waterfall process is your best bet. Conclusion If you’re working on a somewhat traditional project (for instance. Project Lifecycles (version 3) 10 / 87 . The methodology is the least flexible and most obsolete of the life cycle models. while system tests act on the system as a whole. Well suited to projects that have low risk in the areas of user interface and performance requirements.Step 5: Implementation Code is produced from the deliverables of the design phase during implementation. System limitations not being discovered until later in the development cycle. Each phase has specific deliverables. Implementation my overlap with both the design and testing phases. the implementation is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase. this is the main focus of the life cycle because this is where the code is produced. an accounting system) where the features are defined a priori and it’s possible to freeze the specification. Unit tests and system/acceptance tests are done during this phase. Step 6: Testing During testing.

Testing is performed at all stages of the life-cycle. you initiate the project. integration testing during high-level design and unit testing during the detailed design. The Steps Step 1: Project initiation At the very top of the V-shaped waterfall methodology. Project Lifecycles (version 3) 11 / 87 .1.2 * * The V-Shaped Waterfall Methodology Introduction This methodology is similar to the waterfall methodology except it emphasizes on the testing activities up front instead of later in the lifecycle. The initiation step is the first phase of the application development and life cycles during which enough of the application’s requirements and architecture are produced so that agreement can be reached between the development organization and the customer organization regarding the goals and scope (*) of the following phases. This includes system and functional testing during requirements gathering.1.

Step 4: Low Level Design (Detailed Design) A low level design has nuts and bolts type detail in it which must come after high level design has been signed off by the users. typically by its developer or by a peer programmer. Step 3: High Level Design High Level Design means precisely that. as necessary establish controls. Step 9: Integration Testing The testing of a partially integrated application to cause failures resulting from defects involving the interaction of tested components.Step 2: Planning By carefully planning each work activity. Project Lifecycles (version 3) 12 / 87 . you will be better able to recognize safety concerns and issues. and thereby carry out the work more safely. Step 6: Unit Test Planning The task of planning the ‘unit test activities’ that will take place on a project. a Java class) of software. It should have very little detail on implementation.g. Step 5: Code (Coding/Programming) The (manual) task of creating a software component by transforming a software design into source code written in a programming language.e. and in some cases not even details such as database type (relational or object) and programming language and platform. Step 7: Unit Testing Unit testing is the testing of an individual unit (the smallest software component that can be treated as a relatively independent blackbox module. no explicit class definitions. as the high level design is much easier to change than the low level design. i. Step 8: Integration Test Planning The task of planning the ‘integration test activities’ that will take place on a project. e.. A high level design discusses an overall view of how something should work and the top level components that will comprise the proposed solution.

Strengths Simple and easy to use. Project Lifecycles (version 3) 13 / 87 . like the waterfall model. Works well for small projects where requirements are easily understood. Little flexibility and adjusting scope (*) is difficult and expensive. Weaknesses Very rigid. V-shaped waterfall process is your best bet. Model doesn’t provide a clear path for problems found during testing phases. Each phase has specific deliverables. blackbox application against its requirements during the construction phase. Conclusion If you’re working on a somewhat traditional project where the features are defined a priori and testing is very important. Software is developed during the implementation phase. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. Step 11: System Testing The validation testing subactivity of testing of an integrated.Step 10: System Test Planning The task of planning the ‘system test activities’ that will take place on a project. so no early prototypes of the software are produced.

SSADM was declared as the standard to be applied for DP development projects of the British government. De Marco’s Structure Analysis.1. Since then. and contrasts with more contemporary Rapid Application Development methods such as DSDM.3 * * SSADM / Structured Systems Analysis & Design Methodology Introduction During the beginning of the Eighties. Yourdon’s Structured Design. SSADM was based on four previously specified approaches. i. it is freely available for use in industry and many companies offer support. an instance of Systems thinking Larry Constantine. a precursor of Jackson System.e. the complex method SSADM (Structured Systems Analysis and Design Method) was developed on behalf of the British government by the consulting company LBMS-Learmonth & Burchett Management Systems in cooperation with CCTA (Central Computer Telecommunications Agency). SSADM can be thought to represent a pinnacle of the rigorous document-led approach to system design. training and Case tools for it. SSADM is one particular implementation and builds on the work of different schools of development methods. SSADM is a waterfall method by which an IS design can be arrived at. some of the key members of which included: Peter Checkland. In 1983. Jackson. SSADM is an open standard. Chris Gane & Trish Sarson. developer of Jackson Structured Programming Project Lifecycles (version 3) 14 / 87 . developer of Structured Design and inventor of data flow diagrams. developer of the Soft Systems Methodology. authors of Structured Systems Analysis: Tools and Techniques Ed Yourdon. the French system MERISE and Jackson’s Structured Programming. Since then SSADM has been further refined and version 4 was launched in 1990.1. it has been permanently upgraded. developer of the Yourdon method in Structured programming Michael A.

Sign up to vote on this title
UsefulNot useful