Conducting a process assessment is a dz.cult task that requz.resto take various z`ssuesunder consz.deratz.onW.hilst g"eneral(development. procurement) processes have been wz.deLystudz.ed and multiple references z.nIz.'teraturexist, specz`flcprocesses (e.g. database design) have not recez`ved so much attention"In order toface thz"psroblem a study on the z.temsrelated to database design process evaluation has been pezformed. SPICE/ISO-fEC 15504 has become a popular modeL to pezform assessments, and it is z"nternatz"onaalLcycepted. For thz.sreason it has been used as our reference model The results of our work folLowz`ng the specz.flcations defined in the process dz`mensz"oonf SPICE are described wz.thz.nthz"psaper.
In order to allevz.ate the task of managing the assessment, we have developed an integrated tool that provides assistance z.nthe evaluation processes. It oers a ~ fn"endly and easy-to-use z.mezface to carry out assessments. This tool intends to support to the assessor :`n tile task of decz.dingthe level of achz.evement of the work products and base practices. This tool generates reports and statistics }Torn the evaluation informatz"onI.t also provides with the possz`bz.Lz.ozYf having more than one z-nstanceof evaluation performed by dz.erent assessors. Too\ basz.cguidelines are presented.
Nowadays databases play an essential role in systems such as network management, data warehouse and command systems. Good performance of the systems is fundamental and relies on an appropriate database with a good design. The complexity of these systems and their associated databases is increasing at a high speed. Therefore database design process assessments play an important role in the task of guaranteeing that the new functionalities of databaseswill be attained.
Currentprocess assessments models must be general enough in orderto be applied,in principle, to any kind of software process instance. Therefore,it might happenthat, for some specific processes, existing models could not deal with all the information required to properly assess the process [1]. We understandthat this is the case for databasedesignprocess and SPICE/ISO-IEC15504 [4].
SPICErI:SO-IEC 15504 is now widely accepted as a reference model for process assessments and this has been one of the most important reasons to take it as our framework Then we studied the database design process and obtained a mapping of a generic database design process onto the SPICE/ISO-IEC 15504 process dimension. A summarized description of the results, originally dascribed in [2,3], is presented in this article.
As we believe thatthe task of conductingan assessment is hardand deals with a lot of information,we thoughtthat it could be of interestto implement a tool that cou3dgive support during the assessment of database design processes. The tool stores intermediate results and generates reports. Other tools are described in literature [5]. Our tool is specific to the process of defining database schemes. An overview of this tool is described in the article. To end the paper a number of conclusions are presented. 2. Database design process assessment
As we mentioned in the introduction EMEDITA was the startingpointto map a generic databasedesign process onto SPICE/ISO-IEC15504.
As figure 1 shows, EMEDITA is comprised of a set of phases, which contain stages which, in their turn contain tasks and finally, basic activities, subtasks [7]. Subtasks are taken into account to develop the mapping with SPICE base practices~ EMEDITA has been developed according to METRICA framework, the Spanish government system-development methodology (l1]. EMEDITA is compliant with ISO/mC 12207 [10] and has considered database design usual practices as described in {6,8,9]. The findings of mapping a Generic database design process onto the SPICE-ISO/IEC 15504 process model were described in (2]. The most relevant outputs are summarized below, and some of the basics of the mapping guidelines are presented in here as well.
The Capability dimension has been analyzed and, basically, no changes have been introduced except for those corningindirectly from the process dimension~ SPICE is defined on a general-purpose basis. We studied up to what extent SPICE"ISO/IEC15504 offers guidance for database design process assessment and improvement.Specific characteristicsof database become part of a problem when they are treated like any other conventionalsoftware module such a control module or a man machineinterface.
In Orderto analyze the appropriatenessof SPICE for database developments, first, mapping between a generic database design process, obtained from EMEDITA, and SPICE was carried out. A group of tasks that eventually, could be mapped onto SPICE base practices were identified. The second step was to define a number base practices that we considered adequate to support a databaseassessment.
Only the process dimension was taken into consideration as a starting point. The mapping was done maintainingthe maximumcoherence degree between both models and trying to adjust as much as possible their contents. Mapping showed that database design tasks are not fully contemplated in SPICE. We could say that database design tasks would not feel at ease in SPICE. Once processes were mapped,the second step was to find a group of base practices where they could fit, as maintainingboth models philosophy.
The problem of comparing conventional software concepts with database concepts raised up in the base practices mapping. The architecturaldesign concept was considered to be similar to the idea of he conceptual schema definition in database, as well as the concept of detailed design was compared with the rest of subtasks performed to achieve a database physical design. The mapping was carried out taking this criteria into consideration.Figure2 shows the result. STAGE 2: DB | ~ woR K P R oOucTs & T H El R C H A RA C T ERl5T IOS Finally the workproductsof SPICEbase practices were analyzed from the database point of view. They representedthe most difficult partof the mapping as some of SPICE work products matched those of the database design methodology, but their needed characteristicsin a database context were rather different from the SPICE specifications. Some other database work products were missing in SPICE.
The first conclusion that we can draw is that the mapping between the database design methodology and the Spice reference model is not that easy. Actually we understandthat databasedesign tasks have not been fully contemplated within SPICE. We could say that database design tasks would not feel at ease in SPICE. DB: RelationalDatabaseDW: Datawarehouse
Fig. 2. EMEDITA vs SPICE
As far as base practices are concerned, the problem of concepts that cannot be assimilated raises up. In the mapping between SPICE base practiceDevelop software architecture and all the practices of the first design approach, there was a need to compare the concept architecture to conceptual design. It seems that it is possible to integrate both ideas. However the uncertainty still remains, because this mapping is forced by the need of expressing the methodology with SPICE, overlooking the lack of accuracyin this decision.
This inflexibility is a consequence of the existing gap between database design and conventional software modules design that, from our point of view, SPICE does not addresswith enough depth.
Work productshave representedthe most difficult part of the mapping"Some of them turned out to be valid for the database methodology, but the characteristics were completely different from SPICE specifications, which means that thereis no criteriato follow in SPICE to judge whether a database product has been successfully producedornot.
Some otherdatabaseworkproducts did not appearat all in SPICE as the base practicesthatproducethem were also missing. An importantcase was Data Quality, a difficult practicefor which SPICE offers no guidanceto performan assessment We are also studying this issue more in depth and some first resultswere presentedin [profess].
The maingoal of the tool is to provide the assessor with supportforevaluating databaseprocesses. In orderto carry out the evaluation EMEDITA was used with the modifications that are explained above. Both process and capabiliry dimension have been implemented. Capability dimension has been maintained basically unchangedwith respect to the SPICEmodel" vor m14 \d_Pm | Id_Pry Id_Jn [ Id_Wp fd_Sp __i -\ .
|
The too! is comprisedby a graphicaluser interface that basically displays informationrelated to EMEDITA (work products, base practices, management practices. process attributes...)and a database that stores the results of the evaluation. The too! databaseis accessed throughODBC, which adds flexibility to migrate to a different database management system.
The data mode! schema is presented in figure 3. Within this mode! each evaluation is considered as a project withinthe toot. It is possible to have differentprojects for the same set of processes. Within a project it is also possible to carryout several assessments, that can be seen as snapshots of the set of processes. Each snapshot is caned instance. One instance is comprised of an evaluation mark and a report of such evaluation. Several base practices and work products can be analyzed in an evaluation.
A different evaluator can produce each instance, The evaluation goals can be different or they can be just performedin differentmoments. Thus, a projectmay have several instances, each of them containing specific information of the circumstances under which the evaluation was performed. This information is besides fundamental to correctly interpret the results of any evaluation. Whenever an evaluation is performed, a projectand an instance must be specified.
The Process Dimension evaluation offers the list of Base practices and Work products of alt the database design processes. The Base practices and Work products are then measuredaccordingto the evaluators criteriaand the given values are stored.
The Capability Dimensz.onevaluation offers the list of Process Attributes and Management Practices associated to each database design process, and the evaluator also estimates them. The values of each evaluated process are stored inthe database
Inthe following paragraphswe presentan example, and we explain the evaluation procedure for the process and capabilitydimensions
We have considered the subtask 2.2.1.1 Entity /dentcation in EMEDITA and only one base practice, BPI, Determine entities and their description as the following synoptic diagramrepresents: Salidas:
Input:SW requirements Output:High Level SW design
High level soare design, which is an output workproduct.
In the evaluation we first evaluate the workproducts. The evaluator assigns a value for these two workproducts according to his eriteria. The values can be: Fully, Largelly, Partially, None and Unknown as shown in Figure 4.
When the work products are evaluated we can assess the base practices. The associated work products are displayed in order to give supporting evidence to the achievement rating that will be assigned to the base practice. The rating values are also: Fully, I-.argelly, Partially, None and Unknown,
When the base practice is evaluated, we have completed the process dimension evaluation and a report can be then generated with the assigned ratings. 32. Capability dimension evaluation
For our process all the Management Practices are displayed and a value of Fully, Largelly, Partially, None and Unknown can be assigned to them. Once the management practices are evaZuated we can continue on evaZuating the Process Attributes.Fully, Largelly, Partially, None and Unknown are the values that can be assigned to them.
Finally we can generate a report of the CapabilityDimensionEvaluation.
Within this paper we have described the results of a study perforrned with the objective of analyzing the validity of model assessments, such as ISO/IEC 15504 SPICE, for specific processes such as databasedesign. We have also presenteda tool specifically designto supportthe evaluation of data base designprocesses.
After studying the impact of database design processes in current frameworks, such as SPICE/fSO-IEC 15504, our conclusion was that SPICE/ISO-IEC 15504 is oriented towards general software processes and, therefore, there exist a lack of specificity. SPICE has proved as a powerful framework but lacking some specific issues such as some base practices and workproducts. The evaluation tooZ that has been produced in the context of the project takes into account all those issues.
5. Acknowledgements
The work presented within this paper has been performedin the context of the project PROCBD and under a contract with CRONOS ISERlCA S.A. This project is partially supported by the Ministry of Industry of Spain Ref- T87/1998, ProgrammeATYCA.
[1). Data QuaIz.ty and Database Design Process Assessment - Juan Garbajosa Pedro P. AJarcon,Hector Garcia Maria Alandes. Macario Polo DIQ2OOO. Orlando,2000 [2]. Database design in the context of the SPICE process dimension Juan Garbajosa Hector Garcia' Maria Alandes~ Mario Piattini Ist International SPICE conference, SPICE`2OOO.Limmeric2k0,00 [3]. /ntroaucing the data role in models for database assessment - Juan Garbajosa Pedro P. Alarcon, Hector Garcia Maria Alandes. Mario Piattini International Conference on Fredact Focused Software Process Improvement. PROFESS2OOO,OuIu2,000. [4). /SOIIEC FTCI TR 15504'. 1999 Information Technology - Sof!:wareProcess Assessment. Parts J-9, [6}~Database Design. An Enti Relationship Approach Batim`,C., Ceri S.. Navathe, S. Benjamin Cunlln:ings, 1992 [7]. Methodology for the DeveLopment of Data Warehouse Projects (in Spanish) - Carrnona O.. Garcia H. - MinorThesis. Technical University of Madrid.E.U~ Informatica.1999.
Isl"Database Models (In Spanish) Piattini,M- - RA-MA. 1999,
[IO]. ISO/IEC JTCI I 12207:1995 Software Lifecycle Processes [I I]. Methodology for PLannz.ngand Development of Information systems METRJCA versz`on 2 Ministry of Public Administrationof Spain.