First Weekly Report

Date 31/10/2000

Here is our first report:

Stage 1: User Stories

After a first meeting with Manish, during which he briefed us about the big picture, we got down to generating user stories.

It turned out that there weren’t that many. Here they are as written by the customer.

USER STORY #1:

Track the items in the store department so that the store manager at a glance knows the exact quantity of each commodity and accordingly she/he can inform the requisitioning department as well as to the purchase department if any purchase is to be done.

USER STORY #2:

It is store department manager’s responsibility to maintain the various levels of stocks (e. g.: buffer, reorder etc.). If the stock falls below any defined level

The software should flash a warning message to her/him about the status of the stock. This will also depend on the time lag of the purchase activity.

USER STORY #3:

At the end of the day, the software should be able to update the inventory by keeping the track record of each item issued to all the departments. It should be able to calculate the cost department wise also.

SER STORY #4:

At each stock level the software should be able to calculate the repurchase level (Whether it should be the minimum repurchase/ maximum repurchase level) thus

constantly displaying repurchase quantity of each item.

Notes:

The central store is who we are building the software system for. It has a database where it stores its inventory. Each item has a corresponding buffer level, which is the max we can store of that item. It also has a reorder level. If we go below that level, we must issue an order to the purchase department.

This is what a repurchase level (story 4) was defined as by our customer.

Min repurchase level: Reorder level – current stock

Max repurchase level: Buffer level – current stock

Stage 2: Upon some analysis

Figure #1: Level 0 Data Flow Diagram for Users Story #1.

This is a rough sketch of our ER diagram for the database. Might need to be refined as we learn more.

ER- Diagram for ‘Hotel Inventory System’

· · Requisition may contain uncategorized items. For now we will ignore this factor.

· · They may require more items than store can supply In this case supply what we can for now

We introduced the order entity set as a way to store which items had already been ordered for from the purchase department. We would like to know such information, and also this would prevent us from ordering the same item twice, while it was on its way here (from the vendor).

Use cases that came up as part of the analysis

(I know that these aren’t mentioned in XP, but I think XP does say that you can use anything else that happens during analysis, so these just happened, and hence I am including them here)

Use case 1: Requisition arrives from a department

1. Input to Requisition handler is a requisition.

2. Sort it out, generate reorders etc.

3. Generate Report for requisitioning dept saying what is being issued to it and what is not.

Reorder: It happens either when quantity requested is not in stock or a supply causes it to go below the threshold.

use case 2: Arrival of an order from the vendor

1. Order slip comes to the central system

2. Update the database (i.e. increase the stock of the relevant items)

3. Satisfy any departments who are waiting for these items

Stage 3: Breaking up each story into tasks

We found that the last three stories were pretty straightforward, and solved them almost immediately.

They would involve querying our database with the following queries:

For story 3 -

SELECT *

FROM Requisition R, Has H

WHERE R.dept = ‘Some department’.

AND H.slipnumber = R.slipnumber

And for department wise cost –

SELECT H.code, SUM(quantity)

FROM Requisition R, Has H

WHERE R.dept = 'Some dept again'

AND R.slipnumber = H.slipnumber

GROUP BY H.code

Story 4 This was also directly available from the database.

Story 2

For the automatic warning part, we would probably need a trigger in our database or some such mechanism.

As for the maintaining of various levels, this would need to be taken care of only when a requisition was actually handled. This is the only time when the level falls.

Any necessary reorders for items will be sent to the purchase department, by the main requisition handler.

Story 1 This is the meaty one. The basic DFD we came up with, has been shown above.

In an informal CRC card session we came up with the classes. Actually the CRC cards weren’t in the strict format they were supposed to be. They had the class names and important methods and functions, just like in a UML class diagram. However, they were really useful for playing around with, and people demonstrating how they thought various objects would interact with each other. Which objects would know about which others and stuff like that. An extremely useful meeting that was.

Outcome of the CRC session

You’d also have the following classes.

1) 1) Requisition Handler – There would probably only exist one instance of these. It would be created by the main program. We could say something like:

handler.handleRequisition(aRequisition)

The output would be a Result object which stores information about which of the requests were satisfied and which ones weren’t. The classes would be like this –

The following sequence diagram illustrates what I have in mind –

Notes

We thought we might be able to start our first iteration earlier than the 29^th (the proposed date) but ended up starting only then.

In the meantime, the following was accomplished in our iteration 0

1) Creation of mailing list – [email protected]

