I would recommend node.js on the server, AngularJS at the front-end. Put the data into Postgres. The reason I would recommend Postgres is because of the new binary JSON data storage. By storing and indexing JSON you have a flexible data structure. Basically NOSQL with a relational "super-structure". So you structure and index the main table according to the basic relational layout but the stored documents can have templates that could drive the user interface. EJS is a good view engine that is very flexible. OpenRPT as the report writer. PostGIS for the display of statistical data on maps. Personally, I would stick to CSV for data exchange.
The whole stack is open source, and importantly, it is all JavaScript. That means once you have your design and specification laid out. Then you split the whole project up into bite sized chunks and outsource them to different parties. The reduction in costs is significant. Risk is minimized because you don't rely on one party for development. As part of the contract with the developers they have to fulfill (and sometimes write) the tests. That way when the code is returned it slots directly into your test suite. The testing framework I use is Mocha, and would recommend PhantomJS for the user interface testing. But the success relies on how well the specifications are done and the structure of the test suite. I have implemented this approach a number of times and was able to deliver under budget and before the deadlines. Both on a .Net and JS projects. It is all in the analysis, if it is wrong or done halfheartedly you have constant emails and arbitration issues with the developers. The other side is the specifications then become the contract with the client. They have to actually sign off on the specifications (BDD style). On Fri, May 30, 2014 at 6:31 AM, Jeff Johnson <[email protected]> wrote: > "Mini-projects, with small, carefully-defined goals, can succeed better > than > grand plans. They're not only under the radar of bigger projects; they give > client and dev teams natural points at which the project can be redirected, > teams can be swapped out, and schedules adjusted." > > To piggy back on what Ted says here, I have done at least 100 projects for > major corporations. They were all very specific and very targeted in scope > and all very successful. Many of them ran up to or over 20 years. These > projects were ordered and managed by transportation people and the > applications worked with data from on board computers. IBM tried to do the > same thing with some of these companies and failed because of their large > scale approach. > > > > On 5/29/2014 12:25 PM, Ted Roche wrote: > >> It seems there's two kinds of developers: those who think they can whip it >> up in an afternoon (optimists) and those who are sure it's yet another >> government boondoggle, sure to suffocate in its own red tape (pessimists). >> Neither strategy seems to have a long track record of success :) And I >> should know, since I've been burned in both camps. Caution is a good trait >> in consultants and developers; pessimism perhaps less so. Realism is the >> hardest thing to find in our industry. >> >> Ken: yes, the project seems interesting, and yes, I'd be skittish about >> state agency funded or non-profit managed projects: both sometimes have >> motivations at odds to the successful completion of projects. These are >> risks to manage, as Dave somewhat frankly pointed out :) >> >> I would be concerned about state agency acceptance criteria (there are >> state regs, in many states), payments, and project structure: a fixed bid >> demands a fixed specification, a fixed specification often means you get >> what you ask for, but not what you need. (I once sat in on a RFP >> pre-conference, with reps from The Big Five consulting firms plus IBM and >> HP. Despite the small scope of the project, it was clear this would be a >> big budget item.) >> >> So the three concerns are: business aspects, project structure and >> technical feasibility. All three are different axes of the venture, and >> any >> one of the three can be a show-stopper. >> >> Mini-projects, with small, carefully-defined goals, can succeed better >> than >> grand plans. They're not only under the radar of bigger projects; they >> give >> client and dev teams natural points at which the project can be >> redirected, >> teams can be swapped out, and schedules adjusted. Examples: >> >> 1) Develop a paper-only specification of front end, back end, processes, >> import/export formats, sample reports. Estimate the scope and budget of >> step #2. >> 2) Develop a pilot web project to demonstrate the feasibility and >> usefulness of the main app. Estimate the scope and budget of step #3. >> 3) Scale the pilot project to a medium-sized county, fixing issues found >> and identifying additional requirements that emerge. Yeah, estimate the >> scope and budget of step #4 & 5. >> 4) Determine the costs to go into production: 24x7 monitoring, hot sites, >> backups, disaster recovery, archiving, etc. >> 5) Rebuild the pilot project into the production version. >> >> How hard could that be? >> >> If possible, you'd like to introduce as many aspects of Agile project >> management into the mix as possible. The abysmal failure rate cited in >> many >> studies is, to my mind, a fault of poorly thought-out, poorly-designed, or >> poorly funded projects which could be success if proper focus, money and >> time were applied. "The journey of a thousand miles begins with the ground >> beneath your feet" also can mean that if the first step's a misstep, >> you're >> off on the wrong path. The fixed-bid, fixed-spec format is the equivalent >> of asking for a moonshot: hit another body traveling at an unknown >> variable >> speed at a huge distance for the smallest amount of money imaginable, with >> one try. When "Failure is not an option" that means it is inevitable. >> Breaking up a big job into a bunch of smaller, somewhat-independent tasks >> means that revisions and changes are part of the project, not trying to >> re-route a waterfall mid-drop. >> >> My two cents, a couple of times over. >> >> >> >> >> On Thu, May 29, 2014 at 1:42 PM, Ken Dibble <[email protected]> wrote: >> >> Thanks everybody for your enlightening comments so far. >>> >>> Boy..a lot of traumatized people out there! >>> >>> Remember, this is not a "specification", it's a "feeler". A clear >>> specification certainly would be issued before anyone is asked to bid. >>> >>> Perhaps a bit of background would help: >>> >>> Currently the state's developmental disabilities service agency has a >>> very >>> big, very complicated web-based document-management/workflow system >>> called >>> CHOICES. It is based on some MS proprietary web application development >>> software whose name I can't recall right now. It was developed about four >>> years ago and its use is mandatory for thousands of people working under >>> contracts with this state agency. It only works in IE versions 7, 8, and >>> 9. >>> It doesn't work in the two most recent versions of IE. It doesn't work in >>> any other browser. MS promised some pointy-headed IT guy that the system >>> would be "updated" to work with other browsers but it never was. The >>> underlying MS software itself is not even being updated in a timely >>> fashion, BY MS, to work with its most recent platforms. And the agency >>> itself has no budget to keep the application updated. >>> >>> The system I'm talking about is not anywhere nearly as complicated as >>> this >>> example, nor will it require anything like the amount of data storage or >>> user concurrency as this system. The CHOICES system is an example of what >>> can happen when somebody depends on a big proprietary software house for >>> stuff that needs to be kept current. >>> >>> "Commercial solution" providers lie. They make promises they have no >>> intention of keeping. So yeah, if the developer who builds it can't be >>> bothered to keep it updated in a timely fashion for a reasonable fee, you >>> bet your ass we would want to be able to find another developer to do >>> that. >>> >>> And yes, there might not be money for updating at some point. In which >>> case, no updates would be expected. What's the problem? >>> >>> Now, for the system I'm describing. >>> >>> It's a data warehouse for querying and generating reports. Data uploaded >>> to it will contain no personal identifying information, just surrogate >>> primary keys to keep the records separate. Therefore it has NO HIPAA >>> compliance requirements. I have researched HIPAA extensively; I do it all >>> the time. There's a big difference between what CYA lawyers, and paranoid >>> IT Department heads, think HIPAA "requires" and what it actually does >>> require. >>> >>> Uploads would be via CSV or perhaps XML files. Not hourly, daily, or >>> weekly. Perhaps quarterly. Perhaps, at most, monthly. >>> >>> This is not a "medical" application. The data to be stored consists >>> mostly >>> of demographic stuff that changes over time, and very simple dated >>> service >>> "events". >>> >>> It's not a real-time end-user data-entry system. It's designed purely >>> to >>> accept periodic bulk uploads and enable queries on the data it stores. >>> Number of sites uploading would never reach 100. Number of people who >>> need >>> to query the data would never exceed 200. Very little of this access is >>> likely to be concurrent. >>> >>> Again, a state agency would purchase this. It is not going to be resold. >>> >>> The flexibility thing: For example, we want to be able to report on the >>> disabilities of the people served. Suppose today we have a list of 20 >>> disabilities: arthritis, spinal cord injury, diabetes, brain >>> injury...etc. >>> Now next week the state agency adds five more disabilities to the list. >>> The >>> system needs to be able to accommodate that sort of thing as a >>> "configuration" issue, not as a hard-coded feature of the interface or >>> the >>> back end. There could be various sets of other specific data points in >>> the >>> categories of, for example, income ranges, or race/ethnicity categories, >>> or >>> education or employment levels. I already do this sort of thing all the >>> time with my main system. It's not very hard, but it does require >>> forethought. >>> >>> The system needs a flexible query system in order to cross tab any number >>> of demographic data points with each other or with service data. Also >>> stuff >>> we've all done, also requiring forethought. >>> >>> It will also need some minimum number of hard-coded reports, and more >>> would need to be added over time, for a fee. >>> >>> That's all. No secret hidden agenda to rip off hard-working developers >>> here. >>> >>> Do you people make a lot of money by distrusting and bad-mouthing >>> potential customers when they come to you with ideas?? >>> >>> Jeez people, take a breath. :) >>> >>> Ken Dibble >>> www.stic-cil.org >>> >>> >>> >>> >>> >>> >>> >>> >>> [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CAKT3oPcRvb8xW2uVMxo=n6yajxk5tl3++5nk4vbwsw70ppv...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
