- Email: [email protected]
Implementation of development productivity tool into life insurance company
Implementation of development productivity tool into life insurance company P G Bassett
The implementation ~)/a development productivi 0" tool (Netron; CAP) into a liJe insurance compan)' is described. The paper looks at the corporate situation before implementation and considers the selection ~[ the tool and the three pilot projects on which the tool was evaluated. Productivity analysis results are given as a guide to the success ~f the implementation.
Fileaid and Superstructure. DMS (IBM's table-driven development environment) was used extensively, but is to be phased out, since IBM has stopped support. Before purchasing Netron/CAP, FCL did not use prototyping, code generation, or overall development productivity tools, as development productivity tools are in general neither abundant nor executed well on mainframes.
case study, so[tware development, s~?ftware tools, development productivi O'
ISD and users
CORPORATE PROFILE First Capital Life Insurance Company First Capital Life (FCL) Insurance Company (formerly E. F. Hutton Life), o f L a Jolla, CA, USA. is a subsidiary of First Capital Holdings Corp., a financial services holding company based in Los Angeles. FCL employs 600 people and distributes its products through selected broker dealers and its independent managing general agents. Its soliciting agents number more than 10 000. In 1979 FCL pioneered universal life insurance, a premium policy that allows the policy holder to choose the amount of death benefit and the amount and timing of the premium payment. By 1985, universal life products accounted for 41% of all life insurance sales industry-wide. Currently, FCL administers more than 230 000 life and annuity policies, with insurance in force totalling $18.1 billion. Total admitted assets in 1988 were $4.1 billion.
Information Services Department FCL's Information Services Department (ISD) meets the information requirements of the finance, marketing, and actuarial divisions and of policy administration. About 20% of FCL's applications arc vendor packages; thc remainder have been devclopcd inhouse. In June 1987, FCL had two IBM 3081s and a 3083, operating under MVS/XA with TSO and CICS in the production environment. Of the 62 people involved in systems development and maintenance, 26 modified and maintained vendor packages. The remainder built ncw systems and maintained and replaced FCL's existing 7 million lines of mostly Cobol codc. FCL uses a number of tools, including Abendaid, Netron, Inc., 99 St Regis Crescent North, Toronto, Canada M3J IYg. Paper submitted: 19 July 1989. Revised version received:22 December 1989.
370
ISD's user base numbers about 500, with a group in each company area responsible for prioritizing requests for new systems and system enhancements. 1SD works with this user community to define the users" business needs, then decides whether a vendor package is appropriate or if the system should be developed inhouse. FCL evaluates end-user needs to determine systems needs. Once individual projects have been defined, FCL canvasses the market to determine whether a third-party vendor package exists that addresses these needs. Vendor packages are then evaluated on the basis of the degree to which they fit defined needs and their degree of integration with existing systems at FCL. If no vendor package can be found to match the defined needs, or if a strong business case can be made for developing a customized system, the application is developed inhouse. Due to the specialized nature of insurance transactions, the current ratio ofinhouse development to vendor packages is 4:1. Before FCL purchased Netron CAP, inhouse system development began with a requirements gathering process that FCL characterized as "traditional, informal, and relatively unstructured.' FCL's previous developmcnt cycle was characterized by classic developer/user alienation. As a result, systems specifications were often out of sync with the users' real requirements. FCL now plans to design most systems using Netron/CAP in design workshops. In these workshops, the system developcr(s) and users work together in one room on screen and report design and system navigation. The developer uses Netron/CAP to build working prototypes on which the users provide feedback. In most cases, design changes are made immediately, during the sessions. (For more details, see the section 'CFO Online project'.)
INITIAL NETRON/CAP IMPLEMENTATION Selection of Netron/CAP In late 1986, planned development was measured against existing resources, and FCL came up 30 programmers
0950-5849/90/050370-08 ~ 1990 Butterworth-Heinemann Ltd
information and software technology
short. In addition, older, home-grown systems were requiring progressively more maintenance. The time and expense required to increase staffsignificantly led FCL to look tbr a productivity tool to speed development and reduce future maintenance. A survey of development productivity tools was carried out, and Netron;'CAP was selected, due to its portability, code reuse, ease of modification, and open architecture. After investigating Netron/CAP's technology and talking with other Netron/CAP users, FCL cvaluated Netron/CAP and produced a business case based on statistics from the evaluation. The objectives of the evaluation included:
Three developers worked on mainframe terminals and two on PCs. FCL developers generally work on the mainframe: however, FCL also wanted to determine Netron/CAP's capabilities on PCs. For the three-month project period, the developers worked in an isolated training room with the Netron consultant. This enabled them to benefit from each other's experiences and easily share solutions to common problems. The isolation also removed the group from most outside interruptions, allowing them to remain focused on using Netron/CAP.
• evaluate effectiveness of Nctron/CAP • determine implementation requirements, including training, support, hardware, the learning curve, and developer reaction • gather information for a purchase justification.
The initial implementation of Nctron. CAP at FCL had two distinct management flows, one focused on project management, the other on Netron/CAP implementation. Because the three pilot projects represented both an evaluation of Netron C A P and the development of three real and critical systems, it was felt that separating management of the two functions was necessary. As in all business situations, it would have been easy to become ~.rapped up in the logistics of delivering each systcm and lose sight of the larger goal of implementing Netron. CAP in a logical manner.
Initial projects FCL chose to evaluate Netron:'CAP on three projects, developed concurrently over three months. All projects wcrc high priority and would positively impact FCL's immediate systems needs. The three projects addressed three common development activities: new development (project A), re-engineering (project B), and enhancemcnts to an existing system (project C). Any development productivity tool purchased by F C I would have to handle each of these activities. The three-project pilot was therefore seen as a valid and necessary test. Project A was a new system with well defined functional specifications and was needed as soon as possible. In addition, FCL believed it was highly appropriate as developing online components was an important part of the system development. Project B converted a conversational CICS application to pseudo-conversational style. FCL wanted to modularize the system and improve its performance. Project C added extensive online capabilities to a batch system. The online "front-end' was to be used by more than 50 people and was needed as soon as possible.
Developers FCL recognised, on the basis of past performance, that most of its developers would initially be sceptical of Netron/CAP. The first trainees, all experienced analysts, were selected by a number of characteristics: • • • •
interest in using new tools or new technology analytical background tendency to approach their work in innovative ways familiarity with the type of system to be developed (e.g., CICS knowledge for Project B, knowledge of the batch system behind the online component to be developed for Project C) • availability
Development environment Netron/CAP was installed on FCL's mainframe. Concurrently, a Netron education and technical consultant gave the trainees one week of formal training on personal computers. The projects began immediately afterwards.
vol 32 no 5 june 1990
Project and implementation management
System developmentmanagement Each developer completed weekly project status reports and reported to a project leader, who monitored the project, using a plan that outlined project steps, and issues and concerns that could affect progress. The project leader reported to the Vice-President of Systems Development Services.
Implementationmanagement Also reporting directly to the Vice-President was the Netron;CAP Implementation Coordinator, responsible for managing the evaluation and implementation of Netron/CAP. The Coordinator tracked the progress of the individual projects to prevent or solve problems that could compromise the Netron/CAP evaluation. He advised and consulted with thc individual project developers, project leaders, FCL management, and Netron. He also had the authority to requisition operations resources and technical support. In addition, the Coordinator met bi-weekly with the Vice-President of Systems Development Services and Netron representatives. As a group, they reviewed project schedules and discussed the potential and actual impact of technical, personnel, and future implementation issues. They discussed how the developers were progressing through the Netron/CAP learning curve, and the potential use of a frame engineering group.
Focus on function This matrix management allowed those involved in either development or implementation to remain highly focused. The developer and his project leader could concentrate on the project, knowing that another person was directly responsible for issues related to the new technology. The Implementation Coordinator controlled the implementation without worrying about day-to-day details of project development.
371
Table 1. Summary of project developmentstatistics
Table 2. Summary of project results
Project
No of developers Duration of measurement period (weeks) No of Netron/CAP programs Generated LOC* Estimate for traditional LOC/day Netron/CAP LOC/day SPC LOC' SPC as proportion of generated LOC (%) Design time: Estimate for traditional methods (h) Actual with Netron/CAP (h) Actual as proportion of estimate (%) Design speed (times faster than traditional approach) Development time," Estimate for traditional methods (h) Actual with Netron,CAP (h) Actual as proportion of estimate (% I Development speed (times faster than traditional approach) Estimated cost savings ($)' Estimated time savings (months)
Cost savings
Elapsed months ahead of schedule
A
$102 000
B C
$ 17 000 $ 26 000
4.5 2.0 3.5
Total
$145 000
10.0
NETRON/CAP ANALYSIS
PRODUCTIVITY
Overview FCL measured its developers' productivity with Netron/ CAP for 10 weeks, the time allocated for project completion. It evaluated Netron/CAP on productivity and time and cost savings (see Table 1). The software development estimating package. CAEstimacs, was used to standardize and normalize baseline time estimates. Cost savings were calculated using a fully burdened hourly rate that reflected estimated ISD personnel and overhead costs. Lines of code was selected for productivity measurement. Both CA-Estimacs and lines of code were standards already in place, and thus pilot project results could be compared with previous development efforts.
Individual project s u m m a r i e s Project A was a proprietary time and resource management system providing online data entry and inquiry services, plus comprehensive batch reporting capabilities. More than 20 screens and 100 reports were involved. During the project, the three-person development team built custom frames. One embodies special file search capabilities to locate resource information; another contains data consolidation processes for generating reports. Project B was a one-person project upgrading an existing system that processes and reports on projections to a client's portfolio. It now runs more efficiently. (Conversions from conversational to pseudo-conversational CICS programs are inherently more efficient (requiring less machine time).) Project C (CFO Online system update) created an online front-end to an existing batch system. Design was completed in 23% of the estimated time. The Project Coordinator reported, "From a technical, internal design standpoint, frames provided the entire architecture for the online system." FIVE-YEAR
BENEFITS
ANALYSIS
FCL performed a benefits analysis to determine the longterm impact of Netron/CAP on development productivity and future systems maintenance, based on Netron/ CAP productivity analysis (summarized in Table 2) and projected future development activities. Based on pilot project results and projected development activity, FCL determined that it could proceed with an incremental introduction of Netron/CAP and train 20 programmers over five years. (Netron/CAP is best taught through a master/apprentice relationship between experienced users and novices.) For the purposes of the
372
5 It) 55 152 763 250 844 16 344 10.7 460 104 23 4.4 4 594 1 357 30 3.4 145 000 10.0
I.OC - lines ol'codc *Includes comments, data descrlpUons, and procedural ethic 'lnclude~. hand-~rllten (_'ob~fl and Nelron CAP c o m m a n d s :Includes cxlcrnal and mlcrnal design, applicable to Project ( ' onl) qncludes coding, unit It'Sllng, and development of reqmred test data ' Based on F('I "s full) burdened ralc
analysis, FCL assumed that Netron/CAP would be used for new development and maintenance of Netron/CAPdeveloped applications only. The remaining staff will continue to use traditional methods to enhance and maintain: • vendor packages • systems that are being phased out • service requests without sufficient business case to warrant a rewrite using Netron/CAP
Analysis and m e t h o d o l o g y The analysis indicates that over five years, 20 developers using Netron/CAP will be 450% more productive than they would be using traditional development methods. FCL used years of development as their measurement unit, calculated as follows: for each person-year available, subtract the portion of time estimated spent on non-development activities ('overhead' and maintenance). The result is the number of years avaihible for development. When Netron/CAP is used, the figure is further broken into development activities (design, programming, and 'project other'), and time available for each activity is factored by Netron/CAP productivity rates as determined in the productivity evaluation. The total is the number of development years possible with Netron/CAP. (For more details on the model, see Appendix !.)
Effect on development The effect of increased development productivity and reduced maintenance, produced by 20 developers using Netron/CAP for five years, is 143 years of development. Twenty developers using traditional methods for five years would generate 26 years of development. The net
information and software technology
6O I~---~]
]
Traditional Met hoda
>30
• Netron/CAP will allow FCL to replace old systems faster than is possible using traditional methods. • Maintenance of Netron/CAP programs is projected to be substantially less than that required for programs developed without it, largely because of the size and structure of the SPC, where all maintenance is performed.
20
CFO ONLINE PROJECT I0
0
Figure 1. Reduction in required maintenance.for 20 developers over.five years (net reduction in maintenance years represents sa ring of $1.7 m i/lion) 160 140 / 120 -
-
100 -
-
80 . . . . . . . . 60 40
-
..........
20 . . . . . . . 0 -
-
Figure 2. Development output[or 20 developers over.five rears (net increase in development )'ears represents $10.24 million ) gain of 117 years with Netron,'CAP represents a 450% increase in productivity, or $10 million of development. Figures 1 and 2 show Netron/CAP's impact on the development activities of 20 developers.
Effect on maintenance FCL estimatcs that maintenance activities (which include old system rcwrites) will be reduced 40% overall because:
,¢- .,,,,.,.,,......,..... ,~
Project C was an online front-end to CFO (Consolidated Functions Ordinary). CFO is a batch system of about 450 main programs, which processes more than 150 000 insurance policies. It was built in 1962. CFO Online allows transactions to be entered, edited, and validated online. Previously, policy information forms were filled out and passed to data-entry personnel who keyed the information. This data file (an 80-byte card) was then put into a batch cycle where they were then processed overnight on the mainframe. CFO Online does not affect the structure or flow of the batch CFO system (see Figure 3). Temporary files are updated during these online sessions; master file updating is done with the nightly batch run. Based on the sum of the estimated costs ot" performing functions eliminated or streamlined through more efficient programs, FCL estimates that eliminating form processing and data entry, and reducing the time required to input information and correct errors, will save over $125 000 per year.
Functional scoping Before CFO Online was selected as a Netron/CAP project, representatives of the CFO user base outlined 50 functions they required. Then, in conjunction with ISD, they selected II high-priority functions to be implemented first, including handling premium payments, status requests, name and address changes, and transaction generation. Using CA-Estimacs, one staff year was estimated for development using traditional methods.
_
I
Coovo.er/
I
_
r I
Batchor
I
r [Vtaffsa~tion I
- I
I Bato.es
I
CFO Online
T
1
t
Figure 3. CFO s)'stem flow chart
vol 32 no 5 june 1990
373
Functional design Following Netron/CAP installation and training, seven users, the Netron/CAP developer, and the Netron/CAP Implementation Coordinator met in a series of application design workshops. The workshops totalled 18 hours and spanned about two weeks. During the workshops, the users and ISD refined the original system requirements. They discussed specific accounting functions to be accommodated, screen functionality, reports, and inquiry and browsing capabilities. To provide a basis for discussion, the developer built 13 screens with Netron,'CAP before the workshops. These screens were modelled on the forms the users used at the time. During the application design workshops, the team worked to simplify screens. The users were accustomed to thinking of and performing functions in terms of forms and account numbers. By modifying the screens to use business terminology, the team was able to replace eight forms, representing 18 CFO transactions, with six online functions. For example, the "Make a reversal to Returned Money. and balance to Over/Short' transaction was represented on the screen by one code. Selecting that
S
riret
Ca~*l
Screen D Feb 10 a5 3:47 pm
Life
PAYMIffCTSlLEVERSAL.51MISCgLLAMZOU3
A B C D
-
W.L'W£XSALS t o : ~ - Holding I - R e t u r n e d Boney J - uoldin| and Over/short (NTO) K Retu=ned Boney, balance t o O / S
PHMIUM PAYIdJ[HTS f r o e : Holdlnf Holding and Over/Short H o l d i n g and D i v i d e n d s H o l d i n g , balance t o o v e r / S h o r t
LOA/q PAYMZNTS f r o m : E - Holding • - H o l d i n g and O v e r ~ S h o r t G - HoXdlDf. belence to Over/Short Pollcy:
02.55TOS00M
UNsuspended
o.....
o....
MISCELLANEOUS L - F r o m H o l d i n l f t o Returned M o n e y M - TO r e c o r d r e t u r n e d Boney
PDTO:
0 3 15 1 8
S t a t u s Xeq:
code can cause the system to perform up to 16 separate accounting activities. After entering dollar figures and selecting an action code, the user can process the transaction immediately, or access a second screen to edit the individual accounting activities the computer will execute (see Figure 4). When the user is satisfied with the activities the computer will perform, the transaction can be processed without returning to the first screen.
Application design with Netron/CAP In the first application design workshops, the design team decided to use business terminology instead of form and account numbers on the screens. They prototyped these screens with Netron/CAP. decided on menu and screen sequences and function key definitions, and defined validations and help messages. Before the next sessions, the developer built the SPCs to drive the screens. This type of iterative development process is designed to eliminate the kinds of problems that can result from end-user/developer alienation.
Design results The highly functional, user friendly CFO Online system was designed in less titan 25% of the time estimated for traditional methods. This was attributed to Netron.. CAP's screen and system modelling capabilities combined with the application design workshops. The interactive nature of the workshops provided a forum for discussing user needs and sharing systems expertise. The resulting front-end system focuses on business requirements, reducing the users' need to understand CFO technical requirements.
Y
ogtion: . . . . .
~mt
4o
S~L[CT S I ~ I D
Development with Netron/CAP
,
54 (enter) 2 - Process 5 - Vi~IEdit
OPTION:
PBtB • o f
/
--
2
•lrwt
5 - Prey Menu
Capital Life CFO
PP.I~MIUMS/ILEVERSALSIMISC~LLA)#[OU5
Number: Mode : ~e _2 2 -5 --5
025|7S$OOM ~ s u e p e t~ d e d
Payor:
5
85 55 55 SS
Status Req:
TEAMSACTIONS
sc~reen D[~ ~ Feb 10 $| 3:4T
ALITA LYON
Insured :
D~te I5 15 15 15
-
I0 -
Y
Entry
Date
TrKns
_2 0 , 2 _S _Z 1 0 _2 10
55 55 S5 8S
2002 290x 200= 2991
Total:
S[LECT OPTION: -(enter) Ip 2 - PrOcess
Debit
Credit 45.00
45.0~ 5 4 . 0 0
- St.00
9S,O0 5 - ~rO s BUD
9 - Prey
Entry
Code
! 1 1
1
9g,O0 Menu
10 -
Figure 4. Sample CFO online screens. Pressing F3 from top screen gives the bottom screen, where verification of and~or modification to default accounting transactions can be performed.
374
After the design workshops, the developer began implementing the designs (see Figure 5). He found that CAPframes provided a 'working technical solution" to the system. The developer also built his own frames to maximize reusability. Six custom frames embody file definitions and standard FCL routines. Another allows Netron. CAP programs to access FCL's security system. Netron/CAP's open architecture is designed to allow developers to create function-specific code segments (frames), which can be reused to provide uniform solutions to common programming problems. For example, a developer may choose to write a frame to perform a standard function. This same frame can then be incorporated into the program (or into another program) wherever that function needs to be performed. The developer then needs to maintain only a small segment of code to perform functions throughout the program or throughout a number of programs. (See Appendix 2.)
Development results CFO Online, including acceptance testing, training, and implementation, was completed in 5.5 months, 3.64 calendar months ahead of schedule (see Table 3).
information and software technology
CFO Online Processing Main
"a L^ 'ess / ] Mo . C. +s t
Direct Payments
Menu
~] I Misc.Accoualtblgl SuspIMldlh Payments Reversals
I
t I P/RIM i Transactlong
Note:
Transaction
Batch
/
Summary
Tr ansactlon
All screens have direct "Go-to" capability.
b'igure 5. CFO Online system ,vtrueture
Table 3. Summary of CFO Online project data
Maximizing benefits of new technology
No of CFO system users 50 + No of system uscrs involved in CFO Onlinc design 7 No of system developers 1 Years of experience 8 Position Senior programmer..analyst
FCL believes that rapid development of quality systems is critical to the success of any project. The volatile nature of the insurance industry requires that companies be able to 'turn on a dime'. Rapid development ensures that systems are not made obsolete even before they are delivered and allows the company to react quickly to emerging trends. FCL used several approaches in conjunction with Netron/CAP that allowed ISD to deliver C F O Online in less than six months.
Ten weeks after Netron.CAP training, the Implementation Coordinator collected and analyzed CFO Online project data. The following summarizes the rcsults. No of Nctron/CAP SPCs Generated LOC SPC LOC SPC as proportion of generated LOC (~/o) Cost savings ($) Time savings (calendar months) Design time Estimate for traditional means (h) Actual with Netron..CAP (h) Actual as proportion of estimate (%) Nctron/CAP design rate (times faster than traditional approachl Development time Estimate for traditional means (h) Actual with Netron..CAP (h) Actual as proportion of estimate (%) Netron/CAP development rate (times faster than traditional approach)
9 27 171 3 521 13 26 595 3.64 460 104 23 4.4 881 290 33 3.0
CFO Online was implemented five months after the developer's Netron/CAP training. At that time, the system was composed of the following: SPCs Screens Reports Custom procedure division frames Custom file definition frames Total No of program modules
vol 32 no 5 june 1990
12 12 2 9 4 39
Design In the design phase. FCL reduced C F O Online's elapsed time to implementation with two techniques: progressive implementation and application design workshops. In conjunction with ISD the C F O Online system users decided that the C F O Online project should be implemented in three phases. With progressive implementation, the end-users received their high-priority items quickly, while the developer could concentrate on well defined specifications for a subset of the entire system. The application design workshops also reduced elapsed time to implementation. The interactive nature of this design process meant that the users and developer worked closely and communicated effectively. As a result, the users were highly satisfied with C F O Online, which was designed in 23% of the traditional design estimate.
Development FCL's 10-week Netron/CAP productivity analysis showed the C F O Online project was developed in 33% of the traditional estimate. The combination of design and development time savings meant C F O Online was completed 3.64 calendar months ahead of schedule, saving FCL $26 000 in development costs.
375
APPENDIX
1. F I V E - Y E A R
MODEL
~s
Year 1
2
3
Person-years available' 14.00 20.00 20.00 Non-development requirements (in years) Overhead: 2.80 4.00 4.00 New maintenance ~ 0 .81 1.96 Old maintenance a 4.20 5.27 4.24 Actual years available for developmenP 7.00 9.92 9.80 Years possible with N e t r o n / C A P (by activity)" Design 6.19 8.77 8.67 Programming 14.22 20.14 19.90 Project other 1.40 1.98 1.96 Development years possible with N e t r o n / C A W 21.81 30.89 30.53 Total years possible with N e t r o n / C A P ~ 28.81 40.98 40.73 Total development years possible with N E T R O N , ' C A P over five years 143.18
4
5
20.00
20.00
4.00 3.10 3.22
4.00 4.22 2.2 I
9.68
9.57
8.56 19.66 1.94
8.46 19.42 1.91
30.16
29.79
40.48
40.22
Design Programming Project other
...? . . , . , \.,...? ,,),.,,,, ,,...., .,?., ,.:. ?.. ,., ?,?.,, ,. ~ ' ;
2 0 . , . , ..,...;,, ....
========================Programming == ::::::::::::::::::::::::::::::::::::::::: ~?? i: ",.,,.,~,-, ~.',? ,.., ,, ,,.~,.,-,.,.-.-,,..., . , , . , ,,, .,.~......,~.,.,.
"V,\" \ "-,....... "-."", -,N" ",'-" ' ",- \ . b ", . " . -, .t.,............. \ \ -,,',.,.. - . -.,-, , . r \ ". . , . , x .,. "-t.. ", " . " , ~ ." . .
Proportion
Productivity factor
20% 60% 20°/,,
4.4 3.4 N.,A
Programming includes coding and unit and system testing. Project other includes project management; project, system, and user documentation; user acceptance; conversion planning; implementation. ~Development years possible with Netron/CAP: sum of figures for each activity in 'Years possible with N e t r o n / C A P (by activity)'. "Total years possible with Netron/CAP: sum of 'Development years possible with N e t r o n / C A P ' and "Non-development requirements (in years)'. 9Total development years possible with N e t r o n / C A P over five years: sum of yearly total of 'Development years possible with Netron/CAP'.
376
25
,..-..,~,.-.," ~:, .:,,\ "-,'..-.,\',. \ .
In designing the five-year model, FCI, made the following assumptions about its development and used the following formulas for calculation: 'Person-years available: FCI, projccted that 14 people would use N e t r o n / C A P in the first year; 20 in subsequent years. -'Overhead: 20% of "Person-years available' will bc spent on overhead activities. Overhead includes general meetings, nonproject duties, and personal time off. ~New maintenance: F C L used CA-Estimac's conclusion that maintenance equals four times the development time. projected over seven years. In addition, as maintenance of Netron."CAPdeveloped programs is performed on the SPC. which was found to be an average of less than 11% of the size of the application, the formula used to calculate new maintenance is: ( N E T R O N / C A P Programming [from previous year] * 417) * 10% ~Old maintenance: FCL estimates that 30% of "Person-years available' will be spent maintaining old systems. The formula used to derive the old maintenance requirement assumes that 70% of the previous year's programming replaced old systems (thus reducing old maintenance in the long term). SActual years available for development: calculated as: Person-ycars available - [Overhead + New maintenance and Old maintenance]. ~Years possible with N e t r o n / C A P (by activity): To calculate these figures, F C L divided 'Real ycars available for development' into activities and multiplied them by the productivity rates determined in the productivity analysis: Activity
Actual Year,= Available
o
Year 1
I
Year 2
Year 3
Year 4
Year 5
Figure 6. Division of activities o/ Netron;CA P developers over .five years This graph shows activity breakdown of Netron.('AP developers o,,er tNe-year analysis period. Note that 14 developers are available in Year I and 20 in following years. • Overhead: remains constant at 20% • Old maintenance: decreases as new systems built with Netron..CAP replace old ones. . New maintenance: increases as new systems arc built with Nctron: CAP. • l)cvclopment: is time remaining after Overhead and Nev, and Old maintenance requirements are subtracted. 25
20
Actual Years Available 15
10
0
Year 1
Year 2
Year 3
Year 4
Year 5
bTgure 7. Number of development years available with Netron/CA P by activity This graph shows development productivity of Netron/CAP developers over five-year analysis period. To determine productivity with Netron/CAP, actual development years from Figure 6 are broken down into activities and multiplied by productivity rate determined in productivity analysis. • Project other: is constant 20% of each year's actual development years. • Design: is 20% of each year's actual development years * 4.42 (design productivity rate). • Programming: is 60% of each year's actual development years * 3.39 (programming productivity rate).
in|brmation and software technology
APPENDIX
2. W H A T A R E F R A M E S ?
Frames are formal metaphors. A metaphor captures things that arc the same about things that are different. For example, the metaphor 'a plane is like a bird" points clearly to a 'framework' of properties common to many different flying things. On the other hand, to adapt a bird into a plane requires some properties to be altered: replace the feathers, prohibit wing flapping, add an engine, and so on. What alters the properties of a frame? Other frames! A bird frame, describing a prototypical bird, could have its properties extended and modified by duck frames, or even griffin frames. This adaptability is crucial: the power of metaphors is their applicability to novel situations, such as griffins. What do mctaphors have to do with software? Sot)ware metaphors express things that are similar about programs that are different. The word metaphor may not be part of the software jargon, but entity and function types are well known kinds of software metaphors. Familiar entity-types include inventory, customer, order, and supplier, function-types include screen 1/0, batch updates, credit checks, and interest calculations. Such types are common to many programs. Programmers implicitly use same-as, except metaphors: 'this program is the same as that one, except for this and except for that.' A (software engineering) frame is a same-as, except combination of one or more data Tunction types. A program (or any software module) is a same-as, except combination of one or more frames. Frame technology provides the multiple inheritance of object-oriented programming combined with the ability not only to add new features, but to modify and delete at any level of detail. One program, for example, may enter orders, update customer information, and calculate interest on deposits. One frame hierarchy will be able to assemble this program from a same-as, except combination of quite different frame types, each with a disparate sub-hierarchy. Frame technology reflects a paradigm shift in the understanding of software reusability. The breakthrough stems from being able to handle differences as well as similarities in what is reused. It has been employed with multiple programming languages as well as in the production of manuals. Frames have various degrees of reusability. Some will be used in many programs. For example, a Divisions frame should occur in every Cobol program. On the other hand, each SPC (Specifications) frame usually specifies a single program. Frame technology formalizes the specification and composition of frames. A Bassett-frame contains two things:
• (i) a standard definition of its entity-/function-types • (ii) engineering change commands
vol 32 no 5 june 1990
(i) expresses the similarities that are available to all instances of use; (ii) expresses the differences that are peculiar to each instance of use. Data-entry, for example, does not refer to a specific program, but to an infinite class of programs that share a standard set of properties: buffers and protocols for screen and error handling. Such properties comprise a standard definition in a reusable data-entry frame. Given specific and reusable frames, the computer can assemble any of an infinite class of programs. Frames adapt frames through engineering change commands, also called frame commands. Each command can assign or reference frame parameters (properties). If an adaptor frame does not assign a value to the parameter, the adaptee frame's default standard value is used. In other words, only the differences are expressed; differences peculiar to each adaptor frame are expressed as part of the adaptor frame.
SPC (Specif~tiotl Frame)
i
]
I
Workstation frame I/0 i
i
Message declarations ] frame ,
frame /
frame |
]
, handling frame
frame [ Filel/0 i
Layout
I
Screenframel/O
Figure 8. Examph" li'ame hierarchy Frames are organized into hierarchies (see Figure 8). At the top of the hierarchy is a specification frame (called the SPC). The SPC specifies one program or software module. SPCs are special because they are the only frames that application developers may create or modify. All other frames are read-only. The further from the top, the more general is the frame type and the more reused the frame. Each reuse instance is independent of the others. Each frame can be the root of its own hierarchy and is its "boss'. Being the boss means it has the final say in how any frame in its hierarchy is to be adapted for its purposes. That is, the boss prevails over all subordinate frames in assigning a value to a frame parameter. Of course, the boss may have bosses too. In particular, the boss of an entire hierarchy is the SPC. Its hierarchy is processed into tailored results, such as a custom program. Any software system can be constructed from frames. Most of the complexity can be hidden in reusable frames, making complex systems easier to design and, particularly important, easier to adapt to changing needs.
377
The implementation ~)/a development productivi 0" tool (Netron; CAP) into a liJe insurance compan)' is described. The paper looks at the corporate situation before implementation and considers the selection ~[ the tool and the three pilot projects on which the tool was evaluated. Productivity analysis results are given as a guide to the success ~f the implementation.
Fileaid and Superstructure. DMS (IBM's table-driven development environment) was used extensively, but is to be phased out, since IBM has stopped support. Before purchasing Netron/CAP, FCL did not use prototyping, code generation, or overall development productivity tools, as development productivity tools are in general neither abundant nor executed well on mainframes.
case study, so[tware development, s~?ftware tools, development productivi O'
ISD and users
CORPORATE PROFILE First Capital Life Insurance Company First Capital Life (FCL) Insurance Company (formerly E. F. Hutton Life), o f L a Jolla, CA, USA. is a subsidiary of First Capital Holdings Corp., a financial services holding company based in Los Angeles. FCL employs 600 people and distributes its products through selected broker dealers and its independent managing general agents. Its soliciting agents number more than 10 000. In 1979 FCL pioneered universal life insurance, a premium policy that allows the policy holder to choose the amount of death benefit and the amount and timing of the premium payment. By 1985, universal life products accounted for 41% of all life insurance sales industry-wide. Currently, FCL administers more than 230 000 life and annuity policies, with insurance in force totalling $18.1 billion. Total admitted assets in 1988 were $4.1 billion.
Information Services Department FCL's Information Services Department (ISD) meets the information requirements of the finance, marketing, and actuarial divisions and of policy administration. About 20% of FCL's applications arc vendor packages; thc remainder have been devclopcd inhouse. In June 1987, FCL had two IBM 3081s and a 3083, operating under MVS/XA with TSO and CICS in the production environment. Of the 62 people involved in systems development and maintenance, 26 modified and maintained vendor packages. The remainder built ncw systems and maintained and replaced FCL's existing 7 million lines of mostly Cobol codc. FCL uses a number of tools, including Abendaid, Netron, Inc., 99 St Regis Crescent North, Toronto, Canada M3J IYg. Paper submitted: 19 July 1989. Revised version received:22 December 1989.
370
ISD's user base numbers about 500, with a group in each company area responsible for prioritizing requests for new systems and system enhancements. 1SD works with this user community to define the users" business needs, then decides whether a vendor package is appropriate or if the system should be developed inhouse. FCL evaluates end-user needs to determine systems needs. Once individual projects have been defined, FCL canvasses the market to determine whether a third-party vendor package exists that addresses these needs. Vendor packages are then evaluated on the basis of the degree to which they fit defined needs and their degree of integration with existing systems at FCL. If no vendor package can be found to match the defined needs, or if a strong business case can be made for developing a customized system, the application is developed inhouse. Due to the specialized nature of insurance transactions, the current ratio ofinhouse development to vendor packages is 4:1. Before FCL purchased Netron CAP, inhouse system development began with a requirements gathering process that FCL characterized as "traditional, informal, and relatively unstructured.' FCL's previous developmcnt cycle was characterized by classic developer/user alienation. As a result, systems specifications were often out of sync with the users' real requirements. FCL now plans to design most systems using Netron/CAP in design workshops. In these workshops, the system developcr(s) and users work together in one room on screen and report design and system navigation. The developer uses Netron/CAP to build working prototypes on which the users provide feedback. In most cases, design changes are made immediately, during the sessions. (For more details, see the section 'CFO Online project'.)
INITIAL NETRON/CAP IMPLEMENTATION Selection of Netron/CAP In late 1986, planned development was measured against existing resources, and FCL came up 30 programmers
0950-5849/90/050370-08 ~ 1990 Butterworth-Heinemann Ltd
information and software technology
short. In addition, older, home-grown systems were requiring progressively more maintenance. The time and expense required to increase staffsignificantly led FCL to look tbr a productivity tool to speed development and reduce future maintenance. A survey of development productivity tools was carried out, and Netron;'CAP was selected, due to its portability, code reuse, ease of modification, and open architecture. After investigating Netron/CAP's technology and talking with other Netron/CAP users, FCL cvaluated Netron/CAP and produced a business case based on statistics from the evaluation. The objectives of the evaluation included:
Three developers worked on mainframe terminals and two on PCs. FCL developers generally work on the mainframe: however, FCL also wanted to determine Netron/CAP's capabilities on PCs. For the three-month project period, the developers worked in an isolated training room with the Netron consultant. This enabled them to benefit from each other's experiences and easily share solutions to common problems. The isolation also removed the group from most outside interruptions, allowing them to remain focused on using Netron/CAP.
• evaluate effectiveness of Nctron/CAP • determine implementation requirements, including training, support, hardware, the learning curve, and developer reaction • gather information for a purchase justification.
The initial implementation of Nctron. CAP at FCL had two distinct management flows, one focused on project management, the other on Netron/CAP implementation. Because the three pilot projects represented both an evaluation of Netron C A P and the development of three real and critical systems, it was felt that separating management of the two functions was necessary. As in all business situations, it would have been easy to become ~.rapped up in the logistics of delivering each systcm and lose sight of the larger goal of implementing Netron. CAP in a logical manner.
Initial projects FCL chose to evaluate Netron:'CAP on three projects, developed concurrently over three months. All projects wcrc high priority and would positively impact FCL's immediate systems needs. The three projects addressed three common development activities: new development (project A), re-engineering (project B), and enhancemcnts to an existing system (project C). Any development productivity tool purchased by F C I would have to handle each of these activities. The three-project pilot was therefore seen as a valid and necessary test. Project A was a new system with well defined functional specifications and was needed as soon as possible. In addition, FCL believed it was highly appropriate as developing online components was an important part of the system development. Project B converted a conversational CICS application to pseudo-conversational style. FCL wanted to modularize the system and improve its performance. Project C added extensive online capabilities to a batch system. The online "front-end' was to be used by more than 50 people and was needed as soon as possible.
Developers FCL recognised, on the basis of past performance, that most of its developers would initially be sceptical of Netron/CAP. The first trainees, all experienced analysts, were selected by a number of characteristics: • • • •
interest in using new tools or new technology analytical background tendency to approach their work in innovative ways familiarity with the type of system to be developed (e.g., CICS knowledge for Project B, knowledge of the batch system behind the online component to be developed for Project C) • availability
Development environment Netron/CAP was installed on FCL's mainframe. Concurrently, a Netron education and technical consultant gave the trainees one week of formal training on personal computers. The projects began immediately afterwards.
vol 32 no 5 june 1990
Project and implementation management
System developmentmanagement Each developer completed weekly project status reports and reported to a project leader, who monitored the project, using a plan that outlined project steps, and issues and concerns that could affect progress. The project leader reported to the Vice-President of Systems Development Services.
Implementationmanagement Also reporting directly to the Vice-President was the Netron;CAP Implementation Coordinator, responsible for managing the evaluation and implementation of Netron/CAP. The Coordinator tracked the progress of the individual projects to prevent or solve problems that could compromise the Netron/CAP evaluation. He advised and consulted with thc individual project developers, project leaders, FCL management, and Netron. He also had the authority to requisition operations resources and technical support. In addition, the Coordinator met bi-weekly with the Vice-President of Systems Development Services and Netron representatives. As a group, they reviewed project schedules and discussed the potential and actual impact of technical, personnel, and future implementation issues. They discussed how the developers were progressing through the Netron/CAP learning curve, and the potential use of a frame engineering group.
Focus on function This matrix management allowed those involved in either development or implementation to remain highly focused. The developer and his project leader could concentrate on the project, knowing that another person was directly responsible for issues related to the new technology. The Implementation Coordinator controlled the implementation without worrying about day-to-day details of project development.
371
Table 1. Summary of project developmentstatistics
Table 2. Summary of project results
Project
No of developers Duration of measurement period (weeks) No of Netron/CAP programs Generated LOC* Estimate for traditional LOC/day Netron/CAP LOC/day SPC LOC' SPC as proportion of generated LOC (%) Design time: Estimate for traditional methods (h) Actual with Netron/CAP (h) Actual as proportion of estimate (%) Design speed (times faster than traditional approach) Development time," Estimate for traditional methods (h) Actual with Netron,CAP (h) Actual as proportion of estimate (% I Development speed (times faster than traditional approach) Estimated cost savings ($)' Estimated time savings (months)
Cost savings
Elapsed months ahead of schedule
A
$102 000
B C
$ 17 000 $ 26 000
4.5 2.0 3.5
Total
$145 000
10.0
NETRON/CAP ANALYSIS
PRODUCTIVITY
Overview FCL measured its developers' productivity with Netron/ CAP for 10 weeks, the time allocated for project completion. It evaluated Netron/CAP on productivity and time and cost savings (see Table 1). The software development estimating package. CAEstimacs, was used to standardize and normalize baseline time estimates. Cost savings were calculated using a fully burdened hourly rate that reflected estimated ISD personnel and overhead costs. Lines of code was selected for productivity measurement. Both CA-Estimacs and lines of code were standards already in place, and thus pilot project results could be compared with previous development efforts.
Individual project s u m m a r i e s Project A was a proprietary time and resource management system providing online data entry and inquiry services, plus comprehensive batch reporting capabilities. More than 20 screens and 100 reports were involved. During the project, the three-person development team built custom frames. One embodies special file search capabilities to locate resource information; another contains data consolidation processes for generating reports. Project B was a one-person project upgrading an existing system that processes and reports on projections to a client's portfolio. It now runs more efficiently. (Conversions from conversational to pseudo-conversational CICS programs are inherently more efficient (requiring less machine time).) Project C (CFO Online system update) created an online front-end to an existing batch system. Design was completed in 23% of the estimated time. The Project Coordinator reported, "From a technical, internal design standpoint, frames provided the entire architecture for the online system." FIVE-YEAR
BENEFITS
ANALYSIS
FCL performed a benefits analysis to determine the longterm impact of Netron/CAP on development productivity and future systems maintenance, based on Netron/ CAP productivity analysis (summarized in Table 2) and projected future development activities. Based on pilot project results and projected development activity, FCL determined that it could proceed with an incremental introduction of Netron/CAP and train 20 programmers over five years. (Netron/CAP is best taught through a master/apprentice relationship between experienced users and novices.) For the purposes of the
372
5 It) 55 152 763 250 844 16 344 10.7 460 104 23 4.4 4 594 1 357 30 3.4 145 000 10.0
I.OC - lines ol'codc *Includes comments, data descrlpUons, and procedural ethic 'lnclude~. hand-~rllten (_'ob~fl and Nelron CAP c o m m a n d s :Includes cxlcrnal and mlcrnal design, applicable to Project ( ' onl) qncludes coding, unit It'Sllng, and development of reqmred test data ' Based on F('I "s full) burdened ralc
analysis, FCL assumed that Netron/CAP would be used for new development and maintenance of Netron/CAPdeveloped applications only. The remaining staff will continue to use traditional methods to enhance and maintain: • vendor packages • systems that are being phased out • service requests without sufficient business case to warrant a rewrite using Netron/CAP
Analysis and m e t h o d o l o g y The analysis indicates that over five years, 20 developers using Netron/CAP will be 450% more productive than they would be using traditional development methods. FCL used years of development as their measurement unit, calculated as follows: for each person-year available, subtract the portion of time estimated spent on non-development activities ('overhead' and maintenance). The result is the number of years avaihible for development. When Netron/CAP is used, the figure is further broken into development activities (design, programming, and 'project other'), and time available for each activity is factored by Netron/CAP productivity rates as determined in the productivity evaluation. The total is the number of development years possible with Netron/CAP. (For more details on the model, see Appendix !.)
Effect on development The effect of increased development productivity and reduced maintenance, produced by 20 developers using Netron/CAP for five years, is 143 years of development. Twenty developers using traditional methods for five years would generate 26 years of development. The net
information and software technology
6O I~---~]
]
Traditional Met hoda
>30
• Netron/CAP will allow FCL to replace old systems faster than is possible using traditional methods. • Maintenance of Netron/CAP programs is projected to be substantially less than that required for programs developed without it, largely because of the size and structure of the SPC, where all maintenance is performed.
20
CFO ONLINE PROJECT I0
0
Figure 1. Reduction in required maintenance.for 20 developers over.five years (net reduction in maintenance years represents sa ring of $1.7 m i/lion) 160 140 / 120 -
-
100 -
-
80 . . . . . . . . 60 40
-
..........
20 . . . . . . . 0 -
-
Figure 2. Development output[or 20 developers over.five rears (net increase in development )'ears represents $10.24 million ) gain of 117 years with Netron,'CAP represents a 450% increase in productivity, or $10 million of development. Figures 1 and 2 show Netron/CAP's impact on the development activities of 20 developers.
Effect on maintenance FCL estimatcs that maintenance activities (which include old system rcwrites) will be reduced 40% overall because:
,¢- .,,,,.,.,,......,..... ,~
Project C was an online front-end to CFO (Consolidated Functions Ordinary). CFO is a batch system of about 450 main programs, which processes more than 150 000 insurance policies. It was built in 1962. CFO Online allows transactions to be entered, edited, and validated online. Previously, policy information forms were filled out and passed to data-entry personnel who keyed the information. This data file (an 80-byte card) was then put into a batch cycle where they were then processed overnight on the mainframe. CFO Online does not affect the structure or flow of the batch CFO system (see Figure 3). Temporary files are updated during these online sessions; master file updating is done with the nightly batch run. Based on the sum of the estimated costs ot" performing functions eliminated or streamlined through more efficient programs, FCL estimates that eliminating form processing and data entry, and reducing the time required to input information and correct errors, will save over $125 000 per year.
Functional scoping Before CFO Online was selected as a Netron/CAP project, representatives of the CFO user base outlined 50 functions they required. Then, in conjunction with ISD, they selected II high-priority functions to be implemented first, including handling premium payments, status requests, name and address changes, and transaction generation. Using CA-Estimacs, one staff year was estimated for development using traditional methods.
_
I
Coovo.er/
I
_
r I
Batchor
I
r [Vtaffsa~tion I
- I
I Bato.es
I
CFO Online
T
1
t
Figure 3. CFO s)'stem flow chart
vol 32 no 5 june 1990
373
Functional design Following Netron/CAP installation and training, seven users, the Netron/CAP developer, and the Netron/CAP Implementation Coordinator met in a series of application design workshops. The workshops totalled 18 hours and spanned about two weeks. During the workshops, the users and ISD refined the original system requirements. They discussed specific accounting functions to be accommodated, screen functionality, reports, and inquiry and browsing capabilities. To provide a basis for discussion, the developer built 13 screens with Netron,'CAP before the workshops. These screens were modelled on the forms the users used at the time. During the application design workshops, the team worked to simplify screens. The users were accustomed to thinking of and performing functions in terms of forms and account numbers. By modifying the screens to use business terminology, the team was able to replace eight forms, representing 18 CFO transactions, with six online functions. For example, the "Make a reversal to Returned Money. and balance to Over/Short' transaction was represented on the screen by one code. Selecting that
S
riret
Ca~*l
Screen D Feb 10 a5 3:47 pm
Life
PAYMIffCTSlLEVERSAL.51MISCgLLAMZOU3
A B C D
-
W.L'W£XSALS t o : ~ - Holding I - R e t u r n e d Boney J - uoldin| and Over/short (NTO) K Retu=ned Boney, balance t o O / S
PHMIUM PAYIdJ[HTS f r o e : Holdlnf Holding and Over/Short H o l d i n g and D i v i d e n d s H o l d i n g , balance t o o v e r / S h o r t
LOA/q PAYMZNTS f r o m : E - Holding • - H o l d i n g and O v e r ~ S h o r t G - HoXdlDf. belence to Over/Short Pollcy:
02.55TOS00M
UNsuspended
o.....
o....
MISCELLANEOUS L - F r o m H o l d i n l f t o Returned M o n e y M - TO r e c o r d r e t u r n e d Boney
PDTO:
0 3 15 1 8
S t a t u s Xeq:
code can cause the system to perform up to 16 separate accounting activities. After entering dollar figures and selecting an action code, the user can process the transaction immediately, or access a second screen to edit the individual accounting activities the computer will execute (see Figure 4). When the user is satisfied with the activities the computer will perform, the transaction can be processed without returning to the first screen.
Application design with Netron/CAP In the first application design workshops, the design team decided to use business terminology instead of form and account numbers on the screens. They prototyped these screens with Netron/CAP. decided on menu and screen sequences and function key definitions, and defined validations and help messages. Before the next sessions, the developer built the SPCs to drive the screens. This type of iterative development process is designed to eliminate the kinds of problems that can result from end-user/developer alienation.
Design results The highly functional, user friendly CFO Online system was designed in less titan 25% of the time estimated for traditional methods. This was attributed to Netron.. CAP's screen and system modelling capabilities combined with the application design workshops. The interactive nature of the workshops provided a forum for discussing user needs and sharing systems expertise. The resulting front-end system focuses on business requirements, reducing the users' need to understand CFO technical requirements.
Y
ogtion: . . . . .
~mt
4o
S~L[CT S I ~ I D
Development with Netron/CAP
,
54 (enter) 2 - Process 5 - Vi~IEdit
OPTION:
PBtB • o f
/
--
2
•lrwt
5 - Prey Menu
Capital Life CFO
PP.I~MIUMS/ILEVERSALSIMISC~LLA)#[OU5
Number: Mode : ~e _2 2 -5 --5
025|7S$OOM ~ s u e p e t~ d e d
Payor:
5
85 55 55 SS
Status Req:
TEAMSACTIONS
sc~reen D[~ ~ Feb 10 $| 3:4T
ALITA LYON
Insured :
D~te I5 15 15 15
-
I0 -
Y
Entry
Date
TrKns
_2 0 , 2 _S _Z 1 0 _2 10
55 55 S5 8S
2002 290x 200= 2991
Total:
S[LECT OPTION: -(enter) Ip 2 - PrOcess
Debit
Credit 45.00
45.0~ 5 4 . 0 0
- St.00
9S,O0 5 - ~rO s BUD
9 - Prey
Entry
Code
! 1 1
1
9g,O0 Menu
10 -
Figure 4. Sample CFO online screens. Pressing F3 from top screen gives the bottom screen, where verification of and~or modification to default accounting transactions can be performed.
374
After the design workshops, the developer began implementing the designs (see Figure 5). He found that CAPframes provided a 'working technical solution" to the system. The developer also built his own frames to maximize reusability. Six custom frames embody file definitions and standard FCL routines. Another allows Netron. CAP programs to access FCL's security system. Netron/CAP's open architecture is designed to allow developers to create function-specific code segments (frames), which can be reused to provide uniform solutions to common programming problems. For example, a developer may choose to write a frame to perform a standard function. This same frame can then be incorporated into the program (or into another program) wherever that function needs to be performed. The developer then needs to maintain only a small segment of code to perform functions throughout the program or throughout a number of programs. (See Appendix 2.)
Development results CFO Online, including acceptance testing, training, and implementation, was completed in 5.5 months, 3.64 calendar months ahead of schedule (see Table 3).
information and software technology
CFO Online Processing Main
"a L^ 'ess / ] Mo . C. +s t
Direct Payments
Menu
~] I Misc.Accoualtblgl SuspIMldlh Payments Reversals
I
t I P/RIM i Transactlong
Note:
Transaction
Batch
/
Summary
Tr ansactlon
All screens have direct "Go-to" capability.
b'igure 5. CFO Online system ,vtrueture
Table 3. Summary of CFO Online project data
Maximizing benefits of new technology
No of CFO system users 50 + No of system uscrs involved in CFO Onlinc design 7 No of system developers 1 Years of experience 8 Position Senior programmer..analyst
FCL believes that rapid development of quality systems is critical to the success of any project. The volatile nature of the insurance industry requires that companies be able to 'turn on a dime'. Rapid development ensures that systems are not made obsolete even before they are delivered and allows the company to react quickly to emerging trends. FCL used several approaches in conjunction with Netron/CAP that allowed ISD to deliver C F O Online in less than six months.
Ten weeks after Netron.CAP training, the Implementation Coordinator collected and analyzed CFO Online project data. The following summarizes the rcsults. No of Nctron/CAP SPCs Generated LOC SPC LOC SPC as proportion of generated LOC (~/o) Cost savings ($) Time savings (calendar months) Design time Estimate for traditional means (h) Actual with Netron..CAP (h) Actual as proportion of estimate (%) Nctron/CAP design rate (times faster than traditional approachl Development time Estimate for traditional means (h) Actual with Netron..CAP (h) Actual as proportion of estimate (%) Netron/CAP development rate (times faster than traditional approach)
9 27 171 3 521 13 26 595 3.64 460 104 23 4.4 881 290 33 3.0
CFO Online was implemented five months after the developer's Netron/CAP training. At that time, the system was composed of the following: SPCs Screens Reports Custom procedure division frames Custom file definition frames Total No of program modules
vol 32 no 5 june 1990
12 12 2 9 4 39
Design In the design phase. FCL reduced C F O Online's elapsed time to implementation with two techniques: progressive implementation and application design workshops. In conjunction with ISD the C F O Online system users decided that the C F O Online project should be implemented in three phases. With progressive implementation, the end-users received their high-priority items quickly, while the developer could concentrate on well defined specifications for a subset of the entire system. The application design workshops also reduced elapsed time to implementation. The interactive nature of this design process meant that the users and developer worked closely and communicated effectively. As a result, the users were highly satisfied with C F O Online, which was designed in 23% of the traditional design estimate.
Development FCL's 10-week Netron/CAP productivity analysis showed the C F O Online project was developed in 33% of the traditional estimate. The combination of design and development time savings meant C F O Online was completed 3.64 calendar months ahead of schedule, saving FCL $26 000 in development costs.
375
APPENDIX
1. F I V E - Y E A R
MODEL
~s
Year 1
2
3
Person-years available' 14.00 20.00 20.00 Non-development requirements (in years) Overhead: 2.80 4.00 4.00 New maintenance ~ 0 .81 1.96 Old maintenance a 4.20 5.27 4.24 Actual years available for developmenP 7.00 9.92 9.80 Years possible with N e t r o n / C A P (by activity)" Design 6.19 8.77 8.67 Programming 14.22 20.14 19.90 Project other 1.40 1.98 1.96 Development years possible with N e t r o n / C A W 21.81 30.89 30.53 Total years possible with N e t r o n / C A P ~ 28.81 40.98 40.73 Total development years possible with N E T R O N , ' C A P over five years 143.18
4
5
20.00
20.00
4.00 3.10 3.22
4.00 4.22 2.2 I
9.68
9.57
8.56 19.66 1.94
8.46 19.42 1.91
30.16
29.79
40.48
40.22
Design Programming Project other
...? . . , . , \.,...? ,,),.,,,, ,,...., .,?., ,.:. ?.. ,., ?,?.,, ,. ~ ' ;
2 0 . , . , ..,...;,, ....
========================Programming == ::::::::::::::::::::::::::::::::::::::::: ~?? i: ",.,,.,~,-, ~.',? ,.., ,, ,,.~,.,-,.,.-.-,,..., . , , . , ,,, .,.~......,~.,.,.
"V,\" \ "-,....... "-."", -,N" ",'-" ' ",- \ . b ", . " . -, .t.,............. \ \ -,,',.,.. - . -.,-, , . r \ ". . , . , x .,. "-t.. ", " . " , ~ ." . .
Proportion
Productivity factor
20% 60% 20°/,,
4.4 3.4 N.,A
Programming includes coding and unit and system testing. Project other includes project management; project, system, and user documentation; user acceptance; conversion planning; implementation. ~Development years possible with Netron/CAP: sum of figures for each activity in 'Years possible with N e t r o n / C A P (by activity)'. "Total years possible with Netron/CAP: sum of 'Development years possible with N e t r o n / C A P ' and "Non-development requirements (in years)'. 9Total development years possible with N e t r o n / C A P over five years: sum of yearly total of 'Development years possible with Netron/CAP'.
376
25
,..-..,~,.-.," ~:, .:,,\ "-,'..-.,\',. \ .
In designing the five-year model, FCI, made the following assumptions about its development and used the following formulas for calculation: 'Person-years available: FCI, projccted that 14 people would use N e t r o n / C A P in the first year; 20 in subsequent years. -'Overhead: 20% of "Person-years available' will bc spent on overhead activities. Overhead includes general meetings, nonproject duties, and personal time off. ~New maintenance: F C L used CA-Estimac's conclusion that maintenance equals four times the development time. projected over seven years. In addition, as maintenance of Netron."CAPdeveloped programs is performed on the SPC. which was found to be an average of less than 11% of the size of the application, the formula used to calculate new maintenance is: ( N E T R O N / C A P Programming [from previous year] * 417) * 10% ~Old maintenance: FCL estimates that 30% of "Person-years available' will be spent maintaining old systems. The formula used to derive the old maintenance requirement assumes that 70% of the previous year's programming replaced old systems (thus reducing old maintenance in the long term). SActual years available for development: calculated as: Person-ycars available - [Overhead + New maintenance and Old maintenance]. ~Years possible with N e t r o n / C A P (by activity): To calculate these figures, F C L divided 'Real ycars available for development' into activities and multiplied them by the productivity rates determined in the productivity analysis: Activity
Actual Year,= Available
o
Year 1
I
Year 2
Year 3
Year 4
Year 5
Figure 6. Division of activities o/ Netron;CA P developers over .five years This graph shows activity breakdown of Netron.('AP developers o,,er tNe-year analysis period. Note that 14 developers are available in Year I and 20 in following years. • Overhead: remains constant at 20% • Old maintenance: decreases as new systems built with Netron..CAP replace old ones. . New maintenance: increases as new systems arc built with Nctron: CAP. • l)cvclopment: is time remaining after Overhead and Nev, and Old maintenance requirements are subtracted. 25
20
Actual Years Available 15
10
0
Year 1
Year 2
Year 3
Year 4
Year 5
bTgure 7. Number of development years available with Netron/CA P by activity This graph shows development productivity of Netron/CAP developers over five-year analysis period. To determine productivity with Netron/CAP, actual development years from Figure 6 are broken down into activities and multiplied by productivity rate determined in productivity analysis. • Project other: is constant 20% of each year's actual development years. • Design: is 20% of each year's actual development years * 4.42 (design productivity rate). • Programming: is 60% of each year's actual development years * 3.39 (programming productivity rate).
in|brmation and software technology
APPENDIX
2. W H A T A R E F R A M E S ?
Frames are formal metaphors. A metaphor captures things that arc the same about things that are different. For example, the metaphor 'a plane is like a bird" points clearly to a 'framework' of properties common to many different flying things. On the other hand, to adapt a bird into a plane requires some properties to be altered: replace the feathers, prohibit wing flapping, add an engine, and so on. What alters the properties of a frame? Other frames! A bird frame, describing a prototypical bird, could have its properties extended and modified by duck frames, or even griffin frames. This adaptability is crucial: the power of metaphors is their applicability to novel situations, such as griffins. What do mctaphors have to do with software? Sot)ware metaphors express things that are similar about programs that are different. The word metaphor may not be part of the software jargon, but entity and function types are well known kinds of software metaphors. Familiar entity-types include inventory, customer, order, and supplier, function-types include screen 1/0, batch updates, credit checks, and interest calculations. Such types are common to many programs. Programmers implicitly use same-as, except metaphors: 'this program is the same as that one, except for this and except for that.' A (software engineering) frame is a same-as, except combination of one or more data Tunction types. A program (or any software module) is a same-as, except combination of one or more frames. Frame technology provides the multiple inheritance of object-oriented programming combined with the ability not only to add new features, but to modify and delete at any level of detail. One program, for example, may enter orders, update customer information, and calculate interest on deposits. One frame hierarchy will be able to assemble this program from a same-as, except combination of quite different frame types, each with a disparate sub-hierarchy. Frame technology reflects a paradigm shift in the understanding of software reusability. The breakthrough stems from being able to handle differences as well as similarities in what is reused. It has been employed with multiple programming languages as well as in the production of manuals. Frames have various degrees of reusability. Some will be used in many programs. For example, a Divisions frame should occur in every Cobol program. On the other hand, each SPC (Specifications) frame usually specifies a single program. Frame technology formalizes the specification and composition of frames. A Bassett-frame contains two things:
• (i) a standard definition of its entity-/function-types • (ii) engineering change commands
vol 32 no 5 june 1990
(i) expresses the similarities that are available to all instances of use; (ii) expresses the differences that are peculiar to each instance of use. Data-entry, for example, does not refer to a specific program, but to an infinite class of programs that share a standard set of properties: buffers and protocols for screen and error handling. Such properties comprise a standard definition in a reusable data-entry frame. Given specific and reusable frames, the computer can assemble any of an infinite class of programs. Frames adapt frames through engineering change commands, also called frame commands. Each command can assign or reference frame parameters (properties). If an adaptor frame does not assign a value to the parameter, the adaptee frame's default standard value is used. In other words, only the differences are expressed; differences peculiar to each adaptor frame are expressed as part of the adaptor frame.
SPC (Specif~tiotl Frame)
i
]
I
Workstation frame I/0 i
i
Message declarations ] frame ,
frame /
frame |
]
, handling frame
frame [ Filel/0 i
Layout
I
Screenframel/O
Figure 8. Examph" li'ame hierarchy Frames are organized into hierarchies (see Figure 8). At the top of the hierarchy is a specification frame (called the SPC). The SPC specifies one program or software module. SPCs are special because they are the only frames that application developers may create or modify. All other frames are read-only. The further from the top, the more general is the frame type and the more reused the frame. Each reuse instance is independent of the others. Each frame can be the root of its own hierarchy and is its "boss'. Being the boss means it has the final say in how any frame in its hierarchy is to be adapted for its purposes. That is, the boss prevails over all subordinate frames in assigning a value to a frame parameter. Of course, the boss may have bosses too. In particular, the boss of an entire hierarchy is the SPC. Its hierarchy is processed into tailored results, such as a custom program. Any software system can be constructed from frames. Most of the complexity can be hidden in reusable frames, making complex systems easier to design and, particularly important, easier to adapt to changing needs.
377