Compulsory Liability Insurance for Commercial Motor Vehicles

With its core in adaptability and change responsiveness, the Agile methodology has become a popular application of the project process within the often volatile environment of today’s software development projects. The Agile methodology emphasizes interaction between project roles over documentation and formal processes. This higher interaction increases the need for functioning information dissemination throughout the entire project process. The study was carried out at a small sized Swedish IT consultancy firm. The company wished to acquire a project management and planning software tool to support the entire project process and all involved project roles. However, awareness of areas in the project process in need of support was not entirely clear. Therefore, the objective of the study was to investigate the company’s application of the Agile project process and identify potential challenges. Furthermore, the objective was to investigate how a project management and planning software tool can support the Agile project process within software development. The thesis was carried out as an abductive case study, where qualitative data collection methods and literature studies were combined. As a result from the study, two main conclusions have been drawn. Firstly: requirements engineering, the customer role, communication, and knowledge transfer were concluded as prominent challenges in the project process in need of increased support. Secondly, a project management and planning software tool can support the project process by: increasing the communication and collaboration abilities, providing holistic and historical project overview, providing a single storage location, and providing structure. Furthermore, the study has also shown that the project management and planning software tool needs to interact with the Agile project process in order to provide successful support. As final contribution, the Interaction model was created. The model visualizes the main areas in which a project management and planning software tool must interact with the Agile process, in order to support the entire project process successfully.Genom dess anpassningsförmåga och förändringsmottaglighet har den Agila metodiken blivit en populär tillämpning för projektprocessen inom mjukvaruutveckling, en miljö där snabba förändringar tillhör vardagen. Den Agila metodiken framhäver interaktion mellan projektroller  framför  dokumentation  och  formella  processer,  vilket  ökar  behovet  av fungerande informationsspridning genom hela projektprocessen. Studien  har  utförts  hos  ett  mindre  svenskt  IT-konsultföretag,  vilket  önskade  att införskaffa en programvara för ett projektlednings- och planeringsverktyg som kan stötta hela  projektprocessen  och  alla  involverade  projektroller.  Medvetenheten  kring  de områden i projektprocessen som är i behov av stöd var däremot inte helt tydlig. Målet med   studien   var   därför   att   undersöka   företagets   tillämpning   av   den   Agila projektprocessen  och  identifiera  eventuella  utmaningar.  Vidare  var  målet  också  att undersöka hur en programvara för ett projektlednings- och planeringsverktyg kan stödja den Agila projektprocessen inom mjukvaruutveckling. Examensarbetet utfördes som en abduktiv fallstudie där flera kvalitativa datainsamlingsmetoder användes tillsammans med litteraturstudier. Som resultat av studien har två huvudslutsatser dragits. För det första; kravhantering, kundrollen, kommunikation  och  kunskapsöverföring  identifierades som framträdande utmaningar i projektprocessen i behov av ökat stöd. För det andra, att en programvara för ett projektlednings- och planeringsverktyg kan stödja projektprocessen genom att; förbättra  kommunikations-  och  samarbetsmöjligheterna,  ge  en  övergripande  och historisk projektöverblick, fungera som en gemensam lagringsplats och tillhandahålla struktur.  Vidare  har  studien  visat  att  en  programvara  för  ett  projektlednings-  och planeringsverktyg  måste  interagera  med  den  Agila  projektprocessen  för  att  ge  ett effektivt  stöd.  Som  ett  slutligt  bidrag  skapades  "the  Interaction  model",  vilken visualiserar huvudområdena inom vilka en programvara för ett  projektlednings- och planeringsverktyg måste interagera med projektprocessen för att ge ett fullt stöd till processen

MegSDF Mega-system development framework

A framework for developing large, complex software systems, called Mega-Systems, is specified. The framework incorporates engineering, managerial, and technological aspects of development, concentrating on an engineering process. MegSDF proposes developing Mega-Systems as open distributed systems, pre-planned to be integrated with other systems, and designed for change. At the management level, MegSDF divides the development of a Mega-System into multiple coordinated projects, distinguishing between a meta-management for the whole development effort, responsible for long-term, global objectives, and local managements for the smaller projects, responsible for local, temporary objectives. At the engineering level, MegSDF defines a process model which specifies the tasks required for developing Mega-Systems, including their deliverables and interrelationships. The engineering process emphasizes the coordination required to develop the constituent systems. The process is active for the life time of the Mega-System and compatible with different approaches for performing its tasks. The engineering process consists of System, Mega-System, Mega-System Synthesis, and Meta-Management tasks. System tasks develop constituent systems. Mega-Systems tasks provide a means for engineering coordination, including Domain Analysis, Mega-System Architecture Design. and Infrastructure Acquisition tasks. Mega-System Synthesis tasks assemble Mega-Systems from the constituent systems. The Meta-Management task plans and controls the entire process. The domain analysis task provides a general, comprehensive, non-constructive domain model, which is used as a common basis for understanding the domain. MegSDF builds the domain model by integrating multiple significant perceptions of the domain. It recommends using a domain modeling schema to facilitate modeling and integrating the multiple perceptions. The Mega-System architecture design task specifies a conceptual architecture and an application architecture. The conceptual architecture specifies common design and implementation concepts and is defined using multiple views. The application architecture maps the domain model into an implementation and defines the overall structure of the Mega-System, its boundaries, components, and interfaces. The infrastructure acquisition task addresses the technological aspects of development. It is responsible for choosing, developing or purchasing, validating, and supporting an infrastructure. The infrastructure integrates the enabling technologies into a unified platform which is used as a common solution for handling technologies. The infrastructure facilitates portability of systems and incorporation of new technologies. It is implemented as a set of services, divided into separate service groups which correspond to the views identified in the conceptual architecture

Формалізація процесу управління ризиками розроблення програмного забезпечення

An approach to formalizing risk management process of software development (software). The approach allows us to identify and assess the adverse situations during the implementation phases of a software project makes it possible to develop a strategy and tactics of their predictions, perception and overcoming the negative consequences of their manifestations. It was found that the risk management software development should be viewed as a process that allows you to determine the characteristics of the management, the main categories of existing risks, risk-based approach to the implementation of measures for their prevention and decontamination. Also, this process makes it possible to determine the acceptable level of risk for the successful completion (failure) of a software project IT-company. Refined approaches to identifying risks of software development, a thorough risk analysis methods, planning and monitoring. This allowed to change business model of project management in general, and change behaviour in a particular project manager at various stages of the software project. Improved method of determining the possible sources of the risks of software development and identification of potential risk events. Formed structured set of existing risks and the implementation of software projects developed their formal model for the corresponding calculations. Improved method of determining the possible sources of the risks of software development and identification of potential risk events. Formed structured set of existing risks and the implementation of software projects developed their formal model for the corresponding calculations. Improved method of determining the possible sources of the risks of software development and identification of potential risk events. Formed structured set of existing risks and the implementation of software projects developed their formal model for the corresponding calculations. The technique of determining the probabilities of potential risk events in their respective sets. An approach to the allocation of the cost of implementing a software project to these sets in general and the potential risk events in particular. Identified part and the amount of possible losses from the risk events, prioritized mitigation and ranking. Analyzed to identify potential risk events software development, these events are ranked according to priority response, developed their formal models. Clarification of the measures to prevent or neutralization of the risks of software development, improved method of determining the likelihood of reducing or eliminating the various risk events. Defined rules and policies of the application project, implemented the principles of risk management software development, and developed their formal models. The notion of "software development risk monitoring", the specific features of its implementation in the IT-companies from an organizational point of view. Defined as a monitoring system with a set of elements such as target object, subject and implementation mechanism, and also set its security subsystem – a technical, and regulatory information.Розроблено підхід до формалізації процесу управляння ризиками розроблення програмного забезпечення (ПЗ), який дає змогу ідентифікувати та оцінити несприятливі ситуацій під час реалізації етапів програмного проекту, а також уможливлює розроблення стратегій і тактик їх передбачення, сприйняття та подолання негативних наслідків від їх прояву. З'ясовано, що управління ризиками розроблення ПЗ потрібно розглядати як процес, який дає змогу визначити особливості такого управління, основні категорії наявних ризиків, ризик-орієнтовний підхід до управління ними. Уточнено підходи до ідентифікації ризиків розроблення ПЗ, їхнього ґрунтовного аналізу, планування та моніторингу, що дало змогу поміняти модель діяльності проектного менеджменту загалом і змінити модель поведінки керівника проекту зокрема на різних етапах реалізації програмного проекту. Удосконалено методику визначення можливих джерел появи ризиків розроблення ПЗ й ідентифікації потенційних ризикових подій, сформовано структуровану множину наявних ризиків реалізації програмних проектів і розроблено їх формалізовані моделі для проведення відповідних розрахунків. Розроблено методику визначення ймовірностей настання потенційних ризикових подій у відповідних їх множинах, запропоновано підхід до розподілу вартості реалізації програмного проекту за цими множинами загалом і потенційними ризиковими подіями зокрема, визначено частки та величини можливих збитків від настання ризикових подій, встановлено пріоритети їх пом'якшення та ранжування. Уточнено заходи із запобігання чи знешкодження ризиків розроблення ПЗ, удосконалено методику визначення ймовірності зменшення або усунення різних ризикових подій, визначено правила і політику реалізації програмного проекту, розроблено їх формалізовані моделі

