We have a concrete plan now. Basically there was too much debating going on about what real life was about. Finally decided that we were appoaching the "vague requirements" scenario. XP just has one customer, or many customers but they must all agree. Rajesh had been studying various inventory systems and had a clear idea of what he wanted. So he is now the customer. Any disputes about what should be done are cleared by him. If there is a feature we imagine should be there and he doesn’t want it modelled, we don’t think about it further – he’s the one we must satisfy.
After an update about the general idea, of what he expected from the software we got down to writing the stories. We discussed exactly what was desired from the software and also which parts of the system he didn’t want automated, and would carry on happening manually.
We decided what the stories were, then which tasks were involved in each story. The way we worked on the tasks was to take each story in turn and decide what kinds of modules would be needed to satisfy it. If some some tasks turned out to be closely related to tasks in earlier stories we simply modified the previous tasks and made them a little more general to satisfy both cases.
Here are the Stories.
XP says that you develop the system as you go along. Prof Johnson mentioned in class that database guys prefer processes like the waterfall model, because once a database is designed and has a lot of data it becomes very difficult to change it. We had tried to build even the database incrementally in the first iteration but found that every time we shifted a column from one table to another a lot of code had to be changed. So we felt that for starters we would finalize what the database would look like – by modelling it to satisfy all the stories we had so far. Of course future stories or changes in customer requirements could lead to further modifications in our database design, but we’ll see then. It isn’t too much work to design the db up front. Anyway, so the ER, schema and tables were built up. Now pairs working on different tasks at least have a common database to look at rather than each pair designing a separate part of a database. We felt that would not really be useful. Anyway, so the first thing was to do the database. We did the ER (db2.ps) right away, and then implemented it in MSAccess. Here is the Schema
Teams and their tasks for this iteration
Sukhvinder and Manish would like to work on the portion which updates the DB upon receipt of a requisition slip (Story 3)
Nitin and Vibhu had tasks which would add up to 28 hours, so they have chosen just three stories for this iteration, according to the customers priorities. These add up to thirteen (ideal) hours. Estimated to be a week’s worth of work.
Rajesh would like to work on the module which performs necessary calculations which project the quantity to be reordered (story 5). Either Nitin or Vibhu will work with him.
We now have one week iterations until the end of the semester. This one started today (23rd November)