SYSTEM DEVELOPMENT METHODOLOGIES … my intention is rather to convince the reader that all methodologies, even the most obvious ones, have their limits. Paul Feyerabend, Against Method (1975)

Goal of Presentation This presentation will Review software processes and methodologies Overview the System Development Life Cycles process

This presentation will

Review software processes and methodologies

Overview the System Development Life Cycles process

Addressing Complexity The complexity of creating software was identified as perhaps the most important cause of software problems. The solution to this problem, like to the solution to any problem, is to break up the process of solving it into stages. A process is a set of activities and associated results which produce a product. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 46. General problem solving process

The complexity of creating software was identified as perhaps the most important cause of software problems.

The solution to this problem, like to the solution to any problem, is to break up the process of solving it into stages.

A process is a set of activities and associated results which produce a product.

Advantages of Subdivision Subdividing the development process results in smaller tasks that can be more easily managed. Subdividing the development process allows techniques and skills specific to different phases to be developed and used. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 46.

Subdividing the development process results in smaller tasks that can be more easily managed.

Subdividing the development process allows techniques and skills specific to different phases to be developed and used.

Project Lifecycles Subdividing the process of software development produces a life cycle model. A lifecycle identifies the phases along which a software product moves, from inception to shipping. The traditional lifecycle for information systems is also known as the waterfall life cycle model . System Planning Requirements Analysis System Design Implementation Testing Maintenance

Subdividing the process of software development produces a life cycle model.

A lifecycle identifies the phases along which a software product moves, from inception to shipping.

The traditional lifecycle for information systems is also known as the waterfall life cycle model .

System Development Life Cycle Although there are numerous variations, the basic SDLC phases include: System planning - defines what the new system is intended to accomplish and how the project will be organized. Requirements analysis - investigating and documenting in detail what the system actually should do to accomplish what is intended. System design - specifying in detail how to implement the system using specific technology. Implementation - creating the actual system. Testing - ensuring the implemented system meets all of the specified requirements. Maintenance - providing needed improvements or fixes. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 101-2

Although there are numerous variations, the basic SDLC phases include:

System planning - defines what the new system is intended to accomplish and how the project will be organized.

Requirements analysis - investigating and documenting in detail what the system actually should do to accomplish what is intended.

System design - specifying in detail how to implement the system using specific technology.

Implementation - creating the actual system.

Testing - ensuring the implemented system meets all of the specified requirements.

Maintenance - providing needed improvements or fixes.

Waterfall SDLC Advantages Better than ad-hoc, code-and-fix approach. It enforces planning before coding. "plan the work, work the plan" Provides management with predictability and a foundation for measuring progress. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 102

Advantages

Better than ad-hoc, code-and-fix approach.

It enforces planning before coding.

"plan the work, work the plan"

Provides management with predictability and a foundation for measuring progress.

Waterfall SDLC Disadvantages there are few visible results (other than documents) until near the end of the lifecycle. higher risk and failure, and all-around lower productivity. It requires a low-change, low-novelty, and low-complexity problem. pushes many high-risk and difficult elements toward the end of a project. Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

Disadvantages

there are few visible results (other than documents) until near the end of the lifecycle.

higher risk and failure, and all-around lower productivity.

It requires a low-change, low-novelty, and low-complexity problem.

pushes many high-risk and difficult elements toward the end of a project.

Waterfall SDLC Disadvantages The waterfall also aggravates complexity overload and analysis paralysis . Large steps with overwhelming degrees of complexity are attempted. Difficult to plan accurate schedules Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

Disadvantages

The waterfall also aggravates complexity overload and analysis paralysis .

Large steps with overwhelming degrees of complexity are attempted.

Difficult to plan accurate schedules

Waterfall SDLC Disadvantages Difficult to fully specifying the requirements at the beginning of the project. A great deal of time can take place between requirements phases and the implementation phase. The more complex the project, the more requirements change Research shows that a typical software project experiences a 25% change in requirements Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

Disadvantages

Difficult to fully specifying the requirements at the beginning of the project.

A great deal of time can take place between requirements phases and the implementation phase.

The more complex the project, the more requirements change

Research shows that a typical software project experiences a 25% change in requirements

Waterfall SDLC In 1994, the DOD dropped their waterfall 2167A specification, because of abysmal failure. They now encourage an iterative process. Source: Craig Larman, “Software Economics” presentation.

In 1994, the DOD dropped their waterfall 2167A specification, because of abysmal failure.

They now encourage an iterative process.

