Introduction When Lifecycle People Products Management Development Tailoring Other DSDM Consortium. DSDM Public Version 4.

Size: px
Start display at page:

Download "Introduction When Lifecycle People Products Management Development Tailoring Other. 2002-2008 DSDM Consortium. DSDM Public Version 4."

Transcription

1 DSDM Public Version 4.2 Manual Introduction When Lifecycle People Products Management Development Tailoring Other DSDM Consortium [ :58:39]

2 DSDM Public Version Introduction Introduction When Lifecycle People Products Management Development Tailoring Other DSDM: Enabling Business Agility Introduction What is DSDM? There is increasing pressure on organisations to deliver working systems to business in ever shorter timescales. The processes by which systems are developed need to be agile and deliver what the business needs when it needs it. DSDM is a framework based on best practice and lessons learnt since the early 1990's by DSDM Consortium members. It provides a flexible yet controlled process that can be used to deliver new systems, which combines the most effective use of people's knowledge, tools and techniques such as prototyping to achieve tight project delivery timescales. Typically, a DSDM project will deliver an operational system within six months. Time to market is of the essence in most organisations together with robust systems that do not damage their reputation, whether they operate in the public or private sector, in business, education, or any other sphere. DSDM has primarily been used as an approach for IT projects; however, it is appropriate to business change projects and programmes. Such projects may have a large amount of technology change or no technology element at all. The DSDM framework provides an ideal basis for an even-handed development and implementation process, which encompasses people (e.g. organisation, staff, skills and capabilities), the technology that supports them (e.g. IT, office automation and communications) and the processes that bind them all together (in line with the business strategy). DSDM is an essential tool to effectively: understand plan communicate control deliver all projects (IT or Business Change). DSDM and extreme Programming (XP) This version of DSDM contains guidance on how to use XP in conjunction with DSDM. Combining XP and DSDM produces a robust and rigorous hybrid that is scalable and sustainable for projects and organisations whether small, medium or large. This combination brings together the energy and invention of XP with the proven maturity and commercial know-how of DSDM. The inclusion of XP confirms the DSDM framework's position as a repository for system development best practice specifically in relation to the Agile Alliance and the Agile Manifesto and, furthermore, demonstrates how the DSDM Framework including the lifecycle is relevant for this type of development approach. (1 of 4) [ :42:45]

3 DSDM Public Version Introduction Why use DSDM? DSDM is a vendor-independent framework that recognises that more projects fail because of people issues than technology. The focus is on helping people to work effectively together to achieve the business goals. DSDM is also tool and technique independent enabling it to be used in any business and technical environment without tying the method users to any particular vendor. Many system development projects fail to meet the expectations of the end users. Such project failures can be classified into one of five basic types: 1. The system fails to meet the business requirements for which it was developed. The system is either abandoned or expensive adaptive maintenance is undertaken. 2. There are performance shortcomings in the system, which make it inadequate for the users' needs. Again, it is either abandoned or amended incurring extra costs. 3. Errors appear in the developed system causing unexpected problems. Patches have to be applied at extra cost. 4. Users reject the imposition of the system, for political reasons, lack of involvement in its development or lack of commitment to it. 5. Systems are initially accepted but over time become impossible to maintain and so pass into disuse. DSDM aims to prevent all five types of project failure. A fundamental assumption of the DSDM approach is that nothing is built perfectly first time, but that 80% of the solution can be produced in 20% of the time that it would take to produce the total solution. A basic problem with less agile approaches is the expectation that potential system users can predict what all their requirements will be at some distant point in time. This problem is compounded by the fact that the mere existence of a new system affects the users' requirements because the methods of working have changed. In the classical, sequential (or "waterfall") approach, the next step cannot be started until the previous step is completed and fully tested. In practice, a lot of time is spent in getting from the 80% solution to the total solution, with the assumption that no step ever needs to be revisited. This means that considerable time is spent going back to "completed" steps and unravelling the defects from work that has previously been accepted. The result is that projects are delivered late and over budget or they fail to meet the business needs since time is not spent reworking the requirements. DSDM assumes that all previous steps can be revisited as part of its iterative approach. Therefore, the current step need be completed only enough to move to the next step, since it can be finished in a later iteration. The premise is that the business requirements are likely to change anyway as understanding increases, so any further work would have been wasted! Systems built using the DSDM approach address the current and imminent needs of the business rather than the traditional approach of attacking all the perceived possibilities. The resulting system is, therefore, expected to better fit to the true business needs, be easier to test and be more likely to be accepted into the users' working practices. Since the development cost of most applications is only a small part of the total lifecycle costs, it makes sense to build simpler systems that are fit for purpose and easier to maintain and modify after their initial development. The latter is possible since maintenance can be treated as a further incremental delivery towards the total solution. DSDM is not only about developing new systems. Enhancements to existing systems can be created using DSDM. (2 of 4) [ :42:45]

4 DSDM Public Version Introduction Why use DSDM and XP? There are a number of resistors to change that are experienced by XP practitioners, i.e. reasons why organisations do not immediately embrace the ideas of XP. For example: XP is perceived as simply JDI (Just Do It) It's just too extreme for us to use here It's not scalable It s not maintainable. Another reason to use DSDM and XP together is that they are synergistic, for example DSDM focuses on the whole lifecycle whereas XP is stronger on the detailed disciplines of programming. Combining XP with the rigorous yet Agile approach of the DSDM framework addresses the above issues through: Recognised project governance Fundamental pre-coding activities Project risk management Recognition of technical and business organisational standards Team dynamics Team collaboration Extended roles and responsibilities Quality management above and beyond code quality DSDM and project success DSDM aims not only to prevent failure but to bring success, by delivering systems that: satisfy the real requirements of business, in order of importance support the way the business needs to work are delivered on time and within budget are delivered quickly, and yet are robust and right (e.g. the right functionality, performance, security and maintainability) Systems built with DSDM are not developed quickly at the expense of quality. DSDM focuses on the priorities of the business and delivers what can safely be delivered within the time and cost constraints of the project, in priority order determined by the business needs and the objectives of the project. Summary of the benefits of using DSDM Using an iterative process based on prototyping, DSDM involves the end-users throughout the project lifecycle. This has many benefits, for example: the users are more likely to claim ownership of the system the risk of building the wrong system is greatly reduced the final system is more likely to meet the users' real business requirements the users will be better trained, since their representatives will define and co-ordinate the training required implementation is more likely to go smoothly, because of the co-operation of all parties concerned throughout development. (3 of 4) [ :42:45]

5 DSDM Public Version Introduction What is in the Framework? This product provides a framework for development projects that encompasses all aspects for successful delivery: people, process and technology - with the emphasis on people, since more projects fail because of some people-based problem than for any other reason. The framework is based on nine Underlying Principles that enable projects to deliver what the organisation needs when it needs it. The framework defines a set of phases that any new/changing system (IT or business) will pass through - from initial identification of a problem or opportunity to be addressed through the development of the new/changed system to keeping the system operating successfully. These are described in the Process Overview. Various products are produced within each phase. These are defined to a level that enables them to be used in any development environment. As stated above, the people aspects are essential, so DSDM defines key roles and responsibilities for people working inside and alongside the development. Every project will have the need for management techniques to control the process, such as good project planning, risk management, quality management. DSDM provides guidance on management techniques focusing on aspects of control that are specific to fast-moving development work. The Management Techniques section covers all the essentials needed for a controlled and yet flexible approach. Management is not the complete answer, the people within a project will be carrying out various activities from identifying how to create the solution to the business problem or opportunity through building and testing the solution to putting it into operation. DSDM has several core Development Techniques that assist the project workers in these activities. DSDM recognises that every project is unique in some way. Hence, a list of factors to consider when starting a DSDM project are provided in the When to Use DSDM section together with a Suitability Risk/List for ascertaining early in the project what aspects may cause problems later. Moreover, projects come in all sizes and guises, so guidance on Tailoring DSDM for specific projects is also provided. Lastly for those organisations (or parts of organisations) that have never used DSDM before, guidance is provided about Introducing DSDM into an organisation. If you are intending to use DSDM external to your own organisation commercially you must be a Member of the DSDM Consortium and become a Licensed Reseller. Click here to find out about joining the Consortium DSDM Consortium (4 of 4) [ :42:45]

