slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Altran CIS O bject- O riented A nalysis and D esign PowerPoint Presentation
Download Presentation
Altran CIS O bject- O riented A nalysis and D esign

Loading in 2 Seconds...

play fullscreen
1 / 78

Altran CIS O bject- O riented A nalysis and D esign - PowerPoint PPT Presentation


  • 132 Views
  • Uploaded on

Trainers: Pierre LE FEVERE DE TEN HOVE Richard WALKER. Altran CIS O bject- O riented A nalysis and D esign. Session 1 – Introduction Software Development Processes. Objectives and Agenda. Objectives Overview of the software development evolution

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Altran CIS O bject- O riented A nalysis and D esign' - dalit


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Trainers:

Pierre LE FEVERE DE TEN HOVE

Richard WALKER

Altran CISObject-Oriented Analysis and Design

Session 1 – Introduction

Software Development Processes

OOAD Training

objectives and agenda

Objectives and Agenda

Objectives

Overview of the software development evolution

Detailed presentation of the Unified Process

Agenda

Software development evolution

Facts

Conventional development

Iterative development

Agile

Unified Process

Introduction

Rational Unified Process

Phases and Iterations

Risk Management

Course structure

(Kick off inception phase)

software development evolution facts

Impaired: 24%

Successful: 32%

Challenged: 44%

Software development evolutionFACTS

Standish Group International

  • Analyse the application development projects in government and commercial organisations (no vendors, no suppliers, no consultants)
  • Analysis of over 50,000 IT projects in 12 years

Current situation (2009)

  • US annual expenditure for software development: $255 Billions
  • Successful:on budget, on time, with all requirements fulfilled
  • Challenged:over budget, delayed, with fewer requirements fulfilled
  • Impaired: cancelled in development or finished but not used

OOAD Training

software development evolution facts1
Software development evolutionFACTS

Reasons of success (from 2006 report)

OOAD Training

software development evolution facts2
Software development evolutionFACTS

Reasons of failure (from 2006 report)

~ 50% due to requirements

OOAD Training

software development evolution facts3

Requirements: 56 %

Other: 10%

Code: 7%

Design: 27%

Software development evolutionFACTS

Distribution of defects in the Software engineering lifecycle

OOAD Training

software development evolution facts4
Software development evolutionFACTS
  • Average percentage ofcost overrun
  • Average percentage oftime overrun

Evolution since 1994

  • Successful: on budget, on time, with all requirements fulfilled
  • Challenged: over budget, delayed, with fewer requirements fulfilled
  • Impaired: cancelled development or finished but not used
  • Reasons of improvement:
    • Better project management
    • Iterative development
    • Emerging Web infrastructure

OOAD Training

software development evolution facts5
Software development evolutionFACTS
  • Most popular programming language by TIOBE index October 2009
    • Ratings based on world-wide availability of skilled engineers, courses and third party vendors (using Google, MSN and Yahoo! search engines)

OOAD Training

software development evolution conventional development
Software development evolutionConventional Development
  • Winston W. Royce (1970)
  • Big design up-front
  • Coding = little fraction of the overall process (<15%)

OOAD Training

software development evolution v model
Software development evolutionV-Model

Requirements

Acceptance

tests

prepare 

 validate

Analysis

System

tests

Design

Integration

tests

Coding

Unit tests

OOAD Training

Project time line

software development evolution v model test categories
Software development evolutionV-Model – Test categories

Unit Testing

Make sure all tests are fully automatic and that they check there own results

A suite of tests is a powerful bug detector that decapitates the time it takes to find bugs

Run your tests frequently. Every test at least everyday

When you get a bug report, start by writing a unit test that exposes the bug

It is better to write and run incomplete tests than not to run tests

Integration Testing

To ensure that all parts developed separately fit together

Interfaces

System Testing

The system as a whole

Features

Developer focused

Acceptance Testing

The system as a whole also

Requirements

Customer focused

Non-regression Testing

Before migration to operation, verify that previously delivered software still works

OOAD Training

12

software development evolution conventional development1
Software development evolutionConventional Development

Advantages

  • Easy to understand
  • Big effort up front minimizes risk of discovering problems later
  • Emphasis on documentation => easier take over for a new member
  • Possibility to manage independant & specialised teams