Iterative Development The iterative or incremental approach recognizes that users and developers learn about the requirements as they progress through the development process. Development is thus organized into a series of short, fixed-length mini-projects called iterations. Each iteration includes its own analysis, design, implementation, and testing phases. 4 weeks (for example) 4 weeks Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 102 Source: Craig Larman, Applying UML and Patterns, 2 nd Ed (Prentice Hall, 2001), p. 14-5.

The iterative or incremental approach recognizes that users and developers learn about the requirements as they progress through the development process.

Development is thus organized into a series of short, fixed-length mini-projects called iterations.

Each iteration includes its own analysis, design, implementation, and testing phases.

Iterative Development Each iteration is thus a self-contained mini-project containing multiple activities (requirements, analysis, etc) The goal for the end of an iteration is an iteration release, a stable, integrated and tested partially complete system. Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

Each iteration is thus a self-contained mini-project containing multiple activities (requirements, analysis, etc)

The goal for the end of an iteration is an iteration release, a stable, integrated and tested partially complete system.

Iterative Development The Iterative SDLC is based on the successive enlargement and refinement of a system through multiple iterations/releases. The result of each iteration is an executable but incomplete system. The system will not be ready for delivery into production after many iterations (say 5 to 15 iterations). Each iteration should be a production-grade subset of the final system. i.e., each iteration is not a prototype or proof of concept, but a subset of the final system. Source: Craig Larman, Applying UML and Patterns, 2 nd Ed (Prentice Hall, 2001), p. 14-6.

The Iterative SDLC is based on the successive enlargement and refinement of a system through multiple iterations/releases.

The result of each iteration is an executable but incomplete system.

The system will not be ready for delivery into production after many iterations (say 5 to 15 iterations).

Each iteration should be a production-grade subset of the final system.

i.e., each iteration is not a prototype or proof of concept, but a subset of the final system.

Iterative Development The system thus grows incrementally over time, iteration by iteration, with each new iteration/release embodying incremental improvements over the other. Each iteration generally tackles new requirements and incrementally extends the systems. Sometimes, however, an iteration may focus on improving the performance or integration of existing increments.

The system thus grows incrementally over time, iteration by iteration, with each new iteration/release embodying incremental improvements over the other.

Each iteration generally tackles new requirements and incrementally extends the systems.

Sometimes, however, an iteration may focus on improving the performance or integration of existing increments.

Iterative Development Advantages Users do not have to wait until system is delivered before they can gain value from it. Early risk mitigation and discovery Higher priority services added first and thus receive the most testing. More adaptive to changing requirements is used by current agile methods, including Scrum and XP. Disadvantages Sometimes difficult to map user’s requirements into increments. Most systems require basic set of facilities which are used by all parts of a system; these basic facilities may not map well into increments. May require paradigm change for some developers Source: Ian Sommerville, Software Engineering, 6 th Edition (Addison-Wesley, 2001), p. 52-3

Advantages

Users do not have to wait until system is delivered before they can gain value from it.

Early risk mitigation and discovery

Higher priority services added first and thus receive the most testing.

More adaptive to changing requirements

is used by current agile methods, including Scrum and XP.

Disadvantages

Sometimes difficult to map user’s requirements into increments.

Most systems require basic set of facilities which are used by all parts of a system; these basic facilities may not map well into increments.

May require paradigm change for some developers

Managing Iterative Development Source: Craig Larmann, Agile and Iterative Development (Addison-Wesley, 2003)

Which Iterations First? Two strategies: Risk-driven Choose the riskiest, most difficult elements for the early iterations Client-driven Client prioritizes the iterations based on whatever they perceive to have the highest business value to them.

Two strategies:

Risk-driven

Choose the riskiest, most difficult elements for the early iterations

Client-driven

Client prioritizes the iterations based on whatever they perceive to have the highest business value to them.

System Development Methodologies A lifecycle gives a general understanding of what system development is about but it does not give guidance on how to carry out system development. To help develop quality information systems in a timely and manageable way, we may need a complete system development methodology. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 104

A lifecycle gives a general understanding of what system development is about but it does not give guidance on how to carry out system development.

To help develop quality information systems in a timely and manageable way, we may need a complete system development methodology.

Method and Methodology Method Step-by-step description of the steps involved in doing a job Methodology A set of general principles that guide a practitioner to the choice of a particular method suited to a specific task or project. defines the process and sequence of tasks that need to be completed when developing a system, along with recommended techniques for completing the tasks. Defines a series of methods to be used. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 555.

Method

Step-by-step description of the steps involved in doing a job

Methodology

A set of general principles that guide a practitioner to the choice of a particular method suited to a specific task or project.

defines the process and sequence of tasks that need to be completed when developing a system, along with recommended techniques for completing the tasks.

