Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

Definování a správa požadavků Automated Software Quality Miroslav Borský

Podobné prezentace


Prezentace na téma: "Definování a správa požadavků Automated Software Quality Miroslav Borský"— Transkript prezentace:

1 Definování a správa požadavků Automated Software Quality Miroslav Borský

2 Stav trhu Jen 32% IT organizací dodává včas, bez překročení rozpočtu a na základě požadavků  65% koncových uživatelů si myslí, že software nedělá to, co potřebují nebo požaduje drobné úpravy a nové vlastnosti. (customer webinar)  Tři nejčastější příčiny selhání projektů souvisí se špatnými požadavky  82% předělávek má původ ve špatných požadavcích  50% lidí neví kde nebo proč dochází ke ztrátě kvality, případně vědí, že produkt někdy kvalitní je a někdy ne, ale nedokáží určit příčinu. (source: customer webinar)

3 Kde končí snaha vývojářů? 25%Předělávky (zdá se vám to málo? Akceptovaný standard je 20-40%) + 45%Nikdy nepoužitý kód* + 20%Zřídka použitý kód* Až 90% práce vývojářů má velmi malý obchodní přínos! A to jsme nezapočítali čas strávený dokumentací, testováním a integrací… Nehezká pravda: Za každou korunu investovanou do vývoje… …můžeme dostat klidně jen 10 haléřů funkčnosti *(Standish Group Study Reported at XP2002 by Jim Johnson, Chairman) - Poppendieck

4 Kde nejlépe investovat energii? Source: Barry W. Boehm, Software Engineering Economics

5 žádost Sběr a definování požadavků pomocí vizuální specifikace podporuje komunikaci Snižuje riziko, množství předělávek a nespokojenost Spojuje jednotlivé týmy: Obchodníky, analytiky, programátory, architekty, QA,… Sběr a definování požadavků pomocí vizuální specifikace podporuje komunikaci Snižuje riziko, množství předělávek a nespokojenost Spojuje jednotlivé týmy: Obchodníky, analytiky, programátory, architekty, QA,… implementace

6 Visual clarity - simulation

7 Zkratka ve zpětné vazbě Requirements Analysis System Design Architecture Design Module Design Coding Acceptance Testing System Testing Integration Testing Unit Testing Zaplatit Vyzkoušet

8 Vizualizace požadavků Vizualizace redukuje nejednoznačnost Napomáhá odhalení špatných či chybějících předpokladů Zpětná vazba od zúčastněných stran zvyšuje kvalitu požadavků Zakládá společnou vizi a sdílenou zodpovědnost. Pomáhá ujasnit tvar obchodních procesů a obchodní koncepty

9 Simulace požadavků Upevnění společného chápání požadavků Pro-aktivní validace, zkuste před zakoupením Platforma pro inovace Schválení zainteresovanými stranami Pomáhá ujasnit způsob implementace

10 Pragmatická přesnost

11 Od správy dokumentů ke správě požadavků Ruční správa dokumentů –Každý člen týmu si udržuje vlastní zdroj informací –Část informací je obtížně sdílitelná (brainstorming, papír) –Informace jsou uloženy ve více formátech (doc, xls, mail) –Mezi informacemi nejsou udržovány logické vazby Správa požadavků – systémový přístup –Společné úložiště dat (zabezpečení, historie, jednotnost) –Logické závislosti mezi požadavky/externími artefakty (kód, test, model) –Správa verzí, notifikace a analýza dopadu změn (na základě závislostí) –Smluvní správa rozsahu (schvalování, pevný soubor požadavků) –Atributy požadavků (typ, priorita, pracnost, vlastník, přílohy, diskuse) –Generování dokumentace, přehledů, statistik a testovacích scénářů –Vazba mezi technickým řešením a obchodním záměrem/přínosem  konzistence, sjednocení, automatizace, procesní přístup

12 Vlastnosti požadavků Kompletnost - nic nechybí Konzistence - požadavky si neodporují Korektnost - zachycují přání zákazníka přesně Feasibilita - jsou implementovatelné Možnost změny - jednoduchost, určení dopadů Potřebnost - zachycují potřebu zákazníka Prioritizace – ohodnocení podle důležitosti jejich zastoupení v produktu Jednoznačnost - jdou vyložit jen jedním způsobem Verifikovatelnost - specifikace determinuje způsob testů Provázanost - souvislost mezi požadavky, vazba

13 Provázanost požadavků bez provázanosti –korektnost –feasibilita –prioritizace –jednoznačnost –verifikovatelnost provázanost požadavků umožňuje –kompletnost –konzistence –možnost změny –potřebnost

14 “Fail to Plan, Plan to Fail”  Minimálně 30% práce jsou předělávky  Více než polovina softwarových chyb má původ v požadavcích  Více než 80% předělávek souvisí s napravováním chyb v požadavcích  Projekty, které věnují požadavkům méně než 5% práce mívají zvýšené náklady o % Source: Ivy Hooks

