Identification of key process areas in the production on an e-capability maturity model for UK construction organisations

Uptake of e-procurement by construction organisations has been slow (Martin, 2008). Positive e-business achievements in other industries, point towards the potential for the construction industry to accomplish similar results. Since the Modernising Government White paper set targets through best value indicator BV157 for implementation in the public sector, Government has supported many initiatives encouraging e-procurement. These are based on documented efficiency and cost savings (Knudsen, 2003; Minahan and Degan, 2001; McIntosh and Sloan, 2001; Martin, 2008). However, Martin (2003, 2008) demonstrates only a modest increase in the uptake of e-procurement in the UK construction industry. Alshawi et al (2004) identified the significance of possessing a model to sustain the embedment of any business process within an organisation. Saleh and Alshawi (2005) describe a number of model types used to gauge maturity in an organisation. One of these models is the capability maturity model. Paulk et al (1993) released the Software Capability Maturity Model (CMM) in 1991. Since then many CMM’s have evolved. This paper reports on how a CMM based on Drivers and Barriers to e-procurement identified in Eadie et al (2009) can be developed to gauge the maturity of an organisation in relation to e-procurement. This paper presents details of a research project which used factor analysis to produce a set of Key Process Areas (KPA) from the drivers and barriers identified in Eadie et al (2009). These KPAs were then subjected to a mapping process linking them to maturity levels to develop a CMM to analyse the e-procurement capability of construction organisations. The mapping will be reported in a later paper. This termed as e-readiness of organisations will indicate the current state of a construction organisation in terms of its readiness to carry out e-procurement. The paper describes in detail the identification of the KPA’s

An approach to reconcile the agile and CMMI contexts in product line development