Defines a series of methods to be used.

Methodologies A methodology generally has two components, related to what and how: Process component - explains what tasks to do and when to do them, spelling out the life cycle to follow and the general project management approaches to be used. Techniques component - describes the techniques and tools that could or should be used for the tasks at hand. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 104

A methodology generally has two components, related to what and how:

Process component - explains what tasks to do and when to do them, spelling out the life cycle to follow and the general project management approaches to be used.

Techniques component - describes the techniques and tools that could or should be used for the tasks at hand.

Methodology Details What is needed in a methodology varies widely with the projects undertaken. A decisive factor is the number of people involved. In small projects, the main modeling techniques to be used are the most important aspect of the method. As the number of people increases, a comprehensive methodology with a clearly defined process increases rapidly. Another decisive factor is the use of the system: If the system being development is life critical or mission critical then a well-defined process is necessary. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 104

What is needed in a methodology varies widely with the projects undertaken.

A decisive factor is the number of people involved.

In small projects, the main modeling techniques to be used are the most important aspect of the method.

As the number of people increases, a comprehensive methodology with a clearly defined process increases rapidly.

Another decisive factor is the use of the system:

If the system being development is life critical or mission critical then a well-defined process is necessary.

Comprehensive Methodologies A comprehensive methodology should provide a clear work breakdown structure that divides the development effort into phases, steps, and tasks. The methodology should indicate the sequence of tasks: which can be done in parallel, which can be skipped under certain circumstances, and so on. The methodology should indicate inputs and outputs to the phases, steps, and tasks. It should indicate the techniques and tools that should or could be used. It should also be flexible and adaptable to the project at hand by allowing for the deleting, rearranging, and combining of steps and tasks. Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 104

A comprehensive methodology should provide a clear work breakdown structure that divides the development effort into phases, steps, and tasks.

The methodology should indicate the sequence of tasks: which can be done in parallel, which can be skipped under certain circumstances, and so on.

The methodology should indicate inputs and outputs to the phases, steps, and tasks.

It should indicate the techniques and tools that should or could be used.

It should also be flexible and adaptable to the project at hand by allowing for the deleting, rearranging, and combining of steps and tasks.

Trends in Methodologies There are two opposing trends in methodology development: Methodologically Substantial advocates a clearly defined and tightly managed process, emphasizing rigor, predictability, and engineering-like development. e.g., Capability Maturity Model (CMM) and ISO 9000. Methodological Minimalism advocates a minimal methodology with maximum freedom on the part of the developers to adapt their approaches according to the needs of the project. e.g., Extreme Programming, Agile Development

There are two opposing trends in methodology development:

Methodologically Substantial

advocates a clearly defined and tightly managed process, emphasizing rigor, predictability, and engineering-like development.

e.g., Capability Maturity Model (CMM) and ISO 9000.

Methodological Minimalism

advocates a minimal methodology with maximum freedom on the part of the developers to adapt their approaches according to the needs of the project.

e.g., Extreme Programming, Agile Development

Methodologies and Process Object-oriented development should also follow a well-defined software process. Remember, process is a more general term, while methodology the more specific.

Object-oriented development should also follow a well-defined software process.

Remember, process is a more general term, while methodology the more specific.

Unified Software Development Process Developed (1999) by the team that created UML. Embodies best practice in system development. Uses iterative and incremental life cycles. Adopts an iterative approach with four main phases. Different tasks are captured in a series of workflows. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 109-110.

Developed (1999) by the team that created UML.

Embodies best practice in system development.

Uses iterative and incremental life cycles.

Adopts an iterative approach with four main phases.

Different tasks are captured in a series of workflows.

Unified Software Development Process Has four main phases : Inception (determining scope and purpose of project) Elaboration (requirements capturing and determining structure of system) Construction (build the system) Transition (product installation and rollout) Each phases has a workflow or lifecycle: Requirements Analysis Design Implementation Test The balance of effort spent in each workflow varies from phase to phase. Within phases there may be more than one iteration.

Has four main phases :

Inception (determining scope and purpose of project)

Elaboration (requirements capturing and determining structure of system)

Construction (build the system)

Transition (product installation and rollout)

Each phases has a workflow or lifecycle:

Requirements

Analysis

Design

Implementation

Test

The balance of effort spent in each workflow varies from phase to phase.

Within phases there may be more than one iteration.

Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 111. The Unified Software Development Process Size of square indicates relative time spent on workflow in that iteration Inception Elaboration Construction Transition Project Phases 1 2 3 4 5 6 7 8 Iterations within each phase Requirements Analysis Design Implementation Test Workflows Iteration # Time

