Details
-
Spike
-
Must have
-
Obs Mgt & Controls
-
-
-
Inter Program
-
4
-
4
-
20
-
5
-
Team_CREAM
-
Sprint 4
-
-
-
-
16.6
-
Stories Completed, Outcomes Reviewed, Demonstrated, Satisfies Acceptance Criteria, Accepted by FO
-
Taranta Team_CREAM Team_NALEDI
-
DP-SDP: G1 SOL: G1
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
- informs
-
SP-3057 Refactor Taranta Devices to take advantage of React Redux selective rendering
- Done
- is cloned by
-
SP-2812 Contribute to Taranta 2.0 development (SP-2712)
- Done
- relates to
-
SP-2612 Explore modularisation of Taranta with Webpack5
- Done
-
SP-2812 Contribute to Taranta 2.0 development (SP-2712)
- Done
- mentioned in
-
Page Loading...