Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-2712

Architectural spike on Taranta 2.0

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • Obs Mgt & Controls
    • Hide

      Benefits include:

      • We understand what requirements are relevant and how some of the most critical ones could be supported by a certain architecture.
      • the design lets us estimate the effort needed to redesign the entire Taranta
      • the specification lets us identify slices to be added as feature in future PIs
      • after implementing everything in the specification we end up with Taranta 2.0 that:
        • does what is deemed necessary, and
        • is webpack 5 compatible, and
        • there is no library that is out of date.
      Show
      Benefits include: We understand what requirements are relevant and how some of the most critical ones could be supported by a certain architecture. the design lets us estimate the effort needed to redesign the entire Taranta the specification lets us identify slices to be added as feature in future PIs after implementing everything in the specification we end up with Taranta 2.0 that: does what is deemed necessary, and is webpack 5 compatible, and there is no library that is out of date .
    • Hide
      • a google document is produced with a list of relevant requirements, with associated quality attributes and quality scenarios (a paragraph per requirement should be enough):
        • a bullet list of requirements that apply to current Taranta and that we want for Taranta 2.0
        • a bullet list of new requirements and their expected benefits for Taranta 2.0 (eg web responsive dashboards, eg performance reqs, eg. extendability reqs, eg, deployability reqs).
      • code for the prototypes is produced
      • a section of the document is included that discusses the findings and to what extent each of the considered quality scenarios support the requirements.

      Quality scenarios that have to be considered are (other scenarios are welcome):

      • Performance: here we should consider the performance requirements that were analyzed 2 yeasr ago (https://docs.google.com/document/d/1_mfRBUlzVwrsfUN4tVUzOUZaUetAIPGxbcUBUxBBdgk/edit#heading=h.dx716liqcsn2)
      • Extendability: 
        • where a module contains a new type of widget
        • where a module contains a configured widget
        • where a module contains a dashboard
        • where a module contains a new data source (alternative to TangoGQL)
        • where a module contains a new view (ag the synoptic view, alternative to Dashboards and Devices)
      • Deployability
        • where a user wants to configure a certain instalce of Taranta with a subset of existing modules

       

      Two Google documents shall be produced: a list of requirements for Taranta 2.0 and a specification of Taranta 2.0.

      The requirements document should include:

      • a bullet list of requirements that apply to current Taranta and that we want for Taranta 2.0
      • a bullet list of new requirements and their expected benefits for Taranta 2.0 (eg web responsive dashboards).

      The specification document should contain:

      • a description of components (ie. deployable artefacts) that make up the physical architecture of Taranta
      • each component should be associated to a definition of its responsibility and an interaction protocol and API
      • each component should be described in terms of underlying modules and/or classes (ie. parts of the source code), each associated to its responsibility and interaction protocol with other modules
      • in particular, the front end in React should be specified in terms of React components, state management (actions and reducers), and possibly other interaction mechanisms (eg events)
      • appropriate object-oriented patterns are employed
      • appropriate UML diagrams should be added for clarification
      • TangoGQL should be retained.

      These two documents should be sufficiently rich to let a developer understand if the specification provided suffices to support the requested requirements. Detail should be enough also to accurately estimate the total implementation effort needed (in terms of min and max story points needed for each part).

      In order to support the first need ("suffices") a number of quality scenarios should be defined and hand simulated to make sure that the design fulfills that quality attribute (see my comment below https://jira.skatelescope.org/browse/SP-2712?focusedCommentId=160817&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-160817). The list of quality attributes and their scenarios will be defined while working on this feature, after the list of requirements has been understood.

      The specification should be such that appropriate unit, intergration and component tests can be easily written.

      Original estimation was 8 FP.

      Show
      a google document is produced with a list of relevant requirements, with associated quality attributes and quality scenarios (a paragraph per requirement should be enough): a bullet list of requirements that apply to current Taranta and that we want for Taranta 2.0 a bullet list of new requirements and their expected benefits for Taranta 2.0 (eg web responsive dashboards, eg performance reqs, eg. extendability reqs, eg, deployability reqs). code for the prototypes is produced a section of the document is included that discusses the findings and to what extent each of the considered quality scenarios support the requirements. Quality scenarios that have to be considered are (other scenarios are welcome): Performance : here we should consider the performance requirements that were analyzed 2 yeasr ago ( https://docs.google.com/document/d/1_mfRBUlzVwrsfUN4tVUzOUZaUetAIPGxbcUBUxBBdgk/edit#heading=h.dx716liqcsn2 ) Extendability:   where a module contains a new type of widget where a module contains a configured widget where a module contains a dashboard where a module contains a new data source (alternative to TangoGQL) where a module contains a new view (ag the synoptic view, alternative to Dashboards and Devices) Deployability :  where a user wants to configure a certain instalce of Taranta with a subset of existing modules   Two Google documents shall be produced: a list of requirements for Taranta 2.0 and a specification of Taranta 2.0. The  requirements document should include: a bullet list of requirements that apply to current Taranta and that we want for Taranta 2.0 a bullet list of new requirements and their expected benefits for Taranta 2.0 (eg web responsive dashboards). The  specification  document should contain: a description of components (ie. deployable artefacts) that make up the physical architecture of Taranta each component should be associated to a definition of its responsibility and an interaction protocol and API each component should be described in terms of underlying modules and/or classes (ie. parts of the source code), each associated to its responsibility and interaction protocol with other modules in particular, the front end in React should be specified in terms of React components, state management (actions and reducers), and possibly other interaction mechanisms (eg events) appropriate object-oriented patterns are employed appropriate UML diagrams should be added for clarification TangoGQL should be retained. These two documents should be sufficiently rich to let a developer understand if the specification provided suffices to support the requested requirements. Detail should be enough also to accurately estimate the total implementation effort needed (in terms of min and max story points needed for each part). In order to support the first need ("suffices") a number of quality scenarios should be defined and hand simulated to make sure that the design fulfills that quality attribute (see my comment below https://jira.skatelescope.org/browse/SP-2712?focusedCommentId=160817&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-160817 ). The list of quality attributes and their scenarios will be defined while working on this feature, after the list of requirements has been understood. The specification should be such that appropriate unit, intergration and component tests can be easily written. Original estimation was 8 FP.
    • Inter Program
    • 4
    • 4
    • 20
    • 5
    • Team_CREAM
    • Sprint 4
    • Hide

      Taranta 2.0 code can be found at:

      https://gitlab.com/tarantapoc/

      Taranta 2.0 documenation containing requirement, archetecture design and performance comparison:

      https://docs.google.com/document/d/1lY3FNwkSQ8kLT54XxaOLUFodAAPvn-xAclcniHBoK3I/edit 

      Show
      Taranta 2.0 code can be found at: https://gitlab.com/tarantapoc/ Taranta 2.0 documenation containing requirement, archetecture design and performance comparison: https://docs.google.com/document/d/1lY3FNwkSQ8kLT54XxaOLUFodAAPvn-xAclcniHBoK3I/edit  
    • 16.6
    • Stories Completed, Outcomes Reviewed, Demonstrated, Satisfies Acceptance Criteria, Accepted by FO

    Description

      Follows work in PI15 on SP-2612

       

      After a discussion with CREAM and NALEDI we came to the conclusion to change the nature of this ticket.
      This is due to 1) reduced capacity by CREAM (about 2FP) and corresponding reduction of NALEDI ' capacity(2 FP); 2) developers being uncomfortable in writing a valid specification (ie. they are likely to have low confidence on architectural claims based solely on the design).
      Conclusion is to rewrite this enabler as follows.

      Description

      We need to identify relevant requirements for Taranta 2.0 (identification and selection of those supported by the current Taranta 1.0, and new ones, like extendability via federated modules, performance in terms of latency and refresh rate, deployability using federated modules, and possibly new ones).

      We need  to define quality attributes and quality scenarios for those requirements that are architecturally relevant. We need to rank the list of scenarios based on risk factors.

      We need to develop prototypes of the suggested architecture that demonstrate to what extent the hisghest risks are mitigated. At least risks related to performance, extendability and deployability need to be covered.

       I adopted some of the suggestions made in "Software Architecture in Practice" by Bass, Clemens, Kazman https://www.oreilly.com/library/view/software-architecture-in/9780132942799/ - book that we used extensively just prior to the closing of the TM CDR. When I speak about quality attributes and quality scenarios I refer to what is discussed in that book.


      Note the component / PBS item is set to COM TMC software but this product spans multiple subsystems; COM TMC software is just currently considered to be the closest match.

      Redesign of Taranta wrt webpack5 to enable further development and support of Taranta following a modular approach and bringing it in line with modern standards.

      The original idea of doing a partial refactor has been dropped, deemed to be too risky (not sufficient tests exist to protect the refactoring and we assume that there is a substantial effort in untangling dependencies between libraries that is difficult to estimate a-priori).

      We (ie CREAM, NALEDI and me) decided to go for a design activity aimed at (re)defining requirements and architecture of Taranta towards a Webpack5 compatible Taranta package/release built from scratch.

      The expectation/assumption is that this will be developed as a close collaboration between developers from the CREAM & NALEDI teams, possibly by embedding developers in the CREAM team for the duration of this ticket.

      Estimate of 8FP based on 3-4 developers working together for 2-3 sprints.

      Note that this could be reduced to 4FP if work is also tracked against SP-2812 (the DP ART clone of this ticket).

       

       

      Attachments

        Issue Links

          Structure

            Activity

              People

                g.brajnik Brajnik, Giorgio
                D.Fenech Fenech, Danielle
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 4.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete723.0
                  Total723.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel