**7.1 System assessment**

By selecting significant metrics, developers may derive their own system value that best reflects the current condition of the system state based on the type of services and its influence in the surrounding environment. We calculated the system value (SV) as a composite metric of system access rates with the accumulating perceived USI changes that emerged due to task completions over a yearly cycle. Higher demands for system usage should put more values in SV. Ideally, we'd expect a transition of T++ due to expected positive impact of any incremental development activities. However, the scenario is often not the same for real data sets.

38 Real-Time Systems, Architecture, Scheduling, and Application

For example, figure 4 shows the *normalized* data plots (for side-by-side comparison) of the last several years for three development projects for a university administrative office. These are illustrated by different services: **ADMIN-ROLES** (to manage graduate administrative roles across the campus), **ITAP** (registration and scoring system for international teaching assistant program) and **APPTRACK** (a sub-system to manage graduate applications data online). ADMIN-ROLES and APPTRACK are moderate sized projects that run throughout the year. ITAP is a comparatively smaller sized project with

Referencing the state diagram mentioned in figure 2, we can compare the variations in the system value (as the state transitions Ti in the matrix) throughout the yearly cycle. We use the changing values of accumulating Task Requests or Task Completion rates as the underlying cause, because Task completion rates have a more direct impact on the users and overall system values. We have also generated the trend lines to observe the significance of

> Year R2 sERR sigF p-V Correl. 2000 0.507 0.194 0.009 0.009 0.713 2009 0.369 0.333 0.036 0.035 0.608 2010 0.593 0.179 0.003 0.003 0.769

> Year R2 sERR sigF p-V Correl. 2000 0.707 0.185 0.001 0.001 0. 841 2009 0.656 0.218 0.001 0.001 0.810 2010 0.459 0.233 0.015 0.015 0.677

> Year R2 sERR sigF p-V Correl. 2000 0.877 0.103 0.000 0.000 0.936 2009 0.027 0.165 0.606 0.606 0.165 2010 0.837 0.121 0.000 0.000 0.915

By selecting significant metrics, developers may derive their own system value that best reflects the current condition of the system state based on the type of services and its influence in the surrounding environment. We calculated the system value (SV) as a composite metric of system access rates with the accumulating perceived USI changes that emerged due to task completions over a yearly cycle. Higher demands for system usage should put more values in SV. Ideally, we'd expect a transition of T++ due to expected positive impact of any incremental development activities. However, the scenario is often

the intersecting points (see figure 4), as well as their regression analyses in table 4.

**ADMIN-ROLES** 

**ITAP** 

**APPTRACK** 

Table 4. Regression Analyses: Task Completion (TC) vs. System Value (SV)

seasonal usage patterns.

**7.1 System assessment**

not the same for real data sets.

In comparing the accumulating rates of task completions (TC) with the rate of variations in system value (SV) in normalized plots (as shown in fig. 4), first we are interested in the intersecting points indicating that TC and SV have the same rates. Second, for the segments between the intersections, our focus is on the transition of SV. As described in the following sections we see wide variations in the patterns for different projects in respective plots.
