Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Vývoj Software
Co je metodika?
SAY what you do
DO what you say
And be able to PROVE it
plánovat – měřit – řídit
Rigorózní metodiky:
(MULTI)-PROJEKTOVÉ ŘÍZENÍ
Továrna na software - SDLC
Ekosystém pro flexibilní dodávání nových funkčností i změn
PROCES
Centrální repozitář projektových
artefaktů
Správa požadavků
Analýza Návrh Vývoj Testování Nasazení
Provázanost discíplín
Řízení verzí a změn všech artefaktů napříč
projektyAktuální informace z projektů
Architekt VývojářDeploy-
mentTester Podpora
Product
ManagerAnalytik
Regulace a standardy
Because regulations are non-directive, companies turn to industry standards for guidance
StandardsRegulations
SOX
FDA
CFR 21 Part 11
DoDAF
FEAF
Patriot ActHIPAA
ISO 900x
Six Sigma
ITIL CMMi
COSO
Basel II COBiT
RUP
Integrované řešení
Správa požadavků
© 2009 IBA CZ, s.r.o.
Get the RIGHT requirements
Get the requirements RIGHT
F
ED
CB
A Adapt to Change & Incorporate
Balance Competing Stakeholder Priorities
Create in Context Information About Requirements
Develop Solution to Solve Business Problem
Evolve and Incorporate Visual Techniques
Foster a Team Based Approach Through Collaboration
Definice a správa požadavků vs. realita
70-80% of development costs are spent identifying and correcting defects
More than 40% of development budget will be consumed by poor requirements
10
Lost Opportunity
Late to market by 6months or more will cost organizations 33% of the 5-year ROI
41% of projects fail to deliver expected business ROI
49% of projects overrun original estimates
-Standish Group
20
200
Relative Cost to Repair
Unit TestCodingDesignAnalysis
0
Maintenance
1-2
10
5
50
Acceptance
Team Issues, Shared pain, not vision
© 2009 IBA CZ, s.r.o. 11
Limited consensus
Analyst
Limited shared vision
CIO / IT Director
Delays and changes
Project Manager
Too much rework
Developer
Defects released
Tester
Solution unacceptable
Stakeholder
Unproductive: 10% of budget
Rework: 20% over budget
ROI Expectations: 41% of projects fail to deliver
RUP Best Practices – Manage Requirements
Formally defined as:
Eliciting, organizing, and documenting therequirements on the system
Establishing and maintaining agreement between thecustomer and the project team on the system's changing requirements
„No matter how carefully defined, requirements willalways change“.
PI&E 12
Dvě hlavní oblasti
Requirements Definition
Správná formulace požadavků
Definice problému nebo potřeby a konceptuální rámec řešení
Udržení kontextu (business requirements)
Textové, obrazové a další formy
Vytváření a správa atributů (priorita, status,…)
UC, procesní modely, storyboards, skeče, slovníky
Requirements Management
Provázanost, závislosti požadavků
Návaznost na dílčí cíle a koncepty
Vytváření a správa atributů
Workflow, schvalování, návaznost na ALM nástroje
Impact & gap analysis
Změnové řízení, verzování
13
Dobře definovaný požadavek
• Correct (technically and legally possible)• Complete (express a whole idea or
statement)• Clear (unambiguous and not confusing)• Consistent (not in conflict with other
requirements)• Verifiable (it can be determined that the
system meets the requirement)• Traceable (uniquely identified and tracked)• Feasible (can be accomplished within cost
and schedule)• Modular (can be changed without excessive
impact)• Design-independent (do not pose specific
solutions on design)
14
10 steps to better requirements management
Step 1: Structure requirements
• Duplicate requirements can cause work to be performed twice, lead to conflicts, and eventually double your maintenance cost. Omitted requirements may lead to missing functionality or cause shortcomings (see below, “Constraints”). Requirements should be structured to enhance understanding while avoiding duplication and omission. Traceability to higher- and lower-level requirements enables teams to assess coverage.
• Structuring requirements is the first step in taking control and improving the quality of requirements.
15
10 steps to better requirements management
Step 2: Manage and link customer needs, requirements and contracts
• Organizations typically collect the customer’s needs, captured “as is.” These needs undergo an internal translation to requirements in a format that meets the requirements characteristics described above. They may also be made more generic and less customer-specific (so the system can meet multiple customer needs). There is also often a stable contractual agreement, a legally binding third document. Organizations need to capture these levels of user requirements, maintaining intelligent traceability and change impact analysis between them.
16
10 steps to better requirements management
Step 3: Manage constraints• Requirements must not only describe functional behavior.
Nonfunctional requirements, also called constraints, can be critical for compliance and regulations and can add quality to the system. Typical nonfunctional requirements can specify:
• Performance• Interface• Security• Safety• Reliability• Availability• Maintainability
17
10 steps to better requirements management
Step 4: Visualize requirements
• Most requirements analysts find augmenting textual requirements with modeling helpful, whether this means drawing pictures on a whiteboard, utilizing presentation tools such as Microsoft® PowerPoint or simply creating a mental model. These representations should be managed alongside the requirements to help ensure consistency, traceability and change control. Visual requirements modeling provides a simple and powerful way to communicate with, and elicit requirements from, customers and end users. It also helps clarify requirements and create a common understanding between all development team members and stakeholders.
18
10 steps to better requirements management
Step 5: Test requirements
• An efficient way to better manage requirements is to ensure they are clearly mapped to test cases. Making sure each requirement is clearly verifiable from the start not only helps prepare later phases of the project, but it also puts the writer in the correct state of mind. Note that this is true for the nominal functional mode (making sure the system or software does what it’s supposed to do). Requirements and their associated tests must also indicate what the system should not do, and what happens at the limits (degraded mode).
19
10 steps to better requirements management
Step 6: Bridge the chasm between business and development
• In many cases, the route to better requirements management is to have fewer requirements. Projects cannot always offer the luxury of implementing all customer requests, marketing ideas and business suggestions when they also have to meet budget and deadline objectives. Rather than trying to manage every requirement, project and product managers must be able to make decisions on those requirements that bring the most value to the customer and help the business improve innovation. This can be achieved by combining value and priority information from stakeholders and defining the right combination of requirements.
20
10 steps to better requirements management
Step 7: Control change to requirements
• Requirements are subject to continual change. As a project progresses, organizations need to remain agile, adapt to engineering imperatives and respond to evolving marketplace situations and customer needs. Writing a perfect first requirement is insufficient if its evolution isn’t well managed—poorly controlled change can lead to inadequate systems and software, rework effort and loss of revenue.
21
10 steps to better requirements management
Step 8: Capture and track metrics and trends• Today’s complex projects demand automated data collection
and reporting facilities to streamline project management. As such, project managers and all stakeholders need a “management dashboard” of metrics and trends that enables them to quickly monitor project activities such as the progress, growth and volatility of actual requirements. In other words, project managers need to keep their focus on decision making instead of manually gathering data and compiling reports. Most importantly, the display of key requirements monitoring information must be at a high level, allowing users to manage by exception and spot trouble areas quickly. A high change frequency on a specific requirement or a whole subsystem may indicate that the requirement needs to be revisited with the customer. A large amount of rework on implementation may point at a poorly specified original requirement.
22
10 steps to better requirements management
Step 9: Provide examples of good requirements
• By providing examples and counterexamples of good requirements and documents, organizations can enhance the quality, consistency and completeness of their requirements. These can originally be templates, industry standards and rules inside a repository, or a corporate intranet.
23
10 steps to better requirements management
Step 10: Reuse requirements
• When a good requirement has been written for a previous project and it is applicable to a present situation, the natural reaction is to reuse it, generally by copying and pasting the description. This unfortunately breaks the traceability and eliminates impact analysis. A smarter approach to reuse is to maintain a link between the two requirements (for example, creating a reuse type link). This enables analysts to access the original requirement at any time to check allocation of implementation, for instance. Likewise, any changes made to the original requirement (issues detected, updates needed) can lead to the notification of reusing teams.
24
Příklad špatného požadavku
25
Klíč Shrnutí Popis Priorita Stav
XXXX-40 Systém bude
autentizovat vůči
Active Directory (s
využitím SSO)
Na straně AD
bude muset dojít
k revizi, zda AD
obsahuje
potřebné
informace nutné
ke kategorizaci
uživatelů.
must have Accepted
Correct Complete Clear Consistent Verifiable Traceable Feasible Modular DesignIndepent
Y N N N/A N Y Y Y Y
Příklad špatného požadavku
26
Klíč Shrnutí Popis Priorita Stav
XXXX-48 Systém bude
umožňovat
administrátorovi
či oprávněnému
uživateli měnit
rozvržení stránek
portálu
must have Accepted
Correct Complete Clear Consistent Verifiable Traceable Feasible Modular DesignIndepent
Y N N N/A N Y Y Y Y
Příklad špatného požadavku
27
Klíč Shrnutí Popis Priorita Stav
XXXX-42 Systém bude
umožňovat
přístup minimálně
50 uživatelům
Jedná se o přístup
všech
konkurenčních
uživatelů
must have Accepted
Correct Complete Clear Consistent Verifiable Traceable Feasible Modular DesignIndepent
N N N N/A N Y ? ? Y
Příklad špatného požadavku
28
Klíč Shrnutí Popis Priorita Stav
XXXX-39 Systém bude
generovat obsah
v XHTML
Záleží na
jednotlivých
prezentačních
šablonách, jak
validní výstup
generují.
must have Proposed
Correct Complete Clear Consistent Verifiable Traceable Feasible Modular DesignIndepent
Y N N N/A Y Y N ? Y
Příklad špatného požadavku
29
Klíč Shrnutí Popis Priorita Stav
XXXX-157 Systém bude umožňovat synchronizaci mezi úložištěm fotobanky a úložištěm portálu
Jedná se o jednosměrnou datovou pumpu z úložiště fotobanky do úložiště portálu.
Obsah označený jako "portálový" v úložišti fotobanky bude replikován do úložiště portálu.
Correct Complete Clear Consistent Verifiable Traceable Feasible Modular DesignIndepent
Y N Y N/A Y Y Y ? N
Requirements Definition and Management
Requirements Definition
Get requirements rightDefine the problem and conceptualize solutionsMaintain the context of business needs
Requirements Management
Trace requirements to objectives, tests and designsUnderstand the impact of changeKnow what requirements have been delivered
BusinessStrategy
ComplianceMandates
CustomerRequests
CompetitiveResponse
Innovation
Business processes
Sketches and storyboards
Use cases
Rich text
Requirements Management
Search, filter on attributes
Traceability between related
artifacts
Impact & Coverage analysis
Business Objectives
Business Processes
Use Cases
Storyboards & Sketches
Prototypes
Text to visual transformation
Requirements DefinitionElicit, capture, review and discuss
requirements using a variety of techniques and notations
Rich text Requirements
Industry & Domain Models
Requirements Definition and Management
Druhy požadavků
Záleží na metodice…obvykle funkční a nefunkční
Změnové řízení, analytický slovník
STRQ Stakeholder request
FEAT Feature
UC Use case
SUPL Suplementary specs
TERM Glossary
Business rule
Vision
Software
…
32
System Boundary
STRQ
FEAT
UC SUPL
Supporting Features
Supporting Use Case Supporting Non-Functional
IBM GS Method
33
Requirements
Functional
Non-Functional
Change Cases
Glossary
Functional
Non-Functional
Funkční požadavky
34
Functional
Actors
Use Cases
Business Rules
User Centred
Design
Site Map
Brand Analysis
Reports
Control and
Auditability
Context Diagram
Screen Layout
Screen
Navigation
Scenarios
Style Guide
Look and Feel
Use Case List
Use Case
Summary
Use Case Detail
Nefunkční požadavky
35
Non-Functional
Requirements
Resource
Constraints
Quality
Objectives
Performance /
Efficiency
Robustness
Architecture
Security
Archive and
Purge
General
Deployment
National
Language
Support
Schedule
Budget
People
Hardware
Software
Usability
Maintainability
Testability
Development
Locations
Pre-selected
Packages
Existing
Infrastructure
Architecture
Standards
User Interface
Standards
Service Levels
System
Management
Software
Distribution
Business
Environment
Locations
Usage Profiles
User Profiles
Změnové řízení
36
Change Cases
Functional
Non-Functional
Scalability
Portability
Modifications
New Actors
Customisability
Reusability
Additions
Requirement Relationships
Requirements can have dependencies on another requirement of the same type (Hierarchical)
STRQ1 – Process ApplicationThe system shall process an online application submitted by the client
STRQ1.1 – Accept PaymentThe system shall accept payment from the client via Debit, Credit Card, or check
STRQ1.2 – Fax ApplicationThe system shall fax the content of the application to the telephone number specified on the client’s application
STRQ2 – Assign Client NumberThe system shall create a client number for the completed application
Requirement Relationships
Requirements can have dependencies on a requirement of a different type (Traced)
STRQ1 – Process ApplicationThe system shall process an online application submitted by the client STRQ1.1 – Accept Payment
The system shall accept payment from the client via Debit, Credit Card, or check
FEAT1 – Validate Debit PaymentThe system shall validate the Client’s Debit Card number from the client’s bank
FEAT2 – Display Card ErrorThe system shall display to the client any error identified when validating the card number
STRQ1.2 – Fax ApplicationThe system shall fax the content of the application to the telephone number specified on the client’s application
STRQ2 – Assign Client NumberThe system shall create a client number for the completed application
Role of Traceability
Traceability helps us manage the flow down from one requirement to another. It allows us to:
Keep track of the origin of a derived requirement
Where does this requirement come from?
Keep track of the artifacts dependent on a particular requirement e.g. subsystems, design components, test cases etc.
Traceability is key to ensure:
Implementation fulfils the requirements
Ensure all requirements are addressed
Implementation scope is managed
Only implement what is needed
Manage Changes
Analyze the impact of making changes – what is the real impact?
If a change is implemented ensure all dependent requirements, models, designs and tests are updated
39
Requirements Driven Flow-Down
40
Business Modeling
Business Vision
Business Rules
SupplementaryBusiness
Specification
BusinessObject/Process
Model
Business Use-CaseModel
BusinessUse-Case
Specification
Policy doc’s
Commercial doc’s
Regulatory doc’s
Requirements
Driven
Flow-Down
Traceability
Requirements
Use-CaseModel
GlossarySupplementary
SystemSpecification
Use-CaseSpecification
Use-Case Model SurveyVision
Software Architecture Document
Design Model
Analysis andDesign
ClassData ModelDesign Subsystem
Implementation Model
Components (code)
Implement-ation
Test Plan
Test
Test Scripts/Procedures Test Cases Test Model
Analysis Model
Following the IBM Rational Unified Process (RUP)
Design Traceability Tree
Significant (Out of the Box)
STRQ
FEAT
UC SUPL
FEAT - Feature
STRQ - Stakeholder Request
SUPL - Supplementary
UC - Use Case
Traceability Tree
LegendTERM
Design Traceability Tree
STRQSCOPECHART
FEAT
UC SUPL
CHART - Charter
FEAT - Feature
SCOPE - Scope
STRQ - Stakeholder Request
SUPL - Supplementary
UC - Use Case
Traceability Tree
LegendTERM
Design Traceability Tree
STRQSCOPECHART
FEAT
UC SUPL
BR
ASMP - Assumption
BR - Business Rule
CHART - Charter
DPR - Data Propagation
DTR - Data Transformation
FEAT - Feature
FSPEC - Functional Spec
REF - Reference
SCOPE - Scope
STRQ - Stakeholder Request
SUPL - Supplementary
TSPEC - Technical Spec
UC - Use Case
Traceability Tree
Legend
REF
TERM
ASMP
MEMO
Design Traceability Tree
STRQSCOPECHART
FEAT
UC
DTR
SUPLDPR
FSPEC TSPEC
BR
ASMP - Assumptions
BR - Business Rule
CHART - Charter
DPR - Data Propagation
DTR - Data Transformation
FEAT - Feature
FSPEC - Functional Spec
REF - Reference
SCOPE - Scope
STRQ - Stakeholder Request
SUPL - Supplementary
TSPEC - Technical Spec
UC - Use Case
Traceability Tree
Legend
REF
TERM
ASMP
MEMO
Správa požadavků
Rational Requisite Pro
• evidence požadavků
• dokumenty specifikací
• integrace MS Word
Rational ClearQuest
• obecný nástroj pro správupožadavků (úkolů, defektů,…)
• důraz na worklow
Rational Requirement Composer
Rational Rose Data Modeler
Manage requirements with Rational RequisitePro
46
IBM Rational RequisitePro
User-defined requirement types
User-defined attributes
User-defined filters (views)
Saved views
Customizable views
Export views to Word or Excel
Create and compare baselines
Graphical trace matrix
Textual trace matrix
Graphical trace tree
Customize Requirement Data
Customize Information Presentation
Manage ChangingRequirements
Requirements Definition
Definice požadavků
Text - wiki
Slovník
Procesy
Případy užití
Makety GUI
47
DB DB
Spreadsheets
Models
Documents
Folders
DataEmails
Images
Glossaries
Hyperlinks
Requirements Definition
Obchodní cíle
Obchodní procesy
Scénáře a skicy
Oborové a doménové modely
Textové dokumenty
Případy užití
Prototypy
Návrhy GUI
Slovník
Vymyslet, navrhnout, popsatformulovat, diskutovat, …
48
Business processes
Sketches and storyboards
Use cases
Rich text
Requirements Definition
49
DOORS Family of Products
50
Designed to give each stakeholder the right capabilities
DOORS
– Provides rigorous support for detailed and complex requirements management
DOORS Web Access
– Zero-footprint, web-based access to view and discuss requirements that are managed with DOORS
DOORS Analyst
– Provides a visual modeling capabilities which allows requirements to be described in diagrams as well as text
Cover the Spectrum
51
Systems
Formal Req. Change Process
Telelogic Tools / Harmony Process
Formal Rigorous Compliance / FDA
Reviewer Web Client (Coming in July)
DOORS
Software / IT
Lightweight Req. Change Management
Rational Tools / RUP
Full Web Client
RequisitePro
IT Compliance
One Size Does NOT Fit All
DOORS vs. RequisitePro
DOORS scales well to larger complex projects
DOORS security is more granular
DOORS supports (well) 1000s, 10s of thousands or millions of requirements well
DOORS provides electronic signature
History and experience has taught us where RequisitePro and DOORS perform the best
–DOORS historically has sold well into larger, complex IT organizations and systems
–RequisitePro historically has sold well into small IT organizations or small teams in larger organizations
–There are always exceptions
52
Modelování, design, architektura
Model VisusallyBEST PRACTICE
Model Visually
Visual modelling benefits:
Aids understanding of complex system
Helps unambiguous communication
Forms foundation for implementation
Precise capturing of requirements
55
Model Driven Development
Modeling is the standard approach in engineering to
Manage Complexity
Mitigate Risk
Software development is the same asevery other kind of engineering in this respect
Code and other artifacts can be derived from models
56
Well, maybe you shouldn’t’
But then, maybe you should
Maybe you have to
What types of models are important?
Business Model
Visualization of business processes
System Architecture Model
Visualization of the system requirements, structure, and behavior
Use Case Model
Visualization of functional requirements
Analysis Model
“What” the system must do to realize the functional requirements with the system
57
User Experience Model
Visualization of user interaction with the system
Design Model
“How” the system will realize the functional requirements
Data Model
Visualization of persistent storage
Implementation Model
Visualization of the code
Different Stakeholders, Different Models
Representing Architecture
No thick document required
Much of the architecture can be
Selected instead of designed
Referenced instead of described
58
• We are going to use the Chain of Responsibility Pattern to blah
• We have selected Oracle because it will meet the performance requirements and the customer already has licenses and trained DBAs
• We are going to apply a network architecture like this.
• We are applying these J2EE Blueprints
• We are going to distribute the components across the layers this way.
UML 2.0 Diagrams
PI&E 59
Component Diagrams
Interaction Diagrams
State Machine Diagrams
Composite Structure Diagrams
Class Diagrams
Use Case Diagrams
Activity Diagrams
Deployment Diagrams
Activity diagramsshow flow of control and data flow
Use cases are a visualization the functional requirements of a system
Interaction diagrams show the communication behavior between parts of the system
Class diagrams show static structure
Composite Structure diagrams show the internal structure of a classifier and its interaction points to other parts of the system
State machine diagramsare created for objects with significant dynamic behavior
A component is a modular unit (logical or physical) with well defined interfaces that is replaceable within its environment
Deployment diagrams show the execution architecture of systems
Classifications of Models in MDA
Computation-IndependentModel
Platform-IndependentModel
Platform-SpecificModel
More Abstract
More Specific
Computation-Independent Model (CIM) Example
Uses the vocabulary of the domain.
No information in the model indicates that a computer-based solution will be used.
Platform-Independent Model Example
Less abstract than CIM
Closer to implementation but not tied to a platform.
Platform-Specific Model Example
Less abstract than PIM
Closer to implementation
J2EE elements captured in model
Modelování
Rational Software Modeler (RSM)
• Vizuální modelování
• UML
• MDD
Rational Software Architect (RSA)
• Návrhové vzory…
• Vývoj Java EE, C/C++
• .NET modeling extension
WebSphere Business Modeler (WBM)
• Procesní modely a jejich simulace
• BPEL
System Architect
65
Construction tools
IBM Analysis Design & Construction v7 Portfolio
67
ImplementationTechnology
Information ArchitectureTechnical Architecture Construction/Assembly
Business Architecture
Std. C/C++, JavaEmbedded, realtimeRational Rose Technical Developer
Rational Systems Developer Third-Party IDE
VerticalDomainAdd-onsModel-driven
systemsdevelopment
WAS, J2EE,WebSphere Portal, Native System z, System i, Win, Linux, UnixTomcat, BEA WebLogic
Java, Web,Win, Linux, Unix
RWD
Rational Application Developer
VisualConstruction
DatabasesRational Data ArchitectData-driven
development
WebSphere Process Server
WebSphereBusiness Modeler
WebSphere Integration Developer BPEL
Business processmodeling & integration
Visual Studio, JBuilderRational RoseOther IDEs Other Data Modeling Tools
ClassicMDD
Software Modeler
Rational Software ArchitectModel-drivendevelopment
Businessapplicationdevelopment
EGLExtension
EGLExtension
EGLExtension
ModelingExtension for .Net
ModelingExtension for .Net
ModelingExtension for .Net
The Big Picture of SOA Development Cycle
68
Rational RequisitePro
Create, Simulate & Analyze As-Is Business Model
WebSphere Business Modeler
Create FinancialReports & ROIEstimates
Create Observation Model with KPIs & export to Monitor
Create, Simulate, Analyze and Optimize To-Be Business Model
BusinessAnalyst
Integration Developer
WebSphere Integration Developer
Choreograph services using BPEL, WSDL, etc.
Configure Human Task Manager (including Ad-Hoc) & Client
Assemble Solution(BPEL, Human Task Manager, Business Rules, etc)
Understand Risk, Project Costs, and ROI
Identify and Manage Projects and Resources
CIO
ProjectManager
Rational PortfolioManager
DatabaseArchitect
ModelRelationalDatabaseSchemas
Rational Data Architect
RDB Mapping
Trace Requirements & Create System Use Case Realizations
Model & Implement Services, & expose as Web Services
Test Create & Manage SystemRequirements
Architect
Rational
Software
Architect JavaDeveloper
Develop Portlets(App UI and Monitor)
PortalDeveloper
Tester
Rational Functional & Performance Tester
IBM Rational Team Unifying Platform
UML
DBA
Deploy/Run
MonitorBusinessOperationsAnalyst
RuntimeWebSphere Process ServerWebSphere Portal WB Monitor
WSDLEAR
WSDLEAR
Observation Model
Run-time Statistics
BPELWSDL
Vývojové nástroje, architektura
Rational Software Architect (RSA)
Rational Application Developer (RAD)
Rational Web Developer
Rational Systems Developer
WebSphere Integration Developer (WID)
Rational Business Developer
Rational Transformation Workbench
Rational Host Access Transformation Services (HATS)
Rational Developer for system z, i
Rational Data Architect
Rational Rose
Software Configuration Management
© 2009 IBA CZ, s.r.o.
Manage Change
BEST PRACTICE
Konfigurační a změnové řízení
Rational ClearCase (CC)
Rational ClearQuest (CQ)
Rational CC Multisite,
Rational CQ Multisite
Rational Team Concert
Unified Change Management (UCM)
Opensource
JIRA
Microsoft
Team Foundation Server
ClearQuest
• Nástroj pro správu změn a „požadavků“
• Orientace na velké, distančně oddělené až transkontinentální týmy
• Umožňuje vazby mezi artefakty z celého životního cyklu projektu
• Garantuje tracebilitu, auditibilitu, …
• Umožňuje notifikace pomocí e-mailů
• RoundTrip e-maily
Rational ClearQuest – Eclipse GUI
74
ClearCase
• Nástroj pro správu verzí
• Pokročilé řízení přístupu
• Umožňuje plně paralelní vývoj
• Varianta MultiSite řeší geograficky oddělené týmy
• Umožňuje 2 druhy verzování – BASE a UCM
• Verzuje jak soubory, tak adresáře
• Rozpozná až 150 typů elementů
ClearCase - View
• Izolovaná pracovní plocha, poskytující pohled na konkrétní verze elementů
• Konkrétní verze elementů jsou vybírány podle soustavy pravidel – tzv. Configuration Specification
• Zpřístupňuje modifikovatelné kopie konkrétních verzí elementů
• Dynamické view
• Udržuje spojení se serverem
• Okamžitě reflektuje potvrzené změny ostatních uživatelů
• MVFS
• Verze elementů uloženy ve sdílené složce
• SnapShot view
• Offline přístup
• Verze elementů uloženy na lokální disk
Build & Release Management
© 2009 IBA CZ, s.r.o.
Release management
Rational Build Forge
• Automatizace sestavení aplikace
• Multiplatformní řešení
• Kompatibilita s existujícími nástroji
• Build scripty
• Dokumentace, audit
• Reporting, metriky
Software Quality
© 2009 IBA CZ, s.r.o.
Contituously Verify Quality
Software problems are 100 to 1000 times more costlyto find and repair after deployment.
Verifying and managing quality throughout theproject's lifecycle is essential to achieving the rightobjectives at the right time
81
Traditional testing methodology comes up short
82
Requirements phaseDesign/Build phase
Releasedas a product
QA/Testing phase
Source: 2008 GBS Industry standard study
Defect cost derived in assuming it takes 8 hrs to find, fix and repair a defect when found in code and unit test. Defect FFR cost for other phases calculated by using the multiplier on a blended rate of $80/hr.
$80/defect$240/defect
$960/defect
$7,600/defect
Traditional QA Testing 25 – 30 % delivery time in testing Poor upstream quality yields rework Compressed schedules make it worse
80% of development costs are spent identifying and correcting defects!
Quality is a continuous, iterative, integrated process
83
GOVERN TEST LIFE-CYCLE
FUNCTIONAL & SYSTEM TEST
PERFORMANCE TESTDEPLOY & MANAGE
ANALYZE DESIGN VALIDATION
OPTIMIZE
UNIT TESTING
BUILD TESTING
What Does Test Management Mean to Project
PROJECT & PORTFOLIO MANAGEMENT
Change&Release Mng.Requirements Mng. Test Management
Functional Testing(Regression Testing,Manual Testing,...)
Performance TestingSecurity Testing
Zajištění a řízení kvality
• Manuální testování
• Funkční testování
• Výkonové testování
• Bezpečnostní testování
• Compliance testování
• Statická analýza
Requirements Tests Defects
Manuální testování
Rational Manual Tester (RMT)
• Usnadňuje vytváření testovacích scénářů
• Poloprůhledné okno během testování
• Automatizované porovnání textů
• Vkládání screenshotů
Improve manual testing projects
Funkční testování
Rational Functional Tester (RFT)• Urychluje testování• Detekce GUI objektů – Java, .NET, web• Verifikační body• Datapools• Adaptivní technologie ScriptAssure
RFT rozšíření • Siebel• SAP• terminálové aplikace
Rational Robot• Testování starších C/C++ aplikací
Automation to speed testing and improve accuracy
89
Výkonové testování
Rational Performance Tester (RPT)
• Umožňuje včas detekovat výkonové problémy
• Skriptování podobně jako RFT
• Virtuální uživatelé
RPT rozšíření pro Siebel, SAP, Citrix, Oracle, SIP
Rational Purify
• detekce úniků a poškození paměti
• C/C++, Java
Rational Purify Plus
• Navíc profiler
Rational Test Realtime
• Testování embeded aplikací
Rational Tester for SOA Quality
• Testování web services
• Generování testů podle WSDL
IBA CZ, s.r.o.
Analyze application load and performance
91
Bezpečnostní testování
Rational AppScan
• Scanner webových aplikací
• Detekuje bezpečnostní problémy
• SQL injection, XSS, Session HJ,…
• Navrhuje doporučení
Compliance testování
Rational Policy Tester
• Scanner webových aplikací
• Podpora standardů
• Regulační předpisy
• Kvalita
• Ochrana soukromí
• Přístupnost
Statická analýza
Rational Software Analyzer
• Analýza zdrojového kódu
• Java, C++
• Best practices
• Návrhové vzory
Collaborative and adaptive test plan management
Structured test plan with multiple user defined sections
Track test plan history with version snapshots
Individual ownership for every section
Rational Quality Manager
Analyst
Project Manager
Lab Manager
Proof of process
All project stakeholders can review, refine and sign-off on all quality related artifacts
Artifact Versioning
QA team maintains accurate project history with detailed artifact versioning
Requirements Signoff
Quality Certification
Ready for Release
Project A
Project B
Project C
Artifact Reviews and Approvals
Improve operational efficiency
Step by step capture and execution of manual tests
Keyword support for integrated manual and automated testing
Rich defect capture during execution, including screenshot and attachments
Simple intuitive interface for quick test execution
Manual Test Execution
What is needed: Integrated manual test authoring and execution
Reduce risk with constant access to quality metrics
Performance risks are always visible and quickly resolved
Security risks are monitored continuously to ensure business continuity
Manual and functional test automation results available
Testing of requirements can be tracked to assure business needs are realized
Change management and defect tracking fully integrated to assure all changes to production are tested
Quality ManagerDashboard
Lifecycle quality perspective to proactively manage risk
Project & Portfolio Management
© 2009 IBA CZ, s.r.o.
Develop iteratively
BEST PRACTICE
Identify End Goal
101
Stakeholder Satisfaction Space
Project Starting Point
Your goal is to find a Path from
Here to There
Define When Key Management Can Be Achieved
102
Stakeholder Satisfaction Space
1 2 3 4 5 6
Do we understand
the problem?
Do we understand
the solution?
Feature complete?
Release ready?
Planned Completion
Planned Path
Inception Elaboration ConstructionTransition
Use Iteration Assessments to Change Direction
103
Planned Path
Actual Path
1 2 3 4 5 6
1 2 34
5 67Updated
Project Plan
Planned Completion
Stakeholder Satisfaction Space
Manage Requirements
Vyřeš správný problém - vytvoř správný systém
Solution Space
Problem Space
Needs
Features
SoftwareRequirements
Test ScriptsDesign User
Docs
The Product
to Be Built
BEST PRACTICE
Projektová metodika
Rational Unified Process
Rational Method Composer
Rational Process Library
Je pro vaše projekty RUP moc velký?
Small RUP
OpenUP
© 2008 IBA CZ, s.r.o.
RUP je projektová metodika
lépe
radostněji
rychleji
levněji
predikovatelně
RUP minimalizuje riziko
Risk Reduction
Time
Risk
Iterative Risk
Waterfall Risk
History of RUP
108
Planning
Requirements
Analysis & Design
Implementation
Deployment
Test
Evaluation
ManagementEnvironment
Iterace
Fáze
Architecture baselined
Lifecycle Architecture Milestone
Scope and Business Case agreement
Lifecycle Objective Milestone
Product sufficiently mature for customers
Initial Operational Capability Milestone
Customer acceptanceor end of life
Product Release
Inception Elaboration Construction Transition
time
The Spirit of RUP
112
Hlavní principy (Concept)
Adapt the Process
Balance Competing Stakeholder Priorities
Collaborate Across Teams
Demonstrate Value Iteratively
Elevate Level of Abstraction
Focus Continuously On Quality
RUP Tailoring
Small – medium – largeProcess library
Process Maturity
115
CMMI Capability Maturity Model IntegrationMCIF Rational Measured Capability Improvement Framework
OpenUP
OpenUP
117
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
118
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
119
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
120
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
121
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
122
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
Projektové řízení, správa projektů, reporting
Rational Portfolio Manager (RPM)
• Evidence práce
• Postup na projektu
• Finanční ukazatele
Rational Asset Manager (RAM)
• Tvorba a správa „assetů“
• Re-use
• Podpora SOA