110 likes | 224 Vues
This paper discusses the concept of Usable Verification in software systems, emphasizing the importance of user-centered design in the verification process. Jointly authored by Kathi Fisler from WPI and Shriram Krishnamurthi, it explores GUI-based tools, template patterns, and system properties, aiming to improve scalability and accessibility across various domains. Key aspects include the review process, role assignments, and policy verification, ultimately advocating for smoother interactions and decision-making in the verification process through better user trust and permission management.
E N D
Putting the User in Usable Verification Kathi Fisler, WPI Joint work with ShriramKrishnamurthi
What is Usable Verification? Use English Template Patterns GUI-based Tools System ´Properties® true or counter-eg More Domains Better Scalability
Access-Control Policies During the review phase, a reviewer r may submit a review for paper p if r is assigned to review p During the meeting phase, a reviewer r can read the scores for paper p if r has submitted a review for p request decision Patient Developer SocNetwork User PC-Chair
Policy Verification During the review phase, a reviewer r may submit a review for paper p if r is assigned to review p During the meeting phase, a reviewer r can read the scores for paper p if r has submitted a review for p System ´Properties® true or counter-eg Assigned reviewers can submit reviews
Policy Verification During the review phase, a reviewer r may submit a review for paper p if r is assigned to review p During the meeting phase, a reviewer r can read the scores for paper p if r has submitted a review for p ´ (EnvModel´ System)´Properties® true or counter-eg Assigned reviewers can submit reviews
Transfer confidence During the review phase, a reviewer r may submit a review for paper p if r is assigned to review p During the meeting phase, a reviewer r can read the scores for paper p if r has submitted a review for p During the review phase, a reviewer r may submit a review for paper p if ris not conflicted withp During the meeting phase, a reviewer r can read the scores for paper p if r has submitted a review for p assigned(r,p), conflicted(r,p), ... difference: permit vs deny What effect did this edit have? Artifact ´Ground-truth artifact ® Difference
Configuration checking Refactoring testing ? = “What if” questions Mutation testing Upgrade checking Upgrade exploring
Others must find our settings reasonable Those I trust more should have more permissions During the review phase, a reviewer r may submit a review for paper p if r is assigned to review p During the meeting phase, a reviewer r can read the scores for paper p if r has submitted a review for p People triangulate decisions against personal, subjective measures The reviewing process needs to run smoothly
Those I trust more should have more permissions During the review phase, a reviewer r may submit a review for paper p if r is assigned to review p During the meeting phase, a reviewer r can read the scores for paper p if r has submitted a review for p MoreTrusted(chair, reviewer) MoreTrusted(reviewer, author) ... • MoreTrusted(R1,R2) ® • (act,res) : • Permit(R1,act,res) Ù • Deny(R2,act,res) Artifact ´Ground-truth artifact ´ User View ® Difference
System ´Properties® true or counter-eg (EnvModel´ System)´Properties® true or counter-eg Artifact ´Ground-truth artifact ® Difference Artifact ´Ground-truth artifact ´ User View ® Difference