Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

V2 Roadmap

Created |

Status
colourYellow
titleWorking on

Outcome & Benefit

Action Items

Priority

Contributor (Who?)

AMJ '23

JAS '23

OND '23

JFM '24

1

Enable course assessment through ED (for any training use-case) to provide enhanced capabilities to existing and potential adopters.

Today it Course is one of the leading use-cases for ED adopters (DIKSHA & otherwise), but the assessments in a course are powered through ECML . Hence enabling this through QuML will help expose capabilities of inQuiry.

MCQ / MMCQ, FTB,

which has its shortcomings.

  1. Ability to create and consume FTB (P1) & MTF (P2)

  2. Question reusability: Create within a QueSet, use in another (Question Set, use elsewhere.

    1. Question lifecycle changes as per tech review,

    2. Out of scope: Visibility private (P3), Old ECML (P3

    )
    1. )

    . Review question lifecycle.
  3. Attach audio in a question

  4. Support 25k TPS scale

P1Pooja, Kartheek

2

Value Proposition

Become more specific about who will find it more valuable, what will be their reason to believe in the benefits offered and thus having clarity on the right to play. Identify value propositions for independent software vendors (or IT teams in organisations)

  • Market study

    • Will give the ability to target the the right market

    • Will be able Guide the product in the required direction

    • Understand potential inQuiry adoptions FTSO creating products/solutions.

  • P1

    Suren, Pooja

    .

    1. Engage with ecosystem actors in two phases through conversations rooted in this hypothesis & research plan.

    2. Round 1: NIIT/StackRoute, Tarento (Pulse), Manipal (Edu Next), Infosys.

    3. Round 2: Quizizz, DoubtNut.

    P1

    3

    Ease of use: Simplify and self-serve installation

    Gives the ability for anyone (including ED) to leverage inQuiry with minimal support and know monitor the health this giving confidence to the adoptors
    •Saves the team's time is debugging issues.
    •Helps in Faster Resolution"

    1. Simplify installation

    2. Installation process is completely open-sourced

    3. Simplify installation: Local & Server Installation installation Script & its with proper documentation

    4. Make it cost-effective for any one to use

    P1

    4

    Operational Monitoring: A self-serve tool to monitor the health of inQuiry micro-service.
    •Saves the team's time is debugging issues.
    •Helps in Faster Resolution

    Today the team spends time assisting adopters debug issues. Mostly the issues are in the complimentary systems around inQuiry.

    1. Enable health-monitoring for adopters

    2. Create a Tech FAQ and document steps to debug incase of commonly occuring occurring issues

    P1

    Gauraw, Kartheek

    45

    Experience and learn inQuiry. Help users imagine and visualise the possibilities using inQuiry.

    1. Prototypes in experience centre, Microsite upgrade, completeness, and simplification

    2. Reference solution packages for Test prep, Assessment, and Quizzing/Practice use-cases.

    P2

    5

    Testing Automation & Benchmarking

    6

    Scale performance benchmarking

    Today we do not know if inQuiry works at large scale (e.g. 25k TPS). It has neither been used or tested at such a high scale. We rely on it purely based on our design & development practices.

    We need to explicitly establish the scale benchmarks for inQuiry.

    1. Performance Testing & Benchmarking: Today we don’t know this. We want to achieve <5% error rate at expected scale or 25k TPS.

    2. Load testing scripts and reports will be published as open-source assets.

    7

    Testing Automation

    Promise that it works with minimal time/effort spent every release by implementing test automation for all components

    Ensures that microservice is Scale-ready; Get more confident about scale-readiness

    1. Functional Testing Automation: Today the coverage is xy% (i.e x/total APIs and x%). We want to achieve >90% coverage across all APIs.Performance Testing & Benchmarking: Today we don’t know this. We want to achieve <5% error rate. Expected scale: 25k TPS

    2. Current status of code coverage is

      1. Editor: 61%

      2. Player: 87%

      3. Micro-service: 84%

    We want to achieve >90% unit test code coverage as well.

    P1Gauraw, Kartheek

    86

    Easy to ensure QuML compliance (Validate & Generate).

    Ensures that inQuiry follow the QuML spec and hence allow resability, interoperability and longetivity of its assets

    We caught gaps in validation (by chance) and fixed them. Need to put a check so that it is always compliant.

    P1

    79

    Light-weight/low-code inQuiry package

    •Lower cloud infrastructure
    •Simpler tech stack
    •Easy to swap-out/swap-in dependencies (i.e. Knowlg).

    P2

    810

    Out-of-the-box capabilities for visibility of learning outcomes.

    •This will generate necesssary information for questions and question set's analytics and hence make maximun use of the generated data and inQuiry's capabilities
    •The users will be able to make informed decisions based the analytics data

    Out-of-the-box analytics for question usage, performance, and other question/question set related metrics.

    P3

    911

    Activate Community engagement

    More contribution and support form the community, hence refining the product better

    •Co-created roadmap
    •Regular community huddles
    •Design thinking session

    P2

    ...