New Software Practices in Embedded Systems Group

1
New Software Practices in Embedded Systems Group

• August 7, 2001
• Presented by
• Basant Kr. Dwivedi and Anup Gangwar

2
Introduction

• Research in Embedded Systems involves good amount
  of software development
• Software being seen as publication medium for
  academic research
• Incremental process

3
Issues

• Understanding the whole framework
• Productivity of the group
• Quality of developed software tools
• Reliability of core infrastructure
• How much live the group is

4
Common Problems

• Portability of the code
• Coding practices
• Code documentation
• Directory structure
• Testing and bug reporting

5
Software Practices in the Ptolemy Project

• Use of Unified Modeling Language (UML)
• Induction of design patterns
• Daily build and smoke test
• Code rating
• Formal reviews

6
Daily Build and Smoke Test

• The ideas involved
• Automatic nightly rebuild
• Locating the errors and making it known to all
  the group members
• Test runs along-with nightly rebuild to find code
  coverage
• Benefits
• Problems can be fixed at early stages
• Test runs show which package needs more attention

7
Code Rating

• Classifies the code based on its progression
  towards an ideal quality standard
• Indicates level of confidence
• Acts as a framework for peer review
• Enables better control through improved visibility

8
Formal Reviews

• Periodic reviews by peers to identify defects
• It discourages things like defensiveness and on
  the spot redesign
• The focus is to give feedback to authors rather
  than evaluating the work
• Benefits
• Improved quality
• Increased awareness and communication
• Building a culture

9
New Software Practices

• Transparent environment
• Daily builds
• Locating errors in daily builds and mailing it to
  the whole group
• Peer reviews
• Code rating

10
Transparent Environment

• Creation of tools repository and use of
  Concurrent Versions System (CVS)
• CVS enables
• Transparency
• Better Communication
• Effective use of others work

11
Daily Builds

• We intend to rebuild whole framework in the form
  of a distribution
• The idea is to
• Locate errors
• Send message to the whole group to increase a
  sense of responsibility and early fixing of
  problems

12
Peer Reviews

• We propose monthly peer reviews
• The motivation is to
• Improve understanding of the entire framework
• Find unidentified cases
• Locate potential bugs
• Assign confidence level

13
Extensions

• Coding style and standard
• Documentation standard
• Test runs and code coverage
• Code rating

14
References

• John Reekie et. al., Software practice in the
  Ptolemy Project, Technical Report
  GSRC-TR-1999-01, Gigascale Silicon Research
  Center.
• http//www.gigascale.org