Sprint planning¶

Date of the meeting: 08/09/2015
Sprint objective: Fifth release of MARTe aimed at defining the introspection base infrastructure. Refactoring of folders and namespacing to also be included.
Backlog items: #169, #188, #197, #226, #225

Sprint review¶

The following issues and concerns were discussed by the team during the sprint:

• How to improve code documentation. Find the balance between cost and sufficient quality.
  • Use StaticList as a template?
• How to simplify test documentation.
  • Use StaticListTest as a template?
• Rename namespace to marte (as opposed to MARTe)
• Discuss the using namespace directive.
• Discuss if a glossary of acronyms is needed.
• Discuss if namespace sections (i.e. between brackets) must or not span over section comments.
• Discuss use of latex syntax for formulas on documentation (if agree, then discuss which rendering engine must be used)

Sprint retrospective¶

• Things that the team should start doing

1. The QA reviewer shall verify if the documentation is sufficiently detailed to understand the scope of the class/function under scrutiny.
   1. StaticList can be used as a best-practice template, particularly for the end-user classes (e.g. GAMs).
   2. For the tests, the same simplified strategy used in StaticListTest shall be used.
2. The lint comments in the code shall include the MISRA violated rule(s) with the format /*lint -e{...,...,...} [...,...,...] comment*/, e..g. /*lint -e{123, 678} [3-1-1,5-2-1] some justification*/.
3. The use of defensive programming shall be maximised (both by verifying and asserting unexpected parameters and by propagating errors (e.g. returning false)). In particular NULL arguments shall be checked and asserted.
4. The namespace name MARTe shall continue to be used.
5. Create a glossary of terms (to be discussed if to put on the wiki or in the main doxygen file), see #232.
6. Create a doxygen main page and verify if the latex formulas are working correctly, see #233.

• Things that the team should stop doing

1. The using namespace directive shall not be used in the tests.
2. The namespace usage in the header files shall be broken between and after the inline method definition, i.e.:
   

   
   /*---------------------------------------------------------------------------*/
   /*                           Class declaration                               */
   /*---------------------------------------------------------------------------*/
   namespace MARTe{
   ...
   }
   /*---------------------------------------------------------------------------*/
   /*                        Inline method definitions                          */
   /*---------------------------------------------------------------------------*/
   namespace MARTe{
   ...
   }
   

• Things that the team should continue doing

1. Dividing large user-stories in sub-branches (as done for #225).

Technical debt¶

Non-completed user-stories: #169, #188

Backlog review (restimation, reprioritization, weighting)¶

The sprint was not successful given that the introspection was not fully defined. The code and folders restructuring (#226) had a large impact in the dynamics of the team development and have consumed more time than expected.