Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TOPAAS Versie 2.0, een praktische inleiding

1,054 views

Published on

Deze presentatie beschrijft de basis van TOPAAS 2.0, inclusief de aanpak om software bouwstenen te identificeren.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

TOPAAS Versie 2.0, een praktische inleiding

  1. 1. TOPAAS, een model in de praktijk Een pragmatische aanvliegroute voor de inschatting van betrouwbaarheid van ICT oplossingen
  2. 2. Compiler libraries...
  3. 3. OS afhankelijkheden…
  4. 4. Testen is extreem beperkt… • Een simpele 64 bits functie doortesten kost al 200 jaar • Efficiëntere aanpakken zijn in ontwikkeling • Maar in praktijk is software niet deterministisch!
  5. 5. Resultaten uit het verleden… • De faalkans van software is zeer afhankelijk van het soort gebruik • Een trackrecord is maar een zeer beperkte indicatie voor de faalkans
  6. 6. Probleem met de Maeslantkering • “Bewijs” uit het ongerijmde, vol met inhoudelijke fouten • Toonde wel aan dat de cijfers van TDT niet voor publieke verdediging geschikt waren
  7. 7. TOPAAS • Task Oriented Probability of Abnormalities Analysis for Software • Ontwikkeld in 2005 tot 2010 • Ontwikkelteam: DNV, Movares, LogicaCMG, Refis, Intermedion, TU/e • Reviewteam: Delta Pi, NRG, UvA, Rijkswaterstaat
  8. 8. TOPAAS • Centraal staat taakuitvoering • Gebruikt de Bayesiaanse kansopvatting als basis • Gebruikt vragenlijst om deze herhaalbaar te maken
  9. 9. Physical View Development ViewProcess View Logical View 4+1 Modelling Scenarios
  10. 10. Taakuitvoering
  11. 11. Decompositie van taakuitvoering • Moet onderscheidbaar zijn en zichtbaar gedrag vertonen • Zo abstract mogelijk • Alleen splitsen als belangrijke parameters anders worden: – Ontwikkelteam – Gebruiksintensiteit
  12. 12. Software Bouwstenen
  13. 13. Waar op te letten... • Gaat om direct bij de missie betrokken code • “Onterecht sluiten” kent een andere faalkans dan “Niet sluiten” • Afhandelen van falende hardware is andere taakuitvoering (en minimaal 2e orde object)
  14. 14. Dingen die geen bouwstenen zijn • Operating systeem • Firmware • Objecten die geen output kennen
  15. 15. TOPAAS en tunnels • Het ontwerp en de functiedefinities zijn in hoge mate gestandaardiseerd door LTS: – Afsluiting – Hoogtedetectie – Ventilatie – Nooddeuren – Incidentdetectie • Alleen RAMS-eisen liggen nog niet vast
  16. 16. Scoring van TOPAAS • “ONBEKEND” scoren – gewoon doen als het onbekend is – scoren als strategische keuze is echt fout • Er wordt soms veel bijgesleept – Een competentie management organisatie eisen – Er moet kwaliteitsmanagement zijn – De architectuur moet specifieke views hebben – Traceerbaarheid moet met logisch bewijs zijn • Soms zijn draaiuren gewoon makkelijker
  17. 17. Resultaten • Voor een normale ontwikkelaar 10-4 is realistisch: – Systems Engineering aanpak – JSTD-016 goed ingezet – Testen grondig doen • Voor een goede ontwikkelaar is 10-5 realistisch: – IEC 61508, SIL-4 – Goed testen van primaire taakuitvoering
  18. 18. Wat praktische cijfers • Met redelijke cijfers via TOPAAS: “niet sluiten slagboom” levert 10-3 on demand • Op basis van ervaringsgegevens: “onterecht sluiten” ongeveer eens in de 12 jaar
  19. 19. Wat gaat er binnenkort gebeuren? • Publicatie eerste wetenschappelijke TOPAAS artikel in QREI • Onderhoud op TOPAAS (versie 2.0) met onderwerpen: – Sterkere focus op goed modelleren taakuitvoering – Meetvoorschrift voor veel parameters

×