ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr6/proceedings/ascii/bell.ascii

Text File | 1993-10-19 | 12KB | 282 lines

                             Reducing Cognitive  Distance:


                   The  Role  of  an  Effective  Reuse  Program



                                               Peter J. Bell



                              Australian Centre for Unisys Software

                                    115 Wicks Road,North Ryde

                                   Sydney. NSW, Australia 2113.

                                           Tel:  [phone])

                                  Email:  [e-mail]



                                                  Abstract


    This position paper states that the goal of an effective reuse program is to reduce "cognitive
distance", where this is defined as the time between initial concept and final implementation. It
presents the barriers to introducing a reuse program into an organisation as a result of ongoing
experiences in such a program in an Object-Oriented development environment. The attitudes
of both developers and management are presented as two of the main barriers,and the methods
used to address these barriers are discussed. The requirement to focus on well-specified, robust
and efficient assets is identified. Practical side benefits of introducing a reuse program are also
highlighted.


Keywords: Reuse, frameworks, reuse barriers, reuse guidelines


Workshop Goals: Learning: Networking: Understanding the state of the practice.


Working Groups: Reuse Management, Organisation and Economics, Domain Analysis / En-
gineering, Design Guidelines for Reuse & C++, Reuse and 00 methods, Useful and Collectible
Metrics, Reuse Handbook



                                                    Bell- 1


1      Background



The Australian Centre for Unisys Software (ACUS) is the primary centre for research and devel-
opment activities for Unisys in Australia. It was created in 1987 and has since established itself
as a software centre specialising in the development of distributed applications and graphical user
interfaces. Object oriented languages have been used at ACUS since 1988.


In  October  of  last  year  (1992), the  position  of  'reusability  engineer'  was  created  to  ensure that
the  benefits  of  reuse  that  object  oriented  languages  claim  to  support  were  being  realised in  the
organisation. The roles of the reusability engineer are primarily aimed at establishing a culture of
reuse within ACUS and to develop a library of in-house and third party reusable objects (designs,
code, test harnesses, etc). These roles are specified in more detail in the following sections.



1.1     Creation and Maintenance of Reusable objects



This involves finding reusable objects in existing projects and modifying (where necessary) to make
the object satisfy a more generic set of requirements. A set of reuse guidelines have been written
in order to aid project developers in designing with reuse in mind.


This role also involves the ongoing evaluation of third party libraries to determine suitability for
project requirements.



1.2     Involvement in Project Design



This role is intended to promote the re-use of the library objects and frameworks in new project
designs and to ensure that new software componentsare designed with reusability in mind.  The
reusability  engineer  has  the  responsibility  of  ensuring that  pro jects  both  make  use  of  existing
reusable artifices and contribute to the ongoing development of the library of reusable items.



1.3     Alterations to Existing Development Processes:



The definitions of most of the development processes used within ACUS have been (or are being)
altered to cater specifically for reusability.  The intention is that awareness of reuse issues will be
greater if they are made a part of the developmentpro cessesused within the organisation.



1.4     Development of Reusable Frameworks



The development of reusable frameworkstakes reuse beyond isolated objects.  Acollection of inter-
related objects when combined into a useful framework can dramatically reduce the development
time for applications which make use of such frameworks.  One of the more challenging roles of the
reusability engineer is to establish what frameworks exist within the organisation and to ensure
that they are developed in a manner that allows the framework to be utilised by future projects.
It also requires that new frameworks be developed as a result of carefuldomain analysis.



                                                           Bell- 2


1.5     Corporate Strategy Development



Several development plants within Unisys are now combining their reuse experiences in an object
oriented environment in order to establish a corporate strategy towards reuse. ACUS, is contribut-
ing to this strategy development.



1.6     Research Activities and University Contacts



Given that reuse is an area of significant research,  the reusability engineer is also responsible for
staying up to date with research activities and establishing contacts with the relevant researchers
both locally and overseas.



2      Position -  Narrowing  the  Cognitive  Distance



If the cognitive distance is the effort between the initial concept and final implementation, then a
major obstacle for effective reuse within an organisation is the difficulty in creating and developing
an  attitude  that  aims  at  reducing  the  cognitive  distance.   This  is  true  for  both  develop ers  and
management.  Developers have to believe they can find and modify (where necessary) a reusable
object that suits their needs faster than they can build it themselves. Similarly management must
be educated to understand where the long term savings of establishing areuse program will come
from. Our goal is to raise the perception that reuse activities in the development cycle are notonly
beneficial but critical to the long term viability of a commercial software organisation.