6 DSDM Public Version What's New Introduction When Lifecycle People Products Management Development Tailoring Other How to use this site Introduction The DSDM on-line manual can be read sequentially from start to finish by following the "Next" links on each page (at the top and bottom right). You can also browse each section from the menus at the top, or get to the full site map at any time using the manual logo at the top left. For those who need a different route, this section helps you to find the best path through the manual. The routes are provided from four perspectives: Someone new to DSDM and needing a broad understanding of what is in DSDM, why it is the way it is and how it works before going into the detail Someone who has just been assigned to a DSDM project, knows the DSDM role that they will hold and wants to know what this means for them Someone familiar with DSDM in previous versions Someone who understands this version of DSDM. New to DSDM? For quick understanding of the basics of DSDM: How the Process Works explains some of the important techniques of DSDM projects. The Process Overview describes the phases that a DSDM project goes through. The Underlying Principles show the basic philosophy that guides all DSDM projects. The People Overview covers the DSDM roles and how they work together - in line with the principles. After reading these, depending on your personal interest, look at the Management Techniques Overview, the Development Techniques Overview and the Products Overview to gain an understanding of what DSDM contains. The When to Use section will be essential reading when you are considering using DSDM on a particular project. If DSDM has not been used in your organisation before, read the guidance on Introducing DSDM into an Organisation. Just been assigned a DSDM role? Go to the People Overview and select the role from the list. This will take you to a description of the the role and its activities and responsibilities throughout the project. Links to other parts of the DSDM manual are supplied from the role description. Familiar with DSDM in previous versions? Read What's New in Version 4.2 Use the Site Map to find what you are looking for. (1 of 2) [ :09:27]

7 DSDM Public Version What's New Familiar with DSDM Version 4.2? Use the Site Map to find what you are looking for DSDM Consortium (2 of 2) [ :09:27]

8 DSDM Public Versionl Overview Introduction When Lifecycle People Products Management Development Tailoring Other Process Overview Introduction In line with the fifth underlying principle, the project lifecycle that DSDM uses is iterative and incremental. So the computer system may not be delivered to the business in one go, but in a series of increments, which increase what it does each time. In this way, urgent business needs can be addressed early while less immediately important functionality is delivered later. The iterative nature of DSDM enables users to see work under construction, comment on it and request changes during the development of an increment. The lifecycle description below is not the whole picture; How the Process Works provides an overview of key techniques used within DSDM to ensure successful delivery on time. DSDM is more a framework than a method. It does not say how things should be done in detail, but provides a skeleton process and product descriptions that are to be tailored to suit a particular project or a particular organisation. The project process, as shown in the figure above, has five phases: Feasibility Study, Business Study, Functional Model Iteration, Design and Build Iteration and finally Implementation in the working environment. These are preceded by the Pre-Project phase and end with the Post-Project phase. The Feasibility and Business Studies are done sequentially. They set the ground rules for the rest of development that is iterative and incremental and therefore they must be completed before any further work is carried out on a given project. How the three later phases overlap and merge is left to a particular project to decide. This will depend on several things, primarily the nature of the system under construction and the tools being used to develop it. After the project has delivered the solution to the business problem or opportunity, the project team is disbanded and the Post- Project phase comes into play: this covers activities such as keeping the solution operating effectively and checking that the expected business benefits have been achieved. Each phase of the process has a minimum set of products emanating from it. Each of the products has a defined purpose and a set of quality criteria by which achievement of that purpose can be assessed. How the products will be produced and what they will contain is left to the individual organisation or project to decide. (1 of 4) [ :45:05]

9 DSDM Public Versionl Overview Pre-Project The Pre-Project phase ensures that only the right projects are started and that they are set up correctly. Once it has been determined that a project is to go ahead, funding is available, etc., the initial project planning for the Feasibility Study is done. Then the project proper begins with the Feasibility Study. The Feasibility Study An important aspect of the Feasibility Study is the assessment of whether DSDM is the right approach for the project. The normal considerations in a Feasibility Study are also present, such as a definition of the problem to be addressed together with assessments of the likely costs and of the technical feasibility of delivering a computer system to solve the business problem. Given that DSDM is to be used for the development of systems that are needed urgently, the Feasibility Study is necessarily short, and should last no more than a few weeks. This may have an impact on an organisation's standards for an acceptable Feasibility Report. There is not sufficient time in DSDM projects to produce large documents unless they are absolutely necessary. Therefore the Feasibility Report will cover all the usual topics but not in great detail. The DSDM philosophy is to do enough and no more. As well as a Feasibility Report, there are two other products from the Feasibility Study. Both are produced to support the conclusions of the Feasibility Report. The first is an Outline Plan for development, which will add weight to the findings that the desired outcome is achievable and the second is a Feasibility Prototype. The prototype is an optional product to demonstrate that a solution is possible. It may not be a piece of software: it could be document-based. The Business Study Having decided in the Feasibility Study that DSDM is indeed the way to go, the Business Study provides the basis for all subsequent work. Like the Feasibility Study, it is as short as possible (the duration measured in weeks rather than months), while achieving sufficient understanding of the business requirements and technical constraints to move forward with safety. As its name suggests the prime focus of attention is on the business processes affected and their information needs. The short timescales of a DSDM project mean that this activity has to be very strongly collaborative, using a series of facilitated workshops of knowledgeable staff who can quickly pool their knowledge and gain consensus as to the priorities of the development. The result of these workshops will be the Business Area Definition which will not only identify the business processes and associated information but also the classes (or types) of users who will be affected in any way by the introduction of the system. From these user classes, the individuals who will participate in the development will be identified and agreement reached with their management as to their involvement. The key users in a DSDM project are the Ambassador Users. Ambassador Users are so called because they operate in the same way as diplomatic ambassadors. They reside temporarily in the project team and provide a two-way channel of communication between the business and development communities. Their presence is essential to the success of a DSDM project. They are not only responsible for providing information to the project, but also for ensuring that the wider business community is kept up-to-date with progress. All key project roles in DSDM (including the Ambassador User role) have clearly defined responsibilities, since DSDM's strength is in helping people to work effectively together. Each of the requirements identified during the Feasibility and Business Studies has to be prioritised and recorded in the Prioritised Requirements List so that the most important features will be developed in preference to less essential parts that can be added later if required. The prioritisation will principally be led by business need but will also take into account the technical constraints which may drive some requirement to be satisfied first even though it may be less important in business terms. Some nonfunctional requirements, such as security, may also affect the prioritisation. Because parts of the software will begin to be produced in the next phase (the Functional Model Iteration), it is not only important to understand the functionality to be developed but also the system architecture that will be used. So another product from the Business Study is the System Architecture Definition, which describes the development and operational platforms as well as the architecture of the software to be developed in terms of its major components and their interfaces. As with everything else produced during the Business Study, the System Architecture Definition will be refined during later work and may change as the project progresses. Last but not least, the Outline Plan produced as part of the Feasibility Study is refined to produce the Development Plan. This provides the detail of how development will be carried out during the Functional Model Iteration and Design and Build Iteration phases using techniques such as modelling and prototyping. It will also include how the activities and products are checked and controlled as they are developed through timeboxing, risk management, configuration management, quality management and testing. (2 of 4) [ :45:05]

