Vassilka Kirova

Risk Management for Collaborative Software Development

Collaborative software development involving multiple organizational units, often spanning national, language, and cultural boundaries, raises new challenges and risks that can derail software development projects even when traditional risk factors are being controlled. This article presents a framework that can be used to manage collaborative software development projects, based on an extended set of risk management principles. Three risk factors — trust, culture, and collaborative communication — are discussed in depth.

Risk-driven Management Contingency Policies in Collaborative Software Development

Inter-organisational Collaborative Software Development (CSD), like other inter-organisational collaborative efforts that span national, language and cultural boundaries, raises significant challenges and risks. Its study offers useful insight with regard to the more complex, collaborative, and interdependent operational environment, where new risks arise and interfere with software projects even when all traditional risks are well controlled. In this paper, we outline a collaborative risk management framework, and focus on a set of governing policies and management contingency processes required to support the framework and to manage the interactions with other critical project activities and goals.

A refinement of the ECBS architecture constituent

The importance of a clean system architecture in the context of computer based systems increases significantly with the ever higher level of complexity these systems exhibit. As a consequence, the identification of useful architectural concepts and their description in architecture models has become an important concern for software engineering practitioners and researchers. We look at system architectures as elements of the ECBS (Engineering of Computer Based Systems) discipline. We exemplify the concepts of system architecture in this context and make a first step towards a generic, multipurpose software architecture model. This model is two folded: on one side it emphasizes architectural elements-constructive primitives from which a general system design model can be built; on the other side it underlines the importance of design rationale and knowledge, capturing them in a selection of rules and so called aspects. The application of architecture models to systems integration and specification of safety critical systems is discussed in the form of examples.

ASPECT-an Architecture SPECification Technique a report on work in progress

We discuss ASPECT, a first step towards a generic specification technique for software architectures. We present and discuss an abstract grammar for ASPECT that lists and relates to each other all the architectural elements that form ASPECTs vocabulary. After elaborating on the characteristics of these architectural elements, we illustrate their application in a small example.

A component-driven architecture for Internet-based, directly reactive information systems

In this paper we focus on the architecture-based development of what we call directly reactive information systems on the Internet. These systems exhibit full content management of a possibly distributed, multimedia information archive and provide for the integration of infernal with external workflows. They are built to serve as open communications platform for a web-wide audience that is also involved in building, modifying, and restructuring the contents provided. All changes to the information archive have to be executed and reflected to the audience within on-line compatible time-limits. Based on an actual project, the MPDB project at FSU, we derive a reference architecture for this family, of systems and refine it into a concrete application design. We present our solution to the DBMS management problem, inherent to this system type, and motivate the use of the components library that was developed for this task. A short look at technological alternatives to implement the architecture in a concrete system completes our presentation. Throughout the paper we refer to the now released MPDB system to explain our motivation and choices. We strive for an immediately applicable and pragmatic solution that is, nevertheless, based on a clean architecture and reusable concepts.