Issues

  • Plan & estimate too much in advance is difficult
  • Impossible to go back
  • No continuous process improvement (during the project)
  • No intermediate validation => late risk resolution
  • No requirements rework nor customer feedback
  • Close to change

 Great when requirements are stable

OOAD Training

software development evolution conventional development2

100%

Development progress

(% coded)

Time

Original target date

Production

Project Start

Integration

Software development evolutionConventional Development

OOAD Training

software development evolution conventional development3
Software development evolutionConventional Development

Risk curve

Risk

Waterfall process

Requirements

Analysis

Design

Coding

Testing

Time

OOAD Training

software development evolution iterative development
Software development evolutionIterative development

Evolutions

  • Requirements are more and more complex
  • System and technologies complexity increasing
  • Business is evolving faster

Consequences

  • Requirements are never frozen and may evolve during the project
  • Change is inevitable
    • Changes to the makeup of the project team or in stakeholders
    • Changes in the technology being used
    • Changes to any external systems with which the new software must interact
  • More and more interfaces between systems have to be defined

OOAD Training

software development evolution iterative development1
Software development evolutionIterative Development

Need of an "evolutionary" model

  • Open to change
  • Progressive resolution of risks
  • Architecture centric
  • Continuous integration

Iterative models:

  • Iterative (repetitions on the V-model)
  • Incremental
  • Assess highest risks in first iterations
  • Requirements driven:
    • Req. are elements of planning
    • Customer is regularly involved
  • Multi-views architecture

OOAD Training

software development evolution iterative development2

Risk

Waterfall development

Time

Software development evolutionIterative Development

Risk curve

Iterative development

OOAD Training

objectives and agenda1

Objectives and Agenda

Objectives

Overview of the software development evolution

Detailed presentation of the Unified Process

Agenda

Software development evolution

Facts

Conventional development

Iterative development

Agile

Unified Process

Introduction

Rational Unified Process

Phases and Iterations

Risk Management

Course structure

agile
Agile

Agile is a philosophy:

“Agile is an iterative software development style centered on the stakeholders and focusing on customer satisfaction through a continuous software integration.”