Multi-level requirement model and its implementation for medical device

Indiana University-Purdue University Indianapolis (IUPUI)Requirements determine the expectations for a new or modified product. Requirements engineering involves defining, documentation and maintenance of requirements. The rapid improving of technologies and changing of market needs require a shorter time to market and more diversified products. As an important and complex task in product development, it is a huge work to develop new requirements for each new product from scratch. The reusability of requirements data becomes more and more important. However, with the current “copy and paste” approach, engineers have to go through the entire set of requirements (sometimes even more than one set of requirements) to identify the ones which need to be reused or updated. It takes a lot of time and highly relies on the engineers’ experiences. Software tools can only make it easier to capture and locate the requirements, but won’t be able to solve the problem of effective reuse of the existing requirement data. The overall goal of this research is to develop a new model to improve the management of requirements and make the reuse and reconfiguration of existing requirements and requirement models more efficient. Considering the requirements data as an important part of the knowledge body of companies, we followed the knowledge categorization method to classify requirements into groups, which were called levels in the study, based on their changing frequency. There are four levels, the regulatory level, the product line level, the product level and the project level. The regulatory level is the most stable level. Requirements in this level were derived from government and industry regulations. The product line level contains the common requirements for a group of products, the product line. The third level, product level, refers to the specific requirements of the product. And the fourth and most dynamic level, the project level, is about the specific configurations of a product for a project. We chose auto-injector as the application to implement the model, since it is a relatively simple product, but its requirements cover many different categories. There are three major steps in our research approach for the project. The first is to develop requirements and classify them for our model. The development of requirements adopts the goal-oriented model to analyze and SysML, a system modeling language, to build requirements model. And the second step is to build requirements template, connecting the solution of the problem to the information system, standalone requirements management tool or information platform. This step is to find a way to realize the multi-level model in an information system. The final step is to implement the model. We chose two software tools for the implementation, Microsoft Office Excel, a commonly used tool for generating requirements documents, and Siemens PLM suite, Teamcenter, a world leading PLM platform with a requirement module. The results in the study include an auto-injector requirement set, a workflow for using the multi-level model, two requirements templates for implementation of the model in two different software tools, and two automatically generated requirement reports. Our model helps to define the changed part of requirements after analysis of the product change. It could avoid the pitfalls of the current way in reusing requirements. Based on the results from this study, we can draw the following conclusions. A practical multi-level requirements management model can be used for a medical device—the auto-injector; and the model can be implemented into different software tools to support reuse of existing requirement data in creating requirement models for new product development projects. Furthermore, the workflow and guideline to support the application and maintenance of the requirement model can be successful developed and implemented. Requirement documents/reports can be automatically generated through the software tool by following the workflow. And according to our assessment, the multi-level model can improve the reusability of requirements

