Why to y
This presentation is the property of its rightful owner.
Sponsored Links
1 / 28

Why To Y PowerPoint PPT Presentation


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

Why To Y. Kyriakos KONSTANTOPEDOS. Sogeti’s Second Testing Academy 29 April 2009. Summary. Introduction - Why To Y Some history Definitions The Y lifecycle in detail The Y lifecycle and TMAP Conclusion Questions. Introduction. Introduction – Why To Y.

Download Presentation

Why To Y

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


Why to y

Why To Y

Kyriakos KONSTANTOPEDOS

Sogeti’s Second Testing Academy29 April 2009


Summary

Summary

  • Introduction - Why To Y

  • Some history

  • Definitions

  • The Y lifecycle in detail

  • The Y lifecycle and TMAP

  • Conclusion

  • Questions


Introduction

Introduction


Introduction why to y

Introduction – Why To Y

  • Y lifecycle is a development process

  • Y lifecycle builds high quality systems respecting the user requirements

  • No tunnel effect during the development process

  • The system is specified from the user point of view

  • Functional and technical risks are treated and eliminated very early

  • Structured approach based on a UML model


History

History


Some history

Some history

  • On 1994 we counted about 50 different methods for the object oriented application design.

    • Own notation and process.

  • UML initiated the unification by merging the most used notations in a single modeling language.

    • Today UML is the industrial standard for designing object based applications.

    • But UML is just a modeling language.

  • Unified Process: the best practices of the object oriented development.

    • Thanks to the collaboration of Los 3 Amigos (Ivar Jacobson, Grady Booch and James Rumbaugh)


Definitions

Definitions


Unified process

Unified Process

built over a UML model

iterative and incremental

driven from the user requirements

and managed by the risks

  • A Unified Process is a development process

architecture centered


Y lifecycle 2 track unified process

Y lifecycle: 2 Track Unified Process

Functional axis

Technical axis

Implementation

  • System development is decomposed and treated in parallel following a functional and a technical axis

Requirements

  • Functional axis aims to model the functional part of the system to build.

  • Technical axis takes into account all the technical constraints of the system and builds the technical architecture of the system.

  • Both tracks converge and give the Y form to the lifecycle

  • The common track deals with the system implementation


The y lifecycle

The Y lifecycle


The y lifecycle1

The Y lifecycle

Builds the system architecture. Definition of the frameworks to use.

Specifies the system functionalities. The resulting model is independent from any kind of technology.

Workshops

Generic design

POC &

prototypes

HMI mockups

Functional specifications

Detailed design

Design of the system components ready to code.

System

Collects all technical constraints. Use cases can be used in order to model some technical needs.

Models the user business and the system’s context.

Requirements

Technical needs capture

Functional needs capture

GenericDesign

Functional Analysis

Integration of the functional model with the technical architecture. System is decomposed in components

Preliminary Design

Detailed Design

Coding and Testing

Validation

Implementation and test of the system.

Validation of the defined use cases.


Iterative and incremental process

Iterative and incremental process

All disciplines take place during each iteration

It 1

It i

It i+1

It n

  • 4 phases:

    • Inception: defines the scope of the project

    • Elaboration: builds and validates the architecture, specifies the requirements in detail and eliminates the most important risks

    • Construction: builds the system (includes testing)

    • Transition: deploys the system (includes user testing)


Iterative and incremental process1

Iterative and incremental process

  • Iterations allow to avoid the tunnel effect

  • Iterations let project teams to control the technical complexity progressively

  • Increments are potentially exploitable

  • Users can test them and give feedback

Potentially exploitable increments


Controlled by the risks

Controlled by the risks

  • Most frequent reasons of a project failure

    • Functional inadequacy to the users needs

    • Incapacity to manage the technical issues

  • The UP answer

  • Inception is allocated to the definition of the scope of the project using the context formalization techniques

  • Elaboration deals with the architecture definition and the development of the most important functionalities

  • Y cycle completes the approach by treating in parallel

    • Risks due to the functional imprecision on the left track

    • Risks due to the incapacity to integrate technology on the right track


Driven from the user requirements

Driven from the user requirements

<<External system>>

Credit card holder

Bank system

Retrieve money

Retrieve money

