1 / 43

Using Reverse Semantic Traceability for Quality Control in Agile MSF-based Projects

Using Reverse Semantic Traceability for Quality Control in Agile MSF-based Projects. Konstantin Zhereb, Vladimir Pavlov, Anatoliy Doroshenko, Victor Sergienko (INTSPEI). Outline. Background: INTSPEI P-Modeling Framework Motivation: P-Modeling in agile processes Integration with MSF Agile

janfowler
Download Presentation

Using Reverse Semantic Traceability for Quality Control in Agile MSF-based Projects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using Reverse Semantic Traceability for Quality Control in Agile MSF-based Projects Konstantin Zhereb, Vladimir Pavlov, Anatoliy Doroshenko, Victor Sergienko (INTSPEI) SEC(R) 2008, Moscow, Oct 23, 2008

  2. Outline • Background: INTSPEI P-Modeling Framework • Motivation: P-Modeling in agile processes • Integration with MSF Agile • Case study • Results • Conclusions and future research SEC(R) 2008, Moscow, Oct 23, 2008

  3. The Babel experimentSpeechless modeling • Conducted by V. L. Pavlov starting from 2001 • Modeling session: create high-level design in UML • Usage of human languages (English, German, Russian, etc.) is forbidden • All communication using • UML • Pantomime • Forces team to created understandable model • Encourages cooperation SEC(R) 2008, Moscow, Oct 23, 2008

  4. Translation experiment • A text in English • “We are uncovering better ways of developing software by doing it and helping others do it” • One translator translates it into Russian • “Мы выявлено более эффективных способов разработки программного обеспечения, делая его и помочь другим сделать это” • The other translator translates the Russian text back to English • “We found more effective ways to design software, making it and help others to do so” • Two English texts are compared • This procedure can be used to evaluate the quality of translation SEC(R) 2008, Moscow, Oct 23, 2008

  5. Software Engineering analogy • An artifact is a “text” • Artifact creation is “translation” • From requirements to design • From design to code • From bug description to bug fix • … • We can “translate it back” and compare SEC(R) 2008, Moscow, Oct 23, 2008

  6. Reverse Semantic Traceability • Treat artifact creation as translation • Verify translation by restoring original artifact from translated artifact • Compare original and restored version of the artifact • Focus on meaning, not on exact words • Quality control method that can be applied on any stage of lifecycle SEC(R) 2008, Moscow, Oct 23, 2008

  7. Cost to Correct Maintenance Requirements Construction Architecture DetailedDesign Detailed Design Architecture Construction Requirements Phase That a Defect is Created Phase That a Defect is Corrected Early detection of defects • The most important decisions and the most expensive mistakes are done at the beginning of the project • The initial amount of quality control is minimal and then grows as development moves forward • The defects are discovered at the late stages of project, resulting in a large amount of rework • Quality control on early stages is crucial Cost to correct a defect greatly depends on how early it was introduced and revealed SEC(R) 2008, Moscow, Oct 23, 2008

  8. INTSPEI P-Modeling Framework • P-Modeling Session is a combination of Speechless Modeling and Reverse Semantic Traceability into one event • P-Modeling Framework describes application of RST and SM in software development lifecycle • P-Modeling Framework doesn’t replace existing processes – it complements them SEC(R) 2008, Moscow, Oct 23, 2008

  9. P-Modeling in agile projects • First applied in large projects • Initial feedback suggested usage in agile projects • Some changes were needed • Integration with MSF Agile SEC(R) 2008, Moscow, Oct 23, 2008

  10. Microsoft Solutions Framework • Software development process based on Microsoft expertise • Two versions: • MSF for Agile Software Development • MSF for CMMI Process Improvement • Current version is 4.2 • Distributed separately and as a part of Microsoft Team Foundation Server • Process Guidance Generator SEC(R) 2008, Moscow, Oct 23, 2008

  11. P-Modeling integrated with MSF Agile • Added tasks for P-Modeling activities (Speechless Modeling, Reverse Semantic Traceability, Planning RST) • Added work products (RST Session Report, RST Expert Assessment, RST Rank Table) • Modified work items • Added discipline (Traceability Management) SEC(R) 2008, Moscow, Oct 23, 2008

  12. P-Modeling tasks • Plan RST Activities • Perform RST for Scenario; • Perform RST for Solution Architecture; • Perform RST for Development Task Implementation; Perform RST for Database Task Implementation; • Perform RST for Bug Fix; • Perform RST for Scenario Test Cases; Perform RST for Quality of Service Requirement Test Cases. • Conduct P-Modeling Session SEC(R) 2008, Moscow, Oct 23, 2008

  13. Integrated process guidanceMenus SEC(R) 2008, Moscow, Oct 23, 2008

  14. Integrated process guidance P-Modeling menu SEC(R) 2008, Moscow, Oct 23, 2008

  15. Integrated process guidance P-Modeling activities SEC(R) 2008, Moscow, Oct 23, 2008

  16. Integrated process guidance New discipline SEC(R) 2008, Moscow, Oct 23, 2008

  17. Case study • Small project – Life game • Team – 3 students • Project duration – 2 month • 4 iterations, 2 weeks each • Process – P-Modeling integrated with MSF Agile SEC(R) 2008, Moscow, Oct 23, 2008

  18. Using Reverse Semantic Traceability • RST for Design • Original artifact – requirements (captured as Scenarios and QoS requirements in TFS) • Translated artifact – high-level design (class diagrams in Visual Studio) • Restored artifacts – list of restored requirement SEC(R) 2008, Moscow, Oct 23, 2008

  19. RST session • Participants • Artifact owner (architect) • 2 reverse engineers • 4 experts • Duration • Reverse engineering: 1 hour • Expert assessment: 1 hour SEC(R) 2008, Moscow, Oct 23, 2008

  20. Original scenarios • Edit configuration • Run turn(s) • Save/load configuration • Rewind history • Change display zoom • Export configuration(s) as (animated) image SEC(R) 2008, Moscow, Oct 23, 2008

  21. Restored scenarios • Edit configuration • Run turn(s) • Save/load configuration • Rewind history • Change display zoom • Export configuration(s) as (animated) image • Change language • Clear history SEC(R) 2008, Moscow, Oct 23, 2008

  22. RST session results • Original scenarios: 6 • Restored: 2 original scenarios, 2 missing scenarios (4 scenarios not restored) • Scenario Edit configuration required significant rework of design • Comments on design consistency (“change language” missing in UI) • Comments on glossary (configuration → colony) SEC(R) 2008, Moscow, Oct 23, 2008

  23. Learnings from case study • Two options for RST in agile process • First iteration – main quality control technique • Next iterations – complements testing • RST helps reviewers focus on details • RST prevented significant rework • RST helps make artifacts actually useful for agile project SEC(R) 2008, Moscow, Oct 23, 2008

  24. Conclusions • P-Modeling Framework integrated with MSF Agile http://www.intspei.com/Products/PMFramework.aspx • Case study demonstrating usage of RST on early stages of agile project • Future work: • Collecting data from industry projects • Applying RST in later stages SEC(R) 2008, Moscow, Oct 23, 2008

  25. Thank you for your attentionQuestions? kzhereb@intspei.com www.intspei.com SEC(R) 2008, Moscow, Oct 23, 2008

  26. SEC(R) 2008, Moscow, Oct 23, 2008

  27. Back-up slides SEC(R) 2008, Moscow, Oct 23, 2008

  28. Main Idea of P-Modeling • Increase productivity of development teams • Encourage collaboration within team • Two techniques: • Reverse Semantic Traceability: identify defects earlier and prevent cascaded bugs • Speechless Modeling: create high-quality architecture efficiently • P-Modeling Session combines both techniques in a single event SEC(R) 2008, Moscow, Oct 23, 2008

  29. Quality Control SEC(R) 2008, Moscow, Oct 23, 2008

  30. Quality control on each stage SEC(R) 2008, Moscow, Oct 23, 2008

  31. RST Roles • Artifact Owner: creates Translated Artifact; prepares an RST session; reworks artifact based on RST results • Reverse Engineer: restores artifact during RST session • Expert: compares original and restored version of artifact • Project Manager: plans RST activities; makes decision based on RST SEC(R) 2008, Moscow, Oct 23, 2008

  32. RST process SEC(R) 2008, Moscow, Oct 23, 2008

  33. RST workflow SEC(R) 2008, Moscow, Oct 23, 2008

  34. P-Modeling Session Schedule (1) SEC(R) 2008, Moscow, Oct 23, 2008

  35. P-Modeling Session Schedule (2) SEC(R) 2008, Moscow, Oct 23, 2008

  36. P-Modeling principles • Validate as Soon as Possible • Treat Each Artifact as a Translation from Another Artifact • Quality of the Final Product Derives from Quality of Intermediate Work Products • Maintain Traceability • Prioritize then Perform RST SEC(R) 2008, Moscow, Oct 23, 2008

  37. Planning RST activities • Identify significant types of artifacts • Assign two values: • Importance • Level of quality control • RST rank=importance* level of quality control • Prioritize by RST Rank SEC(R) 2008, Moscow, Oct 23, 2008

  38. RST Rank Table SEC(R) 2008, Moscow, Oct 23, 2008

  39. Original designCore classes SEC(R) 2008, Moscow, Oct 23, 2008

  40. Original designGUI classes SEC(R) 2008, Moscow, Oct 23, 2008

  41. Original designGUI classes SEC(R) 2008, Moscow, Oct 23, 2008

  42. Reworked designEditing colonies SEC(R) 2008, Moscow, Oct 23, 2008

More Related