10 DSDM Public Versionl Overview Functional Model Iteration The focus of Functional Model Iteration is on refining the business-based aspects of the computer system, i.e. building on the highlevel processing and information requirements identified during the Business Study. To this end both standard analysis models and software are produced. Both the Functional Model Iteration and the Design and Build Iteration consist of cycles of four activities: 1. Identify what is to be produced. 2. Agree how and when to do it. 3. Create the product. 4. Check that it has been produced correctly (by reviewing documents, demonstrating a prototype or testing part of the software). The Functional Model that is built up in these cycles consists both of analysis models and of software components, which contain the major functionality and will satisfy some of the non-functional requirements, particularly the requirements relating to ease of use. The software parts of the Functional Model are tested as they are produced. This includes technical unit testing, but should also include as many other classes of testing as possible including mini-acceptance tests by the Ambassador Users as soon as new components are available. The focus of testing in the Functional Model is necessarily on what the components do (however limited that is) and whether or not they form the basis of a usable set of functionality. Non-functional aspects such as performance are tested in the Design and Build Iteration. This gives rise to the backwards arrow in the process diagram above from the Design and Build Iteration to the Functional Model Iteration. Any non-functional requirements not captured already should be captured during the Functional Model Iteration ready for the Design and Build Iteration. It will often be easier, and indeed more sensible, to address the detail of an area of functionality together with its non-functional aspects in one chunk before addressing the detail of another area. The extent to which the Functional Model Iteration and Design and Build Iteration merge, overlap and move backwards and forwards between each other will depend largely on how the application being built can be partitioned into smaller functioning areas and the facilities of the development environment. The preconditions for moving from functional modelling to design and build include agreement of a Functional Prototype that may or may not be fully automated. The Functional Prototype may be for only part of the Functional Model. This means that design and build activities may happen concurrently with the functional prototyping activities. Similarly, in a large DSDM project, the subsequent Implementation may be phased, so design and build may be concurrent with some implementation. Design and Build Iteration The Design and Build Iteration is where the computer system is engineered to a sufficiently high standard to be safely placed in the hands of the users. The major product here is the Tested System. The DSDM process diagram does not show testing as a distinct activity because testing is happening throughout both the Functional Model Iteration and the Design and Build Iteration. Some environments or contractual arrangements will require separate testing phases to be included at the end of the development of the increment, but this should not be the major activity encountered in more traditional approaches to development. Testing is just as important in DSDM and consumes just as much effort, but it is spread throughout development. The Tested System will not necessarily satisfy all the identified requirements, but it will satisfy all the requirements that have been agreed for the current increment. Due to the time constraints, some lesser parts of the system will have been agreed to be left to a later date. However, the core of requirements (what DSDM calls the minimum usable subset) will be contained in the Tested System, with as many other parts as time allows. Implementation The Implementation phase covers the cutover from the development environment to the operational environment. This includes training the users who have not been part of the project team. Iteration of the Implementation phase is applicable when the system is being delivered to a dispersed user population over a period of time. The products of this phase include the Delivered System that contains all the agreed documentation, including the User Documentation. The User Documentation is completed in this phase but must have been started earlier during the Design and Build Iteration. One of the responsibilities of the Ambassador Users is to ensure the correct production of the User Documentation and training, thus ensuring that the correct perspective is present. (3 of 4) [ :45:05]

11 DSDM Public Versionl Overview The other product of this phase is the Increment Review Document. This is produced immediately the computer system or increment is deemed complete. The Increment Review Document is used to summarise what the project has achieved in terms of its short-term objectives. In particular, it reviews all the requirements that have been identified during development and assesses the position of the system in relation to those requirements. There are four possible outcomes (three of which are shown by returning arrows on the DSDM process diagram above). The four outcomes are: All requirements have been satisfied. Hence, no further work is currently needed - and no returning arrow. A major area of functionality was discovered during development that had to be ignored for the time being in order to deliver on the required date. This means returning to the Business Study and taking the process on from there. Lower priority functionality, which was known, had to be left out because of the timescale. This is now to be added, so the process returns to the Functional Model Iteration. An area of lesser technical concern was omitted again due to time pressure, but can now be addressed by returning to the Design and Build Iteration. Post-Project The Post-Project phase keeps the solution operating effectively. The iterative and incremental nature of DSDM means that maintenance can be viewed as continuing development. Maintenance is an expected part of a system's lifecycle, which can be accommodated using much the same approach as the initial development. Non-urgent fixes and enhancements may be batched up and implemented using DSDM techniques. This work should follow the DSDM principles with a high level of user involvement and should be treated as further iterations of the system, going round the DSDM method again starting with a quick pass through the Business Study DSDM Consortium (4 of 4) [ :45:05]

12 DSDM Public Version How the Process Works Introduction When Lifecycle People Products Management Development Tailoring Other How the Process Works Introduction The five most important factors to for a successful DSDM project are strong user participation in the development activities, timeboxing, requirements prioritisation, facilitated workshops and prototyping. How these make the process work are covered in this section. Flexing requirements The four possible outcomes described at the end of description of the Implementation phase in the Process Overview are a clear demonstration of the major difference between DSDM and traditional approaches to software development. Traditionally, requirements are fixed and software is delivered which satisfies all of them. To achieve this, time and resources vary during development. In DSDM, the exact opposite is true, time is fixed for the life of a project, and resources are fixed as far as possible, but the requirements that will be satisfied are allowed to change. Hence there is a need to prioritise requirements as they are elicited during the Business Study and refined during the lifecycle. The flexibility of requirements to be satisfied has significant impact on the development processes and controls, and on acceptance of the system. One of the nine underlying principles of DSDM is that fitness for business purpose is the essential criterion for the acceptance of deliverables. This moves away from the approach of satisfying all the "bells and whistles" in a requirements specification, while maintaining a qualityoriented approach to development. The basic mechanism for handling flexibility of requirements in DSDM is timeboxing. A timebox is a simple concept: a period of time with a fixed completion date. DSDM refines the concept of timeboxing by nesting shorter timeboxes within the higher-level timebox that delivers an operational solution. It is these nested timeboxes that demonstrate progress and also drive the project forward. Fixing completion dates will not work on its own. Clear but negotiable prioritisation of what must be achieved within the timebox is also required. DSDM applies the MoSCoW rules for prioritising the requirements addressed by each timebox to ensure that what is delivered now will satisfy the immediate business needs. Timeboxing as a milestone-to-milestone process is really key and can work wonders even if when it isn't done very well. No other method exists with such a well-defined process for milestone-to-milestone work. (1 of 3) [ :45:40]

13 DSDM Public Version How the Process Works Communication channels DSDM is above all about improving the communication channels between the various stakeholders and the project team. One of the most effective mechanisms for improving communications is the facilitated workshop. This is used throughout DSDM to ensure that the project works quickly towards the best solution for all concerned. DSDM also achieves delivery to tight timescales through shortening communication lines between users and IT staff within the project, between analysts and designers, between team members, and between differing levels of management. The mechanisms by which these communication lines are shortened differ from one channel to another. In particular, the communication between developers and users is eased by the use of prototyping rather than the production of lengthy documents. This is why DSDM defines a Functional Model rather than a functional specification. Documents in DSDM DSDM incorporates an approach for defining what the necessary documentation set will be for a given project. Much of the documentation that is traditionally produced is for the transfer of ideas from one developer to another or from the developers to the users. By keeping mixed user/developer teams small and constant throughout development, DSDM renders such documents largely unnecessary. For the management documentation, local practices should be followed but perhaps scaled down to minimise unnecessary barriers to rapid movement through the project. On the technical side, DSDM provides guidance on how to decide what sort of documentation it is necessary to control and why. The basic criterion for deciding to control a technical document is that it is either essential to the developers' progress to implementation or it is required for maintenance purposes. When the documentation that is often required to be delivered is compared with the documentation that is actually useful after delivery, there is quite a wide gap. DSDM's focus on doing the minimum necessary for safety is one of the ways that systems can be delivered faster and yet meet their quality objectives. Some documents may be required for audit purposes. A question that is often asked is "How much documentation is enough?" Enough can be defined as when any extra documentation will not add to the understanding of what is being built. For example, in traditional projects, a lot of effort is devoted to writing, reviewing, agreeing and maintaining a detailed requirements specification, which often has zero value in the longer term. People, Process and Technology The DSDM approach views people, process and technology, as the intertwined components of any business solution. Changes to one component will impact the others. A business change project must include and manage all three aspects. The basic approach to providing business solutions should be: understanding the business objectives re-engineering business processes and aligning people and technology to achieve the objectives. (2 of 3) [ :45:40]

14 DSDM Public Version How the Process Works Whilst the standard DSDM lifecycle does not expressly encompass strategic business planning methods, the approach assumes that a business strategy exists and that it both influences the DSDM project, and is influenced by it. A feedback mechanism should be established to facilitate this DSDM Consortium (3 of 3) [ :45:40]

