1. Leverage other people software whenever possible, ie. Write as little code as possible.

A) Data base: open source packages

Server: Mysql
Server: Postgre SQL
SQL Files: SQLLite

Use Graphics to convey and understand the structure:

MySQL Workbench
DB Designer

B)Python: Data Manipulation

Files: csv, txt, sql, xml, xls, other text file formats

C) make, shell

D) Statistics:

R, SAS, SPSS

E) Mathematics:

Octave
MATLAB

F) MAPLE (symbolic computing)

G) SED (stream editor)

H) XSLT (Transforming xml to xhtml, txt, html)

2. Employ a simple and efficient architecture:

● Database:
 store
 easy access
● Manipulation
 python code
 data extraction
 SQL compilation to produce XML
● XSLT
 XML to HTML
 XML to XML
● Web server

3. Use a source control application and work with logged releases.

● CVS
● Subversion
● 0.11.0015 version

4. When you find a problem you fix it, and introduce a test that you will run after any changes done to the code.

● Equal effort to testing, developing; Testing = Developing

5. Always have a working version

6. Work with a end user as he /she uses the system. Know your users and the information the user needs.

Data Process - input data process/output data process. What data is available and used on each step.
Accounting Process - input/output data required for popper accountability. Accountability for people and data.

● Fraud:

Credit card:
Did you use your credit card sir?
Maybe my wife used it?
Which one? I have 10.
Insurance:
Why there is 10 very similar accidents in this area in past 10 months?
Is that normal/abnormal?
Who are the owners, agents, mechanics ?

7. Understand benefits of your approach to the user (compare to others) and show evidence as much as possible :

● Google vs. Yahoo

accurate vs. user experience

● SAS vs IBM

Do what you want with the data vs. use our database

● User acceptance of the software
● Capture things that other system can't
● Thing that will make your software over the “hump” of user acceptance and
usage.

8. Don't forget the reporting the user needs.

● Activity level
● Trading, tracking system (you need reports)

9. Track bugs and put testing around any bug you find. When new release come up, test the old bugs on it.

10.Keep it as simple as possible

Data definitions

Names

Lucia Gil-Soto
Carlos A Rosario-Rodriguez
Raul Hernandez Ramos

Insurance Business

Database, database, database! Mysql or Postgres. Database doubles with binary speed each month. Cross Platform!!!. Window, mac, linux !!! You can achieve it via browser (with special cases for each browse) or you can do it via gui library with special cases for each platform. You can use tool like Turbogears2 to build this system. You can use OpenOffice to create documents, pdf, with nightly process.

Data tables

zip code and territory

vehicles

Quote

Diary on quote

Policy

Insurance Policy as contract

  1. Treat each insurance as a contract.
    • This Helps to distinguished between various parts of policy change and it will create a much standard way to deal with premium changes.
    • First contract has an effective and expiration date.
    • Endorsement causes previous record expiration date to change. New record is created with effective date of today and expiration date copied from previous record.
    • Renewal goes through similar process.
    • Cancel changes expiration date.
    • Reinstate with no laps cancels the cancelation.
    • Reinstate with laps ends previous contract with expiration date x, and creates new contract with effective date of y and expiration date from previous record.
    • You run into problems when future cancels and reinstatement need to show up in the accounting records or history(For 99.9% of companies that is not the case, so you just need to keep a history of transaction). These records are not actual really cancellation or reinstate. Since you have to give notice to the insureds that you will be canceling their policy the future cancel and future reinstate handle that process. As these records don't have any bearing on the premium at all unless they become really cancellation they are needed to inform insureds/agents that policy might expire if they do not make a payment. 90% of the time the the future cancel and reinstate will cancel each other out if few days. The remaining 10% will actually become a cancellation.
    • The key should be based on agent#,state,line of business.

coverage and limits

  1. Coverages are divided into following categories:
    1. BI
    2. PD
    3. COMP
    4. COLL
    5. UMBI
    6. UIMBI
    7. UMPD
    8. MED
    9. LEGAL
    10. RENT
    11. SPECIAL MED(ADD)
  2. There is a group of coverages: Liability, Comprehensive, Other. Each of these groups have its own coverages, coverage limit, coverage deductible. Liability can include (BI,PD)(Indiana)in one state and include (BI,PD,UMBI) in another (Illinois).

Depending on a state the liability group might change.

sr22

sr22 warning

Underwriting options

User Interface

Browsers and data

  1. Never create browsers that display all data. As soon as number of records reach 50,000 your program will take minutes to display anything. If you want to show some records make sure you use Limit 100 and SQL DATABASE is REQUIRED. No Flat file based db should ever be used. Start with true database from day 0. Mysql Postgres etc.

  2. The UI should have "save" or "close" buttons and not "ok" and "cancel"
  3. The username should be copied to a updateduserid as "firstnamelastname" or "flastname" no sid references as it people might leave and new person will be assign same id number.
  4. Everything should fit on 800x600 screen. Older people even do they have monitors with 1200x1080 can't see letters that well and they WILL change the resolution to 800x600.

Defaults

  1. You will default state. When underwriting people work they will start divide the work by state. You should have a default state ex. IL in which you filter out any other states data. It speeds up the data retrieval and makes things easier for end user.

== Processing

Process at Night

Claims

checks

claim reports

diary

printing

Definitions

Finance company

Bug Tracking

   1. Dispatched: The initial state for a new CR.
   2. Incomplete: Something critical is missing from the CR.
   3. Accepted: CR was accepted, the first step in being investigated and fixed.
   4. Defer: Work on this CR is on hold.
   5. Cause Known: A basic understanding of the problem is known.
   6. Fix Understood: A basic fix is now understood.
   7. Fix in Progress: The assigned engineer is actively working on the fix or getting it integrated.
   8. Fix Available: A changeset or the actual fix has been made available in a team area.
   9. Fix Failed: Something went wrong with the fix.
  10. Fix Delivered: The changeset or fix has been integrated into the master area and will show up in the next build promotion.
  11. Closed: There are many reasons why a bug will be in the closed state. It might be verified as fixed, closed as a duplicate, closed as 'not a bug' or closed as 'will not fix'.

http://blogs.sun.com/kto/resource/BugStates.png

MyWiki: BuildingSoftwareForIndustry (last edited 2009-09-06 02:50:22 by localhost)