158 research outputs found
The quest for know-how, know-why, know-what and know-who: using KAOS for enterprise modelling
No full textWhile the field of information systems engineering is largely focussed on developing methods for complex problems and larger enterprises, less is done to specifically address the needs of smaller organizations like small and medium sized enterprises (SMEs), although they are important drivers of economy. These needs include a better understanding of the processes (know- how), why things are done (know-why), what concepts are used (know-what) and who is responsible (know-who). In this paper, the KAOS approach is evaluated as not only useful for developing software projects, but with the potential to be used for developing a business architecture or enterprise model. An example of KAOS is given, by way of illustration, and KAOS was applied in a case study by an SME’s CEO, which resulted in a set of questions for further research
Questionning the design of business process maturity models
No full textThe importance of business process management goes without saying. As its realization is less straightforward, maturity models have been developed to gradually assess and improve business processes. Although their aim is to assist organizations, the proliferation of maturity models also confuses organizations. They have no overview of existing models and their differences, which makes an informed choice difficult. Choosing the right business process maturity model (BPMM) is however important, as previous research indicated the existence of different maturity types being measured by the existing models [1]. We now add further design elements to our comparative framework by conducting a content analysis of 69 BPMMs. Afterwards, the identified design elements are transformed into a questionnaire that practitioners can use to find the BPMM that best fits their needs. In this paper, we present 16 questions to be included in the questionnaire, without elaborating on the mapping of individual maturity models
Artefacts in Agile Team Communication
No full textAgile software development (ASD) has become standard in software development. ASD methods share a preference for face-to-face communication rather than formal comprehensive documentation. As agile teams are independent in their internal processes they can decide on, whether or not, to use documentation artefacts. Their decisions elaborate the Agile Manifesto’s second statement: “Working software over comprehensive documentation”. Therefore, our main research question is: What is the role of artefacts in communication in agile software development teams? The hypothesis underlying this research is that artefacts have proven their value in traditional software development and that agile teams will carry over some of this value to their current practices. In first instance the use of artefacts in agile teams was investigated through interviewing team members in three agile teams in a case study. Its conclusions demonstrated the basic validity of our hypothesis. The teams did use artefacts and we partially confirmed previous findings and complemented them with additional artefacts. Having established the blend of traditional and agile artefacts does not shine light on reasons for using them. In a holistic view we first investigated the existence of a relation between maturity of an agile team’s ASD and its use of artefacts. Evidence was found for maturity to be negatively correlated with the non-agile/all artefacts ratio. In a follow-up study we explicitly investigated rationales for the use of artefacts. In fourteen agile teams interviews were held with prominent team members to discuss the use of artefacts and the motivation for using them. Agile teams stated five groups of rationales, among which one for agile artefacts and four for traditional artefacts, for instance to promote internal team communication. Formal and informal communication in ASD are often regarded as two distinct end points, resembling the distinction between explicit and tacit knowledge. This distinction is recognized not to be a black and white one and this raised the question whether or not agile teams also experience intermediate appearances between formal communication (artefacts) and informal communication (face-to-face). We coined this appearance a ‘fuzzy’ artefact, an artefact which is not formally documented, but one that is still explicitly recognized by an agile team. The findings confirmed their existence and teams use them, for instance, in the requirements process, the elaboration of user stories and in taking Go/ No-Go decisions. The overall answer to our research question thus is: Yes, artefacts play an important role in the communication within agile teams. This is no surprise as far as agile artefacts, artefacts that are inherent to ASD, are involved, for instance a product or sprint backlog, or user stories. Agile teams use, in addition, non-agile artefacts, which are associated with traditional software development rather than ASD. However, they have sound reasons to do so. Two examples: (1) Team-internal communication benefits from functional and technical design artefacts, (2) Quality assurance leads to test-related artefacts. In general, agile teams are able to explain why they are using the artefacts they use. Artefacts do not replace face-to-face communication, but complement it
Enterprise Models as Drivers for IT Security Management at Runtime
No full textAbstract. This paper describes how enterprise models can be made suitable for monitoring and controlling IT security at runtime. A holistic modeling method is proposed that extends enterprise models with runtime information, turning them into dashboards for managing security incidents and risks, and supporting decision making at runtime. The requirements of such a modeling method are defined and an existing enterprise modeling language is extended with relevant security concepts that also capture runtime information to satisfy these require-ments. Subsequently, the resulting modeling method is evaluated against the previously defined requirements. It is also shown that common metamodeling frameworks are not suitable for implementing a modeling environment that re-sults in suitable IT security dashboards. This leads to suggesting implementa-tion of the modeling environment using the eXecutable Modeling Facility.
Merging computer log files for process mining: an artificial immune system technique
No full textProcess mining techniques try to discover and analyse business processes from recorded process data. These data have to be structured in so called computer log files. If processes are supported by different computer systems, merging the recorded data into one log file can be challenging. In this paper we present a computational algorithm, based on the Artificial Immune System algorithm, that we developed to automatically merge separate log files into one log file. We also describe our implementation of this technique, a proof of concept application and a real life test case with promising results
Waiting list procedure improvements for master program courses in Information and Computing Sciences
No full textIn higher education, at times it happens there are limited places in courses because of, for example, staffing and classroom shortages which can lead to students being waitlisted. Previous research indicates there are numerous waiting list prioritization methods in health care and public housing, whereas research in waiting list prioritization methods for course registration in higher education is very limited. Results of a literature study and interviews with domain experts have been conducted and analyzed to determine how course waiting list procedures can be improved. This has resulted in an improved waiting list procedure including prioritization methods for master program courses in Information and Computing Sciences at Utrecht University, the Netherlands
Documentation in Continuous Software Development
No full textWith the introduction of the Agile Manifesto, Lean Software Development, and Dev-Ops, documentation has become lower in quality and lesser in quantity leading to knowledge evaporation. The Agile Manifesto values working software over comprehensive documentation, and Lean Software Development considers everything that does not contribute to customer value as waste. In Dev-Ops, documentation is primarily found in infrastructure-as-code to keep up with continuously changing legislation and demands for fast time-to-market. Next to the developments above, another issue causing knowledge evaporation concerns the reluctance of software developers to write down information about a software product. In general, software developers and other stakeholders dislike reading documentation; in short, TL;DR. New team members must invest substantial time in comprehending the intentions behind the source code, particularly understanding the reasons for its functioning and extracting insights into how it operates, all directly from the source code itself. The source code alone cannot reveal design decisions or their rationale. Consequently, preserving knowledge necessitates primarily capturing design decisions, rationale, architecture and justification. To mitigate knowledge loss, we formulated three primary research questions that subsequently informed the development of a framework consisting of three approaches and their corresponding artifacts. The first question poses challenges due to culture, loss of focus, and a wide array of tools and processes. The second question examines the characteristics of gls{csd}, including cultural traits defined by values, principles, practices, and processes, life cycle attributes of constant change, systematic challenges like lack of control, and the impact of bugs and new features. The third research question proposes a framework with approaches and artifacts. The approaches in the framework are `Just Enough Upfront', ‘Executable Documentation', and ‘Automatic Text Analysis'. ‘Just Enough Upfront' advocates informal whiteboard sketches to communicate the main objectives between stakeholders, a strictly codified interface description between (sub)systems, and a plan of approach. Afterward, developers document design decisions to incorporate progressive insights and deviations from the initially planned objectives. The characteristics of `Executable Documentation' pertain to human-readable requirements and specifications that can be executed. This approach is typically in use when specifications are clearly defined. With ‘Automatic Text Analysis', machine learning with neural networks is used to identify causal relations in text, especially Git comments, for revealing design decisions. As such, this approach assists in retrieving knowledge
- …