15 DSDM Public Version Principles Introduction When Lifecycle People Products Management Development Tailoring Other Underlying Principles The following principles are the foundations on which DSDM is based. Each one of the principles is applied as appropriate in the various parts of the method. I. Active user involvement is imperative DSDM is a user-centred approach. If users are not closely involved throughout the development lifecycle, delays will occur as decisions are made and users may feel that the final solution is imposed by the developers and/or their own management. Users are not outside the development team acting as suppliers of information and reviewers of results but are active participants in the development process. II. III. DSDM teams must be empowered to make decisions The focus is on frequent delivery of products DSDM teams consist of both developers and users. They must be able to make decisions as requirements are refined and possibly changed. They must be able to agree that certain levels of functionality, usability, etc. are acceptable without frequent recourse to higher-level management. A product-based approach is more flexible than an activity-based one. The work of a DSDM team is concentrated on products that can be delivered in an agreed period of time. This enables the team to select the best approach to achieving the products required in the time available. By keeping each period of time short, the team can easily decide which activities are necessary and sufficient to achieve the right products. IV. Fitness for business purpose is the essential criterion for acceptance of deliverables Note: Products include interim development products, not just delivered solutions. The focus of DSDM is on delivering the necessary functionality at the required time. The computer system can be more rigorously engineered later if such an approach is acceptable. Traditionally the focus has been on satisfying the contents of a requirements document and conforming to previous deliverables, even though the requirements are often inaccurate, the previous deliverables may be flawed and the business needs may have changed since the start of the project. (1 of 3) [ :46:20]

16 DSDM Public Version Principles V. Iterative and incremental development is necessary to converge on an accurate business solution DSDM allows systems to grow incrementally. Therefore the developers can make full use of feedback from the users. Moreover partial solutions can be delivered to satisfy immediate business needs. Iteration is inherent in all software development. DSDM recognises this and, by making it explicit, uses iteration to continuously improve the system being developed. When rework is not explicitly recognised in a development lifecycle, the return to previously "completed" work is surrounded by controlling procedures that slow development down. Since rework is built into the DSDM process, the development can proceed more quickly during iteration. VI. All changes during development are reversible To control the evolution of all products (documents, software, test products, etc.), everything must be in a known state at all times. This means that configuration management must be all-pervasive. VII. Requirements are baselined at a high level Backtracking is a feature of DSDM. However in some circumstances it may be easier to reconstruct than to backtrack. This depends on the nature of the change and the environment in which it was made. The ability to reverse changes is limited to within the development of an increment. Baselining high-level requirements means "freezing" and agreeing the purpose and scope of the system at a level that allows for detailed investigation of what the requirements imply. Further, more detailed baselines can be established later in the development, although the scope should not change significantly. Changing the scope defined in the baselined high-level requirements usually requires escalation. VIII. Testing is integrated throughout the lifecycle Testing is not treated as a separate activity. As the system is developed incrementally, it is also tested and reviewed by both developers and users incrementally to ensure that the development is moving forward not only in the right business direction but is technically sound. Early in DSDM, the testing focus is on validation against the business needs and priorities. Towards the end of a project, the focus is on verifying that the whole system operates effectively. (2 of 3) [ :46:20]

17 DSDM Public Version Principles IX. A collaborative and co-operative approach between all stakeholders is essential The nature of DSDM projects means that low-level requirements are not necessarily fixed when the developers are originally approached to carry out the work. Hence the short-term direction that a project takes must be quickly decided without recourse to restrictive change control procedures. The stakeholders include not only the business and development staff within the project, but also other staff such as Service Delivery or resource managers. When development is procured from an external supplier, both the vendor and the purchaser organisations should aim for as efficient a process as possible while allowing for flexibility during both the precontract phase and when the contracted work is carried out DSDM Consortium (3 of 3) [ :46:20]

18 DSDM Public Version When to Use DSDM Introduction When Lifecycle People Products Management Development Tailoring Other When to Use DSDM Assessing the risks The decision as to whether or not to use DSDM is an important one to be made at the outset of a development project. Some projects are clearly ideal for DSDM. Others require careful consideration to decide whether the use of DSDM will provide business benefits. To assist management in assessing the risks associated with a given project, DSDM provides a risk identification tool - the Suitability/Risk List. The list considers the critical success factors for DSDM and characteristics of projects that are especially effective for DSDM. Each potential project should be judged individually using the risk list. If the project provides a good match against the list, then DSDM can be considered a very appropriate development approach. However inability to satisfy all of the criteria does not automatically prohibit the use of DSDM. However, it will be necessary for risk management strategies to be developed to address any non-compliance. The criteria included within the DSDM Suitability/Risk List are intended as guidance material only and should not be considered exclusive. It is expected that an organisation using DSDM will enhance the list with their own specific factors identified from experience of using the method within their environment. The choice of DSDM as the development method should be carefully monitored during the early stages of the project. If it becomes apparent that the system does not clearly demonstrate all of the expected characteristics and yet the use of DSDM will still provide benefit, then again it is important that risk management strategies are developed to address the problem areas. When to use DSDM and XP This version of DSDM incorporates certain Extreme Programming (XP) techniques within the DSDM framework. The Suitability/Risk List has been extended so that it can be used to assess the risks of using DSDM and XP together. This has been done by including new questions specifically aimed at XP. If the project provides a good match against the list, then the combination of DSDM and XP can be considered an appropriate development approach. However failure to satisfy all of the criteria does not automatically prohibit the use of XP with DSDM but it will be necessary for risk management strategies to be developed to address any non-compliance. Further guidance is provided throughout the manual in the form of "Guidance for those looking to use XP with DSDM". Characteristics of systems where DSDM should be the Framework of choice In addition to considering the critical success factors, DSDM will be especially effective for systems that demonstrate the following characteristics: interactive, where the functionality is clearly demonstrable at the user interface. DSDM is strongly based on incremental prototyping with close user involvement. Therefore users must be able to assess the functionality easily through viewing and operating working prototypes. Hence the need for demonstrable functionality. The user interface includes screens, reports and file-prints (where file-prints may be solely for interim demonstration and verification of the functionality). If the user interface is not highly demonstrable, there must some other way that users can verify that partially built solutions are correct. This characteristic relates in part to Principles I and IV. has a clearly defined user group. If the user group is not clearly defined, there may be a danger of driving the development from a wrong viewpoint or (worse) ignoring some important aspect of the project entirely. This characteristic relates to Principle I. (1 of 3) [ :48:33]

19 DSDM Public Version When to Use DSDM if computationally complex, the complexity can be decomposed or isolated. If the internals of the system are hard to understand via the user interface then there is a risk. The level of computational complexity is often quite difficult to determine in advance and will vary from one project to another. Moreover there can be interactions between different components, which can be difficult to identify up front. DSDM can be used where there is a great deal of computational complexity provided that the application can be decomposed to reduce the complexity. For instance, if an application requires some complex statistical modelling, a project may consider two approaches to development: using existing, well-tested statistical modelling components or developing the models from scratch. The first would be totally acceptable in a DSDM project. The second would require care in the use of the method, unless it is possible either to decompose the complexity into simpler components or to make it transparent at the user interface. If there is complexity but it can be isolated from the rest of the computer system, then it can be handled in a more formal manner and re-integrated later. This characteristic relates in part to Principle V. if large, possesses the capability of being split into smaller functional components. If the proposed computer system is large it should be possible to break it down into small, manageable chunks, each delivering some clear functionality. These can then be delivered sequentially or in parallel. Indeed, some of the functionality may be delivered using traditional waterfall methods. However, each sub-project must be constantly aware of the overall system architecture. Indeed, all aspects of the project must be controlled and co-ordinated. Note: When DSDM teams are working in parallel on a project, the number of teams should be minimised, without exceeding DSDM's recommended maximum team size. This will aid the overall control of the project and minimise the integration overheads. The task of managing and co-ordinating timeboxes should not be underestimated. This characteristic relates in part to Principles III and IV. time-constrained. There should be a fixed end date by which the project must be completed. If there is no real case for the end date to be fixed, it will be relatively easy to allow schedules to slip and the fundamental benefits of DSDM will be lost. The time constraint is usually defined by the business objectives but could also be due to the availability of IT staff within a defined timescale, the imminent removal of support for old technologies, etc. This characteristic relates in part to Principle III. the requirements can be prioritised. The requirements should be prioritised using the MoSCoW rules. Note: If the requirements have already been written before the decision to use DSDM is taken, then it will be necessary to gain acceptance from the "owner" of the project for the requirements to be variable, and to revisit them using the MoSCoW rules. This characteristic relates in part to Principle VII. the requirements are unclear or subject to frequent change. In periods of rapid change it may be difficult to specify the requirements in detail at the outset of the project. This makes traditional approaches unsuitable. DSDM is designed specifically to deal with requirements that change and evolve during a project. Many applications are difficult to specify in advance because the users do not know exactly what is needed at the outset. Examples include when a business process is being redesigned and when new products and services are being built. DSDM is well suited to building such applications because it enables users to change their minds as development proceeds. This characteristic is really checking whether or not there is anything of significance to discuss with the users during development. If the detail of the requirements for the system is clearly understood, there will be less ability to save time through prototyping with the users for requirements elicitation. If they are all fixed there will be less ability to allow some requirements to be left to later developments in order to meet the timescales required. This characteristic relates to Principles V and VI. (2 of 3) [ :48:33]