Consult operations

  • The system is specifiedfrom the users’ point of view

  • Graphical representation

  • Development is driven from the use case model


Driven from the user requirements1

Driven from the user requirements

  • Use cases are prioritized by the users

  • First produce the use cases bringing the most value to the users

Project accumulated value

Project target

Accumulated value of a Y project

Accumulated value of a project without managing the requirement priority

t

Accumulated value is maximized

  • The project development becomes quickly profitable

  • User acceptability of the project is better managed

  • Risks are reduced


Centered on the architecture

Centered on the architecture

Functional

needs

Technical needs

POC &

prototypes

  • Architecture brings the right answer to the client interests

    • Technology

    • System organization

  • Architecture is often the most critical aspect of a project due to the complexity of new technologies integration


Centered on the architecture1

Centered on the architecture

ESB

User

Interaction

Component

Multi-tier architectures

Service

Provider

Service

Consumer

User

Process

Component

Process Controller

Domain Object

Data

Access

Multi-layer architectures

Database

Mgmt System

Component based architectures

Service Oriented Architectures

  • Architecture defines the system organization

    • Multi-tier Architectures

    • Multi-layer Architectures

    • Component based Architectures

    • Service Oriented Architectures

  • The UML model reflects the architecture choices

    • Architecture choices must be respected during each step of the model construction

    • The architect uses the model in order to verify the conformity of the development to the client interests


Built over a uml model

Built over a UML model

Less detailed

(higher abstraction)

More detailed

(less abstraction)

  • UML is the industry standard in the object oriented development

  • The model is used in order to document, predict, study, collect orestimate information of the system

  • The model is an abstraction of the system to develop

    • Abstraction helps to cope with the complexity of the system


The y lifecycle and tmap

The Y lifecycle and TMap®


Y lifecycle and the tmap

Y lifecycle and the TMap®

Requirements

Requirements

Tech needs capture

Tech needs capture

Fn needs capture

Fn needs capture

Functional Analysis

Functional Analysis

GenericDesign

GenericDesign

Plan

P

Preliminary Design

Preliminary Design

Plan

S

P

Detailed Design

Detailed Design

S

Infra

Crtl

E

Coding

Coding

Test de performance

Infra

Crtl

E

A

A

Iteration n+1

Test de performance

Iteration n

Client


Conclusion

Conclusion


Y lifecycle vs other lifecycles

Y lifecycle vs. other lifecycles

The lifecycle provides development tools and methods

Functional and technical risks on the project

Have to develop by value

Not well defined

user requirements

The project is critical

Simple to learn

Need of formalism

No iteration

Highly agile &iterative lifecycle


Questions

Questions ?


Sogeti s 2 nd testing academy 29 april 2009 www sogeti com

Sogeti’s 2nd Testing Academy29 April 2009

www.sogeti.com


Appendices

Appendices


Y lifecycle model point of views

Y lifecycle model point of views

Structural

Logical

Exploitation

Deployment

  • The model provides several point of views:

Functional specification

Software specification

Hardware

Context

Technical analysis

Use cases

Domain analysis

Technical design

System analysis

Systemdesign

Component design


Y lifecycle model point of views1

Y lifecycle model point of views

  • Functional point of view (concerns the analysts)

    • Represents the model of the functional requirements using use cases organized in packages, actors, activities, interactions between objects and dynamic constraints

  • Structural point of view (concerns the analysts)

    • Represents the model of the functional requirements using classes, associations, generalization, etc.

  • Software specification point of view (concerns the architects)

    • In case where architect decided to distribute the technical requirements in layers, this view represents technical use cases, operators, etc.

  • Hardware point of view (concerns the system and network engineers)

    • Represents the physical organization of the network and the hardware using nodes and connections

  • Logical point of view (concerns the designers)

    • Represents the model “ready to code” of the solution using classes grouped in packages, associations, methods, etc.

  • Deployment point of view (concerns the operators)

    • Represents the workstations and localizes the components on the network using nodes (workstations, servers), connections and components. It can be used to diagnose failures

  • Exploitation point of view (concerns the operators and the designers)

    • Represents the component organization and identifies the functions provided by the installed software. Operators use this view in order to identify components that caused a failure. Designers use this view in order to identify software dependencies.


  • Login