Second Weekly Report

 

Weekly Report 2

 

We didn’t get as much done this week as we’d expected. Here is a brief summary. We are working towards completing the required tasks by the end of this iteration.

We now have four developers, instead of seven as we had thought before the commencement of the iteration. That’s two pairs. So half way through the iteration, we did a re-estimate of the tasks. All the tasks which were assigned to people who weren’t developers anymore, were pushed to the next iteration. The remaining were on track. In addition, one of the two teams has taken on the writing of the acceptance tests. We won’t be able to write comprehensive tests right away, but they can develop as the project progresses. As long as they test more than what the developers have implemented it’s OK.

Our plan is that by the end of this iteration, we will be able to provide some sort of demonstration of the features implemented so far.

We took the following decision for this iteration. The scope of the project wasn’t big enough. So Rajesh, set about studying inventory systems, and he has a good idea of what more we can implement. We decided that it was important to continue working on the same tasks for this iteration, in accordance with what the customer wanted, and have something concrete at the end.

So only at the end of this iteration, will we study the new ideas and see what more we should model and how we could go about doing it. Then we think up some more stories, and set about building the system.

 

We found that we didn’t have a well-defined integration process. There were two tasks proceeding in parallel, and everything worked fine because they were totally unrelated. The moment, we needed to test them together, and then the system became one piece, we found it very difficult to edit code and integrate it. After a couple of days like this, we realized that we all knew about integrating frequently, but we hadn’t sat down and worked out the specific process to be followed for integration.

Anyway, we now have a working system for integrating our code.

I’ll end the report with a description of the integration procedure - as written for the members of our group, and then the trackers report.

Integration Procedure

I go over with code I wish to integrate.

  1. Back up Lab 30\\project to P1.
  2. Run all tests in project to see that they are indeed at 100%.
  3. If I’m only adding classes and tests -----

    Straightforward

    Add, run all tests

    If any failed, go back and rework.

    Else fine,

    Clean up P1 and go.

  4. If I had changed some classes two possibilities:
    1. No one else has changed those classes and tests, since I started working on them. Then

      Simply overwrite, run all tests-- old and new -- and go away.

    2. Some classes have changed and tests have changed. Merge such classes, run all tests, if any fail go back and look for remedies.
  • Integrating codes (2 to 3 times a day):

    Integrated code

  • - Source files,
    •

    • - Class files,

    - Tests.

    New code

  • - New source files,
    •

    • - New class files,

    - Edited files,

    - New tests,

    - Modified tests (because I know OLD ones can break under my modifications).

    •

    • Procedure to be followed:

    Rule: Not allowed to integrate if all tests in the system are not at 100%.

    How to integrate?

    Suppose Lab 30\\ Project contains integrated code.

    In other words,

    --- Integration : 15- to- 20 minute MAXIMUM.

    --- If someone got there before you, you’ll probably have to go back to your machine and rework your stuff, unless you are lucky, and all tests pass

    --- Integrating frequently will protect you from this, as the rework needed will reduce.

    Issues:

    1. How do we keep track of modification times for files?
  • Some machines have wrong clocks

    --- Make sure Nitin’s machine is properly working,

    --- Everyone else has a watch,

    --- Team members only need to keep track of when they took out the code from Lab30.

    --- Set up Nitin’s machine, so that running and testing time is minimal (e. g.: classpath, junit framework etc). We need the time the integration process takes, to be as short as possible

    •

     

    Tracker’s Report and Predictions

    Tracker : Sukhvinder Singh

    Date: November 8 ,2000

    The Iteration Report Contents are,

    1. The Release plan

    2. The iteration plan

    3. Acceptance tests,

     

    Release plan :

    The Customer has mentioned the few user stories,these are following,

    Stories Title
    1. Tracking of items in the store department
    2. Store manages various stock levels
    3. Calculations and updation of inventory
    4. Calculation of quantity at various stock levels

    In-Stories,

    The Planned Stories for the first iteration ,(Customer’s preference )

    Stories Title Iteration
    1. Tracking of items in the store department First

    Out-stories

    We are supposed to consider the following in next iteration,

    Stories Title
    2. Store manages various stock levels
    3. Calculations and updation of inventory
    4. Calculation of quantity at various stock levels

    Tracking of Iteration Plan :

    Iteration plan :

    Iteration: First iteration

    Start date: Oct 29,2000

    End date: Nov 11,2000

     

  • Iteration Plan:
    • Stories Title
    1. Tracking of items in the store department
    2. Store manages various stock levels
    4. Calculation of quantity at various stock levels

     

    Total Stories for the first iteration : 3 Stories,

     

     

     

     

    Six Tasks for the first iteration from the three stories are,

    Task Title
    1. Web form for requisition
    2. Interface to form-form code
    3. Regular Database etc.
    4. Code to update database
    5. Interface to order slip
    6. Interface to department

    First iteration task and the pair programmers statistics with their percetage of task completions.

     

    Task Owner Pts.

    Used%

    		 Pts.

    Left%

    		 Stories Supportrd
    1. Nitin + Sukhvinder 80 20  
    2. Nitin + Parag 40 60  
    3. Vibhu+ Rajesh 100 -  
    4. Nitin+Vibhu - -  
    5. Manish+Parag - -  
    6. Manish+Parag - -  

    Tracker’s Predictions for iteration success,

    1. We should reestimate the tasks of various stiories.
    2. Experienced Developers should do the remaining tasks.
    3. Rest tasks should take in next iterations.

    Because we now have four developers so we will take the rest of the Tasks ( Task 4,5,6 ) in the next iterations.

     

    Last changed: November 10, 2000 

    1  

    1

    Hosted by www.Geocities.ws

    1