Real Time Objects & Systems, LLC
ASSET BASED DEVELOPMENT PROCESS
RTOS views every item created for a product a reusable asset, and thus attempts to organize and document individual assets in a reusable manner. This includes standardized naming conventions, document structures, project folder naming conventions and so forth. If a asset isn't required to manufacture and/or provide future product support then why create it? Licensed users are provided the "RTOS Process" document which may be reviewed and modified to be compatible with existing processes or may be adopted when an existing development process does not exist. At minimum it describes the assets and processes recommended by RTOS.
ASSET FOCUS
"You can't reuse what you can't find" and thus the RTOS Process is exremely redundant and attempts to emualte a "repeatable manufacturing process" within product development. Although seldom recognized, a new product creates and integrates hundreds to over a thousand individual assets, some are documented and tested, others are not. RTOS process assumes every asset may contain an unidentified defect and unless it is tested to verify it operates as defined a risk is assumed when asset testing is omitted. Reuse of previously tested and time proven assets thus greatly reduces this risk.
The "Concurrent Spiral" development process incrementally designs, impliments, tests, integrates and retests a system to avoid "big bang" project failures late in a project when changes are difficult and expensive to implement. Objects created and tested on the first XRAE products in 2003 are utilized today, without modification except for extending behaviors when a new product UAP revealed the need for additonal behaviors.
Numerous hardware circuits are reused and thus provide predictable and time proven device behavior. The related requirments, schematics, test plans, test results, operational descriptions are also reused along with the associated Device Driver Objects.
CONSISTENCY
RTOS defines architecture as; "Doing the same thing the same way, always."
EXAMPLE: A User Application Program (UAP) controls the operation of the LEDs on all products and is always named "UAP_LED". The UAP drawing (software schematic) is "UAP_LED.doc", the source code is "UAP_LED.c", the section documenting the UAP in DEVICE PROFILE is "UAP LED", and so on for ALL products. All UAP names start with the letters "UAP" so when viewed in the project directory they all line up in alphabetical order, simplifying locating a UAP to be reused. The source code for objects, like the Parameter Object is contained in "Parameter.c", the reusable include file is "Parameter.h" and the device specific include file naming object instances is "UAP_Parameter.h". The prior approach is used for ALL products. Remember; "You can't reuse what you can't find".
New products are created by dragging and dropping the reusable object class files and UAP files from an existing project to the new project. This repeatability and software reuse often results in the availability of the hardware prototype as the critical path. Utilizing consistency facilitates reuse; thus reducing development time and improving product quality. Reuse also results in consistent operation of these reused UAPs in different products, providing a "common look and feel" for your end customers.
Reuse of functional requirements, associated hardware, objects, UAPs, operaitonal descriptions, test plans, and test results often identifies requirements prevsiouosly ignored or un-specified. Once specified this results in elimination of common previoulsy unknown defects that reside within many existing products. XRAE reuses, refines and extends well documented existing requirements versus recreating assets from scratch for each new product. If changing behaviors results in new defects, assets are corrected, tested and documented to never be repeated.
ASSET STATUS
Asset based project management simplifies tracking and status reporting.
RTOS PROCESS EXAMPLE: Text in the Device Profile is "black" when first entered, "blue" when reviewed and after passing tests, or "red" when tested and failed. Since the Table of Contents are redundant for all devices, a quick review of the Device Profile document will quickly identify incomplete sections and where the color of each section quickly provides insight into the test status with minimal effort (time). If desired each asset is listed in a project schedule, including each object function. A reused asset has a minimal duration, primarily just enough time to review and optionally rerun existing tests. A new asset will have far higher duration's and the "accuracy of duration estimates" will be less and thus of greater risk. Thus the "time saved" by asset reuse is evident when viewing the schedule.
Priority levels are recommnded where critical assets have high priorities and where low priority and low risk assets may be deferred when lmited resources exist at the end of a project.
Various "boiler plate" project schedules exist for those whom require high levels of product testing or where insight into the "cost of quality" is desired to justify the value of "asset reuse".