Graphic courtesy of Oriental Journal of Computer Science and Technology article "Component
Based Software Development Life Cycle Models: A Comparative Review" published 30-Jun-2017.
|
NCSC's very own Barb Holmes shares the following on her experiences working in the Pennsylvania Courts and how they combined a component-based approach with agile methods to tackle complex business problems and ever-changing requirements.
---
After 25 years in software development for a statewide court system, it was easy for me to understand the usefulness of agile approaches. We developed iterative and team approaches very early after many challenging projects that involved water-fall approaches that were painful, especially when contracting for services. Every change was an issue and the battle cry of “that is a new requirement!” often sparked heated conflict between developers and business stakeholders.
Our more agile
approaches promoted user involvement and team development, reducing conflict
and allowing for the ever-changing nature and evolution of business
requirements. As our processes improved, they greatly reduced re-work and the
introduction of bugs.
I understand
more about why this approach works as I have become more deeply involved in
SCRUM. The empirical nature of the
framework promotes transparency, inspection, and adaptation. It engages users and promotes constant
feedback to better meet business needs. Breaking product backlog into sprint
backlogs – logical portions of functionality - is important for continuous
feedback.
The Court
Component Model intertwines with agile approaches in breaking down the business
needs of courts logically. While the
court system I worked for often chose to build rather than buy software, when
the time came to purchase Electronic Content Management (ECM) software, we had
to take a step back and say “can we efficiently build something better than
what is on the market to manage our documents?”
After a lot of research, the answer was definitely “no!” In the changing environment of highly
configurable software that is more reasonable to purchase, there are a lot more
options across the board for all types of software with accessible interfaces.
My ECM
experience taught me that these companies often purchased components separately
as well. For example, we could trade out
their “default” full-text tool for another tool that worked better. Companies throughout the software industry
are picking and choosing other tools to acquire and other business partners to
work with to leverage their own component models.
Another example
of this is the use of e-commerce interfaces to interact with bank software for
electronic payment processing. In many cases, these can be traded out rather
easily as most of their banking processes and interfaces are very similar.
Looking at
court business software needs from a component perspective can allow you to
constantly re-evaluate the changing and evolving nature of industry offerings,
potentially without requiring you to do a lot of recoding because of the
standardization of interfaces. You may
decide to completely replace a component with a richer offering on a periodic
basis, much like we would often re-write entire modules.
How have you have
begun to mesh the Court Component Model with your agile software environment
and what components have you begun to explore?
Examples of practical uses of this framework can benefit other courts
and help us all work toward a more agile business environment.
No comments:
Post a Comment