=Paper=
{{Paper
|id=Vol-1677/paper08
|storemode=property
|title=Combining Agile and Traditional Methodologies in Medical Information Systems Development Process
|pdfUrl=https://ceur-ws.org/Vol-1677/paper08.pdf
|volume=Vol-1677
|authors=Petar Rajkovic,Ivan Petkovic,Aleksandar Milenkovic,Dragan Jankovic
|dblpUrl=https://dblp.org/rec/conf/sqamia/RajkovicPMJ16
}}
==Combining Agile and Traditional Methodologies in Medical Information Systems Development Process==
https://ceur-ws.org/Vol-1677/paper08.pdf
8
Combining Agile and Traditional Methodologies in
Medical Information Systems Development Process
PETAR RAJKOVIC, University of Nis, Faculty of Electronic Engineering
IVAN PETKOVIC, University of Nis, Faculty of Electronic Engineering
ALEKSANDAR MILENKOVIC, University of Nis, Faculty of Electronic Engineering
DRAGAN JANKOVIC, University of Nis, Faculty of Electronic Engineering
Having experience with different traditional and agile methodologies in medical information system development and upgrade
projects, we support the statement that no single methodology can be used with its full potential in all cases. Instead,
mentioned methodologies have their own place in complex software projects and within certain category of sub-projects give the
best results. In this paper we presented the guideline on choosing adequate methodology in different development and upgrade
projects. All examined projects are defined within the scope of larger medical information system called Medis.NET developed
by our research group, and deployed in 30 healthcare institutions. The bottom-line is that during requirement collection we rely
on model and feature driven development supported by automatic code generation tools, which lead to faster prototype
generation. Next, dividing the set of functionalities to sub-projects we group them in three categories – core projects, user-
oriented, and loosely coupled application. For core projects we find traditional methodologies suitable since their outcome is a
stable process and rich documentation. User-oriented sub-projects are developed under standard SCRUM, while for loosely
coupled applications we chose Lean. We measured the effects of chosen approaches comparing time spent against estimated
time for development, and by analyzing code metrics. Code metrics were automatically generated by our development
environment, Microsoft Visual Studio, and we take into account few major values such are maintainability index, lines of codes,
class coupling and cyclomatic complexity. In addition, we propose an adaptation for Lean model which gave us promising
results in software upgrade projects. The proposed approach put additional responsibility to lead architects, since have to
properly identifies all pros and cons for different methodologies and, knowing this well, wisely choose the right methodology for
the right sub-project.
Categories and Subject Descriptors: H.4.0 [Information Systems]: General; D.2.8 [Software Engineering]1: Metrics; D.2.2
[Software Engineering]: Design Tools and Techniques
General Terms: Design, Management
Additional Key Words and Phrases: Traditional software development, Agile software development, Lean, SCRUM
1. INTRODUCTION AND MOTIVATION
Since 2002 our research group was involved in many development and upgrade projects targeting
medical information systems (MIS) [Rajkovic et al. 2005, 2013]. Initially, we relied on standardized
traditional methodologies such are Waterfall, Spiral [Boehm 1988] and Rational Unified Process
(RUP) [Kruchten 2004]. The main advantage of traditional methodologies was, and still is, a concise
set of guidelines and significant volume of produced documentation [Leau 2012]. The main problem
were long phases resulting with late response to potential changes requested by the end user. By
introducing agile methodologies [Beck et al. 2001], primarily SCRUM [Schwaber et al. 2002], that
require more interaction with the end users, we managed to reduce the number of new, surprising
requests coming in the later stages of the project [Black et al. 2009]. On the other side, we faced with
the set of new and unexpected problems – problems with lower volume of generated documentation as
This work is supported by the Ministry of Education and Science of Republic of Serbia (Project number #III47003).
Authors’ addresses: Petar Rajkovic, University of Nis, Faculty of Electronic Engineering – Lab 534, Aleksandra Medvedeva 14,
18000 Nis, Serbia, e-mail: petar.rajkovic@elfak.ni.ac.rs; Ivan Petkovic, University of Nis, Faculty of Electronic Engineering –
Lab 523, Aleksandra Medvedeva 14, 18000 Nis, Serbia, e-mail: ivan.petkovic@elfak.ni.ac.rs; Aleksandar Milenkovic, University
of Nis, Faculty of Electronic Engineering – Lab 533, Aleksandra Medvedeva 14, 18000 Nis, Serbia, e-mail:
aleksandar.milenkovic@elfak.ni.ac.rs; Dragan Jankovic, University of Nis, Faculty of Electronic Engineering – Lab 105,
Aleksandra Medvedeva 14, 18000 Nis, Serbia, e-mail: dragan.jankovic@elfak.ni.ac.rs;
© Copyright © by the paper’s authors. Copying permitted only for private and academic purposes.
In: Z. Budimac, Z. Horváth, T. Kozsik (eds.): Proceedings of the SQAMIA 2016: 5th Workshop of Software Quality, Analysis,
Monitoring, Improvement, and Applications, Budapest, Hungary, 29.-31.08.2016. Also published online by CEUR Workshop
Proceedings (CEUR-WS.org, ISSN 1613-0073)
8:66 • P.Rajkovic, I.Petkovic, A.Milenkovic, D.Jankovic
well as problems with social relations [Leau 2012]. For some users we become annoying and tedious,
and some of our team members feels uncomfortable due to the frequent interaction with the clients.
With standard methodologies we realize that the stress level increases when project ends the
development and has to enter to testing phase. With agile, this problem was also present, but stress-
full intervals are scattered during the whole process and last shorter. After SCRUM, we looked for
Lean methodology [Poppendieck 2003]. The main advantage was the task-based organization of
development process. Having larger number of smaller tasks, allowed us to group them in logical
packages and move these packages through Kanban table with different speed. This resulted in
continuous system integration and our users were not so flooded with demo and test sessions.
When our first research and development project was about to finish in 2007, we had several pieces
of software already finished and had the experience with few different software development
methodologies (SDM). Based on that experience and lessons learned, we actually stop looking for a
single methodology that fits all the cases of development and upgrade, but define the set of guidelines
that would help us in choosing the adequate methodology for each sub-project. In 2008, we started
with the preparation for new development project which primary output was a MIS dedicated for
Serbian primary and ambulatory care. Defined set of the guidelines for choosing appropriate
methodology we applied in mentioned development [Rajkovic et al. 2009]. Complete project consists of
33 development and upgrade subprojects run under different SDMs.
In related work section we described the most important works that were a great support to our
idea. Next section this paper presents our guideline for choosing proper methodology for proper sub-
project. Since we were encouraged with initial results, we decided to propose a modification of Lean
approach by incorporating some SCRUM concepts, which is described in separate section. In result
section, we evaluated our development and upgrade projects that was carried under Medis.NET
software project. The evaluation is based on the code metrics provided by Microsoft Visual Studio and
project timeline analysis.
2. RELATED WORK
The work presented in [Leau et al. 2012] clearly describes all the advantages and disadvantages for
traditional and agile SDMs, claiming that adoption of proper methodology is crucial for governing
software life cycle and later system acceptance. We faced with all of situations described in [Leau et
al. 2012] in our projects developed in period 2002-2007, and start going to the idea that should not
look to one almighty methodology, but to identify different types of projects and the methodologies
which would lead to the most successful scenario. Due to frequent changes in many areas of
stakeholder requests, as well as in legislative, in period of almost 15 years, we had enough
opportunities to check different methodologies.
Using metrics to evaluate software projects maintainability is not a new idea. Since well-known
work of [Coleman et al. 1994], many different studies were conducted. In that branch, we found
[Doherty 2012] as important for our research. This paper presents analysis on the most important
success factors for traditional and agile methodologies. This analysis shows that not methodologies
themselves, but related factors such are user interaction level, team competence, or quality of
collected requirements have bigger effect on development process organization and later system
acceptance. In that light, it is easier to connect SDM with mentioned factors, and based on them chose
a proper methodology.
Introducing hybrid development methodologies is also a topic discussed in literature. For example,
[Runeson 2005] discusses introduction of agile methodologies to traditional stage gate model.
According to this work, the role of gate model is in strategical planning, while agile approach suits
better for “microplanning, day-to-day work control, and progress reporting”. Finding the suitable place
for agile methodologies within large scale projects is described in [Lindvall et al. 2004]. Authors based
the research on the data gathered from large companies (Daimler Chrysler, ABB, Nokia) and analyzed
their experience. The general conclusion is that agile methodologies can match the needs for some
specific types of the projects, while the major challenge lies in “efficient integration the agile project
Combining Agile and Traditional Methodologies in Medical Information Systems Development Process • 8:67
into overall environment”. During the last decade agile methodologies developed rapidly and latest
researches conducted on overall use of SDMs show significant advantage of SCRUM versus Waterfall
[Shane et al. 2015]. Unfortunately this research shows only overall statistics, but not drilled down to
specific domains of developed projects.
Since we decided to use spiral model, SCRUM and Lean as base development methodologies, we
rely on Model Driven Development (MDD) in requirement collection, and on Feature Driven
Development (FDD) in prototype building phase. Works presented in [Torchiano et al. 2013] and
[Loniewski et al. 2010] gave us well argumentation for such decision. Beside we tend to use MDD also
in later stages, mentioned three methodologies are the ones that we followed in our projects. Another
two important aspects for optimal methodology utilizations are planning [Virani et al. 2014] and
customer communication [Korkala et al. 2010]. These two “environmental” variables should also be
considered when it comes to choosing the methodology for specific project. In general, many sources
advocating usage of mixed and/or blended methodologies can be found. For example, we rely on
[Okada et al. 2014] and [Hoda et al. 2013] when defining the updated lean model for software upgrade
projects.
3. GUIDELINES FOR CHOOSING A METHODOLOGY FOR DEVELOPMENT PROJECT
Basically, every SDM we used in our first development project (Waterfall/Spiral/RUP, SCRUM and
Lean) has its own advantages and disadvantages [Black 2009]. For this reason, we defined a set of
guidelines that should help us in defining cases when some SDM should be applied. The summary of
the guidelines contains following statements:
- During requirement collection phase, it is necessary to start building domain models and clearly
identify main features
- Identify extension points in created model as earlier as possible
- Use component generation tools in order to reduce development time
- Categorize sub-projects as core projects, user-oriented (frontend) and loosely coupled components
- For core projects use traditional or agile methodology familiar to all assigned team members
- Frontend project develop under SCRUM to ensure proper communication with end users
- For loosely coupled components use Lean
- When it comes to team members - take care not only on technical, but also social skills, and assign
people accordingly
- If needed, experiment with new development approach only in low to medium scale fronted and
loosely coupled
- Do not experiment with new development approach in mission critical or core components
We started applying it in year 2009 when development of Medis.NET began. Thanks to the earlier
projects, we had enough domain and process knowledge to define basic entities for future system.
Also, we had developed domain models as well as model based code generation tools that should help
us in overall improve our development process. Mentioned MDD tools are intensively used during
requirement specification and prototype building phase [Rajkovic et al. 2015]. Once, when
requirement collection phase is finished and customer signs request document, we already have initial
advantage, since, until that moment, our domain models are on the way to be finished, system
architecture is defined and the most of sub-projects are identified and implementation technology is
chosen.
Next step is to define sub-projects and to divide them in three major groups – front-end projects,
back-end projects and loosely coupled components. As front end projects we categorize these that are
rich with GUI elements and forms. The focus of future’s everyday use, from the customer point of
view, will be on them. For this reason, it is important to maintain constant contact with prospective
users. These sub-projects are developed under SCRUM methodology. Not directly exposed to the
customers are back-end related functionalities containing business logic and data processing
functionalities. The projects belonging to this category make backbone of the system. Due to the
importance, the most detailed documentation is required for this category of the projects. For this
8:68 • P.Rajkovic, I.Petkovic, A.Milenkovic, D.Jankovic
reason, we usually choose some of traditional methodology based on a strong set of rules. Another
advantage that traditional SDMs brought to this category of the projects are long testing and
verification phases which are necessary for the most critical parts of the complete system [Black et al.
2009].
For partially independent and loosely coupled sub-systems, we choose Lean as a compromise
between SCRUM and traditional methodologies. In MIS environment, to this category belong projects
that are developed for some specific department usually requiring higher level of interaction with
third party software and/or medical equipment. Next, common request is that these applications can
work disconnected from the central MIS. The best examples for this type of the projects are
applications for radiology and biochemical laboratory. Lean methodology looked as the good balance
between SCRUM and traditional in this particular case. Equipment integration would be usually
divided in sub-projects defined per communication protocol, which in reality means per device, or with
larger institutions per devices that belongs in the same generation of certain manufacturer. In the
scope of lean methodology all the tasks related to same communication protocol are grouped in the
same work packages. Developed functionalities are then tested package by package, and the
interaction with the users during the development process is reduced comparing to SCRUM.
4. LEAN MODEL ADAPTATION FOR SOFTWARE UPGRADE PROJECTS
The statuses that one task passes through according to the Lean model are: definition and moving to
backlog, approving and moving to to-do list, designing, developing, testing and moving to the list of
finished tasks. Initially, we fully relied on original lean approach. The good side of this approach was
a possibility to group tasks in logical packages, and to change their statuses according to Kanban
table. Grouping tasks to logical packages allowed us incremental development and partial delivery to
the customer. On the other side, the main problems came in integration testing when discovered bugs
can trigger more work needed than expected causing partial or even overall deadline extensions.
Another weak spot, from our point of view, is moving tasks to to-do list. In the moment when task
reaches to-do list, only general requests are known, and, often, followed with even more general
assumptions. Due to this fact, design phase would then last longer, since design phase for upgrade
projects need to include not only new functionalities, but also integration to existing system. This left
a lot of space for misinterpretation and false assumptions. Even worse, this can happen also during
development and testing phases. In upgrade projects, this kind of problems is common and even
expected. This, it is important to identify them as earlier as possible and the react according the case.
For mentioned reasons we proposed the update of Lean approach for upgrade projects (Fig. 1). The
proposed improvement is based on changing the role of design phase. Design phase will be split and
partly incorporated into to-do list creation and partly to development phase. Looking at the design
phase itself, we identified two major parts – functionality design and integration design. Designing
integrational parts for the new components is proportional to their integration level. Thus, we
considered this part of the designing phase is one of the most critical. In order to reduce the possibility
for errors in later stages, this part of design phase is moved to to-do list creation.
The cost of this decision is slower forwarding tasks through Kanban table in initial phases, but the
benefit is visible later when missing links are rarely identified. Another benefit we notice is an
effective introduction of new team members to the functionality of the existing system. Working
together with experience colleagues they are able to get the insight to the initial system and to better
understand the role of the update they will work on. Additional set of tasks moved to this phase is the
improvement of software’s domain model (if needed) and the initial generation of the components that
could be automatically generated. Now, when task is moved to to-do list, it has attached the document
and code snippets needed for later development and the integration. Design phase now remains only
with high-level design of new functionality followed with risk assessment. Detailed design is moved to
development phase. Development phase is enriched also with initial testing that should bring verified
component to the next stage of the process. Enriching the development phase by detailed planning on
the beginning and by functional testing at the end, results in sub-projects consisting of several tasks
Combining Agile and Traditional Methodologies in Medical Information Systems Development Process • 8:69
that can be treated as small software projects. These small software projects are then developed using
SCRUM paradigm. We tend to keep these sub-projects as SCRUM guided projects with just few
sprints that are responsible for development of integration ready components.
Fig. 1 Proposed Lean Model Adaptation
The next stage is testing. Since the functionality testing is done in development phase, the main
part of testing phase is now integration testing. Since, in many cases functionality testing includes
some segments of integration testing, this part is often used for internal acceptance test. On this way,
the majority of bugs is identified earlier in development stage, so in ideal case, this step is more a
formal verification. After this part is successfully finished, product is moved to the hands of
prospective users for their acceptance testing. The main benefit of proposed update is lower number of
moves back in the Kanban table, which results with faster development. Also, created code is with
higher maintainability index (MI) easing future maintenance and further upgrades. In next chapter
the results we get for projects developed under updated Lean are compared with these developed with
standard Lean.
5. RESULTS AND DISCUSSION
With first MIS systems we developed, in period 2002-2006, we got the opportunity to test several SDM
both for development and upgrade projects. As it has been explained in previous section, we decided to
rely on MDD and FDD in early stages of development, but use traditional (Waterfall/Spiral), SCRUM
and Lean for software development itself. [Atalag et al. 2014]. To calculate the effects of different
methodologies we used standard code metrics offered by Microsoft Visual Studio development
environment to check the code maintainability. To check development efficiency, we used ration
between estimated and time needed for development. For calculating time wise efficiency, we used our
projects logs and for code metrics calculation we used embedded code analysis tools that came as the
standard part of Microsoft Visual Studio [Microsoft Library 2015]. As the leading parameter for the
discussion, MI was used. Along with it, class coupling, number of lines of codes, cyclomatic complexity
(CC), used methodology and project type are presented. We used our SDM assignment approach for
total 33 sub-projects within our MIS (Table 1). CC is a measure of structural code complexity. Since it
represents number of paths in the program, lower values are better. Higher CC results in harder code
understanding and larger number of tests needed. CC should not be evaluated separately of the
number of the lines of code. Higher number of lines of code will usually result in higher complexity
number, so the relevant could be the ratio between complexity and lines of codes. As this value is
lower, the code should be easier to maintain. At the end, the parameter named MI is a value in 0-100
range that should describe the relative easiness of code maintenance. Higher value is better. Microsoft
states that minimal value claiming good maintainability is 20. Based on our experience, all the
projects having this index lower than 50 are not quite easy maintainable especially for new team
members. The formula for MI (taken from Microsoft Development Network) used in Visual Studio
code analysis tool looks like:
Both best ratio between time used versus estimated (UvE) and the best overall MI we got with
projects developed under Lean methodology. Between SCRUM and traditional methodologies,
8:70 • P.Rajkovic, I.Petkovic, A.Milenkovic, D.Jankovic
traditional methodologies gave us slightly better values for development, while SCRUM was
significantly better with upgrade projects. Looking the difference between development and upgrade
project Lean and SCRUM gave better results with upgrade than development projects. On the other
side, usage of standard methodologies in upgrade projects resulted with significantly lower MI.
Table 1 Medis.NET MIS – Comparison of the code quality for different projects (Columns: MI – maintainability index, LoC –
lines of code, CC – cyclomatic complexity, RCC – relative cyclomatic complexity (CC/LoC), UM – used methodology, PT – project
type, UvE – time used vs time estimated displayed as percentage)
Project Name MI LoC CC RCC UM PT UvE
MedisControls 81 18131 4513 0.25 SCRUM Dev 1.02
MedisData 86 19772 11115 0.56 Traditional Dev 0.96
MedisDataAcquisitionLab 76 489 175 0.36 Lean Upgrade 1.95
MedisDental 64 2293 582 0.25 SCRUM Upgrade 0.88
MedisEHRCore 54 21571 2499 0.12 Traditional Dev 0.91
MedisEHREditDialogs 61 25693 4422 0.17 SCRUM Dev 1.12
MedisEHREditDialogsGin 57 1295 153 0.12 SCRUM Dev 1.45
MedisEHREditDialogsIZIS 71 255 45 0.18 Modified Lean Upgrade 0.75
MedisEHREditDialogsVisiting 44 10284 521 0.05 SCRUM Upgrade 1.15
MedisEHREditDialogsSportMed 29 1266 30 0.02 Traditional Upgrade 4.33
MedisEHREditDialogsStandards 62 1412 111 0.08 SCRUM Upgrade 0.85
MedisEHREditDialogsDocuments 55 3706 435 0.12 Lean Upgrade 1.04
MedisEHRFactory 66 286 67 0.23 Traditional Dev 0.55
MedisFinanceReporting 77 10709 1967 0.18 Lean Dev 0.92
MedisDoctorAssignment 77 1136 188 0.17 Lean Dev 0.61
MedisIZISCore 89 1163 425 0.37 Modified Lean Upgrade 0.80
MedisIZISExchange 83 658 276 0.42 Modified Lean Upgrade 0.76
MedisCommunicationService 58 3989 641 0.16 SCRUM Dev 1.01
MedisConfiguration 61 6454 838 0.13 Traditional Dev 1.02
MedisLabIS 61 7506 1291 0.17 Lean Dev 1.09
MedisOccupational 48 6042 324 0.05 Traditional Upgrade 2.19
MedisTimeSchedule 67 3720 531 0.14 SCRUM Upgrade 0.79
MedisDocumentsExchange 78 562 139 0.25 SCRUM Upgrade 0.84
MedisFinance 42 1005 80 0.08 SCRUM Dev 0.99
MedisReception 63 5600 951 0.17 SCRUM Dev 1.06
MedisAccessControl 78 2693 941 0.35 Traditional Dev 1.12
MedisRadiology 60 2328 298 0.13 Lean Dev 0.97
MedisWorkOrganization 74 4853 956 0.20 Modified Lean Upgrade 0.98
MedisReports 85 164 100 0.61 SCRUM Dev 1.67
MedisSearchControls 66 4581 703 0.15 SCRUM Upgrade 1.33
MedisInsuranceExchange 78 1312 467 0.36 Lean Dev 2.01
MedisPatientScheduling 67 2538 528 0.21 SCRUM Upgrade 0.89
MedisPatientDocumentation 62 4080 715 0.18 Lean Dev 0.95
As it has been mentioned, we chose standard methodology twice for upgrade project. Once for sub-
project for a department where (we believed) we had strong stakeholder request (MedisOccupational),
while the another was the extension of EHR and corresponding GUI library for sports medicine
department (MedisEHREditDialogsSportMed). With both cases we run into well-known problems
with standard methodologies – we received too many update requests to late in project scope. Chasing
the deadline, we ended up with on-site updates in fastest possible manner. Eventually, we get the
projects with significantly lower MI. Luckily, project MedisEHREditDialogsSportMed having
mentioned index of 29, has relatively small number of lines, so later bug fixes could be conducted
without many problems. Problems with significant delays we experienced in projects where scope
change and project extensions happened too often (such are reporting service and integration with
Combining Agile and Traditional Methodologies in Medical Information Systems Development Process • 8:71
insurance fund). In this cases, chosen methodologies helped in a way that resulting code had
acceptable MI, but the influence of selected methodology on overall delay was minor.
Table 2 Medis.NET MIS – code quality summary (Ovl – overall, Dev – development projects, Upg – upgrade projects)
Number of projects Maintainability index Lines of code Time needed vs
time estimated
Method Ovl Dev Upg Ovl Dev Upg Ovl Dev Upg Ovl Dev Upg
Lean 12 6 6 71.08 69.17 73.00 3183 4512 1854 1.00 1.02 0.96
Standard 8 6 2 68.25 69.17 65.50 3908 4512 2097 1.03 1.02 1.15
Modified 4 0 4 79.25 0.00 79.25 1732 0 1732 0.85 0.00 0.85
SCRUM 14 7 7 63.93 63.86 64.00 5922 7982 3627 1.07 1.06 1.08
Traditional 7 2 5 60.29 69.00 38.50 8297 10155 3654 1.15 0.95 2.56
Development projects that we run under traditional methodologies were core projects which
specifications were designed even before our Medis.NET started. The design was the result of lessons
learned from our initial set of projects, and during development only few inputs were added, updated
or deleted. This helped us in calm development of core system resulting with well-documented and
highly maintainable code. Nevertheless, the average volume of these projects is more than 10000 lines
of code and CC is kept on satisfied level. SCRUM approach gave us similar average results both for
development and upgrade projects. Beside the average volume of development project is more than
twice than with upgrade, all parameters describing code maintainability is on similar rank. For
SCRUM approach, we could just confirm our old finding that SCRUM works well when both sides
(developer and users) are dedicated to get final goal.
We got the best result in projects where Lean approach was applied. Initially we tested modified
Lean approach on the project which outcome should be time-scheduling component. Comparing with
the results we got from the projects of similar volume, but developed with SCRUM and Lean, we get
slightly higher maintainability, but project was finished much faster and with lower bug rate during
acceptance phase. Updated Lean gave us very optimistic results, and with use on future projects
having higher volume of code and functionalities, we expect to prove it as feasible. Currently, we are
working on the project that should integrate different MIS systems used in Serbian public healthcare
where updated Lean is applied.
6. CONCLUSION
This paper presents our heuristic approach, based on the experience of our research group, for
choosing proper SDM for specific development and upgrade projects within MIS systems. After 15
years long experience with MIS development we tend to believe that there is (still) not a silver bullet
when it comes to methodologies supporting software life cycle. Having experience with different
traditional and agile SDMs we support the statement that all of the mentioned methodologies have
their own place in complex software projects and within certain category of sub-projects give the best
results. In this paper we presented our initial experience with traditional and agile models as well as
the guideline how to choose adequate methodology in different MIS related development and upgrade
projects. All examined projects are defined within the scope of larger MIS called Medis.NET developed
by our research group. The bottom-line is that during requirement collection we rely on MDD and
FDD approach supported by automatic code generation tools, which lead to faster prototype
generation. Next, dividing the set of functionalities to sub-projects we group them in three categories
– core projects, user-oriented, and loosely coupled application. For core projects we find that
traditional SDM are suitable since their outcome should be stable process and rich documentation.
User-oriented sub-projects are developed under standard SCRUM, while for loosely coupled
applications we chose Lean.
We measured the effects of chosen approaches comparing time spent against estimated time for
development, and by analyzing code metrics results. Code metrics were automatically generated by
our development environment, and we take into account few major values such are MI, lines of codes,
class coupling and CC. For development project we get satisfied results for each of three used
8:72 • P.Rajkovic, I.Petkovic, A.Milenkovic, D.Jankovic
methodologies. Lower MI for projects developed under SCRUM is mostly the consequence of more
frequent specification change due to more intense interaction with customers. For upgrade projects,
SCRUM and Lean gave slightly better results, while the usage of standard methodologies in upgrade
projects resulted with the significant overdue and extremely low MI in some cases. For upgrade
projects we started specifying updated Lean approach based on combination of Lean and SCRUM. It is
used in the latest upgrade projects and first results look promising. In all projects where it was used,
the consequence was faster development and code with higher MI.
Next step in our research will be analysis of results from testing phase. In this paper, the focus was
clearly on development, while the software verification, despite of its importance, was not covered in
details. Extending presented results with testing, validation and verification analysis will help us in
defining more detailed guidelines covering wider area of MIS life-cycle.
With this paper we wanted also to show that is important that software development process must
be guided carefully, and that no methodology can be claimed as “the best for all purposes and in all
cases”. It is necessary that software architect properly identifies all pros and cons for different
methodologies and, knowing this well, wisely choose the right methodology for the right project. Also,
it is important to state that there is the place to combine different methodologies and lead the process
with blended or mixed methodology. With proper methodology choosing guidelines and the
introduction of even new promising approaches, development and upgrade processes for large and
complex software projects, similar to Medis.NET, should be more effective, less stressful and gave
more benefits both to developers and end users.
REFERENCES
Alexandra Okada, et al, 2014. Knowledge Cartography: software tools and mapping techniques. Springer
Barry W. Boehm. 1988. A spiral model of software development and enhancement. Computer 21.5 (1988): 61-72
Don Coleman et al. 1994. Using metrics to evaluate software system maintainability. Computer 27.8 (1994): 44-49.
Grzegorz Loniewski, Emilio Insfran, and Silvia Abrahão. 2010. A systematic review of the use of requirements engineering techniques in model-
driven development. Model driven engineering languages and systems. Springer Berlin Heidelberg, 213-227.
Hastie Shane, Wojewoda Stephane, Standish Group 2015 Chaos Report. Infoq. https://www.infoq.com/articles/standish-chaos-2015
Ken Schwaber and Mike Beedle. 2002. Agilè Software Development with Scrum
Kent Beck et al. 2001. Manifesto for agile software development.
Koray Atalag et al. 2014. Evaluation of software maintainability with openEHR–a comparison of architectures. International journal of medical
informatics, 83.11: 849-859.
Marco Torchiano et al. 2013. Relevance, benefits, and problems of software modelling and model driven techniques—A survey in the Italian
industry. Journal of Systems and Software 86.8: 2110-2126
Mary Poppendieck and Tom Poppendieck. 2003. Lean Software Development: An Agile Toolkit: An Agile Toolkit. Addison-Wesley
Michael J. Doherty et al. 2012. Examining Project Manager Insights of Agile and Traditional Success Factors for Information Technology Projects:
A Q-Methodology Study. PhD, Marian University, Doctoral Dissertation.
Microsoft Library. 2015. https://msdn.microsoft.com/en-us/library/bb385914.aspx
Mikael Lindvall et al. 2004. Agile software development in large organizations. Computer, 37.12: 26-34.
Mikko Korkala, Minna Pikkarainen, and Kieran Conboy. 2010. Combining agile and traditional: Customer communication in distributed
environment. Agility Across Time and Space. Springer Berlin Heidelberg, 201-216.
Per Runeson et al. 2005. Combining agile methods with stage-gate project management. IEEE software, 3: 43-49.
Petar Rajković, Dragan Janković and Tatjana Stanković. 2009. An e-Health Solution for Ambulatory Facilities, 9th International Conference on
Information Technology and Applications in Biomedicine, ITAB 2009, Larnaca, Cyprus, November, 2009; ISSN: 978-1-4244-5379-5
Petar Rajković, et al. 2005. Cardio Clinic Information System Realization, Electronics, Vol. 9, No 1, pp, 41-45.
Petar Rajkovic, Ivan Petkovic, Dragan Jankovic. 2015. Benefits of Using Domain Model Code Generation Framework in Medical Information
Systems. Fourth Workshop on Software Quality Analysis, Monitoring, Improvement, and Applications SQAMIA 2015. pp. 45-52
Philippe Kruchten. 2004. The rational unified process: an introduction. Addison-Wesley Professional.
Rashina Hoda, James Noble, and Simon Marshall. 2013. Self-organizing roles on agile software development teams. Software Engineering, IEEE
Transactions on 39.3: 422-444.
Shamsnaz Virani and Lauren Stolzar. 2014. A Hybrid System Engineering Approach for Engineered Resilient Systems: Combining Traditional and
Agile Techniques to Support Future System Growth. Procedia Computer Science 28: 363-369.
Sue Black et al. 2009. Formal versus agile: Survival of the fittest. Computer 42.9 : 37-45.
Yu Beng Leau et al. 2012. Software development life cycle AGILE vs traditional approaches. International Conference on Information and
Network Technology. p. 162-167.