Changes between Version 10 and Version 11 of LEGACY - LAMP proposal


Ignore:
Timestamp:
08/09/11 12:05:06 (13 years ago)
Author:
jeff.lusted
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • LEGACY - LAMP proposal

    v10 v11  
    2222
    2323==== Labels Webapp: ====
    24   * Number of users: 1 at any one time
    25   * Hours of use during the day: 8:00 to 17:00
    26   * Peak or sensitive periods: None.
    27   * Level of activity. Fifty transactions per week if recruiting 50 participants per week,
    28   * Quality of service:
    29     1. Speed of response: within 10 seconds.
    30     1. Speed of restore after a failure: ?
    31     1. We cannot afford to lose transactions, which would give rise to the possibility of duplicate id's.
    32   * Type of data: Transactional.
     24  (The Labels Webapp and the UIDGen have been moved to the hospital environment.)
    3325
    3426==== caTissue: ====
    … …  
    6860I'm not sure exactly what this would mean in practice. Perhaps it's just a rule of thumb. But there are important considerations behind this...
    6961
    70   * Will the live production systems (eg: Labels Webapp, caTissue, i2b2) be administered by RCS? If not BRICCS must supply the admin side of things.
     62  * Will the live production systems (eg: caTissue, i2b2) be administered by RCS? If not BRICCS must supply the admin side of things.
    7163  * The level of admin might need to vary. Take test systems. This could be Unit testing, Integration testing, or Acceptance testing. I can see this range of testing being required where the admin side of a live system is complicated. See next point.
    7264  * Whoever manages the i2b2 data warehouse (University or UHLT), the live systems cannot be administered in isolation. The two systems must be synchronized in some way. A failure on one side will have ramifications for the other.