kiv/sizcu.arcao.com/_statnice_ing_fav/nis/prednasky-si/sip10-sdlc.pdfrequirement, project and...

KIV/SIPřednáška č.10

Jan Valdman, [email protected]

3.5.2011

mailto:[email protected]

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


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


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


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


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


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


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


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


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


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


26



umožňovat

administrátorovi

či oprávněnému

uživateli měnit

rozvržení stránek

portálu

must have Accepted


Y N N N/A N Y Y Y Y


27



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


N N N N/A N Y ? ? Y


28



generovat obsah

v XHTML

Záleží na

jednotlivých

prezentačních

šablonách, jak

validní výstup

generují.

must have Proposed


Y N N N/A Y Y N ? Y


29


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.


Y N Y N/A Y Y Y ? N

Requirements Definition and Management


Get requirements rightDefine the problem and conceptualize solutionsMaintain the context of business needs


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


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


STRQSCOPECHART

FEAT

UC SUPL

CHART - Charter

FEAT - Feature

SCOPE - Scope



UC - Use Case

Traceability Tree

LegendTERM


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



TSPEC - Technical Spec

UC - Use Case

Traceability Tree

Legend

REF

TERM

ASMP

MEMO


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



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


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


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


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.

http://www.amazon.com/gp/product/images/0201633612/ref=dp_image_0/103-2158338-1013418?ie=UTF8&n=283155&s=books

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



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

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/oct01/t_requisitePro_fig2.jpg

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


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


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