280 likes | 428 Vues
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.
E N D
Why To Y Kyriakos KONSTANTOPEDOS Sogeti’s Second Testing Academy29 April 2009
Summary • Introduction - Why To Y • Some history • Definitions • The Y lifecycle in detail • The Y lifecycle and TMAP • Conclusion • Questions
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 • 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 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 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 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 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 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 • 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 <<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 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 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 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 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® 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
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 2nd Testing Academy29 April 2009 www.sogeti.com
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 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.