2.1     Changing Developer's Attitudes



The need to change the developers attitudes towards reuse stems from the 'not invented here syn-
drome'. In the past the perception has been that the effort to understand, modify and incorporate
someone else's code into your own was to o great. Unfortunately the perception has too often been
an accurate one.


The role of the reusability engineer is to work with the developers and ensure that they have at
their fingertips the information they need to quickly and easily assess the suitability of any given
reusable object. The phrase "well- specified correct, robust and efficient" [1] has become the key to
turning developers attitudes around. Our experience has been that if they can understand easily
what  the  initial  requirements  of  an  object  were, then  they  can  assess  whether  it  matches  their
needs. Similarly a common regression test procedure allows the developer to determine an objects
stability and to see if a particular test case is catered forand able to be handled by the object.  If
these two criteria are applied to all reusable objects, i.e. developers know what it is supposed to
do and that it is done correctly, thenthey will happily reuse someone else's code.



2.2     Changing Management's Attitudes



The  second  aspect  of  changing  developers  attitudes  deals  with  new  reusable  designs  and  code.
Whilst achieving reuse of existing objects is half the battle, the library needs to grow in order to
remain viable.  This brings the developers into conflictwith managers.  Until managers perceive


                                                           Bell- 3


a real benefit from reusing designs on code, they will remain very reluctant to allow more time
in project schedules than is necessary to get the job done.  This leaves little room for the work
required to generalise a good design into a reusable design.


Our  expectation  is  that  only  when  we  are  in  a  position  to  require  projects  to  submit  a certain
percentage of their development work for inclusion in the library, will a change in attitude come
about.  In  the  interim, it  is  the  responsibility  of  the  reusability  engineer  to  solicit  new  reusable
objects from the project teams.  Involvement in design discussions enable more generic designs to
be achieved. Again it is a gradual change in attitude that will bring about effective reuse.



2.3     Beneficial Side Effects



Given that the key to the reuse program is "well specified correct,  robust and efficient" designs
and code, several safeguards have been put in place which stand to have beneficial side-effects for
project teams.


The entrance criteria are strict and uncompromising.  This leads to a development approach for
reusable code that is more exacting than would otherwise be necessary.  If this feeds back into the
project teams, the results can only be beneficial to the quality of delivered products. The level of
documentation, the use of standard testing mechanisms and adherence to programming guidelines
are  all  strongly  monitored  for  objects  in  the  reuse  library.   This  is necessary  in  order  to  ensure
consistency within the library. Only by maintaining theconsistency and stringent requirements on
quality can we hope to achieve effective reuse - to narrow the cognitive distance. If this insistence
on quality improves the processes used within thepro ject teams, thenit b ecomesa b eneficial side
effect.



3      Comparison



3.1     Experience Report on Software Reuse Project



In the proceedings of the 14th annual conference on software engineering,  Sadahiro Iso da [2] re-
ported on his experiences with specific software reuse projects.  The scale of his efforts was sig-
nificantly bigger than our own, particularly in terms of the resources that were available to him.
However, his findings matched our perceptions quite closely.  Of paramount importance was the
support of senior management. Only with this support can a reuse program hope to survive. Also
of interest to us was the establishmentof a reusability committee to oversee the activities of the
reuse program. We have attempted to emulatethis by ensuring that the reusability engineer works
closely with each of the project groups. One thing we have taken notice of is the suggestion that
a paper based searching mechanism will suffice for the library up until it contains about 1000 ob-
jects. This reduces our need to spend time on developing/acquiring support tools and allows us to
concentrate on developing the content of the library itself.



References



[1]  M. Cline and D. Lea, Using Annotated C++. Clarkson University and SUNY, Owego, 1991.



                                                           Bell- 4


[2]  S. Isoda, "Experience report on software reuse pro ject: Its structure activities and statistical
     results," in Proceedings of 14th InternationalConference on Software Engineering, 1992.



4      Biography



Peter L Bell is a senior software engineer with the Australian Centre for Unisys Software (ACUS),
Sydney, Australia.  He  holds  the  position  of  Reusability  Engineer  and  is  responsible  for  the  de-
velopment of reuse activities within ACUS. This includes the development of a reuse library for
multiple platforms and the establishment of processes which will result in more reusable designs.
He is working, in conjunction with others inUnisys to establish a corporate strategy towards reuse.
Prior to taking up this position, he worked on several software development projects in the areas of
distributed computing and graphical user interfaces using object oriented languages.  He received
a B.E. (Elec) from the University of New South Wales in 1987.



                                                           Bell- 5