20 DSDM Public Version When to Use DSDM Characteristics of systems where special care is needed in applying DSDM Many systems may appear not to demonstrate compliance with the critical success factors and the required characteristics. However, if the development support environment is strong enough and the development team is experienced in the DSDM approach, benefits can be gained by using DSDM techniques where appropriate. There are some systems where using DSDM will need special care. Such systems will display one or more of the following characteristics. process control/real-time applications. Much of the processing of process control/real-time applications (e. g. systems that control manufacturing equipment, power plants or weaponry) is not visible at the user interface, is often very complex and cannot be decomposed into smaller components. In addition, extensive validation and verification is frequently needed. For these reasons DSDM would normally be considered unsuitable for such applications. requirements have to be fully specified before any programs are written. In some projects, it may be demanded or considered essential that the requirements be fully specified and approved before programming takes place. The attempted use of DSDM in this situation could be disastrous. DSDM is an iterative approach and the momentum and synergy of the DSDM project team would be seriously affected by defining all requirements in advance. Time delays in the project would inevitably occur while waiting for all the requirements to be defined, the value of business knowledge within the project team will diminish and senior management might seriously question the credibility of DSDM as a rapid development approach. Techniques such as facilitated workshops might still be useful for defining requirements but it is unlikely that full DSDM could be used. safety-critical applications. As well as the need for detailed specifications, the exhaustive validation and verification activities required for safety-critical systems (i.e. systems that can endanger lives) make it unlikely that they will be suitable for the iterative development approach of DSDM. It should be noted that safety-critical systems have been developed using DSDM. In this sort of project, the skill and experience of the Technical Co-ordinator will be a critical factor in ensuring success. delivering re-usable components. Projects may be required to produce re-usable components. Such components must be exactly right. Generally, the speedy delivery of business benefits and the creation of reusable components are two contradicting goals, with different sponsors. As you cannot have two sponsors, satisfy the business-benefit goal first, then move on to the second. That said, DSDM will be very suitable if the re-usable components are highly modular and can be built incrementally without prejudicing the rest of the application DSDM Consortium (3 of 3) [ :48:33]

Agile Projects 7. Agile Project Management 21

Agile Projects 7. Agile Project Management 21 Contents Contents 1 2 3 Agile Projects 7 Introduction 8 About the Book 9 The Problems 10 The Agile Manifesto 12 Agile Approach 14 The Benefits 16 Project Components 18 Summary 20 Agile Project Management

More information

DSDM DSDM. CONSORTiUM. CONSORTiUM. AgileBA. The Handbook for Business Analysts. Extract The Requirements Lifecycle In An Agile Project. www.dsdm.

DSDM DSDM. CONSORTiUM. CONSORTiUM. AgileBA. The Handbook for Business Analysts. Extract The Requirements Lifecycle In An Agile Project. www.dsdm. DSDM CONSORTiUM DSDM CONSORTiUM AgileBA The Handbook for Business Analysts Extract The Lifecycle In An Agile Project www.dsdm.org This Extract from AgileBA, The Lifecycle in an Agile Project, is based

More information

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process

More information

DSDM Case Study. An Agile Approach to Software Systems Development for the Highways Agency

DSDM Case Study. An Agile Approach to Software Systems Development for the Highways Agency DSDM Case Study An Agile Approach to Software Systems Development for the Highways Agency Government agencies are constantly striving to develop software systems that support business objectives, deliver

More information

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3)

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) 1st February 2006 Version 1.0 1 P3M3 Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce This is a Value

More information

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Objectives To explain how an iterative, incremental development process leads to faster delivery of

More information

Introduction... 2 Introducing the DSDM Agile Project Framework (AgilePF)...2 Introducing DSDM...2 Introducing Scrum...3

Introduction... 2 Introducing the DSDM Agile Project Framework (AgilePF)...2 Introducing DSDM...2 Introducing Scrum...3 Contents Introduction... 2 Introducing the DSDM Agile Project Framework (AgilePF)...2 Introducing DSDM...2 Introducing Scrum...3 AgilePF for Scrum... 4 Philosophy...4 Agile Values...4 Principles...5 Variables...8

More information

Agile Project Management Foundation and Practitioner Syllabus Summary

Agile Project Management Foundation and Practitioner Syllabus Summary Agile Project Management Foundation and Practitioner Syllabus Summary This document can be viewed as a comprehensive course outline OR a summary of the full course syllabus. In order to make it easier

More information

(Refer Slide Time: 01:52)

(Refer Slide Time: 01:52) Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This

More information

Introduction. Contents. Introducing the DSDM Agile Project Framework. Introducing DSDM

Introduction. Contents. Introducing the DSDM Agile Project Framework. Introducing DSDM Contents Introduction... 2 Introducing the DSDM Agile Project Framework... 2 Introducing DSDM... 2 Introducing Scrum... 3 The DSDM Agile Project Framework for Scrum... 4 Philosophy... 4 Values... 4 Principles...

More information

PRINCE2 and DSDM: Why should I use both?

PRINCE2 and DSDM: Why should I use both? PRINCE2 and DSDM: Why should I use both? Author: Dorothy Tudor - DSDM and PRINCE2 Practitioner and Trainer, a Certified ScrumMaster (Agile), ITIL Service Manager and a Director of the DSDM Consortium,

More information

Are waterfall and agile project management techniques mutually exclusive? by Eve Mitchell, PwC. 22 MARCH 2012 www.pmtoday.co.uk

Are waterfall and agile project management techniques mutually exclusive? by Eve Mitchell, PwC. 22 MARCH 2012 www.pmtoday.co.uk Are waterfall and agile project management techniques mutually exclusive? by Eve Mitchell, PwC 22 MARCH 2012 www.pmtoday.co.uk Projects need to be managed to be successful Change is a ubiquitous feature

More information

The profile of your work on an Agile project will be very different. Agile projects have several things in common:

The profile of your work on an Agile project will be very different. Agile projects have several things in common: The Agile Business Analyst IT s all about being Agile? You re working as a Business Analyst in a traditional project environment, specifying the requirements for IT Developers to build. Suddenly everyone

More information

In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is:

In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is: In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is: The period of time that starts when a software product is conceived and ends when the product is no longer

More information

Agile for Project and Programme Managers

Agile for Project and Programme Managers Agile for Project and Programme Managers Author Melanie Franklin Director Agile Change Management Limited Introduction I am involved in a mixture of assignments for different organisations across Europe

More information

Introduction to CiCS Agile Projects

Introduction to CiCS Agile Projects Introduction to CiCS Agile Projects This is an introduction to how we run CiCS projects. It s written for people who will be involved in our projects, but may be of interest more generally. Background

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,

More information

TenStep Project Management Process Summary

TenStep Project Management Process Summary TenStep Project Management Process Summary Project management refers to the definition and planning, and then the subsequent management, control, and conclusion of a project. It is important to recognize

