Filetype PDF | Posted on 30 Jan 2023 | 2 years ago
Authentication
digital resources
177x Filetype PDF File size 0.06 MB Source: karmila.staff.gunadarma.ac.id
Case Study: SITINA - A Software Engineering Project Using Evolutionary
Prototyping
Nuno Jardim Nunes
dnnunes@dragoeiro.uma.pt
Phone/Fax: +351 (91) 705160 / +351 (91) 705199
Address: UMa - Madeira Tecnopolo, Penteada, 9000 - Funchal, Portugal
João Falcão e Cunha
jfcunha@garfield.fe.up.pt
Phone/Fax: +351 (2) 2041736 / +351 (2) 319125
Address: FEUP - Rua dos Bragas – 4099 Porto CODEX - Portugal
ABSTRACT
This paper presents a case study based on a complex software engineering project that took place in a Portuguese SME,
Small to Medium sized Enterprise. Our initial goal was to evaluate and adapt Software Engineering theory to the reality
of SMEs, usually working in chaotic environments, and following no standard method. We refer to such absence of
method as the just do it process model.
We shortly present the project, critically discuss its results, and summarise what we believe has been learnt from the
experience. We will consider the highly interactive collaboration model, evolutionary prototyping model,
object-oriented A&D methods, and CASE tool support. We will discuss its theoretical principles and evaluate its
expected advantages and shortcoming on the project mentioned. Finally we propose a new model for evolutionary
prototyping, better adapted to the reality of the environment we faced.
1. INTRODUCTION
1 1
The SITINA project started with the need that the EDM utility company had to monitor two small, completely
automated, hydroelectric power plants [1]. The main goal was to develop a low cost application that enabled the board
of directors to monitor those power plants and retrieve statistical data on their production.
It is not in the scope of this paper to offer a detailed description of SITINA [2]. However, as we can see from its final
2
general architecture on Figure 1, we are dealing with a complex SCADA/EMS based system with many technologies
and different software products.
1
SIstema de Telemetria para Instalações Não Acompanhadas (Telemetry System for Unaccompanied Utilities).
Administration Facilities
SITINA Communication
Server
SITINA User SITINA Software
SITINA User Interface RDMS Client DNP 3.0
Software (forms, gráphs and SITINA Database Server (4D Client) L1
reports)
RDMS Client RDMS Server WWW
(4D Client) (4D Server) Server MacOS /
MacOS / Windows95
MacOS / TCP/IP or Windows95 / TCP/IP or Serial
Windows95 AppleTalk Windows NT AppleTalk TCP/IP orAppleTalk
Communications
Ethernet
Utilitie: Electric Power Production Plant
Measurement Concentrator / Protocol
Powermeter Transformers: Converter ISDN / Analog
IED Voltage and Commuted
(Intelligent Electronic Device) Current SITINA Software Network
Instrumentation RDMS DNP 3.0 Binary
Software 4D L1 ModBus
Binary ModBus MacOS / Windows95 WWW Browser
Serial Serial SITINA Remote User
Communications Communications
RS422 Multidrop
Figure 1 – SITINA®’s General Architecture
Before starting the project we decided to choose a suitable subset of well-known and well-established software
engineering methods and techniques. We mean suitable in both the senses that they could help in attaining all the user
requirements and also in that they could be used successfully in the organisational context in which SITINA was going
to be developed. It was also our own research goal to study them and evaluate their ability to improve the development
process and help in solving problems that would arise. Initially we considered the following issues that should be
considered in choosing reference models and methods:
(i) Maintaining user satisfaction by allowing the system to adapt to changes in user requirements;
(ii) Maintaining user satisfaction in terms of usability of the system and time to deploy it;
(iii) Adding value to the Software Engineering SME that was used to a just do it process model [6];
(iv) Ability of the project team, in particular developers, to learn and use such new models, methods and
techniques;
(v) Adaptability of the models, methods and techniques to building an embedded system.
In this process we used what we call a catalytic Trojan-horse3 approach. We introduced in the SME well-known
models, methods and tools that have been established for some time and are accessible to regular practitioners. We have
1
EDM, Electricidade da Madeira, is the company that has all the responsibility for electrical production, transport and
distribution in Madeira Island.
2
SCADA/EMS technology was introduced about 50 years ago to enable the operation and control of energy production,
transport and distribution systems: EMS [5] (Energy Management System): systems that maximise the efficiency of the
production, transport and distribution of electric energy; SCADA [3] [4] (Supervisory Control and Data Acquisition):
technology that enables a user to collect data and send commands to one or more remote utilities.
3
We use the term Trojan-horse approach to indicate the way we worked within the company. We wanted to gain the
developers’ confidence and we wanted them to know that our main intention was to help them being more productive and more
satisfied. The term should therefore be regarded only with its positive connotations, regarding success, as no harm was meant or
delivered.
not used or evaluated advanced methods and techniques, namely on the object-oriented area. Although they play a
substantial role on the software engineering discipline, they were not considered mainstream tools for the regular SME
software Development Company or practitioner. Following the same policy, we have not used or evaluated experimental
or sophisticated tools and technologies, like version and configuration control, automated metrics or object-oriented
databases. Some of these tools and techniques were not available for the development team, and others would have taken
a considerable amount of time or other resources to use and integrate.
1 2
Related work concerning process assessment and improvement efforts, using CMM and QIP in SMEs, clearly
concluded that these methods are not suitable to such organisations. Cattaneo et al [7] present a case study of CMM and
QIP assessment in SMEs and conclude that "we should define assessment and methodology with a broader vision of the
problem (...); it is not sufficient to consider just engineering issues (...), we have to take into account that most software
companies are still at a very low maturity level". Brodman and Johnson [8] report about applying CMM in small
organisations and conclude that SMEs "want to improve, but they have concerns with being measured against a model
whose requirements they cannot rigidly meet".
2. THE PROJECT AND THE PEOPLE
2.1. Organisational Context
Three separate institutions were involved in the development of the SITINA system. A customer company with the end-
users, the software supplier company with the development and management team, and finally the research institution
that co-ordinated the project regarding the software process and the modelling method: analysis, design and
implementation of the system.
One benefit of our Trojan-horse approach was the capability it gave us to influence directly the way people were going to
collaborate and communicate during the system development. Since we required a pro-active attitude from everybody,
we suggested that all the entities involved could communicate and collaborate directly. This model (see Figure 2)
enabled us to have continuous feedback and to react very quickly to users and developers during the entire system
development process.
Client Company
General Specification
Prototype Evaluation
Final Tests
Research Institution Supplier Company
Requirements Analysis Implementation
Coordenation: ISystem Analysis and Installation
Design, mplementation,Tests Tests
Maintenence
Figure 2 - Organisational Development Context
1
Capability Maturity Model of the Software Engineering Institute.
2
Quality Improvement Paradigm of the University of Maryland.
The distribution of tasks indicated in Figure 2 was not defined at the beginning of the project, but was itself a product of
the evolutionary process described later on this paper. To understand in detail the conditions imposed by the
organisational context, we describe some of the characteristics of the other two institutions and professionals involved in
the project:
Customer Company: Involved in the project were the actual end-users, mainly senior engineers from the Board of
Directors. They were very experienced on the application domain, i.e., power management, but had
moderate computer experience, mainly from the users point of view. Their co-operation and comments,
during all the evolutionary prototyping process, were always excellent, leading to a considerable amount of
suggestions and new features added to the prototypes. Usability of the system was their main emphasis.
Supplier Company: It is a good example of the software engineering SMEs. The development team was based on a
small number of computer skilled people, without higher degrees, simultaneously involved in several small
or medium sized projects. They used mainly the just do it approach, but were aware of other models and
methods of software development. They had a strong dependency on the platform and development tool that
had been adopted by the project: the MacOS®1 based fourth generation language.
2.2. SITINA®’s Project Schedule
The project ended up having two phases, each one corresponding to the construction of two distinct versions of SITINA.
The first version only dealt with two small hydroelectric power plants, but the second version is monitoring all the 10
hydroelectric power plants in the production network. The project had a time to market of approximately 14 months.
The project team consisted of 2 people from the Research Institution (RI), 1 project manager, 2 software engineers and 2
hardware engineers from the Supplier Company (SC), and 3 senior engineers from the Board of Directors of the
Customer Company (CC). Figure 3 represents the monthly summary of the actual project schedule.
Month Tasks RI SC CC
(in general terms) (2 Men) (5 Men) (3 Men)
1 General requirements analysis for SITINA®V1. 44 70 26
2 Survey of similar commercial products. Requirement gathering from SCADA/EMS systems. 88 35 11
3 General specification and analysis of SITINA®V1. 88 70 26
4 Implementation and design of the 1st SITINA®V1 prototype. Select and install data 44 232 0
acquisition hardware.
5 Partial tests, 1st prototype evaluation for SITINA®V1. Analysis and Design iteration (2nd 88 232 26
SITINA®V1 prototype).
6 Implementation and partial tests for the 2nd SITINA®V1 prototype. 2nd prototype 58 352 26
evaluation.
7 Final tests. Install and deploy SITINA®V1. 18 352 26
8 Evaluation (requirements gathering) and maintenance of SITINA®V1. 18 232 53
9 Evaluation (requirements gathering) and maintenance of SITINA®V1. 0 70 26
10 Final evaluation of SITINA®V1. Requirements analysis for SITINA®V2. 88 70 11
11 Analysis and design of SITINA®V2 1st prototype. Partial tests and implementation of 58 352 0
SITINA®V2. Data acquisition hardware installation.
12 Partial tests, 1st SITINA®V2 prototype evaluation. Analysis and design iteration (2nd 44 352 26
SITINA®V2 prototype).
13 Partial tests and implementation of the 2nd SITINA®V2 prototype. 2nd SITINA®V2 18 352 0
prototype evaluation.
14 Final tests SITINA®V2. Install and deploy SITINA®V2. SITINA®V2 maintenance. 0 352 26
Figure 3 - Actual Project Schedule: activities and effort in person.hour
1
© Apple Computer Inc.
no reviews yet
Please Login to review.
