The Motley Fool Discussion Boards

Previous Page

Industry Discussions / Healthcare

URL:  https://boards.fool.com/software-issues-with-obamacare-30813946.aspx

Subject:  Software issues with Obamacare Date:  8/6/2013  7:23 PM
Author:  klee12 Number:  2857 of 2992

Software engineering is the discipline concerned with writing large scale software so that a large software package comes in on budget and on time. I will present a software development model that is applicable to the software required for Obamacare.


In any software projects there are 3 actors: (1) the management who pays the technical staff and should monitor the project to see if it is on schedule and on cost, (2) management should write, and debug the code and (3) the clients. The three actors should be independent. The stages might be something like the following.

1. Requirements analysis: The management should know what is required and hire a SD to be responsible for developing the software. The management meets with the SD (and preferably with some clients) where management explains to the SD what management wants and the date he would like to have the software working. At the end of this project a set of specifications for the project should be developed. This is important because at the end of the project we do not want the SD to say "It's done, pay me" and the management replies it "But you didn't do this". The SD replies "that's not in the specifications and it will cost you $$$$ more to do that". Management may be a very difficult situation if the organization needs the project at that time.

2. Software Design: The SD goes home and with his staff defines the architecture, components, interfaces required. Briefly this is a macro view of the software code. For example, the Obamacare requires the IRS data base must be accessed to determine who is eligible for certain subsidies. Also the SSN database will probably have to be accessed. The interfaces to these data bases must be defined and carefully controlled for privacy reasons. Then subdivisions of code (called modules) must be determed with clearly defined interfaces. For example you might have a module accessing the IRS, another module that handles interaction with clients, and so on. There may be tens or hundreds of modules required. At this point no code need be writing ... what we want is a macro view of the project. At this stage the large parts of code related to a particular function. No code is written at this stage; we just want a macro view of the project.

After the software design a PERT (or similar) Chart (see

http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_T...
)

should be drawn up. It is important that the milestones represent the the completion of a module including testing of the module. Without the PERT (or similar tool) chart the software project is out of control. There will be no way from someone on the outside to tell how the project is progressing. When one builds a house, you can see foundations being laid, the frame going up, electrical wiring and plumbing going in. With a software project you see nothing nothing. Management is at risk of (1) discovering the project will be late the day the software is supposed to go online and/or (2) having to negotiate additional payments to complete the project. Management should never be surprised; if the project is late the management should know as soon as possible so that problems can be mitigated. Or management may even pull the plug on the whole project.

After the software design is finished the SD sits down and decides how much the SD will ask for the project an how long it will take. Then the SD will sit down with management and negotiate a fixed price and timeline and possible penalties for missed deadlines.

Any changes to the specifications after this point may be very expensive.

3. Software coding: this involves coding and testing at the module level.

4. System testing: tests the system as a whole, in particular it tests all the interfaces between modules and external inputs.

5.
Roll out or implementation: Two possible strategies are a phased roll out or big-bang roll out. For Obamacare a phased roll out may be to start the rollout in several states first, then a few more states later, and the remaining states still later. Big-bang means rolling out the whole system all at once. One advantage of phased implementation is that it may be easier to train the clients.

6. Software maintenance: Maintenance includes fixing bugs and adding adding functionality to the software. A large number of bugs probably means not enough resources were given to testing, and a large number of changes probably means that not thought was given to the requirements and design phase of the software project. Making changes in the maintenance phase is very expensive compared to getting it right the first time.

It seems probable that Obamacare did not follow the above procedures. For example implicitly the delivery date was fixed in Congress when they wrote into law that the law would take effect in 2014 and I assume that the system had not been designed at that time. Without seeing the PERT chart it is difficult to determine if the software will be ready next year and what parts will need work. The fact that the employer mandate will be pushed back to 2015 indicates that some of the project are behind schedule.

A particular worry is security (privacy) threat that involves accessing the IRS and SS databases. The Snowdon and earlier Wikileaks leaks does not indicate the government is good at security.

For an example of a project that went off the rails see

http://finance.yahoo.com/news/pennsylvania-kills-ibm-contrac...

I can't tell what happened but it seems that the plug should have been pulled earlier.

klee12
Copyright 1996-2019 trademark and the "Fool" logo is a trademark of The Motley Fool, Inc. Contact Us