Download 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?