15 Hlavní přínosy RDM Vytvoření jednoznačné specifikace Řízení očekávání Jednotný zdroj pravdy Správa změn a jejich dopadu Souhrnný pohled na fungování podniku Zlepšení komunikace v týmu Pevnější kontrola nad rozsahem projektu Snížení nákladů Zvýšení kvality Rychlejší realizace projektů

16 Příklad zákazníka – Met Office Jako jedno ze dvou center globálních předpovědí počasí je Met Office jedním z celosvětových poskytovatelů služeb souvisejících s počasím a s prostředím. Centrum George Hadleyho je sídlem mezinárodního výzkumu klimatických změn a jejich dopadu na současné i budoucí generace… Industry: Government Oblasti: Evropa/Blízký východ/Afrika Řešení: RDM, SCCM Produkty: CaliberRM™, StarTeam®, Together™, Consulting ServicesCaliberRM™StarTeam®Together™ Consulting Services Výzvy –Dodávat meteorologické řešení pro komerční i vládní organizace na celém světě –Řídit IT jako organizaci zaměřenou na dodávky zákazníkům –Vyvíjet, testovat a dodávat na základě jasně artikulovaných a dokonale pochopených požadavků zákazníka –Snížit cenu podpory a údržby a tím snížit celkovou cenu software Výsledky –50% snížení nedodržených časových harmonogramů projektů (deadlines) –Zlepšení komunikace mezi obchodem a IT –Zvýšena kvalita produktů i konzistence vývojového cyklu –Zvýšena efektivita řízení změn “Nasazení nástrojů firmy Borland (A Micro Focus Company) společně s dalšími změnami, které jsme v Met Office provedli, nám umožňuje dodávat konzistentně, včas, kvalitně a podle požadavků našich zákazníků.” Dave Underwood Technology Deputy Director Met Office

17 Dotazy

18 Backup slides

19 CaliberRM Enterprise Customers Multi-national Bank based in Brazil –More than 1,200 user accounts with up to 250 concurrent users –Database contains more than 700,000 reqs across 250 projects –Database size approaching 12GB Global Medical Device company based in Germany – More than 1,800 user accounts –Up to 200 concurrent users Large Telecomm company in US –More than 1,500 user accounts –Up to 150 concurrent users Large Health-Care Provider in US –Databases contains more than 4,000,000 objects –Database size exceeds 2.1 GB Global Systems Integrator based in US –More than 5,000 user accounts –Up to 150 concurrent users with more than 200 projects

20 Key RDM Processes Requirements Definition & Management IIT Management & Governance Technique | Stakeholders System Boundaries | Glossary IT Management & Governance Strategic & Operational Demand Business Demand IT Operations ELICITATION 1 Detail Requirements | Business Model Scenarios | UC Model | Prototype SPECIFICATION 3 Prioritization | Verify Risk | Estimation ANALYSIS 2 Review | Signoff | Baseline VALIDATION 4 Storage | Linking/Trace | Measure/Audit | Reporting/Doc | Security MANAGEMENT 5

21 Quality Requirement Characteristics Completenothing is missing; no “To Be Determined”s Consistentdoes not conflict with other requirements Correctaccurately states a customer or external need Feasiblecan be implemented within known constraints Modifiablecan be easily changed, with history, when necessary Necessarydocuments something customers really need Prioritizedranked as to importance of inclusion in product Traceablelinked to system requirements, and to designs, code, and tests Unambiguoushas only one possible meaning Verifiablecorrect implementation can be determined by testing, inspection, analysis, or demonstration

22 Ambiguity Review Checklist Dangling else Ambiguity of reference Scope of action Omissions –Causes without effects –Missing effects –Effects without causes –Complete omissions –Missing causes Ambiguous logical operators –Or, And, Nor, Nand –Implicit connectors –Compound operators Negation –Scope of negation –Unnecessary negation –Double negation Ambiguous statements –Verbs, adverbs, adjectives –Variables, unnecessary aliases Random organization –Mixed causes and effects –Random case sequence Built-in assumptions –Functional/environmental knowledge Ambiguous precedence relationships Implicit cases The use of “Etc.” Using “I.E.” versus “E.G.” Temporal ambiguity Boundary ambiguity

23 What is CMMI ? Capability Maturity Model Integration –Developed by the Carnegie Mellon Software Engineering Institute (SEI) –Identifies the maturity of the software development process for a given organization –One of the first quality measurement techniques specifically designed for software development CMMI focuses on process quality rather than the deliverable quality –Uses a reference model of mature practices in a specified discipline to assess an organization’s capability to perform that discipline

24 Staged Levels of the CMMI 5 - OPTIMIZING 4 - MANAGED 1 - INITIAL 2 - REPEATABLE 3 - DEFINED CONTINUOUSLY IMPROVING PROCESS PREDICTABLE PROCESS CONSISTENT PROCESS DISCIPLINED PROCESS

25 ROI for CMMI Investments Note: Data was averaged over 1233 separate projects in 261 organizations spanning 10 countries, to gauge the benefits of reaching higher maturity levels. Data was normalized to a 200K line-of-code software project. Source: Software Engineering Institute, SEI 92-TR-24


Stáhnout ppt "Definování a správa požadavků Automated Software Quality Miroslav Borský"

Podobné prezentace


Reklamy Google