AN APPROACH FOR MODELING TECHNIQUE SELECTION CRITERIONS * Gytenis Mikulenas, Rimantas Butleris Kaunas University of Technology, Department of Information Systems, Studentu str. 50, Kaunas, Lithuania,
[email protected],
[email protected] Abstract. There are various information system modeling techniques such as UML, BPMN, IDEF, ORM, Petri Nets, ERD, DFD, CRC, etc. A very interesting question is how to effectively select an appropriate technique for the specific task. The paper introduces an approach for the identification of the selection criterions that can be applied during the modeling technique selection. We analyzed different modeling perspectives, views, roadmaps and presented 8 criterions, such as requirements artifacts, modeling perspectives, project member roles, end users of models, enterprise size, software development method, mastering modeling techniques and project environment constrains. Possible values of 8 criterions are also presented. We conclude with a discussion on the future framework research. Keywords: Modeling method, information system, modeling technique selection, software development, selection criterions.
1
Introduction
There are various information system (IS) modeling techniques, methods, languages and roadmaps. They include UML, BPMN, IDEF, ORM, Petri Nets, ERD, DFD, CRC and others [5]. The amount of techniques and their evolution should be a proof of software development maturity and project success but it is not so. The famous CHAOS Report published by Standish Group shows that still only about one third of software projects can be called successful, i.e. they reach their goals within planned budget and on time [24, 31]. So the wealth of approaches does not fix existing problems but it brings other problems, namely, selection and choice problems. The more options there are, the harder the choice. One of the pretexts of this research was the problem of UML complexity and its adaptation. UML is one of the most popular modeling languages [16, 34], extended with various profiles. Some authors propose that UML is the evolutionary general purpose [3], broadly applicable, tool-supported, and industry-standardized modeling language for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process [26]. UML 2.1.1 has 13 main modeling diagrams, more than 100 metaclasses, profiles, Object Constraint Language (OCL) extension [29]. This amount of possibilities makes UML difficult to adopt efficiently for personal needs [14, 18]. There are different UML roadmaps but they do not fix all the problems [17]. Inspired by this problem we analyzed different modeling roadmaps. The paper aims to analyze what impact factors affect the choice of modeling technique, method or language selection. We prefer calling them criterions. Though it may seem that modeling technique selection issues do not change so much, the evolution of UML and Agile based approaches, newest surveys determines the need of new approaches. We evaluated those modeling technique selection criterions that could be used in real life competitive project environments, because every effort must create value. During the research we identified 8 criterions which will be in the heart of the future framework research.
2
Objectives of the study and research approach
Our primary research objective was to identify criterions, affecting modeling method, technique or language selection. Another objective was to establish a foundation for the further research for building modeling technique selection framework. The paper also includes background of the problem, identification of criterions, affecting IS modeling technique selection, criterions classification approach, directions for further research.
3
Problem background
Modeling is the process of creating abstract, conceptual, graphical and/or mathematical models. Modeling is performed to support other activities, such as review, analysis, specification and elicitation [19]. There are a lot of various modeling methods, techniques and languages. So the key question for the research presented in this paper is why in some cases we choose one modeling techniques over the others? * This work is supported by Lithuanian State Science and Studies Foundation according to High Technology Development Program Project "VeTIS" (Reg.No. B-07042) - 207 -
According to Alhir S. S. [3] there is no ‘silver bullets’ in systems development. This means that every technique has its own application domain where it should be used for best results. The question on what and when to choose could be answered if we address an even more fundamental question: what is the value of a process or methodology, independent of its weight, and why would one process or methodology be more suitable than another? Various tactics attempting to reconcile or debate various approaches miss the opportunity to address this fundamental question regarding the value of a process or methodology. So, only analyzing the criterions affecting the value of modeling, we can understand why one modeling technique in some situations brings more value than the other. There is a Methodology Engineering branch first introduced by Kumar and Welke [22] as a discipline aimed at constructing methodologies to match given organizational settings or specific development projects. They proposed an ISD-Personal Value Questionnaire which can be assessed within three different groups, addressing technical values, such as timeliness of information; economical values, such as ISD costs; or sociopolitical-psychological values, such as system responsiveness to people. But another approach will be taken in this paper.
4
Research boundaries
During research we tried to focus on the identification of modeling technique selection criterions for use in our future modeling technique selection framework. But criterions identification determines other research objects. Due to this, we define some boundaries for this paper analysis process: Dependence. Some modeling techniques bring models and some models elements that could be detailed using other techniques. For example, UML use case element could be detailed with sequence diagram. We do not analyze these dependencies and this kind of selection criterions. Overlapping. Some modeling techniques propose similar models to those offered by other techniques. We do not analyze such overlapping and this kind of selection criterions. Ambiguity. Some of our proposed selection criterions or their values may seem to belong to other criterions. We do not perform a detailed analysis of criterions in order to eliminate ambiguous criterions. Criterions prioritization. Some criterions are more important than others but in this paper we limit our research to their identification only. Prioritazation will be included in the future framework research because it is a part of selection process model. In this paper we take multidimensional, independent, unambiguous, non-overlapping modeling technique selection criterions view, because our goal is to establish a foundation for further research. This multidimensional approach is transformed into the modeling technique selection criterions.
5
Modeling technique selection criterions
Environment Artifacts Various artifacts from environment are captured into models during modeling process at various project phases and stages. Modeling is used for capturing and visualizing these artifacts, so every model consists of elements and every element is coherent with the corresponding artifact which is captured in the model. In a paper based on analysis results, Silingas D. discusses how various domain and requirements analysis elements – semantic map of business concepts, lifecycles of business objects, business processes, business rules, system context diagrams, use cases and their scenarios, constraints, and user interface prototypes – can be modeled using UML [34]. Some of the most popular requirements artifacts are shown in the Table 1. 5.1
Table 1. Some of the most popular requirements artifacts [34]
Requirements Artifact Business concept Document (information) sample Business concept relationship Information flow Business object lifecycle User group Business goal User task Business role Usage scenario Business process Non-functional requirement Business task Time constraint Business rule GUI navigation schema Business fact GUI prototype
- 208 -
These requirements analysis elements are common to many modeling techniques not only to UML and can be found in most software development projects. Aurum A. and Wohlin C. [8] state that the goal of requirements engineering is to transform potentially inconsistent, incomplete and conflicting stakeholder goals into a complete set of high quality requirements. But requirement artifact is not the only type of artifacts that are captured during whole project lifecycle. We propose term environment artifact by meaning anything valuable that could be captured from environment into model or model element. Modeling technique selection depends on what environment artifacts we need to capture in models. So, the question, what modeling method, technique or language to select, leads to another question, what environment artifacts do we need to model? 5.2
Modeling Perspectives A little bit different but similar to environment artifacts is modeling perspectives approach. It is modeling perspective, which defines context and boundaries of modeling. We analyzed several modeling perspectives (Table 2.) that in literature are sometimes called modeling approaches or views: Table 2. Modeling approaches
Zachman J. A. [37] • scope modeling • business modeling • system modeling • technology modeling • component modeling • operation modeling Ambler S. W. [7] • Code distribution modeling • Data storage modeling • Data Transmission modeling • Deployment modeling • Function/Logic/Services modeling • Events modeling • Hardware modeling • Network modeling • System interface modeling • User interface modeling • Usage modeling Wiegers K. E. [36] • Business requirements modeling • User requirements modeling • System requirements modeling • Business rules modeling • Quality attributes modeling • External interfaces modeling • Constraints modeling
OMG MDA [28] • Computation independent modeling (CIM) • Platform independent modeling (PIM) • Platform specific modeling (PSM)
Ambler S. W. [6] • Usage modeling • User interface development • Supplementary requirements modeling • Conceptual domain modeling • Process modeling • Architectural modeling • Dynamic object modeling • Detailed structural modeling
Alhir S. S. [3] • Use case (user) modeling • Structural (static) modeling • Behavioral (dynamic) modeling • Component (implementation) modeling • Deployment (environment) modeling • Constraint (OCL) modeling
Some perspectives, for example, behavioral, use case and structural modeling are well-known while others are not. Though modeling perspectives and environment artifacts in some cases may seem to be the same thing, we separate them according to the classification rule we identified. We use an identified classification rule that modeling perspective may include several environment artifacts, while environment artifacts may not include several modeling perspectives and must belong to one perspective only, but we do not exclude exceptions. There is a need for an in depth comparative analysis and investigation of other possible modeling perspectives. The goal of our paper is not to compare these perspectives. Our task is to identify what criterions affect modeling technique selection. So, the question, what modeling method, technique or language to select, leads to another question, what modeling perspective is the most suitable for modeling required environment artifacts? 5.3
Project Member Roles It is not enough to know what environment artifacts we need to model. IS researchers define stakeholders as those participants in the development process together with any other individuals, groups or organizations whose actions can influence or be influenced by the development and use of the system whether - 209 -
directly or indirectly [4, 30]. Typical stakeholders are product managers, various types of users and administrators from the client side, and software team members from the software development side. Ambler S. W. [11] assumes that a project stakeholder is anyone who is a direct or indirect user, manager, senior manager, operations staff member, the project owner who funds the project, support staff member, auditor, program/portfolio manager, software developer or maintenance professional potentially affected by the development and/or deployment of a software project. In addition there are software architects, quality assurance engineers [33]. Theoretically modeling could be done by anyone who is involved in the project software development but in practice not all project stakeholders do modeling. For example, clients usually do not do modeling. People usually do modeling because they have a task to capture software requirements into specifications. Silingas D. [33] proposed the schema of project member roles applicability to modeling tasks. Table 3. Project member role applicability to modeling tasks [33]
Project member role Business Analysts
Software Architects
Developers
Quality Assurance Engineers
Modeling tasks Capture business processes Model organizational structures Perform analysis of domain concepts Prepare use case-driven requirements model ... Relate different architectural views Transition from business to system models Define top-level component and package structures Manage modeling teamwork … Prepare detailed class models Model interactions for use case Introspect existing systems by reversing and visualizing code Design OO, relational, and XML data Transform class structures to database or XML schemas … Analyze workflows for use cases Prepare action flows for test cases Model test data Model interaction for unit and system testing …
Cockburn A. proposes similar role mapping to modeling [12]: Table 4. Project member role mapping to modeling [12]
Project member role Business expert Lead designer Designer-programmer Writer
Modeling tasks Produce Actor-Goal List Produce Use Cases and Requirements File Produce User Role Model Produce Architecture Description Produce Screen Drafts Produce Common Domain Model Produce Design Sketches and Notes Produce User Help
Depending on the role of a modeler, different environment artifacts are captured into the models. So, the question, what modeling method, technique or language to select, leads to another question, who will do the modeling? 5.4
End Users of Models In modeling technique selection it is also important to know who will use the model, created using the selected technique. For example, if software enterprise analysts or developers use models for communication or negotiation with client representatives, these models must be understandable to people with no IT qualification [6]. This means that analysts or developers will probably not choose UML sequence or collaboration diagrams because sometimes they are hard to understand even for IT specialists. Client representatives rarely have enough modeling technique skills to understand complex modeling notations. There are modeling roadmaps that propose - 210 -
client – centered modeling. One such example is the use case modeling because the use case notation is quite simple to understand for client representatives. Many of Agile methods and best practices claim that modeling should be done in the simplest way [5, 12] because in most cases it is too time consuming and difficult to use for communication with client. So if the end users of the model will be the client representatives, the selection of modeling technique will be narrowed to those techniques that offer the simplest notations. On the other hand, there are projects of a certain type, called environment analysis projects. These projects are initiated for inception, analysis and elicitation of requirements that must be met for building future software product. The company that creates requirements specification must capture all possible requirements in the most suitable for later use format that partly consists of models. User of that requirement specification could be other software development company whose analysts, quality assurance specialists and developers will use that specification to build the software product. In this case the specialist of the first project company will be encouraged to use comprehensive modeling. So, the question, what modeling method, technique or language to select, leads to another question, who will use the model? 5.5
Enterprise Size: Quality vs. Efforts Some Agile software development methods such as Xp [9] or Scrum [32] and their practitioners propose using those methods for small projects only [1]. For example, Cocburn A. even classifies the use of Crystal family methods according to the number of the active project members [11]. This shows how project size could impact the selection of a software development method. In 2005 European Commission published “The New SME definition: User Guide and Model Declaration” [15] where the following three levels of small to medium-sized enterprises (SME) were defined: Small to medium –“employ fewer than 250 persons and which have an annual turnover not exceeding 50 million Euro, and/or an annual balance sheet total not exceeding 43 million Euro”; Small – “which employ fewer than 50 persons, and whose annual turnover or annual balance sheet total does not exceed 10 million Euro” and Micro – “which employ fewer than 10 persons ”. In 2008th there was a survey of 392 participants from 28 countries worldwide [23] which results show that there are 36 % micro and 22% small size enterprises worldwide (Figure 1., part in the left). There are large software companies that build large and complex software systems. Development of some parts is outsourced from micro and small companies by large companies [27]. So micro and small companies are a part of a large software development process. Research identified that most of those enterprises do not use any quality or maturity standards such as CMMI, SPICE, ISO-12207. Because of that, any bug or mistake made by micro or small company might be the reason of the entire large system failure and might cost millions of dollars. Some research identified the key reasons of not using standards were the shortage of time, lack of support and lack of resources (Figure 1, part in the right) because micro and small companies have small budget and often do not have enough circulating assets.
Figure 1. Survey results [23]
If company size affects the use of standards, it could affect the modeling technique selection because most complex modeling techniques require training which might be too time/money - consuming. Low efforts on training could have a negative impact on the modeling quality (Figure. 2).
- 211 -
Figure 2. Quality dependency to efforts
Because of the software company size and its budget, some modeling techniques might be unavailable due to the lack of training, resources, time-span and encouragement from management. So, the question, what modeling method, technique or language to select, leads to another question, what is the size of your enterprise or project? 5.6
Software Development Method: lightweight or heavyweight The selection of the modeling technique itself is a process step of creating a model. This process step of modeling fits into the project lifecycle. There are various software development methods that define various project lifecycle models. Each of them defines some modeling techniques that should be used during the appropriate process steps. A lot of IT practitioners discuss about strong and weak sides of various methods, about what software development process and technique should be used, etc. Kroll P. and MacIsaac B. [21] distinguish some dipole between heavyweight and lightweight software development methods while Kroll P. and Kruchten P. [20] identify two converse dipoles – iteration and ceremony weight (Figure 3.).
Figure 3. Process map of software development [20]
Every software development method has its own features and they could be evaluated according to dipole metrics. Low ceremony dipole methods (Figure 3.) require less documentation than high ceremony dipole ones. For example Agile methods such as XP [9], Scrum [32], Agile Modeling [5, 6] propose a minimal amount of modeling such as CRC cards, user stories, product and sprint backlogs. Although theoretically Agile philosophy [2] does not prohibit the use of other requirements modeling and gathering techniques, most of them prefer less documentation, which means less modeling. The more heavyweight is the process the more heavyweight modeling ought to be. This is obvious evidence of how existing software project development methods impact the use of modeling techniques. Other important aspect of modeling is that software development methods use software lifecycle models which consist of phases and steps. Modeling technique selection depends on when the modeler must do the modeling. Interesting misunderstanding about Agile methods is that most people think they restrict any modeling or specification to sketch, CRC or user stories. That is not true. Agile practitioners are against Big Requirements Up Front (BRUF) at the early project phases [5]. They authorize only the kind of modeling that brings value to software development product but not to its specification. So if there is a need to capture and specify some business logic, rules or software, then this should be done during the later phases of the project when no or small requirement changes may occur. So, the question, what modeling method, technique or language to select, leads to another question, what software development method do we use and at what step do we need to model? - 212 -
5.7
Mastering Modeling Techniques A very primitive but humane feature of modeling technique selection is the fact that choice is made depending on skills and knowledge about the options. Some authors blame UML 2 for its adaptation and use complexity [14, 18]. That means practitioners do not use all UML modeling techniques because of their complexity. A worldwide survey [23] showed that micro and small enterprises do not use standards because it is too time consuming and demands too much training and resources. So the reasons of not using some modeling techniques could be the same as those of not using standards. IT market is very dynamic and competitive. Because of the lack of circulating assets micro and small companies cannot allocate appropriate training and materials for mastering appropriate modeling techniques. This means for the specific modeling task the modeler might choose a modeling technique that he knows better than others. Alhir S. S. [3] notes that every project team is a unique object bringing its own flavor to the software development process. This means that even if two project teams use the same modeling techniques, they might produce a little bit different results. So, the question, what modeling method, technique or language to select, leads to another question, what modeling techniques do we master? 5.8
Project Environment Constraints There is one more group of criterions affecting modeling selection. It is various standards that are implemented in the project environment. They are CMMI, ISO 12207, ISO 9001, SPICE maturity standards that help companies grow in terms of quality. But these models do not prohibit companies from adding individual flavor to the standard installation. So, in some cases companies that installed CMMI [13] or ISO 9001 [25] just formalized and specified their know-how knowledge and started using their own methods “legally” [35]. However, the key is that standards create restrictions in the project environment. For example, company may implement ISO 9001 standard for the IS development process. As a result, software development activities, project member roles, techniques and even specification document templates may be defined. This will undoubtedly have an impact on what, how and when to model. So, the question, what modeling method, technique or language to select, leads to another question, what constraints exist in the project environment?
6
Research Results: Criterions Affecting Modeling Selection
Different approaches, roadmaps were analyzed and the combined approach was offered. It is clear that modeling technique selection is multidimensional and cannot be done in a simple way. Table 5 shows the summary of gathered, identified and analyzed criterions: Table 5. Classification of criterions
Criterion group Environment Artifacts (EA) Modeling Perspectives (MP) Project Member Roles (PMR) End User of Models (EUM) Enterprise Size (ES) Software Development Method (SDM) Mastering Modeling Techniques (MMT) Project Environment Constrains (PEC)
What question does it answer to? What environment artifacts do we need to model? What modeling perspective is the most suitable for modeling required environment artifacts? Who will do the modeling? Who will use the model? What size is the enterprise or project? What software development method do we use and at what step do we need to model? What modeling techniques do we master? What constraints exist in the project environment?
- 213 -
What software development method we use and at what step do we need to model?
What modeling perspective is the most suitable for modeling required requirements artifacts?
What size is your enterprise or project?
What environment artifacts do we need to model?
Modeling task Who will do modeling?
Who will use model?
What project environment constrains exists?
What modeling techniques do we master?
Figure. 4. Criterions affecting modeling technique selection
Figure 4 shows a conceptual view of the modeling task and displays several different views of solving both this modeling task and the technique selection problem.
Figure 5. Example of modeling technique selection by using criterions
Let’s go through a visualized modeling technique selection process example. Assume that we have a task to create some model. At the very begining it seems there are a lot of possible modeling techniques to select (Figure 5, part a). Not all modeling techniques can capture desired environment artifacts, however, so after answering the first “Environment Artifacts” criterion (C1) question “What environment artifacts do we need to model?” less possible options remains (Figure 5, part b). They are marked as medium grey circles. Those possibilities that do not meet the criterion requirements are on the crossings. As mentioned in research boundaries section, we do not analyze overlapping, dependency and ambiguity. These possibilities are marked as light grey circles. After considering our other seven criterions we have a few possibilities left (Figure 5, part c). This example demonstrates how proposed 8 criterions might be used in practice. During our research, we also distinguished prioritization as an efficient way to rate criterions according to their importance. Prioritization is widely used in software requirements engineering, software project management, software development methods, etc. [10, 36]. Because some criterions are more important than others there is a need for the evaluation of criterion prioritization. However, this is a subject of the future framework research. The proposed criterion-based approach for the selection of the modeling technique helps gain the better understanding on how choices are made. In real life competitive project environments, every selection must bring value. But if the choice is made without a proper knowledge, it is very hard to achieve this value. Some authors suggest that inappropriate selection could be the reason for the project failure [5]. Sometimes too many resources are spent on modeling with techniques that require more effort than they create value. If so, the proposed criterion-based approach should help understand why one modeling technique is more preferable than other and to make the selection accordingly.
- 214 -
7
Conclusions
Our research proved that modeling technique selection mechanism is complex and multidimensional. During the presented research, 8 criterions were identified, each affecting modeling technique selection. But this number may change during the further research as it could result in the discovery of new criterions. The research presented in this paper kept within certain boundaries. Such issues as criterions dependency, overlapping and ambiguity were not addressed. Every proposal has its exceptions, so it is possible that there might be exceptions. But the goal was to establish an approach for evaluating modeling value by identifying its selection criterions. The resulting methodology can be used for answering such questions as what modeling technique to choose. There are no ‘silver bullets’ not only for systems development, but also for modeling. Various tactics attempting to reconcile or debate various approaches miss the opportunity to address the fundamental question of value. Only understanding the criterions affecting the value of modeling, we can understand why one modeling technique in some situations brings more value than the other. Only then we can make our selection effectively. This paper does not address the modeling technique selection situations in non real-life competitive project environments. Presented research was based on the proposal that in such cases every effort must create value. Sometimes there is an illusion that a wide range of modeling technique possibilities is available. But under closer inspection we discover that for every situation only a few options are worth considering.
8
Future work
One of the goals of the paper was to establish a foundation for the future research. To make further progress the following research activities should be addressed: •
Search for additional possible criterions;
•
Detailed analysis of dependency, overlapping and ambiguity of every criterion;
•
We use a rule that modeling perspective may include several environment artifacts, while environment artifacts may not include several modeling perspectives and must belong to one only. More research is needed to identify possible exceptions;
•
Criterions prioritization analysis;
•
Building of modeling technique selection framework.
References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]
Abrahamsson P., Salo O., Ronkainen J., Warsta J. Agile Software Development Methods: Review and Analysis, VTT Publications, 2002. Agile Alliance. Principles behind the Agile Manifesto. http://agilemanifesto.org/principles.html Alhir S. S. Guide to Applying the UML. Springer-Verlag, 2002. Ambler S. W. Active Stakeholder Participation: An Agile Best Practice. http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm Ambler S. W. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. John Wiley & Sons, 2002. Ambler S. W. The Object Primer, Third Editon. Cambridge University Press, 2004. Ambler S. W. UML Data Modeling Profile. http://www.agilemodeling.com/essays/agileArchitecture.htm Aurum A., Wohlin C. Requirements Engineering: Setting the Context. In: Aurum A., Wohlin C. (Eds.): Engineering and Managing Software Requirements, Springer-Verlag, 2005, pp. 1-16. Beck K. Extreme Programming Explained: Embrace Change, Second Edition. Addison Wesley Professional, 2004. Berander P., Andrews A. Requirements Prioritization. In: Aurum A., Wohlin C. (Eds.): Engineering and Managing Software Requirements, Springer-Verlag, 2005, pp. 69-94. Cockburn A. Agile Software Development: The Cooperative Game, Second Editon. Addison Wesley Professional, 2006. Cockburn A. Crystal Clear A Human-Powered Methodology for Small Teams. Addison Wesley Professional, 2004. Dayan R., Evans S. KM your way to CMMI. Journal of Knowledge Management, Emerald Group Publishing Limited, 2006, Vol. 10, Nr. 1, pp. 69-80. Dobing B., Parsons J. Dimensions of UML Diagram Use: A Survey of Practitioners. Journal of Database Management, IGI Publishing, 2008, Vol. 19, Issue 1, pp. 1-18. European Commission. The New SME Definition: User Guide and Model Declaration 2005. http://europa.eu.int/comm/enterprise/enterprise_policy/sme_definition/sme_user_guide.pdf
- 215 -
[16] [17] [18] [19] [20] [21] [22] [23]
[24]
[25] [26]
[27] [28] [29] [30] [31] [32] [33] [34]
[35]
[36] [37]
Evans G. K. Agile RUP: Taming the Rational Unified Process. In: B. Roussev; L. Liu (Eds.): Management of the Object-Oriented Development Process, Idea Group Publishing, 2006, pp. 231-246. Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition. Addison Wesley, 2003. Grossman M., Aronson J., McCarthy R. Does UML make the grade? Insights from the software development community. Information and Software Technology, 2005, Vol. 47, Issue 6, pp. 383-397. Hood C., Wiedemann S., Fichtinger S., Pautz U. Requirements Management: the interface between requirements development and all other systems engineering processes. Springer-Verlag, 2008. Kroll P., Kruchten P. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Addison Wesley, 2003. Kroll P., MacIsaac B. Agility and Discipline Made Easy: Practices from OpenUP and RUP. Addison Wesley Professional, 2006. Kumar K., Welke R. J. Methodology Engineering: a Proposal for Situation-Specific Methodology Construction, Challenges and Strategies for Research in Systems Development, John Wiley & Sons, 1992, pp. 257-269. Laporte C. Y., Alexandre S., O’Connor R. V. A Software Engineering Lifecycle Standard for Very Small Enterprises. In: O'Connor R. V. Baddoo N., Smolander K., Messnarz R. (Eds.): Software Process improvement: 15th European Conference, Springer, 2008, pp. 129-141. Lopata A., Gudas S. Enterprise model based specification of functional requirements. In Information Technologies' 2008 : proceedings of the 14th International Conference on Information and Software Technologies, IT 2008, Kaunas University of Technology, 2008, pp. 189-194. McMichael B., Lombardi M. ISO 9001 and Agile Development. AGILE 2007 Conference, pp. 262-265. Nemuraite L., Ceponiene L., Vedrickas G. Representation of business rules in UML&OCL models for developing information systems. In: Stirna, Janis Persson, Anne (Eds.): The Practice of Enterprice Modeling : First IFIP WG 8.1 Working Conference, PoEM 2008, Springer Berlin Heidelberg, 2008, Vol. 15, pp. 182-196. Oktaba H., Piattini M. Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies. Information Science Reference, 2008. OMG. MDA Guide Version 1.0.1, 2003. OMG. Unified Modeling Language: Superstructure. Version 2.1.1, 2007. Pouloudi A, Whitley E. Stakeholder identification in inter-organizational systems: Gaining insights for drug use management systems. European journal of information systems, Palgrave Macmillan, 1997, Vol. 6, No. 1, pp. 1-14. Rubinstein D. Standish Group Report: There’s Less Development Chaos Today. SD Times, March 1, 2007. Schwaber K. Agile Project Management with Scrum. Microsoft Press, 2004. Silingas D. Best Practices for Applying UML, Part I. http://www.magicdraw.com/files/whitepapers/Best_Practices_for_Applying_UML_Part1.pdf Silingas D., Butleris R. UML-intensive framework for modeling software requirements. In Information Technologies' 2008 : proceedings of the 14th International Conference on Information and Software Technologies, IT 2008, Kaunas University of Technology, 2008, pp. 334-342. Tutkute L., Butleris R., Skersys T. An Approach for the Formation of Leverage Coefficients-based Recommendations in Social Network. Information Technology And Control, Kaunas University of Technology, 2008, Vol. 37, No. 3, pp. 245-254 Wiegers K. E. Software Requirements, Second Edition. Microsoft Press. 2003. Zachman J. A. Zachman Enterprise framework. http://www.zachmaninternational.com/index.php/homearticle/13#maincol
- 216 -
