Transcript Document
Miser-C MISRA-C Compliance Checker Ian Biller, Phillippe Dass, Bryan Eldridge, Jon Senchyna, Tracy Thomas Summary • • Client: US Food and Drug Administration MISRA-C Compliance Checker – Intended Use • • – Medical Device Industry Open Source Community System Output Scope • • • • Parse compilable C code Checkable vs. Uncheckable Rules Prioritization of rules Open Source Release Context • Design/Implementation Constraints – – – • Language restricted to Java Restricted to freely available components Final product is stand-alone system Operating Environment – – Java Virtual Machine (JVM) Support Java 1.4 or higher Features • • • • • Check C Source-Code Files for Violations XML Output of Violations and Consequences XML Error Report Configuration of Rules Subset Configuration of Acceptable File Extensions Technologies • ANTLR – – – • Lexer/parser generator Runtime library C Grammars Java Process Methodology • Bits and Pieces of Scrum – – – – – • Only have 20 weeks for Senior Project Time-boxed software development 30 day sprints need to be 14 day sprints 6 releases planned Backlog High transparency Process Methodology • Metrics being tracked used for size of sprint – If too much time per rule, cut scope of successive releases Schedule • • • Software release 1 scheduled for end of week 1 Subsequent software releases every two weeks. Implementing backlog will depend on results of metrics. Requirements Elicitation • Four Phases – – – – • Domain Analysis Brainstorming Interview Review Low Volatility Requirements • Documentation • • • • Software Requirements Specification Use-Case Specification Product Backlog Sprint Backlog Design Process • Documentation – Model Diagrams • • • Activity Diagram Class Diagram Modeling Languages – UML Current State of Design • Completed – • Activity Diagram In Progress – Class Diagram Task Estimation • • • • New domain/technology Complexity and size Track actual time spent Update estimates based on metrics Metrics • • • • • Individual Effort Team Effort Effort per Task Number of Rules Met Development Time per Rule Risks • • Risk Management High-impact Risks – – – Research takes too long Incorrect estimates No suitable C grammar available Versioning Tradeoffs • Use version 2 • GNU C Grammar written in Version 2 • Less work up front • Convert to version 3 • ANTLRWorks • Other ANTLR features • More testing required Current Project Status • Completed Tasks – – – – – – – Website Process Methodology Project Plan Software Requirements Specification ANTLR Research MISRA Rule Prioritization Prototype Current Project Status • Tasks In Progress – – Grammar Design Software Architecture Design Planned for Spring Quarter • • • • • Completion of Architecture Design Incremental Releases of Rules Testing Plan User Documentation Configuration Utilities Lessons Learned • • • • Importance of Methodology Transparency greatly increases productivity Allow for adequate review time Set concrete goals Demo • (Link to demo) Questions?