More information

Quality assurance in an Agile delivery method

Quality assurance in an Agile delivery method Quality assurance in an Agile delivery method Guy Nelson (Quality Manager, Fidelity International) Barbara Roberts (Accredited DSDM Consultant) April 2006 Agenda The Challenges to Quality Assurance CMMi

More information

Learn Agile Project Management In 60 Minutes Flat! Agile Project Management Overview. Agile Project Management

Learn Agile Project Management In 60 Minutes Flat! Agile Project Management Overview. Agile Project Management Learn Agile Project Management In 60 Minutes Flat! Agile Project Management Overview Agile Project Management Copyright Copyright 2013 by David Geoffrey Litten Cover and internal design David Geoffrey

More information

Process Methodology. Wegmans Deli Kiosk. for. Version 1.0. Prepared by DELI-cious Developers. Rochester Institute of Technology

Process Methodology. Wegmans Deli Kiosk. for. Version 1.0. Prepared by DELI-cious Developers. Rochester Institute of Technology Process Methodology for Wegmans Deli Kiosk Version 1.0 Prepared by DELI-cious Developers Rochester Institute of Technology September 15, 2013 1 Table of Contents 1. Process... 3 1.1 Choice... 3 1.2 Description...

More information

Software Life Cycle. Main issues: Discussion of different life cycle models Maintenance or evolution

Software Life Cycle. Main issues: Discussion of different life cycle models Maintenance or evolution Software Life Cycle Main issues: Discussion of different life cycle models Maintenance or evolution Not this life cycle SE, Software Lifecycle, Hans van Vliet, 2008 2 Introduction software development

More information

Purpose: Content: Definition: Benefits: outputs outcomes benefits Business Case dis-benefit Key Responsibilities: Approach: Executive Developed

Purpose: Content: Definition: Benefits: outputs outcomes benefits Business Case dis-benefit Key Responsibilities: Approach: Executive Developed Key Learning Points The Swirl Logo is a trade mark of the AXELOS Limited. Is used by the Project Board throughout the project to verify its continued viability:- Is the investment in this project still

More information

Software Engineering. What is a system?

Software Engineering. What is a system? What is a system? Software Engineering Software Processes A purposeful collection of inter-related components working together to achieve some common objective. A system may include software, mechanical,

More information

The Basics of Scrum An introduction to the framework

The Basics of Scrum An introduction to the framework The Basics of Scrum An introduction to the framework Introduction Scrum, the most widely practiced Agile process, has been successfully used in software development for the last 20 years. While Scrum has

More information

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur Module 2 Software Life Cycle Model Lesson 4 Prototyping and Spiral Life Cycle Models Specific Instructional Objectives At the end of this lesson the student will be able to: Explain what a prototype is.

More information

Agile So)ware Development

Agile So)ware Development Software Engineering Agile So)ware Development 1 Rapid software development Rapid development and delivery is now often the most important requirement for software systems Businesses operate in a fast

More information

Rapid Software Development

Rapid Software Development Software Engineering Rapid Software Development Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain how an iterative, incremental development process leads to faster delivery

More information

Integrating PRINCE2 and Scrum for successful new product development

Integrating PRINCE2 and Scrum for successful new product development 1 Goal Professional Services Pty Ltd 2 Renewtek Pty Ltd Integrating PRINCE2 and Scrum for successful new product development Rankins G J 1 and Kearns M 2 This paper was presented at the Australian Institute

More information

Development Methodologies Compared

Development Methodologies Compared N CYCLES software solutions Development Methodologies Compared Why different projects require different development methodologies. December 2002 Dan Marks 65 Germantown Court 1616 West Gate Circle Suite

More information

Life-Cycle Model. Software Life-Cycle Models. Software Development in Theory. Software Development in Practice

Life-Cycle Model. Software Life-Cycle Models. Software Development in Theory. Software Development in Practice Life-Cycle Model Software Life-Cycle Models Xiaojun Qi It specifies the various phases/workflows of the software process, such as the requirements, analysis (specification), design, implementation, and

More information

WHITE PAPER IT SERVICE MANAGEMENT IT SERVICE DESIGN 101

WHITE PAPER IT SERVICE MANAGEMENT IT SERVICE DESIGN 101 WHITE PAPER IT SERVICE MANAGEMENT IT SERVICE DESIGN 101 Prepared by: Phillip Bailey, Service Management Consultant Steve Ingall, Head of Service Management Consultancy 60 Lombard Street London EC3V 9EA

More information

Agile Project Management: Integrating DSDM Atern into an existing PRINCE2 environment Keith Richards, Director, Keith Richards Consulting

Agile Project Management: Integrating DSDM Atern into an existing PRINCE2 environment Keith Richards, Director, Keith Richards Consulting For Portfolio, Programme, Project, Risk and Service Management Agile Project Management: Integrating DSDM Atern into an existing PRINCE2 environment Keith Richards, Director, Keith Richards Consulting

More information

Document management concerns the whole board. Implementing document management - recommended practices and lessons learned

Document management concerns the whole board. Implementing document management - recommended practices and lessons learned Document management concerns the whole board Implementing document management - recommended practices and lessons learned Contents Introduction 03 Introducing a document management solution 04 where one

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

AGILE METHODOLOGY IN SOFTWARE DEVELOPMENT

AGILE METHODOLOGY IN SOFTWARE DEVELOPMENT AGILE METHODOLOGY IN SOFTWARE DEVELOPMENT Shivangi Shandilya, Surekha Sangwan, Ritu Yadav Dept. of Computer Science Engineering Dronacharya College Of Engineering, Gurgaon Abstract- Looking at the software

More information

Software Development Life Cycle

Software Development Life Cycle 4 Software Development Life Cycle M MAJOR A J O R T TOPICSO P I C S Objectives... 52 Pre-Test Questions... 52 Introduction... 53 Software Development Life Cycle Model... 53 Waterfall Life Cycle Model...

More information

A Capability Maturity Model (CMM)

A Capability Maturity Model (CMM) Software Development Life Cycle (SDLC) and Development Methods There are some enterprises in which a careful disorderliness is the true method. Herman Melville Capability Maturity Model (CMM) A Capability

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies If you are running a software project, one of the main questions you are likely to come across is which development methodology to use. There are as many opinions on

More information

Verification of need. Assessment of options. Develop Procurement Strategy. Implement Procurement Strategy. Project Delivery. Post Project Review

Verification of need. Assessment of options. Develop Procurement Strategy. Implement Procurement Strategy. Project Delivery. Post Project Review Who should read this fact sheet? Many construction clients are not regular purchasers of construction work. This fact sheet is an introduction to construction procurement for occasional clients with a

More information

Maturity Model. March 2006. Version 1.0. P2MM Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce

Maturity Model. March 2006. Version 1.0. P2MM Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce Maturity Model March 2006 Version 1.0 P2MM Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce This is a Value Added product which is outside the scope of the HMSO

More information

Foundations for Systems Development

Foundations for Systems Development Foundations for Systems Development ASSIGNMENT 1 Read this assignment introduction. Then, read Chapter 1, The Systems Development Environment, on pages 2 25 in your textbook. What Is Systems Analysis and

More information

SEEM4570 System Design and Implementation Lecture 10 Software Development Process

SEEM4570 System Design and Implementation Lecture 10 Software Development Process SEEM4570 System Design and Implementation Lecture 10 Software Development Process Software Development A software development process: A structure imposed on the development of a software product Also

More information

COMPARATIVE STUDY ON SOFTWARE PROJECT MANAGEMENT MODELS

COMPARATIVE STUDY ON SOFTWARE PROJECT MANAGEMENT MODELS COMPARATIVE STUDY ON SOFTWARE PROJECT MANAGEMENT MODELS *1 Mrs. Kalaivani S., * 2 Mrs. Kavitha S., *1 M.Phil Research Scholar, Department of Computer Science Auxilium College (Autonomous), Vellore, TamilNadu,

More information

1. What is PRINCE2? Projects In a Controlled Environment. Structured project management method. Generic based on proven principles

