Requirements


Plans for the week ahead

We’re meeting with Dermot to give a release next Friday, here are my plans between now and then:

Create templates and editable text for the offline products
Add in login functionality

Validation of form fields

Email component

Server side validation

Form field persistence – a handler that fires on quote Generate? or quote Generate and copletePurchase handler passing request to FormFieldPersister, FormFieldDAO.

Similarly, a requestHandler for form field value requester.

Online purchase shaping up

Only one more step to add to the online purchase process.
At present it works as follows,

A customer registers as a site user, this gives them a site user id.
This is associated with any quotes or purchases.
I they make a purchase, they become a client and so a row is created for them in the climas table, and a corresponding foreign key is set in their site user row. Emails are sent to the customer and to the DM Office, sample below

Quote 104 has been generated and purchased by customer 224.

David Gibbon, 09/03/1970 purchased Hibernian Life Cover Only at EUR631.63 (Annual).

The customer’s contact details are as follows:
Telephone: 085146xxxx
Email: Link to david@xxxxxxx.com
Address:
200 The Street,
Nice town,
Dublin

Customer’s client key is 224.

Customer accepted execution only disclaimer at time of purchase (11/03/08 21:49)

All that needs to be integrated now is the login functionality, which will retrieve a site user id from the backend, to stop multiple clients being created

for one customer.

My plan of action for the rest of the week is to implement this last piece of functionality, and then try to get all of the products (both on / offline) finished on the shop front side.

I’ve sent Dermot another email asking for furhter information and feedback on some of these products.

Got the external quote requests going through dcu proxy in the labs late last night, so that’s that out of the way. Emails are a little problematic as the DCU mailserver does allow relaying. Perhaps I’ll direct my local mailserver through the dcu proxy, or just use dcu addresses while in dcu.

The Assignments have now all come in, and there really isn’t a moment to spare, so we’re just focussig on getting each assignment out of the way as quickly as possible, hopefully leaving the last few weeks free for a full final sprint on this.

Meeting with Howard

We had our weekly catch up with Howard, this week consisting mainly of a demo of the work we’ve done since last week. Page editing, Quote Generation, New Policy work and client links.

The quote generation item brought my attention to the DCU proxy, our quote requests are sent externally and so Tomcat will need to be configured to use the proxy server for making that request. I’ve looked into this and it seems to be as straight forward as adding some lines to the Catalina.properties file, naturally enough pointing to the proxy server and port. Will test this on Thursday.

Some further points raised were whether a policy could have any number of clients associated with it (or just a straightforward two as in a couple), we’ll need to iron out this granular requirements with Dermot, but in theory any number of people could be party to a policy protecting say an investment property. Perhaps each would have their individual mortgage protection policy covered to their respective amounts? All conjecture until we check it out with Dermot.

Howard asked us if we had planned on going into business with the project, and its something we’ve talked about a lot. He then forwarded us an email from two fiontar students looking to do a business plan for their final year project. We’ll get in touch with them tomorrow. Exciting times ahead.

The semester 2 assignments have come in. The next 3 months will be busy!

Having exported DM’s legacy customers to our new mySQL database, today it fell to me to
figure out how to create a new customer [from the management system, or from a customer
sign up] and enter them into the database.

DM’s legacy clients have CLIENTCODEs which aren’t at all uniform, probably dependent on the
database system he was using at their inception. I had to create a hibernate mapping that
could ensure unique codes would be assigned to new customers upon their persistence to the
database.

I created a new ‘id’ column in the client table, which has an autoincrement property, all
of his original 2000 or so clients now share this common column, while new and online
cliets will have a new CLIENTCODE which is based on this column, prefixed by some
characters, thus ensuring all CLIENTCODEs are unique.

It’s been a long time since we worked on the OBS, but now that the exams are out of the way
it’s full steam ahead to get each production phase delivered as per the schedule. First up
it’s a working subset of the Management System, as Dermot needs to view his customers,
which we have exported from his previous MS Access database system.

Also this week, we have migrated Dermot’s Access database (to which he was subscribing with an annual fee) and integrated it into a mySql database belong to the OBS. Dermot will now be able to see his _existing_ customers, and run his old queries as before.

The process was quite painstaking, to ensure data consistency and no loss of information. All tables were exported from Access into delimited files and loaded into the mySql database. It took a few tries to ensure no data was lost in respect of each table.

Meeting with DM
We had quite a lengthy meeting with DM today, showing him our prototypes to date, and trying to nail down some requirements for the Functional Spec.

Prototypes
The runthrough with the prototypes was quite smooth, showing examples of 2 types of products, those which cannot be completed online, and those which can. This led nicely onto getting requirements for other products in each category, and we believe now have the final list of products for the delivery of the production system. Further products can be added in the future naturally.

This new requirements information will help us to complete that section of our functional spec, a final copy of which we hope to send to DM next week.

DM introduced us to a new service BestAdvice, which is simalar to adviserplus that I’ve mentioned before, they claim to provide a ‘feed’ by which they might mean API or similar means for us to generate quotes.

DM has never been involved in a software project before and traditional requirements gathering is therefore not easy.

We decided that a good way to illicit his requirements and desires was to produce prototypes of each area of functionality. He can then explicitly see what he likes, what he doesn’t like, and extra functionality he would like to see provided.

So far, we have prototyped a subsection of the Shop Front and a sample screen from the Customer Management System.
It has proved useful as it has gotten him talking about how certain processes should take place, where before he may have just spoken about how the website should look or who it should appeal to.

I’ve had a look into the Data Protection Act and found a wealth of information online.

Certain procedures must be followed and only certain data may be kept.

Some of those procedures:

The Data Protection Rules

Registering with The Commissioner

Guidance Material

Security Guidelines – Use a screensaver with password protection. Love it.

I’d love to find a page geared towards developers or DBA’s. Will look into this one.

Meeting with HD
Had our weekly meeting with HD at which we presented a demonstration of the front end and back end communicating through a controller. Two flex form components formed the basis for this presentation. One form was for adding a new customer entity to the database. The other displayed all customers. Howard added one customer on Kevin’s laptop, which called the controller webservice on mine, which in turn added that customer to the MySql database running on mine. We queried the customer table on my laptop to demonstrate that it had worked, and then to further demonstrate, Howard clicked the customer display table on Kevin’s laptop and the new “customer” appeared there too. I then explained how all of our technologies and frameworks are sitting together comfortably now. I have also implemented the Acegi Security package, which is a comprehensive security package and built for the Spring framework. It is easily integrated in terms of user authentication but we must next figure out how only flex components may call flex controllers.

I proposed my flex -> Controller -> backend architecture which you can see below:

Discussed our XML <request> type, so that modules could be added to flex, as long as a handler which understood the flex module’s request and returned the expected result was wired to the controller.

Howard brought up the point of the Data Protection Act, which we have asked DM about previously, but hadn’t got any firm answers from him about his requirements or current practices. Howard suggested we do some reading on it ourselves.

In reference to scheduling work, we decided that we should break down days into smaller units rather than find we have wasted hours chasing an error, we should stop at our scheduled time and move onto something else. (We did this this afternoon and found it beneficial).

Development work
We started to come up with a nice looking interface for our screens and implemented the first of our working prototypes (Customer researches and enquires about offline product – Pensions, lump sum, savings). The customer chooses one of these products, reads a little about it and then fills in a form requesting some more info. Flex passes the details to its controller, the controller chooses the appropriate handler which in turn sends the email.

Functional Specification
Started a draft on the Functional Specification, doing those sections addressable now. It will be necessary to nail down some further requirements to get this right.

Next Page »