1 / 17

Definitions

Open Source Software Quality Assurance - Lessons Learnt Imed Hammouda, adjunct professor Alexander Lokhman, researcher Tampere University of Technology Credits to Prof. Ernesto Damiani, University of Milan, Italy. Definitions. Software Assurance

lara-simon
Télécharger la présentation

Definitions

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. Open Source Software Quality Assurance - Lessons LearntImed Hammouda, adjunct professorAlexander Lokhman, researcherTampere University of TechnologyCredits to Prof. Ernesto Damiani, University of Milan, Italy

  2. Definitions Software Assurance “the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at anytime during its lifecycle, and that the software functions in the intended manner” National Information Assurance Glossary Software Quality The degree to which a system, component, or process meets specified requirements. The degree to which a system, component or process meets customer or user needs or expectations. IEEE Standard Glossary

  3. Software Quality Attributes

  4. Traditional Assurance Tasks - Security Security requirements External Review Penetration Testing Security Operations Risk-based Security Tests Code Review (Tools) Risk analysis Abuse cases Risk analysis Requirements and Use Cases Architecture and Design Test Plans Code Tests and Test Results Feedback

  5. FLOSS Development Contributor Committer Bug reports Trusted Repository Source code Distributor User

  6. Multi-Tiered Assurance Process of FLOSS

  7. Quality by Access Availability of source code from an easily accessible medium No authorization is required Source code is made available in a format that is suitable and workable for the purpose of review and development, and appropriate for free distribution "Given enough eyeballs, all bugs are shallow" Linus’s Law

  8. Quality by Development Precise and explicit understanding of the software goals and requirements Choice of methodologies for testing, debugging, and error and bug reporting Tools to provide effective communication, coordination and the overall management of the project Facilitation of rapid frequency of beta releases Release early, release often

  9. The Role of Community – Maemo Karma Product Karma Features/components are rated by contributors (+1/-1) A certain karma level has to be reached for the component to be promoted MemberKarma Comments, commenting a news item or a Maemo app in testing: 2 * sqrt(# comments) Favourites, voting on news items: 0.25 * sqrt(# thumbs) Package testing, promoting or demoting packages in Extras Testing: 0.5 * # thumbs Blog post, 1-10 per post depending on votes it has received Products, applications in Maemo Downloads: 7 * (1 + stars per application) Discussion, posts to Maemo mailing lists: 2 * sqrt(# posts) Brainstorm: 5 for idea under vote or in development, 10 for implemented idea, 2 for solution under vote or in development, 10 for implemented solution Groups, 3 * # garage project memberships Bugzilla_reported: 6 * sqrt(# bugs reported) Bugzilla_comments: sqrt(# bug comments) Itt_thanks, thanks for TMO posts: 8 * sqrt(# thanks) Itt_posts, posts on TMO: sqrt(# posts) Mediawiki_edits: 6 * sqrt(# edits)

  10. The Role of Tools [www.bugzilla.org]

  11. The Role of Reviews • Projects go through six distinct phases • All Projects are required to have at least one review per year. [www.eclipse.org]

  12. The Role of Processes Contribution Untrusted Trusted Under Test Tested Repository User

  13. The Role of Version Control Systems Repository Central Repository commit maintain User A checkout checkout checkout User A pull pull User C patch patch User B User C User B pull pull User D commit Centralized Version Control Distributed Version Control

  14. The Role of Forges Infrastructure for collaboration and communication Maintaining project data and statistics Requirements for hosting projects Visibility of projects to other communities Access to a database of past experience

  15. The Role of Conventions and Guidelines Naming Conventions - How to name things like packages, classes, and methods Coding Conventions - How to make source code readable Documentation - How to write documentation comments, especially for API User Interface Guidelines - How to achieve user interface consistency Version Numbering - How to evolve plug-in version numbers

  16. Checklist Objectives Critical success factors Roles and responsibilities Plans Technical architecture and good practice Risks OSS challenges User-related Technology-related

  17. Thank You !Questions?

More Related