1. What is PRINCE2? Projects In a Controlled Environment. Structured project management method. Generic based on proven principles 1. What is PRINCE2? Projects In a Controlled Environment Structured project management method Generic based on proven principles Isolates the management from the specialist 2 1.1. What is a Project? Change

More information

PROJECT MANAGEMENT FRAMEWORK

PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK DOCUMENT INFORMATION DOCUMENT TYPE: DOCUMENT STATUS: POLICY OWNER POSITION: INTERNAL COMMITTEE ENDORSEMENT: APPROVED BY: Strategic document Approved Executive Assistant to

More information

Dynamic System Development Method

Dynamic System Development Method Dynamic System Development Method Submitted by * : Benjamin J. J. Voigt Zürich, Switzerland S99-728-123 Supervisor: Prof. Dr. M. Glinz Advisor: Dipl.-Inf. C. Seybold Department of Information Technology

More information

Understanding Agile Project Management

Understanding Agile Project Management Understanding Agile Project Management Author Melanie Franklin Director Agile Change Management Limited Overview This is the transcript of a webinar I recently delivered to explain in simple terms what

More information

A. Waterfall Model - Requirement Analysis. System & Software Design. Implementation & Unit Testing. Integration & System Testing.

A. Waterfall Model - Requirement Analysis. System & Software Design. Implementation & Unit Testing. Integration & System Testing. Processing Models Of SDLC Mrs. Nalkar Sanjivani Baban Asst. Professor, IT/CS Dept, JVM s Mehta College,Sector 19, Airoli, Navi Mumbai-400708 Nalkar_sanjivani@yahoo.co.in Abstract This paper presents an

More information

10/4/2013. Sharif University of Technology. Session # 3. Contents. Systems Analysis and Design

10/4/2013. Sharif University of Technology. Session # 3. Contents. Systems Analysis and Design Session # 3 Contents Systems Analysis and Design 2 1 Tiers of Software Development 10/4/2013 Information system development project Realistic behavior 3 Information system development project System Development

More information

Basic Trends of Modern Software Development

Basic Trends of Modern Software Development DITF LDI Lietišķo datorsistēmu programmatūras profesora grupa e-business Solutions Basic Trends of Modern Software Development 2 3 Software Engineering FAQ What is software engineering? An engineering

More information

AGILE vs. WATERFALL METHODOLOGIES

AGILE vs. WATERFALL METHODOLOGIES AGILE vs. WATERFALL METHODOLOGIES Introduction Agile and waterfall are two major methodologies that software developers and project managers have the option of using. Some of the goals of developers and

More information

A Comparison between Five Models of Software Engineering

A Comparison between Five Models of Software Engineering International Journal of Research in Information Technology (IJRIT) www.ijrit.com ISSN 2001-5569 A Comparison between Five Models of Software Engineering Surbhi Gupta, Vikrant Dewan CSE, Dronacharya College

More information

Advanced Software Engineering. Software Development Processes

Advanced Software Engineering. Software Development Processes Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Advanced Software Engineering Software Development Processes Prof. Agostino Poggi Software Development

More information

PRINCE2:2009 Glossary of Terms (English)

PRINCE2:2009 Glossary of Terms (English) accept (risk response) acceptance acceptance criteria activity agile methods approval approver assumption assurance A risk response to a threat where a conscious and deliberate decision is taken to retain

More information

White Paper IT Methodology Overview & Context

White Paper IT Methodology Overview & Context White Paper IT Methodology Overview & Context IT Methodologies - Delivery Models From the inception of Information Technology (IT), organizations and people have been on a constant quest to optimize the

More information

ASSESSMENT OF SOFTWARE PROCESS MODELS

ASSESSMENT OF SOFTWARE PROCESS MODELS ASSESSMENT OF SOFTWARE PROCESS MODELS Akhilesh Research Scholar, Department of Computer Science, Manav Bharti University, Solan (H.P.) ABSTRACT The field of software engineering is related to the development

More information

Various Software Development Life Cycle Models

Various Software Development Life Cycle Models Various Software Development Life Cycle Models Sahil Jindal, Puneet Gulati, Praveen Rohilla Dronacharya College of Engineering, India Abstract:An SDLC model is a conceptual framework describing different

More information

Skatteudvalget 2014-15 (2. samling) SAU Alm.del Bilag 48 Offentligt. Programme, Project & Service Management Analysis

Skatteudvalget 2014-15 (2. samling) SAU Alm.del Bilag 48 Offentligt. Programme, Project & Service Management Analysis Skatteudvalget 2014-15 (2. samling) SAU Alm.del Bilag 48 Offentligt Programme, Project & Service Management Analysis Table of Content 1 Executive Summary... 3 1.1 Scope of Work... 3 1.2 Methodology for

More information

A flexible approach to outsourcing in the financial services sector

A flexible approach to outsourcing in the financial services sector A flexible approach to outsourcing in the financial services sector A White Paper produced by Eversheds in association with Serco Global Services - February 2015 A flexible approach to outsourcing in the

More information

Software Development Process

Software Development Process Software Development Process A software development process, also known as software development lifecycle, is a structure imposed on the development of a software product. Similar terms include software

More information

Scrum, User Stories, and More! CSCI 5828: Foundations of Software Engineering Lecture 22 11/06/2014

Scrum, User Stories, and More! CSCI 5828: Foundations of Software Engineering Lecture 22 11/06/2014 Scrum, User Stories, and More! CSCI 5828: Foundations of Software Engineering Lecture 22 11/06/2014 1 Goals Cover Material from our User Stories Book Chapter 15: Using Stories With Scrum Chapter 16: Additional

More information

Software Process for QA

