Trainers:
This presentation is the property of its rightful owner.
Sponsored Links
1 / 78

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


  • 78 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Altran CIS O bject- O riented A nalysis and D esign

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


Altran cis o bject o riented a nalysis and d esign

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 engineering evolution why

Software engineering evolutionWhy?

OOAD Training


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


Software development approaches scrum

Software development approachesSCRUM

OOAD Training


Software development approaches scrum1

Software development approachesSCRUM

OOAD Training


Altran cis o bject o riented a nalysis and d esign

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 planning exercise user stories

    Unified ProcessPlanning – Exercise – User stories

    8, 2, 2, 1, 020, 5, 2, 1, 0.5


    Unified process planning exercise detailed tasks

    Unified ProcessPlanning – Exercise – Detailed tasks


    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


  • Login