Agile principles from the Manifesto (http://agilemanifesto.org/)

  • Customer satisfaction first
  • All change requests are welcomed
  • Frequent software delivery (in weeks rather than in months)
  • Business and software engineers working together
  • Working software is the primary measure of progress
  • Technical excellence and good design
  • and six others ...

OOAD Training

agile1
Agile

A matter of tipping the balance on the good side…

OOAD Training

agile2
Agile

A question of commitment…

"Pigs" and "chickens" are the two types of roles in the Scrum method

... or a question of fun?

OOAD Training

agile3
Agile

Scrum (www.controlchaos.com)

  • By Ken Schwaber (inspired by Japanese emergency plans)
  • Rugby Strategy for HR
  • Iterative process
  • No development practice
  • Management process for software engineering
    • Self organized team
    • 30-days iterations
    • Daily meetings
  • Transparency at all levels:
    • High level burndown (Backlog)
    • Iteration burndown (Sprint)
    • Daily meeting
  • Less formalized than UP
  • To be used in conjunction with XP

OOAD Training

slide26

Software development approachesSCRUM

facilitates Scrum process, insures Scrum best practices usage

is committed to perform a sprint (without any defined sub-roles)

describes and prioritizes the items of the Product Backlog

master list of all functionality desired in the product

list of tasks that has to be completed in the current sprint

team progress vs release plan updated at the end of each sprint

OOAD Training

agile4
Agile

Agile methodologies:

  • Scrum (www.controlchaos.com)
  • X-Treme Programming (http://www.extremeprogramming.org/)
  • Feature-Driven Development (www.featuredrivendevelopment.com)
  • Unified Process
  • Rational Unified Process?

OOAD Training

agile5
Agile

Daily Scrum meeting

  • Max 15 minutes
  • Stand-up meeting
  • Only pigs allowed to speak
  • 3 questions:
      • What did you do yesterday?
      • What will you do today?
      • Are there any impediments in your way? (ex: I can't get the ____ group to give me any time and I need to meet with them.)
  • The Scrum Master role is to help resolve impediments offline.
  • Transparency is key in order to:
      • Maintain quality(developers usually tend to drop quality without telling when asked to do more)
      • Help management take appropriate decision early(managers usually believe in magic: they just have to ask for more it and it will be done)

OOAD Training

objectives and agenda2

Objectives and Agenda

Objectives

Overview of the software development evolution

Detailed presentation of the Unified Process

Agenda

Software development evolution

Facts

Conventional development

Iterative development

Agile

Unified Process

Introduction

Rational Unified Process

Phases and Iterations

Risk Management

Course structure

unified process introduction
Unified ProcessIntroduction

a Software Engineering Process

  • Defining tasks & responsibilities
  • Ensuring high-quality within schedule & budget
  • Focused on content

a Software Development Method

  • Iterative
  • Incremental
  • Use case driven
  • Focused on architecture

<> project management methodology

OOAD Training

unified process rational unified process
Unified ProcessRational Unified Process

Iterative software development process

  • Created by Rational Software corp. (now IBM)
  • Based on Unified Process

Software process product: Rational Method Composer

  • Customizable process framework
  • Knowledgebase
  • Template and artifacts library
  • Published on the web

OOAD Training

unified process rational unified process1
Unified ProcessRational Unified Process

Iterative software development process

OOAD Training

unified process rational unified process rup and pm 1 2
Unified ProcessRational Unified Process RUP and PM (1/2)

Prince2 & PMI

  • Broad Project Management usage
  • Main deliverables are business case, project plans, changes requests, corrective actions, lessons learned, risk plan…
  • Project management disciplines
    • Integration and Scope management
    • Risk and Quality management
    • HR and Communication management (hiring, training, coaching…)
    • Time and Cost management
    • Procurement management (with suppliers, sponsors, ...)
  • Do not contain development method best practices

RUP

  • Limited to software engineering
  • Focus on content: main deliverables are business case, iteration plans, SRS, SAD, implemented components, iteration evaluations…
  • Project management is a discipline of RUP
    • Planning (iterations & phases)
      • In terms of risk, time and people (tasks & responsibilities allocation)
  • Contain development method best practices

OOAD Training

unified process rational unified process static aspect
In RUP all disciplines are expressed in terms of roles, activities and artifacts

A unit of work with a clear purpose that a worker will perform

Activity = element of planning & progress

The behaviour and responsibilities of a (group of) individual(s). An individual can have many hats

Worker = role

A piece of information produced, modified or used by a process

Artifact = Input & Output of activities

Unified ProcessRational Unified Process Static aspect

OOAD Training

unified process rational unified process dynamic aspect
Unified ProcessRational Unified ProcessDynamic aspect

A project is broken into 4 phases

Each phase can have several iterations

Major Milestones

Inception

Elaboration

Construction

Transition

time

OOAD Training

unified process rational unified process rational method composer
Unified ProcessRational Unified ProcessRational Method Composer

First aim of RMC:

  • Content management system providing a common management structure for all of content development practitioners.

OOAD Training

unified process rational unified process rational method composer1

Requirements workflow in RUP

Unified ProcessRational Unified ProcessRational Method Composer

Second aim of RMC:

  • Provide process engineering capabilities for supporting process engineers and project managers for their development projects.

OOAD Training

unified process rational unified process rational method composer2
Unified ProcessRational Unified ProcessRational Method Composer

Illustration:

  • Requirements workflow with RUP

OOAD Training

unified process phases and iterations sequential phases 1 2
Unified ProcessPhases and IterationsSequential Phases (1/2)

4 sequential phases

  • Inception
    • Approximate the vision
    • Define the scope of the project
    • Build the business case (Go – No-Go ?)
    • Capture high-level requirements
    • 1st bid (rough planning estimates)
    • Usually last a few days for small projects or a week for medium projects
  • Elaboration
    • Refine the vision
    • Iterative implementation of core architecture
    • High risks resolution
    • Use cases description
    • Development plan and realistic estimates
  • Construction
  • Transition

OOAD Training

unified process phases and iterations sequential phases 2 2

Resources

Inception

Elaboration

Construction

Transition

Effort

65%

Lifecycle Objectives Milestone

Lifecycle Architecture Milestone

Initial Operational Capability Milestone

Project Release Milestone

10%

20%

5%

Time

Inception

Elaboration

Construction

Transition

Time

10% 30% 50% 10%

Unified ProcessPhases and IterationsSequential Phases (2/2)

4 sequential phases

  • Inception
  • Elaboration
  • Construction
    • Iterative implementation of software components
    • Internal releases
    • First external release
  • Transition
    • Beta-tests
    • Performance tuning
    • End-user training and appropriation

OOAD Training

unified process phases and iterations n iterations

Inception

Elaboration

Construction

Transition

Preliminary IT_1 IT_2 IT_m IT_m+1 IT_m+2 IT_n-1 IT_n Iteration(s)

First internal release (Conceptual prototype)

Internal Release

First external release (beta)

Final Release (Delivery)

Internal release (Architecture baseline)

4%

5%

20%

35%

20%

4%

5%

5%

3%

Unified ProcessPhases and Iterationsn iterations

n Iterations

  • Each iteration is a complete development process resulting in an executable but incomplete system
  • Iterations could exist in each phase
  • 2 to 8 weeks duration
  • In each iteration  a V-schema

OOAD Training

unified process phases and iterations approach
Unified ProcessPhases and Iterations Approach

Iterative development

  • Quick-wins with lessons-learned of each iteration
  • Review the scheduling strategy to review and revise parts of the system
  • Early feedbacks
  • Early risks handling

Incremental development

  • Development and delivery in stage
  • Divide complexity to conquer
  • More and more functionalities from

iterations to iterations

OOAD Training

unified process phases and iterations approach1
Unified ProcessPhases and Iterations Approach

Types of feedback

  • In early developments
    • From programmers trying to read specifications
    • From clients using the demos  refine requirements
  • In project progress
    • From team workers to refine schedule and estimates
    • From clients to re-prioritize the features to be tackled in next iteration
  • In late developments and tests
    • From developers and testers to refine designs or models

OOAD Training

unified process phases and iterations n iterations1
Unified ProcessPhases and Iterationsn iterations

Number of iterations

  • Depends on the phase
  • Depends on the project size
  • Generally from 1 to 4 for one phase

Duration of an iteration

  • Depends on the project size
  • Generally from 2 to 8 weeks

Time-boxing

  • Deadlines fixed  length-fixed
  • Date slippage is forbidden
  • If needed: reduce scope (but not quality!)

OOAD Training

unified process phases and iterations n iterations2
Unified ProcessPhases and Iterationsn iterations

Time-boxing or content-boxing?

  • Aim: reduce risks & keep meeting reservations
  • Not able to do scope during time frame?

too many issues?

each iteration aims to reduce risks

do not face too many risks at once

reduce scope

  • It’s fine to not release the software at the end of an iteration (YAGRI principle)
  • You can increase the number of iterations

OOAD Training

unified process phases and iterations n iterations3
Unified ProcessPhases and Iterationsn iterations

Tip

Workload = Productivity (1,5 or 2)

Project iterations illustrations

+ 1

=

OOAD Training

unified process phases and iterations n iterations4

Inception

Elaboration

Construction

Transition

IT_1 IT_2 IT_3 IT_4 IT_5 IT_6 IT_7

First internal release (Conceptual prototype)

Internal Release

First external release (beta)

Final Release (Delivery)

Internal release (Architecture baseline)

Inception

Elaboration

Construction

Transition

IT_1 IT_2 IT_3 IT_4 IT_5 IT_6 IT_7 IT_8 IT_9 IT_10

First internal release (Conceptual prototype)

Internal Release

First external release (beta)

Final Release (Delivery)

Internal release (Architecture baseline)

Unified ProcessPhases and Iterationsn iterations

Small project

Large project

OOAD Training

unified process phases and iterations n iterations5

Inception

Elaboration

Construction

Transition

Phases Plan

Preliminary IT_1 IT_2 IT_m IT_m+1 IT_m+2 IT_n-1 IT_n Iteration(s)

Iterations Plan

Unified ProcessPhases and Iterationsn iterations

Rolling wave

OOAD Training

unified process phases and iterations in practice 1 3
Unified ProcessPhases and IterationsIn practice (1/3)

Inception

1 Iteration – 2 days

  • Requirements workshop (Chief architect, business and analysts)
    • Day 1 a.m.: high level requirements analysis  set of high level UC
    • Day 1 a.m.: pick 10% from those high level UC.
    • Day 1 p.m and Day 2 a.m. : do intensive detailed analysis of the functional and non functional requirements for these UC.
  • Planning meeting (Chief architect, analysts and development people)
    • Day 2 p.m.: hold an iteration planning meeting for the first iteration on a subset of detailed use cases. Break them down to detailed iteration tasks.
  • Validate business case

OOAD Training

unified process planning
Unified ProcessPlanning

What is the main challenge of planning?

 Estimations

Study by the Simular Research Group

on Factors that influence estimation

  • Effect of irrelevant information
unified process planning1
Unified ProcessPlanning

2. Effect of extra requirement

3. Effect of length

unified process planning2
Unified ProcessPlanning

4. Effect of anchoring

unified process planning3
Unified ProcessPlanning

Technique: Poker planning!

  • Avoid anchoring influence
  • People that will actually do the job must participate
  • Units:
      • Story points for high level planning
      • Hours for detailed tasks
    • Extremes bets are the most interesting
unified process phases and iterations in practice 2 3
Unified ProcessPhases and IterationsIn practice (2/3)

Elaboration

1st Iteration – 3 weeks

  • Kick-off clarifying the iteration
  • Modeling and design workshops in pairs: 2-3 days
  • From modeling sketches: programming and testing: 9 days
    • After 4-5 days: Scope review (de-scope for time-boxing if necessary)
  • Feedback request: D-3
    • Create baseline: code frozen, checked in, integrated
    • Demo the partial system to external stakeholders and request feedback
  • Requirements workshops: D-2
    • Review and refine all materials of last workshops
    • Pick another 15% of UC and detail them
  • Iteration planning meeting: D-1

2nd Iteration – 4 weeks

  • ...

3rd Iteration – 4 weeks

OOAD Training

unified process phases and iterations in practice 3 3
Unified ProcessPhases and IterationsIn practice (3/3)

After 3 iterations: end of Elaboration phase

  • Progress:
    • Detailed use cases: 80 to 90%
    • Implementation status: 15%
    • Project duration: 30%
  • Effort to provide:
    • Requirements stabilized (but not frozen !)
    • Early exploratory development completed
    • Clear estimates are now provided
    • Major significant risks are handled
    • Focus on design, implementation and tests
    • Continue with 4 iterations of 3 to 4 weeks: Construction phase

OOAD Training

unified process use case driven

Requirts

Analysis

Design

Implemnt

Tests

Unified ProcessUse case Driven

UP is driven by use cases

  • Scope the system
  • Capture functional requirements
  • Define test cases
  • Organize releases and plan iterations
  • Estimate project costs
  • Initial framework for documentation

Importance of capturing and documenting good use cases!

Use cases bind these workflows together

OOAD Training

unified process risk management
Unified ProcessRisk management

Focused on risk management

  • Risk reduction
    • Break down the project into small iterations (set of use cases)
    • Handle riskiest use cases first

 Take user’s importance into account!

  • Be architecture centric
    • Architecture is a common risk
    • Produce many views of a complex system
    • Build up an executable baseline architecture during elaboration
    • Select technologies

OOAD Training

unified process risk management1

How to deal with those risks ?

Unified ProcessRisk management

Risks category

  • Political

 political choices such as fusion, managers, program constraints, external resources, etc.

  • Requirements

 comprehension of what we do, definition of requirements from the different end-users point of view, etc.

  • Technological

 technological risks such as new technology not yet integrated in our environment, etc.

  • Skills

 competences, lack of back-ups, under-trained team members, etc.

OOAD Training

unified process risk management deal with political risks
Unified ProcessRisk management Deal with Political Risks

No systematic approach

  • Unified Process does not provide specific approach for handling political risks
  • Best practices
    • Program manager support and close collaboration
    • Procurement team support and close collaboration
    • If internal project responsibility, foresee internal back-up for external profiles
    • Careful choice of key users
    • Bring externals into projects
    • Often refer to theory / company standards / universal best practices

OOAD Training

unified process risk management deal with requirements risks
Unified ProcessRisk management Deal with Requirements Risks

Use cases

  • Unified process handle requirements risks through the “Use case driven” approach
    • Use cases will be defined to capture the requirements as the result of the discussion between key users and business analysts
    • Use cases will be involved in the project planning
    • During elaboration phase, the most important and riskiest risk will be handled first
    • Use cases will be the source for domain modeling, interactions modeling, functional testing, documentation and training

Domain expertise

  • Getting access to domain experts will decrease requirements risks
    • Invest in bringing domain experts in your team
      • Part time
      • Open-minded
      • Available for questions
    • Involve them in requirements workshops with key users

OOAD Training

unified process risk management deal with technological risks
Unified ProcessRisk management Deal with Technological Risks

Architecture

  • Unified process handle technological risks through the “architecture centric” approach:
    • The main aim of the elaboration phase is to end with a build-in architecture
    • All the views will be partly implemented together
    • All technologies will be used and components collaborating with each other
  • When designing the architecture, ask yourself
    • What if a piece of technology does not work?
    • What if two pieces of technology do not connect?

Prototypes

  • Build prototypes that challenge the technologies you want to use
    • Design a prototype so that it force you to mix technologies

OOAD Training

unified process risk management deal with skills risks
Unified ProcessRisk management Deal with Skills Risks

Iterative

  • Unified process handle skills risks through the “iterative” approach:
    • Iterative approach  repetitive set of activities
    • Iterations lessons learned will help to better collaborate with all stakeholders
    • Small iterations allow you to change teams if skills problems are raised
  • Having worked in a 6-iterations project is like experiencing 2 different projects

Mentoring

  • X-treme programming handle skills risk through the “pair-programming” approach

OOAD Training

unified process unified process disciplines and uml 1 4
Unified ProcessUnified Process Disciplines and UML (1/4)
  • Business Process
      • Define high-level business activities and processes

(usually broader than project scope)

 Activity Diagrams for Business Process Modeling

  • Requirements
      • Capture use cases mapped on the business process model

 Use case Diagrams for Requirements Modeling

      • Refine the use cases with requirements, constraints, prioritization and scenarios description

 Use case Diagrams for Refined Requirements Modeling

 Sequence Diagrams or Activity Diagrams for Use Case Details Modeling

      • Define acceptance tests and criteria for each use case
  • Analysis
  • Design
  • Implementation
  • Tests

OOAD Training

unified process unified process disciplines and uml 2 4
Unified ProcessUnified Process Disciplines and UML (2/4)
  • Business Process
  • Requirements
  • Analysis
      • Construct a domain model for business objects captured in the business process model and requirements model

 Class Diagrams (Conceptual perspective) for Domain Modeling

  • Design
      • Refine the domain model class diagram to capture the classes of the system with attributes and responsibilities.

 Sequence and Communication Diagrams for Interaction Modeling

 Class Diagrams Refinement (Specification perspective)

 State-Machine Diagrams for Behavioral Modeling

 Class Diagrams Refinement (Specification perspective)

      • Define unit tests for each class so that the class works and interacts with other related classes as expected
  • Implementation
  • Tests

OOAD Training

unified process unified process disciplines and uml 3 4
Unified ProcessUnified Process Disciplines and UML (3/4)
  • Business Process
  • Requirements
  • Analysis
  • Design
  • Implementation
      • Build a components structure to define interfacing service-oriented sets of classes

 Components Diagrams

      • Define integration tests for each components so that their required/provided interfaces meet the specifications
      • Model a package structure to define the technical grouping of classes and namespaces

 Package Diagrams

      • Define the physical architecture of the system (hardware, OS, network, …)

 Deployment Diagrams defined nodes with deployed components

      • Build the system by assigning use cases to the development team

 Class Diagrams (Implementation perspective)

 Activity Diagrams to specify detailed methods algorithm

  • Tests

OOAD Training

unified process unified process disciplines and uml 4 4
Unified ProcessUnified Process Disciplines and UML (4/4)
  • Business Process
  • Requirements
  • Analysis
  • Design
  • Implementation
  • Tests
      • Track defects from the testing phases and escalate to related models

 All UML diagrams reviewed

OOAD Training

unified process conclusion
Unified ProcessConclusion

Critical Unified Process practices

  • Both acquirer and supplier uses UP
  • Handle high-risk and high-value issues first
  • Engage users for evaluation and feedbacks
  • Build an executable core architecture in early iterations
  • Verify quality, test early and realistically
  • Apply use cases
  • Do visual modeling

OOAD Training

unified process conclusion1
Unified ProcessConclusion

Unified Process benefits

  • Accommodates change requests by reviewing the requirements at each iteration
  • Avoids one big-bang integration at the end of the project by integrating building blocks at each iteration
  • Better manage risks by implementing highest risks in early iterations
  • Fit potential tactical changes by developing quickly an executable architecture (adopt another technology vendor, compete with competitor…)
  • Encourage reuse by design reviews in early iterations
  • Implement robust architecture by detecting and correct defects in early iterations
  • Better use project resources through the spreading of disciplines workload along the iterations
  • Increase team maturity by analysing the opportunities and mistakes after each iterations and improving skills

OOAD Training

objectives and agenda3

Objectives and Agenda

Objectives

Overview of the software development evolution

Detailed presentation of the Unified Process

Agenda

Software development evolution

Facts

Conventional development

Iterative and evolutionary development

Unified Process

Introduction

Rational Unified Process

Phases and Iterations

Risk Management

Agile

Kick-off inception Phase

Course structure

course organisation
Course organisation

BPM

SSD

SMD

Class D

UC

Archi

OOD

OOD

DomainModel

From Design to code

Design Patterns

Priorit. UC

Evaluation

Kick-off

Kick-off

OOAD Training

objectives and agenda4

Objectives and Agenda

Objectives

Overview of the software development evolution

Detailed presentation of the Unified Process

Agenda

Software development evolution

Facts

Conventional development

Iterative and evolutionary development

Unified Process

Introduction

Rational Unified Process

Phases and Iterations

Risk Management

Agile

Kick-off inception Phase & Business Process Modeling

Course structure

software engineering process rational unified process inception phase
Software Engineering ProcessRational Unified ProcessInception Phase

Inception Main Objectives

  • Produce the vision
  • Establish the business case
  • Set-up the first version of Project Plan
    • Phase plan
    • Iteration plan
  • High-level Requirements understanding

Project Kick-off

OOAD Training

software engineering process rational unified process inception phase1
Software Engineering ProcessRational Unified ProcessInception Phase

Inception Main Objectives

  • Produce the vision
    • Define positioning (business opportunity, problem statement…)
    • Stakeholders view of the information system to be developed
    • High-level needs and features of the new system
  • Establish the business case
    • Justification for undertaking the project in the business context
    • Consideration of alternatives
    • Estimation of costs, risks, benefits expected
    • Management and technical approach
    • Feasible? Do it? Buy it?
  • Set-up the first version of project plan
  • High-level requirements understanding

OOAD Training

software engineering process rational unified process inception phase2
Software Engineering ProcessRational Unified ProcessInception Phase

Inception Main Objectives

  • Produce the vision
  • Establish the business case
  • Set-up the first version of Project Plan
    • Phase plan
      • Define the phases milestones
      • Staffing profile
    • First iteration plan
      • For elaboration
      • Rolling-wave and time-boxed
  • High-level Requirements understanding
    • Define the boundaries of the system
    • Detect roles interfacing the system
    • Primary high-level use cases (10% analysed)

OOAD Training

software engineering process rational unified process inception phase3
Software Engineering ProcessRational Unified ProcessInception Phase

Inception <> Requirements phase !

  • Inception answers to

“ Have the stakeholders basic agreement on the vision of the project and

is it worth investing in serious investigation ? ”

  • Start with business process modelling if your project
    • involve a lot of or complex processes or workflows;
    • involve processes that are unclear or need to be improved before they are automated;
    • involve many departments and users.
  • Main disciplines:
    • Business Process Modeling
    • Requirements Modeling
    • Domain Entity Modeling

OOAD Training

training and certification calendar
Training and certification Calendar

Session 1 - Introduction

Session 2 - Processes

Session 3 - Inception

Session 4 - Elaboration 1st iteration

Session 5 - Elaboration 2nd iteration

Session 6 - Mock exam + Q&A

Take IBM-833 exam before 31/01/2010

OOAD Training