The P3 platform: an approach and software system for developing diagrammatic model-based methods in design research

Many issues in design and design management have been explored by building models which capture the relationships between different aspects of the problem at hand. These models require computer support to construct and analyse. However, appropriate modelling tools can be time-consuming to develop in a research environment. Reflecting upon five design research projects, this paper proposes that such projects can be facilitated by recognising the iterative and tightly-coupled nature of research and tool development, and by attempting to minimise the effort of solution prototyping within this process. Our approach is enabled by a software platform which can be rapidly configured to implement many conceivable modelling approaches. This configurability is complemented by an emerging library of modelling and analysis approaches tailored to explore design process systems. The platform-based approach enables any mix of modelling concepts to be easily created. We propose it could thus help researchers to explore a wide range of questions without being constrained to existing conventions for modelling – or for model integration

Software Reuse in Agile Development Organizations - A Conceptual Management Tool

The reuse of knowledge is considered a major factor for increasing productivity and quality. In the software industry knowledge is embodied in software assets such as code components, functional designs and test cases. This kind of knowledge reuse is also referred to as software reuse. Although the benefits can be substantial, software reuse has never reached its full potential. Organizations are not aware of the different levels of reuse or do not know how to address reuse issues. This paper proposes a conceptual management tool for supporting software reuse. Furthermore the paper presents the findings of the application of the management tool in an agile development organization

System implementation: managing project and post project stage - case study in an Indonesian company

The research reported in this paper aims to get a better\ud understanding of how the implementation process of\ud enterprise systems (ES) can be managed, by studying the\ud process from an organisational perspective. A review of\ud the literature on previous research in ES implementation\ud has been carried out and the state of the art of ES\ud implementation research is defined. Using several body of\ud literature, an organisational view on ES implementation is\ud described, explaining that ES implementation involves\ud challenges from triple domain, namely technological\ud challenge, business process related challenge, and\ud organisational challenge. Based on the defined state of the\ud art and the organisational view on ES implementation\ud developed in this research, a research framework is\ud presented, addressing the project as well as the postproject\ud stage, and a number of essential issues within the\ud stages. System alignment, knowledge acquisition, change\ud mobilisation are the essntial issues to be studied in the\ud project stage while institutionalisation effort and\ud continuous improvement facilitation are to be studied in\ud the post-project stage. Case studies in Indonesian\ud companies are used to explain the framework

Integrating automated support for a software management cycle into the TAME system

Software managers are interested in the quantitative management of software quality, cost and progress. An integrated software management methodology, which can be applied throughout the software life cycle for any number purposes, is required. The TAME (Tailoring A Measurement Environment) methodology is based on the improvement paradigm and the goal/question/metric (GQM) paradigm. This methodology helps generate a software engineering process and measurement environment based on the project characteristics. The SQMAR (software quality measurement and assurance technology) is a software quality metric system and methodology applied to the development processes. It is based on the feed forward control principle. Quality target setting is carried out before the plan-do-check-action activities are performed. These methodologies are integrated to realize goal oriented measurement, process control and visual management. A metric setting procedure based on the GQM paradigm, a management system called the software management cycle (SMC), and its application to a case study based on NASA/SEL data are discussed. The expected effects of SMC are quality improvement, managerial cost reduction, accumulation and reuse of experience, and a highly visual management reporting system