Software Process for QA Software Process for QA Basic approaches & alternatives CIS 610, W98 / M Young 1/7/98 1 This introduction and overview is intended to provide some basic background on software process (sometimes called

More information

Why the Traditional Contract for Software Development is Flawed

Why the Traditional Contract for Software Development is Flawed Why the Traditional Contract for Software Development is Flawed Susan Atkinson satkinson@gallenalliance.com Introduction Agile has entered the mainstream. In a recent survey, more than 50% of the respondents

More information

What is Agile Software Development?

What is Agile Software Development? What is Agile Software Development? Introduction What is agile software development, and what changes does it require of a tester? How does a tester become more effective in an agile environment? This

More information

Testing, What is it Good For? Absolutely Everything!

Testing, What is it Good For? Absolutely Everything! Testing, What is it Good For? Absolutely Everything! An overview of software testing and why it s an essential step in building a good product Beth Schechner Elementool The content of this ebook is provided

More information

In today s acquisition environment,

In today s acquisition environment, 4 The Challenges of Being Agile in DoD William Broadus In today s acquisition environment, it no longer is unusual for your program to award a product or service development contract in which the vendor

More information

CS435: Introduction to Software Engineering! " Software Engineering: A Practitioner s Approach, 7/e " by Roger S. Pressman

CS435: Introduction to Software Engineering!  Software Engineering: A Practitioner s Approach, 7/e  by Roger S. Pressman CS435: Introduction to Software Engineering! " " " " " " " "Dr. M. Zhu! Chapter 3! Agile Development! Slide Set to accompany Software Engineering: A Practitioner s Approach, 7/e " by Roger S. Pressman

More information

Ten steps to better requirements management.

Ten steps to better requirements management. White paper June 2009 Ten steps to better requirements management. Dominic Tavassoli, IBM Actionable enterprise architecture management Page 2 Contents 2 Introduction 2 Defining a good requirement 3 Ten

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Software Engineering. So(ware Evolu1on

Software Engineering. So(ware Evolu1on Software Engineering So(ware Evolu1on 1 Software change Software change is inevitable New requirements emerge when the software is used; The business environment changes; Errors must be repaired; New computers

More information

Agile Software Development

Agile Software Development Agile Software Development 7 Steps to Successful Projects 2012 Kynetix Technology Group INTRODUCTION Many organisations adopt an Agile approach to software development and later wonder why applications

More information

Enterprise Content Management (ECM)

Enterprise Content Management (ECM) Business Assessment: A Quick-Reference Summary Intro to MIKE2 methodology and phase 1 The methodology that will be used throughout the specialist track is based on the MIKE2 methodology. MIKE stands for

More information

A COMPARISON OF PRINCE2 AGAINST PMBOK

A COMPARISON OF PRINCE2 AGAINST PMBOK Introduction This comparison takes each part of the PMBOK and gives an opinion on what match there is with elements of the PRINCE2 method. It can be used in any discussion of the respective merits of the

More information

Appendix D Programme Stream 6 CRM Procurement. Programme Stream 6 Remodelling of Customer Services Programme CRM Procurement

Appendix D Programme Stream 6 CRM Procurement. Programme Stream 6 Remodelling of Customer Services Programme CRM Procurement Programme Stream 6 Remodelling of Customer Services Programme CRM Procurement Recommendations That the Executive note CRM procurement will be put out to tender in 2010/11 and note the proposed phasing

More information

Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire. P3M3 Project Management Self-Assessment

Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire. P3M3 Project Management Self-Assessment Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire P3M3 Project Management Self-Assessment Contents Introduction 3 User Guidance 4 P3M3 Self-Assessment Questionnaire

More information

LECTURE 1. SYSTEMS DEVELOPMENT

LECTURE 1. SYSTEMS DEVELOPMENT LECTURE 1. SYSTEMS DEVELOPMENT 1.1 INFORMATION SYSTEMS System A system is an interrelated set of business procedures used within one business unit working together for a purpose A system has nine characteristics

More information

Expert Reference Series of White Papers. Intersecting Project Management and Business Analysis

Expert Reference Series of White Papers. Intersecting Project Management and Business Analysis Expert Reference Series of White Papers Intersecting Project Management and Business Analysis 1-800-COURSES www.globalknowledge.com Intersecting Project Management and Business Analysis Daniel Stober,

More information

P3M3 Portfolio Management Self-Assessment

P3M3 Portfolio Management Self-Assessment Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire P3M3 Portfolio Management Self-Assessment P3M3 is a registered trade mark of AXELOS Limited Contents Introduction

More information

A Viable Systems Engineering Approach. Presented by: Dick Carlson (richard.carlson2@boeing.com)

A Viable Systems Engineering Approach. Presented by: Dick Carlson (richard.carlson2@boeing.com) A Viable Systems Engineering Approach Presented by: Dick Carlson (richard.carlson2@boeing.com) Philip Matuzic (philip.j.matuzic@boeing.com) i i Introduction This presentation ti addresses systems engineering

More information

Chapter 4 Software Lifecycle and Performance Analysis

Chapter 4 Software Lifecycle and Performance Analysis Chapter 4 Software Lifecycle and Performance Analysis This chapter is aimed at illustrating performance modeling and analysis issues within the software lifecycle. After having introduced software and

More information

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development 1 Objectives To explain how an iterative, incremental development process leads to faster delivery of more useful software To discuss the essence of agile development methods

More information

Selecting a project management methodology

Selecting a project management methodology VICTORIAN GOVERNMENT CIO COUNCIL Project Management Selecting a project management methodology Guideline This guideline provides advice for selecting and tailoring a project management methodology. Keywords:

More information

Achieving ISO 9001 Certification for an XP Company

Achieving ISO 9001 Certification for an XP Company Achieving ISO 9001 Certification for an XP Company Graham Wright Development Team Coach Workshare 20 Fashion Street London, E1 6PX (44) 020 7539 1361 graham.wright@workshare.com Abstract It is generally

More information

Software Development Processes. Software Life-Cycle Models

Software Development Processes. Software Life-Cycle Models 1 Software Development Processes Sequential, Prototype-based RAD, Phased, Risk-based Spiral (c) 1998 M Young CIS 422/522 4/3/98 1 Software Life-Cycle Models Breaking projects down into pieces for... Planning

More information

Agile project management: A magic bullet?

Agile project management: A magic bullet? Agile project management: A magic bullet? Prof. Darren Dalcher d.dalcher@mdx.ac.uk Conferencia Iberoamericana de Calidad del Software Prof. Darren Dalcher 1 Outline I. What is agilility? The agile manifesto

More information

University of Cambridge Information Services Committee Governance of ISC Projects Originated January 2009 (updated December 2011; awaiting further

University of Cambridge Information Services Committee Governance of ISC Projects Originated January 2009 (updated December 2011; awaiting further University of Cambridge Information Services Committee Governance of ISC Projects Originated January 2009 (updated December 2011; awaiting further revision June 2014) 1. Introduction This paper defines

More information

Lesson 1 Introduction to Rapid Application Development using Visual Basic

Lesson 1 Introduction to Rapid Application Development using Visual Basic Lesson 1 Introduction to Rapid Application Development using Visual Basic RAD (Rapid Application Development) refers to a development life cycle designed to give much faster development and higher-quality

More information

Chapter 9 Software Evolution

Chapter 9 Software Evolution Chapter 9 Software Evolution Summary 1 Topics covered Evolution processes Change processes for software systems Program evolution dynamics Understanding software evolution Software maintenance Making changes

More information

Waterfall vs. Agile Methodology

Waterfall vs. Agile Methodology 2012 Waterfall vs. Agile Methodology Mike McCormick MPCS, Inc. Revised Edition 8/9/2012 Contents Waterfall vs. Agile Model Comparison...3 Conceptual Difference...3 Efficiency...4 Suitability...4 Waterfall

More information

CS4507 Advanced Software Engineering

CS4507 Advanced Software Engineering CS4507 Advanced Software Engineering Lectures 2 & 3: Software Development Lifecycle Models A O Riordan, 2015 Some diagrams from Sommerville, some notes from Maciaszek/Liong Lifecycle Model Software development

More information

Agile development of safety-critical software while meetings standards' requirements

Agile development of safety-critical software while meetings standards' requirements 1(37) Agile development of safety-critical software while meetings standards' requirements Matti Vuori, Tampere University of Technology 2011-11-04 Contents 1/2 A study in Ohjelmaturva 4 Tendency to be

More information

Axe in the Agile World

Axe in the Agile World Axe in the Agile World WHITE PAPER Executive Summary This paper explains the way in which Axe (Odin s Enterprise Test Automation Platform) allows the automated testing to take place in a range of project

More information

PRACTICE GUIDE FOR AGILE SOFTWARE DEVELOPMENT [G62]

PRACTICE GUIDE FOR AGILE SOFTWARE DEVELOPMENT [G62] PRACTICE GUIDE FOR AGILE SOFTWARE DEVELOPMENT [G62] Version: 1.0 March 2015 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of the Office

More information

Requirements Management In Action. A beginners guide to Requirements Management

Requirements Management In Action. A beginners guide to Requirements Management Requirements Management In Action A beginners guide to Requirements Management Table of Contents Introduction How to Capture Requirements What is Traceability? Tips to Capture Better Requirements Conclusion

More information

Clinical Risk Management: Agile Development Implementation Guidance

Clinical Risk Management: Agile Development Implementation Guidance Document filename: Directorate / Programme Document Reference NPFIT-FNT-TO-TOCLNSA-1306.02 CRM Agile Development Implementation Guidance v1.0 Solution Design Standards and Assurance Project Clinical Risk

More information

SPECIFICATION BY EXAMPLE. Gojko Adzic. How successful teams deliver the right software. MANNING Shelter Island

SPECIFICATION BY EXAMPLE. Gojko Adzic. How successful teams deliver the right software. MANNING Shelter Island SPECIFICATION BY EXAMPLE How successful teams deliver the right software Gojko Adzic MANNING Shelter Island Brief Contents 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Preface xiii Acknowledgments xxii

More information

Software Development Processes. Software Life-Cycle Models. Process Models in Other Fields. CIS 422/522 Spring 1998 1

Software Development Processes. Software Life-Cycle Models. Process Models in Other Fields. CIS 422/522 Spring 1998 1 1 Software Development Processes Sequential, Prototype-based RAD, Phased, Risk-based Spiral (c) 1998 M Young CIS 422/522 1/10/99 1 Software Life-Cycle Models Breaking projects down into pieces for... Planning

More information

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Spring 2014 (elicitation)

More information

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK IBM Software Group Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK Jean-Louis Maréchaux Software IT Specialist IBM Rational

More information