No abstract

No abstract

Software engineering standards developed under the auspices of ISO/IEC JTC1's SC7 have been identified as employing terms whose definitions vary significantly between standards. This led to a request in 2012 to investigate the creation of an ontological infrastructure that aims to be a single coherent underpinning for all SC7 standards, present and future. Here, we develop that necessary infrastructure prior to its adoption by SC7 and its implementation (likely 2014). The proposal described here requires, firstly, the identification of a single comprehensive set of definitions, the Definitional Elements Ontology (DEO). For the scope of an individual standard, only a subset of these definitional elements will be needed. Once configured, this definitional subset creates a Configured Definitional On-tology or CDO. Both the DEO and the CDO are essentially foundational ontologies from which a domain-specific ontology known as a SDO or Standard Domain Ontology can be created. Consequently, all such SDOs are conformant to a CDO and hence to the single DEO thus ensuring that all standards use the same ontological base. Standards developed in this fashion will therefore be not only of a higher quality but also, importantly, interoperable.

No abstract

Software development methodologies usually contain guidance on what steps to follow in order to obtain the desired product. At the same time, capability assessment frameworks usually assess the process that is followed on a project in practice in the context of a process reference model, defined separately and independently of any particular methodology. This results in the need for extra effort when trying to match a given process reference model with an organisation's enacted processes. This paper introduces a metamodel for the definition of assessable methodologies, that is, methodologies that are constructed with assessment in mind and that contain a built-in process reference model. Organisations using methodologies built from this metamodel will benefit from automatically ensuring that their executed work conforms to the appropriate assessment model.

The changing environments of software development such as componentbased, distributed and outsourced software development require matching changes by project managers to monitor, control and coordinate their projects. While the objectives of project management may be well established, the mechanisms with which those objectives are achieved are less well known. An empirical study was undertaken to investigate which mechanisms were used by practising project managers to monitor, control and coordinate software development projects. First, the types of mechanisms are discussed so that the mechanisms can be classified usefully. Then, the design of the empirical study is described. The data were collected through structured interview, which provided both quantitative and qualitative data. The data are analysed for each mechanism separately and the findings presented. The study found that project managers use multiple mechanisms to achieve project management objectives and use the same mechanism to serve multiple objectives. Further research is suggested to investigate project management from the opposite orientation, that is, which objectives are served by specific project management mechanisms.

This paper outlines existing maturity models of project management and their underlying constructs. Organizations involved in software development in Sydney, Australia were interviewed about their project management practices and their responses analysed to determine whether different project managers used different levels of project management practices and whether the practices were in accordance with a process based maturity model. This did not seem to be the case, yet the data suggested that, as a possible alternative, a systems theory based approach might be more tenable. The overall conclusion, that a system theory based maturity model appears to be better correlated with organizational size and software development maturity than a process based maturity model, is briefly discussed and additional research is suggested that could investigate this novel conclusion further.

Summary:The assessment of COBIT process maturity levels for each COBIT