BPS has developed the world’s first fully autonomous software test agent capable of testing enterprise web applications by itself. ASTA is currently available to BPS clients and beta program participants. Learn more about ASTA here.
Author Archives: David Isaac
BPS Wins ED PMO-IVV BPA Recompete
(June 29, 2017) Business Performance Systems was awarded a Blanket Purchase Agreement (BPA) contract to provide the Department of Education with IT Program Management Office (PMO) support and Independent Verification and Validation (IV&V) services. This BPA enables ED programs and projects to quickly obtain expert services needed to help formulate and manage IT projects. BPS is teamed with ZipZap IT solutions as its hubzone partner.
Agile: It’s Not Just for Software
It seems Agile software development practices are being applied to everything these days. There is even Agile Parenting! It reminds us of the object-oriented craze in the late 80s and a publication titled “My Cat is Object-Oriented”. So are we going too far, or is Agile good for more than just software?
For large organizations, including federal government agencies, we believe Agile has a lot to offer beyond software development. Let’s look at IT project management, for example. While Agile promotes a shift of emphasis away from documentation, there are still plenty of documents required for large IT projects. These include project charters, acquisition plans, project plans, system security plans, training documents, and much more. Following waterfall methods, these documents would be delivered as near-final drafts for stakeholder review and input. But we have found that an Agile approach with frequent delivery (sprints) and daily stand-up meetings (scrum meetings) works wonders for speeding the delivery of project documents and constantly closing the gap between results and expectations to further the success of the project. Consequently, we have adopted Agile practices for all of our projects, whether they include software development or not. Could Agile practices help you succeed too?
BPS Awarded Grants.gov Program Technical Support Contract
(August 24, 2015) Business Performance Systems was awarded a five year contract to provide Program Technical Support services to the HHS/Grants.gov program. Under this contract, BPS provides a variety of technical services to the Grants.gov Program Management Office, including Independent Verification and Validation of system releases, technical analysis of important issues, life-cycle management, program/project management support, and assessment of promising technologies.
BPS Wins USPTO Performance Analysis Testing Contract
(March 3, 2014) Business Performance Systems was awarded a five-year contract to provide Performance Analysis Testing services to the U.S. Patent and Trademark Office. BPS will perform final performance testing and detailed analyisis on all releases of nearly 200 enterprise applications to help ensure that USPTO staff and public users always have access to critical information in a responsive and timely way.
BPS Supports ED On-Line Application System
(September 18, 2013) Business Performance Systems was awarded a task order with the U.S. Department of Education to support planning, acquisition, implementation, and verification of a new On-Line Application System (OLAS) for the Office of Communication and Outreach. For this effort, BPS supports concept development, analysis of alternatives, cost estimation, ROI calculation, system acquisition, and independent verification.
BPS Wins ED PMO/IVV BPA
(June 29, 2012) Business Performance Systems was awarded a Blanket Purchase Agreement (BPA) contract to provide the Department of Education with IT Program Management Office (PMO) support and Independent Verification and Validation (IV&V) services. This BPA enables ED programs and projects to quickly obtain expert services needed to help formulate and manage IT projects.
Vendor Independence: Theory and Practice
This topic comes up periodically, usually just before or after introducing a new major commercial off-the-shelf (COTS) product into a solution. Forward-thinking managers or software architects become concerned about avoiding “vendor lock-in” that could result in higher license costs, increased dependence on obsolete products, or an expensive software migration in the future. Unfortunately, this is a case where the cure can be worse than the problem.
The knee-jerk response is to write an “isolation layer” that in theory reduces the dependency on vendor-specific application programming interfaces (APIs). But this merely aggravates the problem: now you are dependent not only on the product (because you inevitably can’t hide the vendor-specific functionality) and you are also dependent on a raft of custom software that comprises the isolation layer. This custom isolation layer ultimately has the same the characteristics you sought to avoid in the vendor API in regard to future cost and support concerns. Meanwhile, you doubled your cost and schedule by effectively undertaking a standards-definition effort within the scope of your development project.
In practice, there are at least three better alternatives. The easiest is to resign yourself to using the proprietary API. At least this interface has been thought out and refined over the years by the product vendor…generally better that what you can expect out of a system integrator operating on constrained project budgets and schedules in an area that is not their core competency. If the day comes where you need to change products, only then do you write the isolation layer…but now it translates from the legacy product API to the new product API. This way you only incur the cost when you have to, and you’ll still spend less time and money because you have two well-defined interfaces to bridge.
An even better approach is to use the natural utility classes in your application to serve as the isolation layer. You have to write this code anyway, and if written correctly you can isolate the impact to a relatively small set of code. The third and perhaps best approach is to leverage a standards-based API. This buys you real isolation, and with a little luck it is something that the vendor or a third-party has already implemented. The downside is that you may sacrifice some proprietary functionality when using the standards-based API, but you can always extend this approach with one of the other two alternatives if really needed.
Ultimately, a good solution depends on both the right approach and a faithful implementation of the approach. But beware of integrators selling vendor independence through isolation layers…they are likely just moving the dependency, not eliminating it.
XForms – Lagging Implementations Point to Bigger Issue
XForms seem like such a good idea. With declarative binding of form fields directly to XML document elements, you can implement an XML-centric XFormx/REST/XQuery (XRX) architecture and avoid a bunch of complex server-side code: no Javabeans needed to map HTML form fields to Java objects, and no object-relational mappings to persist the data. Use some XSLT to create XForms from a schema, and you could eliminate most of the custom programming needed to collect, store, and display business information.
So why — nearly 10 years after the initial XForms recommendation — why aren’t XForms being used everywhere? Our recent experience on a research project provides a clue.
First, XForm implementations are lagging. There are arguably only a couple robust implementations on the market: the rest are little more than tinker toys that are extremely limited and fragile. In addition, the implementations have enough extensions and different interpretations of the standard that code portability is non-existant, so you’re locked into a product. This is a far cry from JSF, which has more than a dozen implementations that are more or less interchangeable. The paucity of good implementations is an immediate problem for a development project, but it is really just a symptom of a deeper issue.
The real issue may be that the things that make XForms so great in theory make it hard to adopt in practice. XForms provides relativly complete support for the model-view-controller (MVC) pattern, including a robust event model. Cool, now you can do highly-interactive AJAXy things on the client. But now the developer is working in a strange world of XForms event programming rather than Java or JavaScript. Whoa…we’re going to discard all that experience and infrastructure? And do all our control scripting in an XML dialect? And what about a debugging environment? The idea of client-side support for the MVC model sounds great, but when you get into you find it was the “MV” part that was exciting, and the “C” comes along like unwanted baggage. But even the “M” part can be an issue. Say you want to let users check of a bunch of items on a list for processing. In a traditional form, it’s easy to provide a combined view of a perstent object with transient (checkbox) data. But doing that in XForms either mucks up our business object with control data, or requires a second correlated object, which isn’t really supported by the standard XForm controls. And what about paging a large list? I could go on, but the point is that developers will have to find new ways and awkward workarounds for everyday features of all but the simplest forms.
The problem with this deeper issue is that it will be very slow to be resolved, if it is resolved at all. If the only issue with XForms was in weak implementations, a new development project might be willing to bet on rapid improvements driven by high demand. With deeper issues at play, I wouldn’t bet on it.
BPS Wins HHS Grants.gov IV&V Contract
(May 1, 2011) Business Performance Systems has been awarded a five year contract to provide independent verification and validation support for the Grants.gov eGov initiative at HHS. BPS will perform testing, technical assessments, and requirements management to ensure the functionality and performance of the Grants.gov system, adequacy of all contractor processes and deliverables, and systematic management of user requirements.