Ats Engineering Tasks

Part of AtsGoesExtreme and the AtsDiary. See also EngineeringTask.

---

ATS's EngineeringTasks are pretty standard. We're tracking the tasks on standard 3x5 index cards, as with everything on this project. On the ruled side of the card, they say "TASK" in the top center and have a brief description of the task in the center. We add new information to the card as it comes up, but tend to keep to-do lists for the cards separately, mostly because there's not enough room on the card for all the stuff that comes up. In the bottom-left corner is the name of the developer who signed up for the task.

The back side of the card contains the risk in the upper left, the estimated IdealEngineeringTime? for the task in the lower left, and the actual IdealEngineeringTime? to date in the lower right. When the task is done, we put a check mark by the word "TASK" and tack the card to the wall. At the end of the iteration, we'll probably have a ceremonial card burning party, but we're keeping them around for now for tracking purposes.

The first time we created the tasks for a story, we didn't use any CRC cards. That turned out to be a mistake. When our third developer arrived and we needed to describe the tasks, we discovered that we didn't have a clear understanding of the problem. So we did some AtsCrc? and it was a huge help. In the future, I'll always start with CRC before coming up with tasks, or at least have some CRC cards laid out (presumably wherever they've been laid out) so we can refer to them.

Here's the tasks we're working on right now, modified slightly to protect my client. I've only included the tasks for our current story because I want to create new tasks for the remaining stories, using CRC cards to flesh out the design this time.

---

Story: Restrict access to the application. Only allow people who know a user's username and password to access ATS. Authenticate using [sec].

Tasks: (roughly in order)

• Spike [sec]. Test: make sure password isn't cached.
• Automate deployment.
• Create session table and methods. *Create Session class.
  • Create new session
  • Validate existing session
  • Invalidate/turn off existing session
• Modify warehouses to validate session. (Includes modifing objects to pass session.) * Create SecurityException? class.
• Add context column to user table. (Migrate data too.)
• Track current user's session on client. Also perform login and logout. (SessionManager?)
• Login/logout window.
  • Make File/Exit logout
  • Dialog for login failure and bad session
• Automated session cleanup (needs spike).
• Functional tests for application access. Also do basic deployment test