Re: is XP adapted for Business Intelligence applications

> loicmidy wrote:

> I work at the french institute of statistics (INSEE). We are going to try 
> agile processes (I think a mix of SCRUM and XP).

XP _is_ a mix of Scrum and XP. Scrum is the "planning game" and "user 
stories" aspect of XP. They are the concept that programmers should work on 
one small feature at a time, and do features in order of business priority.

> Like most firms we have OnLine Transactional Processing (OLTP) 
> applications and we also have Decision Support System (DSS) (or Business 
> Intelligence)applications.

> for the OLTP applications we have mainly J2EE applications with struts 2 
> and hibernate. In this context the programmation is OOP. I see clearly how 
> to do XP and we know the toolkits (Junit, Dbunit, easyMock and so on).

It sounds like you don't have unit tests yet. Some frameworks make them 
hard, so you should schedule an "engineering task" to write some example 
unit tests for each of those layers

> for the DSS applications I don't see how to do XP.
> for example we are doing the developpment of an application with a lot of 
> statisticals calculus and with a lot of data agregations in batch mode. 
> the data is in an oracle database with a star schema.

You need a "customer test" system, also called "behavior driven development" 
these days. Consider the table at the end of this:

http://c2.com/cgi/wiki?MoreliaViridis

 Scenario: orders above $100.00 to the             continental US get free 
ground shipping
   When we send an order totaling $<total>,              with a 12345 SKU, 
to our warehouse
    And the order will ship to <destination>
   Then the ground shipping cost is $<cost>
    And <rapid> delivery might be available

        |  total | destination            |  cost | rapid |

        | 101.00 | Rhode Island           |  0.00 |  yes  |
        |  99.00 | Kansas                 |  8.25 |  yes  |
        | 101.00 | Kansas                 |  0.00 |  yes  |
        |  99.00 | Hawaii                 |  8.25 |  yes  |
        | 101.00 | Hawaii                 |  8.25 |  yes  |
        | 101.00 | Alaska                 |  8.25 |  yes  |
        |  99.00 | Ontario, Canada        | 40.00 |   no  |
        |  99.00 | Brisbane, Australia    | 55.00 |   no  |
        |  99.00 | London, United Kingdom | 55.00 |   no  |
        |  99.00 | Kuantan, Malaysia      | 55.00 |   no  |
        | 101.00 | Tierra del Fuego       | 55.00 |   no  |

(Apologies for the wretched word-wrap there!)The top part is a test 
specification with insertable data. The bottom part means "re-run that test 
case for each of these records, with these values copied in.

In the case of Morelia, you attach that to a Python back-end by writing 
"steps" into a test suite; each documented with the regular expression that 
matches one of those lines starting with Given, When, And, etc:

    def step_the_order_will_ship_to_(self, location):
        r'the order will ship to (.*)'

        self.order.ship_state = location
        self.order.save()

(Subsequent steps will run in the same test case instance, so they all see 
each other's self. variables.)

Java has a system like this, called FIT.

> we are going to do the batch using only SQL scripts. those scripts will be 
> wrapped together with java or PL SQL. So the programmaing is NOT OOP.

If you attach a table-runner, like mine (except it's in the wrong 
language!), to your unit tests, they can then copy those data into the 
database and call those SQL proceduces.

So to test huge blocks of data, you essentially add an "alternative user 
interface" for that data, so your "onsite customers" can review and augment 
those data without running the end-users interface over and over again, 
entering each data item.

And neither XP nor TDD requires OOP!

-- 
  Phlip
  http://twitter.com/Pen_Bird