Waterfall Life Cycle Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 111. Requirements Analysis Design Implementation Test Requirements Analysis Design Implementation Test

UP Phases: Inception Goal is to get the project off the ground by establishing feasibility, creating a business case of benefits of project, capturing essential requirements and identifying critical risks. Focus on requirements and analysis workflows. Deliverables are a problem/vision statement document, initial use case model (10% complete), business case document, initial architecture, simple prototypes, project plan. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 33-4.

Goal

is to get the project off the ground by establishing feasibility, creating a business case of benefits of project, capturing essential requirements and identifying critical risks.

Focus

on requirements and analysis workflows.

Deliverables

are a problem/vision statement document, initial use case model (10% complete), business case document, initial architecture, simple prototypes, project plan.

UP Phases: Elaboration Goal is to capture up to 80% of the functional requirements in use cases, create detailed plan for construction phase, create initial executable architectural baseline (i.e., initial system) that will evolve and grow in next phase. Focus on requirements, analysis, and design workflows. Implementation and test workflows also become important toward the end of the phase on in so far that one constructs and tests the initial baseline. Deliverables are Use Case model, UML static model, UML dynamic model, updated project plan, and executable architectural baseline. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 34-5.

Goal

is to capture up to 80% of the functional requirements in use cases, create detailed plan for construction phase, create initial executable architectural baseline (i.e., initial system) that will evolve and grow in next phase.

Focus

on requirements, analysis, and design workflows.

Implementation and test workflows also become important toward the end of the phase on in so far that one constructs and tests the initial baseline.

Deliverables

are Use Case model, UML static model, UML dynamic model, updated project plan, and executable architectural baseline.

UP Phases: Construction Goal is to complete all requirements, analysis, and design, and to evolve the architectural baseline into the final system. Key issue is maintaining the integrity of the system architecture (i.e., not to cut corners, but maintain proper design). Focus on implementation and testing workflows, with secondary effort made on completing requirements, analysis and design. Deliverables The software product, the completed UML model, a test suite, and user manuals. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 36.

Goal

is to complete all requirements, analysis, and design, and to evolve the architectural baseline into the final system.

Key issue is maintaining the integrity of the system architecture (i.e., not to cut corners, but maintain proper design).

Focus

on implementation and testing workflows, with secondary effort made on completing requirements, analysis and design.

Deliverables

The software product, the completed UML model, a test suite, and user manuals.

UP Phases: Transition Goal Starts when beta testing is complete and the system is deployed. Goal is thus to fix bugs and prepare for the rollout. Focus on testing workflows (as well on implementation in that bugs have to be fixed). Deliverables The software product, user manuals, and user support plan. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 37-8.

Goal

Starts when beta testing is complete and the system is deployed. Goal is thus to fix bugs and prepare for the rollout.

Focus

on testing workflows (as well on implementation in that bugs have to be fixed).

Deliverables

The software product, user manuals, and user support plan.

Workflows: Requirements Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112. Workflow Techniques Key Deliverables Requirements Requirements Elicitation Use Case Modelling Prototyping Use Case Model Requirements List Prototypes Glossary

Workflows: Analysis Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112. Workflow Techniques Key Deliverables Analysis Collaboration Diagrams Class and Object Models Analysis Modelling Analysis Models

Workflows: Design Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112. Workflow Techniques Key Deliverables Design Class and Object Modelling Interaction Modelling State Modelling Design Patterns Deployment Modelling Component Modelling Package Modelling Architectural Modelling Design Models Overview Design and Implementation Architecture

Workflows: Implementation Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112. Workflow Techniques Key Deliverables Implementation Programming Component Re-use Database DDL Programming Idioms Executable System Documentation

Workflows: Testing Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 112. Workflow Techniques Key Deliverables Testing Programming Test Procedures Tested System

O-O Methodologies The previous process is not a complete methodology. Most larger software companies have their own methodology that you must work within and follow. Most current methodologies are based upon the Unified Software Development Process. In this course, we will not be following a specific methodology. We will try to follow, in spirit, the Unified Software Development Process. Due to time-constraints, we will not be able to realistically follow all the phases and increments. Inception Elaboration Construction Transition 1 2 3 4 5 6 7 8 Requirements Analysis Design Implementation Test

The previous process is not a complete methodology.

Most larger software companies have their own methodology that you must work within and follow.

Most current methodologies are based upon the Unified Software Development Process.

In this course, we will not be following a specific methodology.

We will try to follow, in spirit, the Unified Software Development Process.

Due to time-constraints, we will not be able to realistically follow all the phases and increments.