Why to y
1 / 28

Why To Y - PowerPoint PPT Presentation

  • Uploaded on

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.

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

PowerPoint Slideshow about 'Why To Y' - sera

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


Sogeti’s Second Testing Academy29 April 2009


  • Introduction - Why To Y

  • Some history

  • Definitions

  • The Y lifecycle in detail

  • The Y lifecycle and TMAP

  • Conclusion

  • Questions

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

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)

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


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


  • 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 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.


Generic design



HMI mockups

Functional specifications

Detailed design

Design of the system components ready to code.


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.


Technical needs capture

Functional needs capture


Functional Analysis

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

Preliminary Design

Detailed Design

Coding and Testing


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


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



Technical needs



  • 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





Multi-tier architectures








Process Controller

Domain Object



Multi-layer architectures


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

Y lifecycle and the tmap
Y lifecycle and the TMap®



Tech needs capture

Tech needs capture

Fn needs capture

Fn needs capture

Functional Analysis

Functional Analysis





Preliminary Design

Preliminary Design




Detailed Design

Detailed Design







Test de performance






Iteration n+1

Test de performance

Iteration n


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

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

Sogeti’s 2nd Testing Academy29 April 2009


Y lifecycle model point of views
Y lifecycle model point of views





  • The model provides several point of views:

Functional specification

Software specification



Technical analysis

Use cases

Domain analysis

Technical design

System analysis


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.