Versions Compared

Old Version 56

changes.mady.by.user Bobo Tory (Unlicensed)

Saved on

compared with

New Version 57

changes.mady.by.user Bobo Tory (Unlicensed)

Saved on

Key

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

About This Project

The goal of this project is to develop the Intelligent Transportation Systems (ITS) Joint Program Office (JPO) Operational Data Environment (ODE) Collaboratively using Agile Development Methodologies with the CV Pilot Teams.

The Operational Data Environment is a real-time data acquisition and distribution software system that processes and routes data from Connected-X devices –including connected vehicles (CV), personal mobile devices, and infrastructure components and sensors –to subscribing applications to support the operation, maintenance, and use of the transportation system, as well as related research and development efforts.


Leveraging The ODE

leveraging-the-ode-cv-pilot-systems-engineering-briefing.pdf
 


ODE Architecture Diagram

Helpful Documents

usdot-rsu-specification-4-1_final_r1.pdf

ode_user_consumer_producer_activity.xlsx

semi-ode-task-4-conops-final.pdf

wyo-phase-2-v2.zip

scms-poc-ee-requirements-20160407_1648.pdftask-4-system-design-description-v3-1-20160526.pdf

Definition of Done

  1. User acceptance criteria in the user story has been met    
  2. Testing has been  completed

  3. The code has been pushed out to GitHub

  4. This process has been documented in Jira & release notes

  5. Demonstrated to Product Owner


Process for Closing a Story

  1. Developers burn down their hours and change the status of their completed tasks to Done.  
  2. Developers mark whether the Acceptance Criteria has been met and Mark (X) that all the Definition of Done criteria has been met.

  3. The Product Owner verifies that the Acceptance Criteria has been met  and that the Definition of Done is satisfied after the Sprint Review (Demo).

  4. This Product Owner gives the OK to close the story.

  5. The Scrum Master close out the Sprint.


Bugs

A bug is a defect in a feature that has already been accepted. Bugs should not used to detail new features and functionality  . Bugs are directly related to features that have already been delivered and provide no new user value, which is why they do not have points. The other reason they do not have points is that bugs can be impossible to estimate and could take 30 seconds or 30 days to resolve.

Bugs should include this information:

  1. Title:  Short and descriptive 
  2. Description: Reference the story that produced the bug. Describe what should be happening and what is currently happening.

  3. Instructions: Outline the steps to reproduce it.

  4. Resources: Include screenshots and other assets to help show the bug.

  5. Make a comment in the story that produced the bug.




Tip
title Tip Of The Day
 
Life is 10% what happens to you and 90% how you react to it. Charles R. Swindoll
 







UNDER CONSTRUCTIONS