1 / 28

Why To Y

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.

sera
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Why To Y Kyriakos KONSTANTOPEDOS Sogeti’s Second Testing Academy29 April 2009

  2. Summary • Introduction - Why To Y • Some history • Definitions • The Y lifecycle in detail • The Y lifecycle and TMAP • Conclusion • Questions

  3. Introduction

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

  5. History

  6. 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)

  7. Definitions

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

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

  10. The Y lifecycle

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

  12. 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)

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

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

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

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

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

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

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

  20. The Y lifecycle and TMap®

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

  22. Conclusion

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

  24. Questions ?

  25. Sogeti’s 2nd Testing Academy29 April 2009 www.sogeti.com

  26. Appendices

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

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

More Related