proper practices and procedures, tools and co-operative knowledge. Software production I Software engineering was in serious trouble in the beginning of this decade because of lack or workstations, which combine modern hardware and software technology with understanding of both end-user's and software engineer's needs and wishes, seem to resolve many problems in the near future. A four-level model of software production and three sets of CASE tools based on that model are presented. The tool sets are - sof.tware project manager's workstation OHTO (developed in 1985 - 88) - software quality/configuration manager's workstation SAMPO (developed in 1983 - 86) and - software developer's workstation ELiNA (developed in 1986 - 87). The basic issues behind the tool sets are both flexibility and uniformity. They are achieved by using - open tool set architecture, which allows use of popular commercial tools for general purposes (e. g. for text processing) and for special purposes (e. g. for drawing data flow diagrams) and - both official and de-facto standards at all possible levels (e. g. hardware, system software, documentation).
Loosely integrated sets of CASE tools: our experiences
The glorious decade of software engineering, the seventies, with its structured programming techniques. top-down analysis and design methods and waterfall models of development processes ended with confusion: end- users did not like cryptic methods and rigid development models even we ourselves did not like our own cumbersome techniques and out-of-date alphanumeric software tools.
But worst of all, we did not understand the nature and processes of our own work and therefore, did not manage it properly.
In the eighties everything seems to get better. We have accepted the existence of end-users and their requirements; sometimes some of us are even trying to see things their way. Enormous progress of hardware and software technologies has given birth to a generation of very good tools for bOlh software engineers and software managers. And the best thing is that we are beginning to be able to merge the good things of the seventies (basically sound methods and techniques) with the good things of the eighties (tools and new mutual understanding).
In the beginning of the eighties we at VTT (Technical Research Centre of Finland) started to develop a series of software engineering workstations: first within the Software Engineering Research Program of VTT and later within the Finnish Program for Research and Development in Information Technologies (FINPRIT). We developed three workstations - OATO, SAMPO and ELINA. The focus of these workstations is on software management activities based on a model of software production and projects. We have come a long way and learned many hard lessons, but we think we have made many right decisions on our way.
Soltware production is an activity of a company if it produces software applications (for its other activities or for other companies), software packages or embedded software.
Soltware projects usually cover most of software production activity. They may concern ( software development software maintenance or software 'customization or a mixture thereof.
Software projects include many different kinds of actiVItIes on many different levels. We analyzed software production processes in several major Finnish software-producing companies III using most of the well-known authorities in the field of software engineering as our theoritical background /2/. Based on that analysis we developed a lour-level model 01 soltware productioll alld projects (figure I) /3/.
This model may be described as a software factory having four floors (above the ground rlonr including the support activities of software production).
The first floor is the manufacturing floor: there software is specified, designed, coded, unit-tested and integration-tested, maintained, enhanced and customized (software work or software engineering in the narrow sense; software engineering in the broad sense covers of course whole software production). software project management (SPM) software quality assurance (SQA) software configuration management (SCM) that part of project management activities that has not been transferred to the project manager by his superiors; e.g. decision making in the project steering group.
Any software project consists of software project management in the broad sense and activities on the first floor.
In this paper we use the term 'software project management' in the narrow sense unless otherwise specified.
a lack of agreed terminology incomplete and ambiguous requirements imprecise and incomplete specifications inability to model systems uncertainties in software/hardware apportionment rapidly changing technology suitability of languages problems with integration a general lack of visibility difficulties in resource, schedule and cost estimation inability to predict and measure reliability difficulties with progress monitoring complicated error and change control a lack of agreement on test and quality assurance metrics difficulty of controlling of maintenance.
The first group of problems should be resolved for the first floor of our software factory; the second group of problems concerns the second and third floors.
We state that there is a cure for many of those problems: soj/ware produc/ioll works/atiolls. By our definition soj/ware produc/ion works/alion is all illtegrated set oj special soj/ware /ools general sojtware /ools alld o/her (Iloll-soj/ware) /ools combilled with sui/able hardware alld sys/em soj/ware which serves aile persall doillg his/her soj/ware work or mallagemell/ ac/ivies alld which has beell cus/omized jar his/her Ileeds alld wishes /akillg ill/a aCCOII/1I s/alldards alld procedures oj the compallY· Special software tools cover customized software engineering tools like software specification, design, coding and testing tools on the first floor, SCM and SQA tools on the second floor and special SPM tools like software cost estimation models on the third floor.
General software tools cover tools that are used as well in other activities than software production, e.g. text processing, spreadsheeting and data transmission tools.
Other tools include all 'manual' tools like standards, guides, method descriptions, etc. The above definition may sound trivial and self-evident but it contains two key (and almost contrary) issues of success in software production ullijormity (workstations bring concistency and coherence into software production by giving all users the same framework of methods, techniques and company procedures; this helps to gain optimal efficiency of project groups) jlexibilily (workstations gives all users the possibility to customize the user's working environment, which helps to gain optimal effectiveness of individuals). ( (
We decided to set several further development principles for our workstations in order to enhance their capabilities open architecture; tools can be added, changed and removed for flexibility reasons according to uniformity restrictions use of common general tools; people certainly prefer to use e.g. same text processing software in software workstations as for other purposes use of best special tools; it is very sensible to use the best special tools available in the commercial marketplace for every single special purpose within software production whenever it is cost-effective use of other tools in accordance with software tools; in principle prodedures and practices, methods and techniques should be chosen first and software tools accordingly (today, in many cases it is wise to do just the opposite) use of documentation (and other) standards; there are not so many international (or even national) software standards around, but every activity which increases their use is a step towards software industry which does not have to be ashamed of its un maturity as a serious business sector use of 'de-facto' standard system software; it is very desirable to have workstations that are transferrable over hardware model generations and over hardware vendor restrictions use of 'de-facto' standard hardware; it is work-consuming not to have troubles with 'almost standard' system software and software tools.
We chose three main strategies for our development work: commercial technology transfer; we decided to find all possible tools and other components in t h e l commercial marketplace according to the issues and principles mentioned above; if there were several applicaple tools, we had three choices: -- choose one of them (usually by the uniformity issue) choose many of them (and let the flexibility issue to decide) development several parallel versions of the workstation and use one or some tools in one workstation and some other tools in others (usually according to software tool interfaces) incremental development; we decided to build at least three consecutive versions of each workstation in order to study and learn things step by step be able to change the most important choices (system software and central special tools) if necessary give companies in our project support groups chance to influence our development decisions as often as desirable intensive role of companies; we decided to tie several major Finnish software-producing companies as closely as possible to our development work right from the beginning in order to get financial support (which is a benefit for the continuing motivation in the companies except for our financies) form an active group of contact persons (which is a benefit for gelling workstations piloted in the companies except for gelling comments all the time) get piloting experiences of each workstation version.
We developed three consecutive versions of workstation OHTO for software project managers. In the following, the capabilities of the latest workstation called OHTO-3 are described.
OHTO-3 is a workstation that supports software project managers covering all project managemenl activies: project goal-selling and estimation project planning' and execution project monitoring and control project terminating and evaluation project administration.
Follow-up reports
PROJECT Fin a I rep 0 r t .. TERMINATIN G.
OHTO-3 runs on IBM PCI AT (or compatible) with 640 K memory, hard disk, EGA or Hercules graphics, mouse and laser or matrix printer. Its user interface is picture-oriented, menu-based and mouse-driven under MS Windows environment.
OHTO-3 has several groups of user interface screens. Opening screen gives the list of identifications of started projects; after one of them has been chosen, the full names of the project and its manager are given and it is possible to continue to the function screen.
FlInctioll screen gives the functional diagram of software project management activItIeS (or sub functions) presented in figure 2. For every function there is a sub-/lInctioll scre.en covering several tasks. Every sub-function screen shows after every choice of tasks a dialog box with 'radio' buttons for further choices and there is a help screell for every screen and task.
There are five tasks under 'Goal-sel/ing alld estimatioll'. Task 'Construct schematic project plan' means writing and composing a document which includes main goals of project overall structures of project and software estimates of resources, schedule and costs.
Schematic project plan may.be used as a project idea, proposal or offer and it contains the results of three other tasks of goal-selling and estimation. We used Windows Write for text processing purposes in OHTO-3, because it is easy to transfer screens of other tools into Write text using the internal Clipboard facility of Windows and Windows Draw for diagramming purposes for the same reason. ( ( Task 'Structure software and estimate size' includes constructing the overall software structure (programs, modules), estimating sizes of the software components and summing them up to get the size estimate of the whole system for cost estimation. It is also possible to use Function Point Analysis /4/ with some conversion data base for size estimates to perform a 'sanity check'. We built a MS Multiplan application for these purposes and developed a link which transfers software structure and size estimates to the software cost model WICOMO described below.
Task 'Estimate project' contains the estimation of resources, schedule and costs. We applied WI's WlCOMO (based on Boehm's COCOMO /5/) in OHTO-3 by developing many enhancements and by transforming its phase/activity model for our purposes.
Task 'Structure project' includes dividing the overall project structure into phases and other activities like project management, quality assurance and configuration management. We developed a link between WICOMO and MS Project to get a Gantt chart based on WICOMO schedule estimates (using our own phase/activity model).
Task 'Assess project risks' covers assessing related risks based on McFarlan's ideas /6/. We used an expert system shell called VP-Expert for implementation.
Other sub-functions presented in figure 2 have similar tasks. In the following only the most important tools and standards used within those sub-functions are shortly described. (
Within 'Project plal/lling and execution' we included software quality assurance plan and configuration management plans as appendices of the project plan using the corresponding ANSI/IEEE standards /7,8/ as base examples for plan formats built a resource allocation link between MS Project and MS Multiplan because of Project's insufficient resource allocation capabilities. Preliminary scheduling is done within Project, then preliminary resource allocation (persons - activities) within Multiplan and last fine-tuning of schedule and resource usage levels within Project used MS Multiplan for spreadsheeting and Windows Graph for presenting cumulative resource and cost curves, thus being able to use links between them and MS Project.
Within 'Project monitoring and control' we developed in co-operation with a major Finnish company a resource monitoring system prototype using MS Multiplan and linked that system to OHTO-3 in order to produce required resource and cost follow-up reports.
Within 'Project terminating and evaluation' the most important task is to update corresponding company history data bases. The risk-related data base was implemented using MS Multiplan having a link with the VP-Expert implementation of our risk assessment model. The project history data base was implemented using Rbase System V DBMS package using more than 200 different data elements. The data base was designed also in order to help the calibration of cost drivers of software cost model WICOMO described before.
Within 'Project administration' we used Windows Cardfile and Calendar for the corresponding tasks. OHTO-3 is primarily software project manager's workstation, but a software production manager can also use OHTO-3 e.g. to combine project plans or follow-up reports of multi-projects (combinations of several projects) check project estimates set schedule dependencies between projects allocate resources over different projects and combine monitoring information of different projects.
We developed two consecutive versions of software configuration manager's workstation SAMPO. The latest version called SAMPO-2 is described below.
SAMPO-2 runs on Microvax II computer under Ultrix-32m operating system and uses Empress/32 as its (relational) data base management system (ROBMS).
SAMPO-2 is a multi-user workstation with three virtual desks as figure 3 shows.
A desk can be either on a 'dumb' terminal or on a PC (emulating terminal) or e.g. in the window emulating terminal on a PC.
The 'author's desk' must be used by every member of the project group when author wants to get objects accepted that he/she has 'created' or 'modified'. Objects can be either 'initial' (e.g. modules) or 'derived' (e.g. software packages). Author 'proposes' the object by sending it to the 'configuration manager's desk' who initiates the planned software quality assurance procedure and, after that, either 'rejects' or 'accepts' the object. 'Accept' puts the object to the 'archive desk' (which is also in configuration manager's responsibility). There are many other functions within SAMPO-2, e.g. ( Create Reserve r
AUTHOR'S DESK Modify Rejed
Propose Unpropolo 1
I pONF. fdANAGER'S pESK GeneraIe. AnaIyEe, Ll'it, Show, CompOIe, Repor SAMPO-2
DESKS AND
FUNCTIONS Accept l
I ACRHIVE DESK
Releaae, Mark ~ author can 'reserve' objects so that nobody else cannot make any changes to that object author can 'unpropose' any object if he/she finds an error in the proposed object configuration manager can 'mark' an accepted object, which is erroneous, but cannot be fixed immediately objects can be 'analyzed' with several analyzers during specification phase (static analysis of completeness, traceability and concistency), design phase (SO-based IDES-method) and testing phase (concistency) it is possible to get reports about objects, their hierarchies and configurations (e.g. phase products). Software developer's workstation EUNA We developed two parallel versions of software developer's workstation ELINA
ELINA-E for documentation of embedded software and
ELINA - T for documentation of data processing applications.
ELINA runs - like OHTO-3 - on IBM PCI AT (or compatible) with 640 K memory, hard disk, EGA or Hercules graphics, mouse and matrix printer or laser. Its user interface is picture-oriented, menu based and mouse-driven under MS Windows environment.
Its user interface is similar with OHTO-3. In figure 4 is the software development process implemented as an ELINA-E screen.
In the case of figure 4 'Software specification' is the chosen document. In the low left corner of the screen appears a dialog box with two sub- boxes: the other one is for 'text skeletons' and the other one is for 'diagram skeletons'. Text skeletons can be either 'tables of contents' (in this case there are two choices: a FlPS-standard and VTT's own specification standard) or older versions of the corresponding document.
We used most major software documentation standards, e.g. IEEE's, as text skeletons. Diagram skeletons can be either 'symbol libraries' with the total set of symbols of a diagramming technique (in the case of figure 4 there is only one choice: IDEF- (SADT-) symbol library) or a diagramming sheet (in the case of figure 4 there are IDEF sheets both in Finnish and in English) or older versions of diagrams.
~ Flf.lI'J f--
SOFTV,'ARE l£eCst>~f·lIW"r.;'f:J
Soflw.. rc ....::;;:--_. pl;\n ~-
CODE A!'"j() ~ leST
FROGRAI,IS
Soflw",c rCQuircmer,ls specific"r
~ortW;lrC spec:'jc"t;':'n ...."- dcs.::ripliom
Solll'.'.. re rrloOdvl,:, ~/-- 50:-11·..'.:>'(.' me-:tJ!-:=;-~ slK,vn,,'y
SOUW.:IfC rro<:-doJles /
I\ITEGRATE 5oflw.;vc _; ...... Af'.o TEST lest rct'«l """'- SOfTWARE £-~lw•.rC Llset inslrtY-lion Us:-d;ll(.' inslrUCI" ~F-EClF,( '=':;.FH·...'AF.E I:=.:·il.,,'.-,re spr,:;ii.;"tior, .f
"
SOFJUnRE SPEC IFIcn II 011 C:\ELINn\PROJECTS\PROJ1 :.!I~i~:~·D12 It I!~~t~~·~!~ t 'I I Ill~I~~~'~iU~...7 ~
= We have implemented symbol libraries for many well-known diagramming techniques, e.g. SA, SO and SADT.
Texts and diagrams can then be combined arbitrarily to produce the chosen document. The other version EUNA-T for data processing applications was developed using a commercial Finnish information system development model (including e.g. Swedish-based system analysis and design method lSAC, conceptual analysis method ER/EAR and structured programming method JSP).
All our workstation projects had one main goal: to produce a useful workstation prototype which could be further customized to useful workstations in Finnish companies.
We had ten organizations piloting OHTO, two organizations piloting SAMPO and four organizations piloting ELINA. Nevertheless, it is not sure whether any of those companies will use our workstations in the future. There are very obvious and acceptable reasons fot that situation which can be shortly summarized as follows: the user interface implementation of OHTO-3 using Windows Software Development Kit is too tedious to be customized for different purposes of different companies. We have to get reasonable tools for Windows (or Presentation Manager) user interface development. the DBMS implementation of SAMPO-2 is far too slow for production purposes. We have to get faster RDBMS packages. software documentation itself is not a sufficient topic for a software developer's workstation if there are no linkages to more genuine CASE tools. We have to get CASE interface standards to be used within open CASE tool sets like EUNA.
We feel that we have had many sound ideas before having the opportunities to implement them efficiently.
Experience gained around workstation development and piloting During five years of our R&D we got important experience concerning organizing workstation projects choosing hardware and system software organizing piloting in companies.
Software production workstation projects are like any other software package projects in many ways. To start with, there has to be a very small group, which believes in what they are doing, does not listen too much and pushes their way through difficulties. it is not sensible to have a big group of people expressing their own views from one meeting to another especially if they work many hundred kilometres from each other. Later on, the group must listen very much and be very sensitive to realize the real needs and wishes of the users. And last but not least, we could see that to develop a product from a prototype must take an incredible amount of time, resources and money. Choosing hardware and system software for workstations is not a very easy job. For example: we started SAMPO project with Altos micro, Xenix operating system and Informix RDBMS, then changed Altos to Intel. Then we went over to VAX 750 and VMS operating system with Eunice Unix-emulator, then changed Informix to Mistress. After that we used Convergent with Unix, then Microvax " with Ultrix and finally updated Mistress to Empress. And all this happened in three years! Concerning OHTO and EUNA we would have been lucky to choose Windows environment (because it is now de-facto standard of windowing environments) if we had had beller tools for user interface implementation.
We noticed that piloting is very sensitive: if something goes wrong, it is a tough job to gain back the confidence of the piloting user, no matter whose fault it was in the first place. Anyway, Our experiences concerning piloting were positive: we avoided many painful mistakes by listening the piloting users.
We have already started our next project within the Finnish Research Program for Software Technology (FINSOFT) by the name 'Management, Communication and Collaboration within DiStributed PROjects producing Software (DISSPRO). The main goal is to produce a 'DiStributed Software Engineering Environment GENerator' (DISSGEN) which could be used to produce tailorable environments for software engineers working in software projects which are either geographically or organizationally distributed. The first prototype will be implemented on our Sun 3 network using a hypertext package for user interface implementation and collaboration support and Unix mail facilities for communication support.
We are aware of the danger of producing our prototypes once again a few years before they are implementable for production purposes. Anyway, compared with the other choices - producing academic papers or competing with software tool companies - it is our only possible way to a successful R&D result. /3/ K~ns~I~, K., Software project management. VTT Research Notes 920. Espoo, 1988. 21 p.+app.3 p. /8/ ANSI/IEEE Std 828-1983. Standard for Software Configuration Management Plans. IEEE, 1983.
II p.