This situation also implies dedicating more time to train new team members. The present proposal arises due to the identification of a highly negative impact on the quality of the software, the estimated deadlines and budget, in the late phases of a large software project. It was the first of a program of projects whose teams were scattered in several countries: The users of this first software project were located in Caracas Venezuela. In this second project, the proposal for mitigating threats to requirements was applied, based on the difficulties encountered in the first project.
Teams Distribution in Venezuelan and Brazilian projects. The development strategy for these two projects consisted in moving the analysts from Buenos Aires to the country where the users were located, in order to perform requirements elicitation and preliminary modeling.
The planning, requirement specifications and design were performed at Buenos Aires. Subsequently, the transition to the software factory took place in Pune, in order to start the development. In this factory, the requirement specifications were assigned to developers, who fulfilled their doubts with the analysts. After the development, integration testing was made in Chennai; the testing team deliver the software to the destination country, where the software certification tests took place.
Resuming, in both projects it was used the cascade life cycle with the following seven phases:. Conceptualization Phase involves analysis activities, feasibility activities, tools and infrastructure set up, configuration, scope and business requirements definition, and preliminary architecture design;.
Initiation Phase involves risk management and planning activities, project kick-off meeting, and training of the team;. Analysis and Design Phase involves management activities to update project planning, test plan definition, analysis activities, architectural design, data model preparation, classes design, and test cases creation;.
Transition to Software Factory and Development Phase involves activities of transferring requirement specifications to software factory, code generation, unit test, user manual creation, and elaboration of installation and operation manuals.
Servicios Personalizados
Implementation Phase involves project management activities, deliverables acceptance and closing meetings, training activities for end users, generation of support plan, implementation of deliverables in production environments, and knowledge management activities by creating knowledge transfer documentation for the support team;.
Post-Implementation Phase involves lessons learned meetings, release of project resources and post-implementation review. The requirements process in the Venezuela project was performed along the first and third phase, and their activities are detailed below. In the Conceptualization Phase , the scope and business requirements definition activity involves:.
Citations per year
Elicitation and analysis of business requirements. Prioritization of business requirements. After approval of requirement specifications, during sub-sequent phases, an activity of requirement specifications evolution was performed, despite being a waterfall model. In both projects, every model and document was written in English, being the common language adopted due to language differences of all the stakeholders.
Both projects used a set of predefined metrics provided by the insurance company, which were calculated based on the collected information of each activity. Table 1 only shows the subset of metrics related to requirements. The estimation for the activities was based on the historical information of the company. The metrics related to requirements were estimated according to the complexity of the specification: Low, Medium, and High, also distinguishing them by analysts or developers with or without knowledge of the insurance domain.
The complexity of the specifications was established with the help of a functional point estimator. Metrics related to requirements, used in Venezuela and Brazil projects. During the certification of the software in Venezuela, many rejections from users were identified; those rejections turned on alarms in the new project that was about to start, whose destination country was Brazil. Based on the analysis of the calculated metrics, a proposal was elaborated to reduce rejections in the Brazil project. In the Venezuela project, 20 users from Caracas were involved, 13 analysts from Buenos Aires, 38 developers from Pune and 8 testes from Chennai.
The first ones had an average of 18 pages, the Medium complexity ones had an average of 48 pages and the last ones 82 pages. Details of the metrics obtained in the Venezuela project are presented below. The value of the DFE01 metric presents substantial differences between the estimation and the actual times for creating specifications.
Table 2 also shows that the creation time of a specification made by an analyst with knowledge in the domain is clearly lower than the one created by the inexperienced one. Variation between effective and estimated time for creating specification days. Variation between effective and estimated time for specification approval days. During the transition phase to the software factory, the overlapping of the working hours between Buenos Aires and Pune was only of 2 hours a day and the chosen language was English, which was not the native language of any of the teams.
Every developer made a previous reading of the assigned requirement specification to familiarize with it. Then, they clarified their doubts with the analyst during a session limited to those 2 hours of overlapping. The communication tools used were: Phone conference, Video conference and a QandA management tool. Table 5 represents the estimated and effective times for the transition to the factory by type of specification and by analyst category TRATPT01 metric.
The developers made on average That lack of domain knowledge and of the terminology resulted in losing a significant part of the synchronous time in clarifying basic concepts.
Computer Science > Software Engineering
Variation between effective and estimated time for transitioning specification to software factory hours. Average variation of questions by specification and developer category. Defects existing prior to inclusion of new feature: Errors due to test execution: Errors in promoting code to environments: Defects due to errors, changes or ambiguities in requirements: Table 7 summarizes the threats that affected the Venezuela project, identifying the requirement metrics associated to those threats. Threats identified in Venezuela Project.
It is assumed that many of the threats affected the requirements, since the majority of the defects detected in the certification phase had their origin in the requirement specifications. The largest variation in costs was due to the delay in the deadline. Due to the kind of contract with the supplier, it was necessary to extend the contracts of the whole team, which had a strong impact on the total cost. The time extension indirectly arose due to the rejection of the requirement specifications during formal approval, the amount of developer questions, and transition times to the software factory.
While the amount of defects by specifications seems to be low, the most time-consuming activities seem to come from the requirements stage. There were no problems of rotation of team members, since specific strategies have been implemented for the retention of the staff. Moreover, there were penalties for suppliers in case the established attrition rate would increase a certain percentage. Individual goals of the distributed teams did not affect the project.
The supplier of development and testing, selected for both projects, had been working with the company for several years. Therefore, the supplier knew in detail the regional strategy and the leadership of the insurance company and of other suppliers, and was aligned with the company strategies allowing him to make the right decisions in order to achieve the commitment and alignment of every team members with the shared project goals. Management committee meetings were done monthly; in these meetings not only the project results were presented, but also the company and the suppliers exposed their concerns, risks and respective mitigation actions in order to align goals and priorities of the project teams.
There were no problems regarding tools, such as video conference, shared desks, and management tools, since they were available to the team. This means that no technical problems have appeared. The Brazil project was similar to the Venezuela one, regarding the characteristics of the software to be built. Although the number of requirement specifications was higher, the process to follow and the planning were similar.
This project was planned with an estimated deadline of The project was initially proposed to start 8 months later than the beginning of the Venezuela project, but finally began 13 months later due to the need to implement appropriate mitigation actions. Although, the software development process followed in Brazil was similar to the one in Venezuela, some activities were incorporated in the different phases to mitigate the possible occurrence of threats that had affected requirements in the Venezuela project. The proposal was based on the use of natural language models: The highlights of these models are communication among stakeholders, reduction in ambiguities and inaccuracies by using LEL symbols in every created model, understanding of the problem through the Current Scenarios, and understanding of the interaction between the future software and its context through the Future Scenarios.
The definition and management of these models required additional activities in several phases of the development process described in section 3. Besides, a repository to share these models was incorporated in the Brazil project. In the preparation of infrastructure and tools activity within the Conceptualization Phase , a sub-activity was included for the selection, installation and configuration of knowledge management tools.
Additionally, in the Conceptualization Phase , the scope and business requirements definition activity was re-designed adding several new activities. Therefore, this activity involves the following sub-activities new sub-activities are marked in italics:. Creation of Language Extended Lexicon. In the Initiation Phase , the project kick-off meeting activity included the presentation of the LEL and Scenarios models, and of the knowledge management repository to the stakeholders.
Training took place through meetings held in each of the locations. The main Current Scenarios were presented in detail, providing a high-level view of the essential characteristics of the business. Then, it was delved into the rest of those scenarios to give a correct view of the interaction of different areas, such as, claim and policy administration. It was presented the derivation towards Future Scenarios, which provided a global view of the system goals.
During these sessions, the necessary information related to the LEL, to Current Scenarios and to Future Scenarios was provided, such as the location of these models within the repository of information and the access to them, among other information. In the Analysis and Design Phase , the creation, validation and formal approval of the requirement specifications continued being performed, but these ones were created taking into account the vocabulary defined in the LEL and based on the created Future Scenarios.
These specifications were also stored in the knowledge management repository. During the following phases of the process, the activity of evolution of LEL, of Current Scenarios and of Future Scenarios was added, aligned with changes in business requirements or corrective changes due to a better understanding of the problem domain. Just like in the Venezuela project, there was a similar proportion of analysts and developers with no experience in the Insurance domain.
This was, in both projects, as consequence of the lack of available resources in the labor markets of Buenos Aires and Pune. The amount of pages by specification was similar to the Venezuela project, with a similar composition regarding the complexity. All models were written in English, due to the diversity of languages that the teams had, and were also written using a unified terminology provided by the LEL model.
Tables 8 to 12, show the calculated values for the Brazil project, which are equivalent to the Tables 2 to 6 of sub-section 3. The same time estimations were used in both projects. Comparing Tables 2 and 8, improvements in the time used for creating a specification may be observed. Variation between estimated and effective time for creating a specification days. Table 9 in contrast with Table 3 , shows an important reduction in time consumed for requirements approval versus the estimation for inexperienced analysts.
Analyzing the duplication of time for specification approval, related to low complexity specifications created by expert analysts, has only been able to conclude that the estimation of 2 days was an optimistic one. Variation between estimated and effective time for approving a specification days.
On the other hand, a substantial decrease in the rejections average for medium and high complexity specifications created by inexperienced analysts versus experts, may be observed in Table Average variation of rejections by specification and analyst category. In the transition to the software factory in the Brazil project, the effective versus estimated times were reduced although in low proportion compared to Venezuela project see Tables 5 and In the Brazil project, the number of questions from developers compared to Venezuela was considerably reduced, being on average 8.
It was feasible to equal the same number of questions for inexperienced and expert developers, except for highly complex specifications Table These defects were originated in 69 specifications, from a total of ones. The intelligibility of a modeling language is a characteristic depending on an ability and background of the interpreter, thus it is difficultly measurable.
Nevertheless some researchers address this topic, e. The ability to represent workflow patterns shows the expressiveness of the language. The complexity of models increases with a less expressive language. The intelligibility decreases and the number of mistakes grows by the increase of the complexity of models. Besides the expressiveness of the language, coverage of process elements identified in [2] is required.
As we would like to create and modify our process models quickly and easily, another goal is to have a suitable software support for the chosen language. Besides freely choosing the software used for modeling, saving into a portable format may also be useful. The more a technology or a modeling solution is used, the easier its introduction and acceptance. As a result, it is important to choose a solution as widely applied as possible. Summarizing, we considered the following aspects: These are the comparison criteria for selecting the process modeling language.
We deal with the criteria in order of their importance. The order of importance was decided by us taking into account project needs. They asked participants to fill in questionnaires, then they analysed how the participants can interpret the 12 models presented. The other important factor in terms of the intelligibility is the model size, which can be measured with different metrics [20], [22]. Additional possible influencing factors of the intelligibility could be the expertise of the interpreter in the modeling language, the components of modeling language, the layout and arrangement of figures.
In terms of intelligibility [6] we did not see any difference between UML 2. From among the three modeling languages, software designers and developers use UML. In Table 1 we map process elements identified to the three preselected process modeling language elements. In order to understand how people perceive PML elements, besides the official specifications we looked at additional tutorial sites e. Table 1 shows that most of the process elements identified previously are present in BPMN, EPC and UML activity diagrams, therefore we consider them equally good for representing processes.
Such elements are the fork-join, branch-merge, basic and extended activities, but these are defined using different notations. The equivalent of some elements do not exist in the other diagrams, which make the automatic conversion difficult.
Zádor Dániel Kelemen - Google Scholar Citations
He remarks one single exception, that the meta-model of activity diagram does not have a suitable structure to describe a certain workflow pattern. White concludes that the two approaches are different views of a single meta-model [6]. EPC was examined by Mendling et al, based on the 20 patterns of Aalst.
Deficiencies were discovered and corrections were also proposed [26]. It is difficult to rank the three approaches from this point of view; all the three can represent the most of fundamental workflow patterns.
Process Based Unification for Multi-Model Software Process Improvement
However, a distinction is needed to be made: Therefore, we consider UML the most software- supported solution. In spite of the fact that most modeler tools support UML, it is possible to find suitable solutions for the other two languages too. The question is that, how the different applications will support it. It is visible that all three formats are based on XML and freely available, but deficiencies exist in all three cases on the side of implementation.
The opportunity is given; the application of the standardised format depends on the developers of modeling tools. Therefore, they may count on a bigger support than EPC. From the portability point of view, XMI format was implemented by several manufacturers therefore, we consider the UML the most portable modeling language. EPC was introduced at a concrete company with no consortium behind it, which resulted a more modest spreading compared to the former two.
In the business modeling multiple notations are used, starting from the simple flowcharts towards the BPMN, EPCs and UML; therefore it is difficult to tell which one is the most widespread in this area.
Because of UML is spread in both areas, we consider it the best solution for our goal. At the same time, taking into account the previously defined criteria, BPMN seems the most appropriate solution from the intelligibility and expressiveness point of view. Verified email at nng. Articles Cited by Co-authors. Title Cited by Year Identifying criteria for multimodel software process improvement solutions — based on a review of current problems and initiatives ZD Kelemen, R Kusters, J Trienekens.
Journal of Software Maintenance and Evolution: Dublin, Ireland , Evolution and Process 28 11 , ,