2) Preliminary meeting with Manish

3) User stories generation

4) Estimation of user stories: (More on the estimation below)

5) Iteration planning meeting

The web page was postponed. It is being worked upon and should be up in a day at most from now.

Estimation

We identified the following two distinct components of the system –

1) The part that would handle a requisition

2) The part that would handle the fresh supplies coming in from the vendor

The first had the following tasks:

a) A web form for getting the requisitions from the department

b) The main module which would handle such a requisition

c) Some sort of interface between the web form and the module

The second was similar:

a) An interface to collect the order slip

b) A module to update the database and inform departments that are waiting

c) Interface to these departments.

We thought 2(b) and 2(c) would need to wait.

But, we also thought it was possible, from the numbers we put in front of these that we could finish all the tasks this iteration, provided we put in three hours consistently everyday.

Spike solutions

We debated on what language to use. The main point was that we weren’t sure how easy it was to connect to a database in java. A half day spike solution sorted this out. So Java it was.

The XP idea of a spike solution was really a big help, because it helped us to identify the exact part that we weren’t sure of. Without a process we would have started off writing code, and been in awe of jdbc for half the duration of the project.

We are now a couple of days into our iteration, and things haven’t been going exactly as planned. We are making good progress, but it hasn’t been as disciplined as I would have liked. What we need to do is re-estimate the tasks taking into account the following -

· All but three of us are new to Java.

· These three are also using Java for the first time.

· Time for learning the testing framework, needs to be allowed for

· I have found initial development to be very slow because of the “test before writing any code” rule.

· The pair programming rule wasn’t being followed as strictly as I would have liked. This was because of the following that I think was the problem.

Given that we have scheduled three hours per day, I don’t think it’s right to ask someone to pair program with you for any extra time that you put in. However, the logic behind pairing is that two people together will be more productive than if they work separately.

I have the following argument for extra time. If someone chooses to work extra, i.e. outside of the scheduled time, then he must find out if anyone else, is also keen to work then, in which case he should pair up with him.

However, if there is no one else, that shouldn’t stop him from working on his own, since one person working at all, is better than no one working at that time. This doesn’t violate the argument behind pairing.

Thus, the reality of pair programming is that a lot of work during the course of this project, as I can see it will be done by single programmers. This is because we are not working in an office environment yet, where everyone works the same number of hours, and is dedicating all his time to a single project. We need to decide whether there is a way to work around this. Perhaps it will be sorted out as a result of our restructuring the group tomorrow.

Outcome of meeting on day 3

The following is a more realistic team structure, as opposed to the structure proposed in our first submission –

Developers

Nitin

Sukhvinder Singh (Jimmy)

Vibhu

Parag

Alok

Coach

Vibhu

Customer

Manish

Tracker

Sukhvinder Singh ( Jimmy )

No Testers yet. We will think about acceptance tests, after the first week of development at which point we will decide exactly who the testers are and how they should proceed.

Progress

Tests and code have been developed to handle requisitions, according to current stock in the inventory. We have managed to figure out jdbc/odbc and so we are being able to maintain our inventory in a database.

Simultaneously, there has been excellent progress made on a java GUI that accepts requisitions. The remaining part is to get the first part (i.e. the requisition handling code) to support the exact interface that is needed, so that these two can be integrated.

Notes

I find that the XP idea of each team being allowed to work out its own design for its tasks, not very practical. The reason I think is as follows:

In a large system, the modules are quite distinct and probably more independent of each other, than ours are. This is because as it turns out the tasks we had for this iteration (which in fact covered all the stories), are really artificial divisions, which would probably be implemented by just one team.

Now we are attempting to distribute this work between teams. I feel that for this more design should be done, before we all rush off to do our own parts. At the very least, we need to define each part clearly enough so that the interfaces between parts are clear.

Timecards

We are maintaining timecards, but I don’t think it’s necessary to include them in this first report, since we are only three days into our iteration.

Code

I am submitting the code produced so far. Suggestions regarding whether or not the unit testing is being done in the right way would be appreciated. The GUI part has been excluded.

Basically the RequisitionHandlerTest, is what was written first – it assumed existence of everything else. To make it work, the entire system had to be built. Then we realized that the smaller classes should have been built first with their test cases, as they were the ones which were failing. Anyway, that was a first try at “test before writing any code”.

In closing : The web page is now almost ready, and we will let you know as soon as it is. The idea of the web page is to show our progress, so it will develop as we go along.

Hosted by www.Geocities.ws