Software product line approaches produce reusable platforms and architectures for products set developed by specific companies. These approaches are strategic in nature requiring coordination, discipline, commonality and communication. The Capability Maturity Model (CMM) contains important guidelines for process improvement, and specifies "what" we must have into account to achieve the disciplined processes (among others things). On the other hand, the agile context is playing an increasingly important role in current software engineering practices, specifying "how" the software practices must be addressed to obtain agile processes. In this paper, we carry out a preliminary analysis for reconciling agility and maturity models in software product line domain, taking advantage of both.Postprint (published version

The Measurement of Quality of Semantic Standards: the Application of a Quality Model on the SETU standard for eGovernment

eGovernment interoperability should be dealt with using high-quality standards. A quality model for standards is presented based on knowledge from the software engineering domain. In the tradition of action research the model is used on the SETU standard, a standard that is mandatory in the public sector of the Netherlands in order to achieve eGovernment interoperability. This results in improvement suggestions for the SETU standards, just as improvement suggestions for the quality model have been identified. Most importantly it shows that a quality model can be used for several purposes, including selecting standards for eGovernment interoperability

A hierarchy of SPI activities for software SMEs: results from ISO/IEC 12207-based SPI assessments

In an assessment of software process improvement (SPI) in 15 software small- and –medium-sized enterprises (software SMEs), we applied the broad spectrum of software specific and system context processes in ISO/IEC 12207 to the task of examining SPI in practice. Using the data collected in the study, we developed a four-tiered pyramidal hierarchy of SPI for software SMEs, with processes in the higher tiers undergoing SPI in more companies than processes on lower level tiers. The development of the hierarchy of SPI activities for software SMEs can facilitate future evolutions of process maturity reference frameworks, such as ISO/IEC 15504, in better supporting software development in software SMEs. Furthermore, the findings extend our body of knowledge concerning the practice of SPI in software SMEs, a large and vital sector of the software development community that has largely avoided the implementation of established process maturity and software quality management standards

Requirements engineering for computer integrated environments in construction

A Computer Integrated Environment (CIE) is the type of innovative integrated information system that helps to reduce fragmentation and enables the stakeholders to collaborate together in business. Researchers have observed that the concept of CIE has been the subject of research for many years but the uptake of this technology has been very limited because of the development of the technology and its effective implementation. Although CIE is very much valued by both industrialists and academics, the answers to the question of how to develop and how to implement it are still not clear. The industrialists and researchers conveyed that networking, collaboration, information sharing and communication will become popular and critical issues in the future, which can be managed through CIE systems. In order for successful development of the technology, successful delivery, and effective implementation of user and industry-oriented CIE systems, requirements engineering seems a key parameter. Therefore, through experiences and lessons learnt in various case studies of CIE systems developments, this book explains the development of a requirements engineering framework specific to the CIE system. The requirements engineering process that has been developed in the research is targeted at computer integrated environments with a particular interest in the construction industry as the implementation field. The key features of the requirements engineering framework are the following: (1) ready-to-use, (2) simple, (3) domain specific, (4) adaptable and (5) systematic, (6) integrated with the legacy systems. The method has three key constructs: i) techniques for requirements development, which includes the requirement elicitation, requirements analysis/modelling and requirements validation, ii) requirements documentation and iii) facilitating the requirements management. It focuses on system development methodologies for the human driven ICT solutions that provide communication, collaboration, information sharing and exchange through computer integrated environments for professionals situated in discrete locations but working in a multidisciplinary and interdisciplinary environment. The overview for each chapter of the book is as follows; Chapter 1 provides an overview by setting the scene and presents the issues involved in requirements engineering and CIE (Computer Integrated Environments). Furthermore, it makes an introduction to the necessity for requirements engineering for CIE system development, experiences and lessons learnt cumulatively from CIE systems developments that the authors have been involved in, and the process of the development of an ideal requirements engineering framework for CIE systems development, based on the experiences and lessons learnt from the multi-case studies. Chapter 2 aims at building up contextual knowledge to acquire a deeper understanding of the topic area. This includes a detailed definition of the requirements engineering discipline and the importance and principles of requirements engineering and its process. In addition, state of the art techniques and approaches, including contextual design approach, the use case modelling, and the agile requirements engineering processes, are explained to provide contextual knowledge and understanding about requirements engineering to the readers. After building contextual knowledge and understanding about requirements engineering in chapter 2, chapter 3 attempts to identify a scope and contextual knowledge and understanding about computer integrated environments and Building Information Modelling (BIM). In doing so, previous experiences of the authors about systems developments for computer integrated environments are explained in detail as the CIE/BIM case studies. In the light of contextual knowledge gained about requirements engineering in chapter 2, in order to realize the critical necessity of requirements engineering to combine technology, process and people issues in the right balance, chapter 4 will critically evaluate the requirements engineering activities of CIE systems developments that are explained in chapter 3. Furthermore, to support the necessity of requirements engineering for human centred CIE systems development, the findings from semi-structured interviews are shown in a concept map that is also explained in this chapter. In chapter 5, requirements engineering is investigated from different angles to pick up the key issues from discrete research studies and practice such as traceability through process and product modelling, goal-oriented requirements engineering, the essential and incidental complexities in requirements models, the measurability of quality requirements, the fundamentals of requirements engineering, identifying and involving the stakeholders, reconciling software requirements and system architectures and barriers to the industrial uptake of requirements engineering. In addition, a comprehensive research study measuring the success of requirements engineering processes through a set of evaluation criteria is introduced. Finally, the key issues and the criteria are comparatively analyzed and evaluated in order to match each other and confirm the validity of the criteria for the evaluation and assessment of the requirements engineering implementation in the CIE case study projects in chapter 7 and the key issues will be used in chapter 9 to support the CMM (Capability Maturity Model) for acceptance and wider implications of the requirements engineering framework to be proposed in chapter 8. Chapter 6 explains and particularly focuses on how the requirements engineering activities in the case study projects were handled by highlighting strengths and weaknesses. This will also include the experiences and lessons learnt from these system development practices. The findings from these developments will also be utilized to support the justification of the necessity of a requirements engineering framework for the CIE systems developments. In particular, the following are addressed. • common and shared understanding in requirements engineering efforts, • continuous improvement, • outputs of requirement engineering • reflections and the critical analysis of the requirements engineering approaches in these practices. The premise of chapter 7 is to evaluate and assess the requirements engineering approaches in the CIE case study developments from multiple viewpoints in order to find out the strengths and the weaknesses in these requirements engineering processes. This evaluation will be mainly based on the set of criteria developed by the researchers and developers in the requirements engineering community in order to measure the success rate of the requirements engineering techniques after their implementation in the various system development projects. This set of criteria has already been introduced in chapter 5. This critical assessment includes conducting a questionnaire based survey and descriptive statistical analysis. In chapter 8, the requirements engineering techniques tested in the CIE case study developments are composed and compiled into a requirements engineering process in the light of the strengths and the weaknesses identified in the previous chapter through benchmarking with a Capability Maturity Model (CMM) to ensure that it has the required level of maturity for implementation in the CIE systems developments. As a result of this chapter, a framework for a generic requirements engineering process for CIE systems development will be proposed. In chapter 9, the authors will discuss the acceptance and the wider implications of the proposed framework of requirements engineering process using the CMM from chapter 8 and the key issues from chapter 5. Chapter 10 is the concluding chapter and it summarizes the findings and brings the book to a close with recommendations for the implementation of the Proposed RE framework and also prescribes a guideline as a way forward for better implementation of requirements engineering for successful developments of the CIE systems in the future

Designing a consulting services architecture model

textDuring my years of experience in the technology industry, it has become obvious that standard processes and methodologies within the engineering discipline are at a mature state. The realization though is that software engineering specifically lags behind. Most software engineering methodologies that I have studied focus on the mission of software development. It is this realization and the need for structure that led me to review existing methodologies used within my company's software services organization. The definition of what a successful software services methodology entails is rather limited. This report will provide a history of existing software engineering methodologies that I have studied, describe an initial services method that was being developed within my organization, develop a new model that addresses previous shortcomings and identify additional components required to further define a strong software services-oriented delivery methodology.Electrical and Computer Engineerin

Modeling the object-oriented software process: OPEN and the unified process

A short introduction to software process modeling is presented, particularly object-oriented modeling. Two major industrial process models are discussed: the OPEN model and the Unified Process model. In more detail, the quality assurance in the Unified Process tool (formally called Objectory) is reviewed