Agile Legacy reengineering by wuyunqing

VIEWS: 3 PAGES: 24

									     ShouldersCorp:
Software Framework
        30 September 2010




                            1
Who are we?
A 12 year old professional services
 company
With significant management consulting
 and new application development
 experience




                                       2
ShouldersCorp: experiences

 Schedule, budget and technology risk evaluations
 Construct-ability reviews based upon comparable projects
 Accuracy checks on cost and schedule estimates
 Reusability audits to eliminate unnecessary development
 Project restructuring to achieve lowest cost or shortest schedule
 Real time monitoring of software construction projects
 Complete software construction management services
 Deep Dive technical analyses
 Agile Legacy Reengineering


                                                              3
4
ShouldersCorp Track Record
12 years experience doing Agile Legacy
 Reengineering including:
   an international risk management system
   an order management system for steel
   a huge parts catalog (386m parts!)
   an integrated HR and Payroll system
    (supporting 10,000 companies)
   an electronic medical records system (a work
    in process)

                                           5
Software Framework
 Started with a “prototyping” application to assist in:
    gathering business process flows,
    determining the fields needed to collect and use for
     decision making at each state in the business
     process,
    understanding the roles and their responsibilities,
    gathering the business rules that were needed for
     validation and process logic.
 We became aware that instead of custom code, a
  reusable workflow engine with externalized workflows,
  externalized rules, data dictionaries, and easily
  configured interfaces for persistence and external
  systems could address most of our clients problems.
                                                      6
The framework was used on
many engagements and...
  It evolved into a system for expressing the
   information gathered into an xml file.
  That xml file could be used to:
   • Create html documentation about the applications
     and their processes including role-based views,
   • Run a simulation of the processes using client
     supplied numbers for the numbers of actors and
     expected service times and variations,
   • Create a data dictionary,
   • and...
  Actually be used as the input to the web-
   engine for running the processes.
                                               7
 Architecture
Our experiences convinced us that
   Clients change their minds a lot, so we have to be
    prepared for that.
     • 3 database changes during one project
     • Add new process with 5 screens...
   The system needed to be “loosely coupled” so that it
    would not be fragile.
   The persistence mechanisms were constantly
    changing.
   Business Rules often needed customization on a per
    client basis
   The need to connect to external systems was always
    there.
                                                    8
Our Solution




               9
Created a workflow editor




                            10
Reads and writes xml




                       11
Creates system
documentation




                 12
Example of Application docs




                              13
Process step doc




                   14
Cross referenced by roles




                            15
Same XML is base for
simulation




                       16
Simulation Results




                     17
And for execution




                    18
A “generic” jsp during
exploration




                         19
With business rules




                      20
Histories and Statistics




                           21
Summary
Metrics
    50 packages
    748 classes
    68,803 SLOC excluding comments.
    Lots of test cases.
 Value
    Used for many engagements
    Allows a quick start and early demonstrable
     functionality.
    Supports n-tier implementations.
    Not tied to a particular data base or messaging
     system.
                                                       22
Contribution to OHT
All
    50 packages
    Demo web-site
    Test Suite
    Work Flow Editor
 Value
    Most aspects of health revolve around processes.
    There are rules associated with steps in the
     processes.
    Can be used as web-based or Rich Client
    Very useful for providing inter connections.
                                                    23
Contribution to OHT
How OHT can help
    Extend adapters to NHIN, HL7, etc.
    Create adapters to existing and developing web
     services.
    Improve the work flow editor.
    Improve and extend the entity management portion.
 Our continuing contribution
    Involvement with OHT to assist with further
     development and improve usefulness to community.
    Open to all help in making this useful and easier to
     use.
    Involvement with OHT as needed.
                                                    24

								
To top