Accessibility and Software Engineering Processes: A Systematic Literature Review

Welcome to the International Conference on Software and Systems Process (ICSSP) held in Zurich, Switzerland, on June 2nd and 3rd, 2012. Having grown from a Software Process Workshop in 2005 to the International Conference on Software Process (ICSP) in 2007, and finally to the International Conference on Software and Systems Process (ICSSP) in 2011, this conference series has established its place in the software engineering community as a respected conference focusing on research and practice related to software and systems development process. Software and software systems development use processes as one major means for achieving and ensuring the quality of the final product. This leads to specific challenges regarding software processes such as simplicity, adaptability, standard conformance, the coordination of multiple domains and lifecycles, etc. Processes from other domains (e.g., health care, manufacturing, business, aerospace, automotive systems, and others) face similar challenges. Yet, they share interesting similarities with and differences to software processes. The question is: How can we in the software domain learn from other domains to meet our software process engineering challenges? The ICSSP conferences hence connect the traditional software and systems process community with outside views and insights, broadening its scope of software development processes to system development and explicitly including processes of other domains such as health care, business, and manufacturing. By sharing process development theories and practices from such domains, ICSSP 2012 is investigating novel solutions to today's process challenges. Correspondingly, the main theme of ICSSP 2012 is Beyond Software and Software Systems Processes, signaling our goal of learning from domains other than the traditional software process community.

work of W. Edwards Deming has convinced industry that must first measure quality and then emphasise process to improve quality. In response to Deming's arguments and in light of perception that software industry is unable to produce quality products on schedule, and within budget, more software development organisations are now emphasising process measurement, monitoring, and assessment. This paper describes what is meant by software process and discusses an approach for its measurement and improvement. INTRODUCTION Unreliable software makes big news, from emergency services disasters to social security payment blunders. Improved software quality is essential to ensure reliable products and services, and gain customer satisfaction. While software development has existed for more than four decades, we failed so far to make as an industry and as an engineering discipline rather than craft. Developing reliable and usable software that is delivered on and within budget still represents difficult endeavour for many organisations. As role of software becomes increasingly critical for businesses as well as for human lives, problems caused by software products that are late, over budget, or that do not work, become magnified. If lives are lost or people inconvenienced due to incapable computer software, news media is there to make big stories. Organisations are realising that their fundamental problems is immaturity of their software process. Robert Lai (1993) proposes that process improvement is second maturity wave of software industry. He states that the first wave of software was developed using waterfall model in 1970's. Today we are Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 216 Software Management in midst of second wave maturity movement as we attempt to formally define development process and best ways to continuously improve it (Lai 1993). Taking lead in this area has been Watts Humphrey (Humphrey 1989, 1990, 1991), and Software Engineering Institute (SEI) at Carnegie Mellon University. SEI started in 1986 to develop process maturity framework to help organisations appraise maturity of their software process, and to provide guidance for organisations to improve their software process capability. A brief description of framework was released in September 1987, including maturity questionnaire. SEI evolved model and questionnaire into 5 -Level Capability Maturity Model (CMM) in 1991. In February 1993, released CMM version 1.1 (Paulk et al 1993). This paper discusses software process and describes capability maturity model (CMM). It also shows how CMM can be used as basis to measure maturity of software process of an organisation and plan its improvement. SOFTWARE QUALITY AND PROCESS IMPROVEMENT In his book Quality is Free Phil Crosby states that: Quality is free. It is not gift, is free. What cost money are unqualify of things all actions that involve not doing jobs right first time (Crosby 1980). If such statement is true for many disciplines, is particularly true for evidence is abundant in number of software products which exceeded their budget, were produced late, failed to satisfy user requirements, and are full of bugs. demand for improved software quality is increasing to ensure reliable products and services. benefits of improved quality comes in form of reduction in failure costs. For software projects failure costs include (DTI 1992): • costs of correcting defects, both before and after delivery • overruns against and budget • unnecessary high maintenance costs • indirect costs which users incur due to poor quality software link between process maturity and software quality is expressed in premise that The quality of software system is governed by quality of process used to develop and maintain it. One stumbling block to improving software quality seems to be that not enough attention is paid to overall development process itself. While software professionals typically devote their to developing, testing or documenting software products, no one has prime responsibility for improving software process. Experience has shown that if Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 Managing Systems 217 no one is working on software process, orderly improvement is unlikely. process certainly won't improve itself, rather, most likely, will deteriorate over time. Continuous improvement can occur only if process infrastructure is in place. Watts Humphrey argues in an early article published in Datamation, April 1989 that: Without work on process, there will be little or no progress in improving software. THE SOFTWARE PROCESS Adopting process view of software development represents revolutionary change in perspective. A process orientation to software development involves elements of structure, focus, measurement, ownership, skills, and supporting technology. In this section we investigate what is meant by software process. What Is Software Process According to Webster's dictionary, process is a system of operations in producing something .. series of actions, changes, or functions that achieve an end result. Chambers Concise Dictionary defines process as a series of actions or events .. sequence of operations or changes undergone. IEEE defines process as a sequence of steps performed for given purpose. In general business context, process is defined as a structured, measured set of activities designed to produce specified output for particular customer or market (Davenport 1993). These definitions put strong emphasis on HOW work is done, in contrast to product focus's emphasis on WHAT. Accordingly, process can be considered as a specific ordering of work activities across and place, with beginning, an end, and clearly identified inputs and outputs: structure for action. In this paper we will adopt following definitions quoted in (Humphrey 1990, Paulk et al 1993) are intended to encompass software throughout its life, which covers new development, enhancement, and repair. software process is The set of activities, methods, and practices used in production and evolution of software. software engineering process is The total set of software engineering activities needed to transform user's requirements into software. Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 218 Software Management People and Software Process Software development is still people-intensive activity. Talented people are most important element in any software organisation. Even if you get best people available, if they do not follow common process, if everyone wrote in different programming languages, used different conventions, or didn't co-ordinate their design and code changes with their peers, results will be chaos. Successful software organisations have learned that even best professionals need structured and disciplined environment in which to do cooperative work. Software organisations that do not establish such disciplines condemn their people to endless hours of repetitively solving technically trivial problems. obvious fact is that attracting best people is vital, but is also essential to support them with an effectively managed software process. Technology and Software Process Another myth is widespread belief that some technologically advanced tool or method will provide magic answer to software crisis. This is not only wrong, but is dangerous. Organisations which jumped on bandwagon of CASE tools, and ended up in failure and wasted and effort have learned their lesson hard way. Just ask yourself before introducing technology: What do I want to automate? In absence of defined, practised, and managed process, introducing automation can lead to increased chaos. There are several factors which limit effective use of software technology: an illdefined process, inconsistent process implementation, and poor process management. Software technology cannot be fully effective until these problems have been properly addressed. Need for Defined Process If no effort is made to define and enhance software development process across whole organisation, each software development project latches on to its own tools, methods, and practices with little guidance available on how to use them. This ad hoc approach will not be sufficient to tackle task of developing complex software systems. goal of software process management is to enable organisations to produce software that meets cost, schedules, and quality objectives. principles are same that underpins statistical process control-principles that have been successfully used in controlling scientific experiments and in high -volume manufacturing operations. Statistical concepts have been found to be just as applicable to software development as they are to production of manufactured goods such as motor cars. Applying such concepts will only be possible if there is defined and managed process. Software Process Models Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

Patterns are a means for capturing experience in solving general problems. They give general solutions to common and recurring problems. They exist at various phases of the software development life-cycle (SDLC), namely the analysis phase, the design phase, the coding phase and the testing phase. Patterns in each phase are identified independently. It is possible for the patterns of one phase to be related to patterns in other phases. This paper proposes pattern mapping to inter-relate the patterns of various phases in SDLC to address this issue. It is advantageous to capture the related patterns of different phases as a single unit for software development. Reusable integrated components (ICs) of patterns are proposed to capture the related patterns. A software IC is a group of inter-related patterns, that gives solutions for a recurring problem at various phases of SDLC. A representation mechanism for ICs is presented using the URA (Unified Representation of an Artifact) model, which captures the software development process. Also, this paper proposes a software development process that is based on reusable ICs of patterns. The representation of a software project developed using ICs is also discussed.

Cybersecurity risks are increasing in frequency and complexity, but many organizations struggle to plan and implement adequate protections at all stages of the software development life cycle (SDLC). Security is frequently added at the end of development (afterthought), and making effective use of safeguard space is difficult for IT leaders. The purpose of this study is to produce an all‐encompassing framework to adopt and ensure security throughout each phase of the SDLC, from planning through maintenance. The aim is to minimize vulnerabilities and improve the resilience of software by making “security by design” a structure that not only adopts security elegantly as a living document but also is built to be part of the development process. This study adopted a mixed‐methods approach. The initial stage of inquiry involved a systematic literature review (SLR) to identify common cybersecurity issues associated with each SDLC phase. The SLR was followed by an empirical survey of 71 software professionals from a variety of organizations. The survey was designed to gather perceived threats, current practices, and challenges associated with software development for survey participants' organizations. The data collected were analyzed and reviewed statistically, through chi‐square tests and ANOVA, to profile the variance relative to the size of the organization, geographic region, and experience level of the practitioner. The results noted several high‐risk challenges across the SDLC: underfunded security controls, imprecise requirements, insecure architecture, software bugs (i.e., injection vulnerabilities), inadequate testing, misconfigured production environments, and unreliable maintenance. The proposed framework provides cybersecurity mitigation techniques for each stage of the SDLC, such as leveraging security‐oriented design patterns, secure coding policies (i.e., input validation and authentication protocols), robust testing (i.e., penetration testing and code review), and continuous monitoring after deployment. The implementation of these measures leads to a significant risk reduction in the overall organizational security posture. The framework is a formalized end‐to‐end approach to secure software development by embedding security throughout the cycle. Embedding security as a part of the process versus an afterthought at every stage of the cycle creates a risk reduction impact. This integrated approach also provides organizations with the opportunity to foresee and mitigate events earlier in the cycle, along with general compliance mandates (i.e., GDPR, HIPAA, and PCI‐DSS), to provide more resilient, trustworthy software systems.

Nowadays, knowledge about design and implementation models of current version of software system and also knowledge about application domain of software system are important for software engineering processes related to design, management, maintenance and modification of software system. Utilization of proper knowledge can streamline and speed up each phase of software system life cycle and increase quality of outcome software and length of its operation. This paper briefly analyzes types of knowledge which could be utilized in software development and maintenance process and the ways how they can be acquired and stored. Proposed model-driven maintenance is based on utilization of knowledge acquired from abstract models of software system, which could be used as easy readable and understandable source of essential knowledge for maintenance process. The paper also analyzes the need of representing the knowledge about application domain in form of ontologies and the possibilities of using OMG specification of Ontology Definition Metamodel as a basis for development of these ontologies.

Practitioners as well as academics claim that the component-based software development paradigm is of major importance for the field of software engineering, and expect that in the near future most software systems will be developed following from components. Software organisations, applying component-based software-development technologies, are not only better able to handle complexity but also to reduce development times and cost by the systematic reuse of in-house and standard components. Thus, component-based development offers organisations a way to quickly react on market requirements.In practice the component-based development paradigm has only has a significant impact on the implementation phase of the software life cycle. Component technologies such as CORBA, JavaBeans/EJB, DCOM/AxtiveX and lately .NET basically allow the ‘technical’ cooperation of binary software building blocks of different origin. To counter this view there is a significant need to introduce the component-based development paradigm into all phases of the development life-cycle. In other words, the concept of a component should not just be seen as an implementation vehicle, but also as a central part of software design in term of concepts, methods and processes.The goal of this workshop is to examine the process of component-based software development in all phases of the development life-cycle (i.e., specification, design, composition, testing, deployment) and to identify how this process needs to be different from traditional software development. Participation is encouraged both from practitioners to provide their experiences and help in identifying open questions, and from researches to suggest methodological support for addressing these questions. The ultimate goals is thus to enable an exchange of experience between practitioners and researches concerning the relevance and feasibility of using the component paradigm throughout the software life-cycle.

A fuzzy logic based approach for phase-wise software defects prediction using software metrics

Integrating security at each phase of the software Development Life cycle (SDLC) has become an urgent need. Moreover, security must not be overlooked at early phases of SDLC. This helps to minimize cost and efforts for later phase of the life cycle. In addition, software security metrics are the tools to judge level of security of software. Without the use of the metrics, no one can ensure the usefulness of any approach which claims to improve security of the software. The paper presents a phase-wise review of security metrics and the issues in their adaptation. Though there are security metrics available for each phase of the software development life cycle, their usefulness in the software industry or in research is in question without their validation. In addition, a concrete research is needed to develop security metrics at early phases of software development life cycle.

Accessibility modifications are required for individuals with situational, temporary, or permanent impairments to properly interact with web applications. Incorporating accessibility guidelines, such as the Web Content Accessibility Guidelines (WCAG), into software development, along with the software development life cycle and other paradigms, poses challenges. The linear progression of steps in a conventional software development process leads to the identification of problems at a later stage because testing is typically conducted toward the end. Limited attention to accessibility until the final development phase results in prolonged efforts, increased resource allocation, and higher expenses to address accessibility issues. Consequently, numerous software applications remain inaccessible to users with impairments. This study focuses on a Shift Left-based model to improve accessibility in the software development process. Employing the Shift Left a11y Model that emphasizes early integration for accessibility and coupling it with the Extreme Programming Development Life Cycle would enhance the integration of various testing practices and facilitate the development of software that is accessible to all users, including those with impairments. Keywords: Accessibility, accessible software, shift-left, model, methodology for accessible software

Many papers proposed in the software engineering and information systems literature are dedicated to analysis of software projects missing their schedules, exceeding their budgets, delivering software products with poor quality and in some cases even wrong functionality. The expression “software crisis“ has been coined since the late 60's to illustrate this phenomenon. Various solutions has been proposed by academics and practitioners in order to deal with the software crisis, counter these trends and improve productivity and software quality. Such solutions recommend software process improvement as the best way to build software products needed by modern organizations. Among the well-known solutions, many are based either on software development tools or on software development approaches, methods, processes, and notations. Nevertheless, the scope of these solutions seems to be limited and the improvements they provide are often not significant. We think that since software artifacts are accumulation of knowledge owned by organizational stakeholders, the software crisis is due to a knowledge gap resulting from the discrepancy between the knowledge integrated in software systems and the knowledge owned by organizational actors. In particular, integrating knowledge management in software development process permits reducing the knowledge gap through building software products which reflect at least partly the organization's know-how. In this paper, we propose a framework which provides a definition of knowledge based on information systems architecture and describes a knowledge-oriented software development process to help organizations in reducing the software crisis impacts.

The software development process model or what is commonly called SDLC (Software Development Life Cycle) is one of the Software Engineering (RPL) course materials in the Information Engineering Education (PTI) undergraduate study program where one of the competencies is understanding and knowing the concepts of device engineering software that can be applied in the software development life cycle which is summarized in the material for the SDLC software development process model. This material is the initial material that must be mastered by students to develop quality software. The use of interactive and interesting computer assisted learning media is expected to help the stages of the student learning process properly. This requires an interactive learning multimedia application. The purpose of this research is to develop interactive learning media as an alternative to independent learning tools to assist students in mastering the Software Development Process Model (SDLC) material for students and to find out the feasibility of multimedia application products for learning the Software Development Process Model (SDLC). The research and development methodology used in this research is Research and Development (R&D) with Borg and Gall's development steps which include: (1) Research and data collection; (2) Planning; (3) Development of product drafts; (4) Initial field trials; (5) Revision of trial results (6) Field trials; (7) Product improvement; (8) Field implementation test; (9) Completion of the final product; and (10) Dissemination of implementation. This methodology covers all matters relating to development to produce quality interactive learning media software. Based on the trials, the results obtained were 90.63 percent from media experts, 98.08 percent from material experts, 85.46 percent from initial field trials, 84.56 percent from field trials, and 86.27 percent from field implementation trials. The average value obtained is 89 percent based on the results of the overall data analysis. The conclusion of this research is that the development of multimedia applications for learning the Software Development Process Model (SDLC) is feasible as an independent learning medium. The product produced in this development research is a multimedia application for learning flash-based software development process (SDLC) models.

Effective prediction of software modules, those that are prone to defects, will enable software developers to achieve efficient allocation of resources and to concentrate on quality assurance activities. The process of software development life cycle basically includes design, analysis, implementation, testing, and release phases. Generally, software testing is a critical task in the software development process wherein it is to save time and budget by detecting defects at the earliest and deliver a product without defects to the customers. This testing phase should be carefully operated in an effective manner to release a defect-free (bug-free) software product to the customers. In order to improve the software testing process, fault prediction methods identify the software parts that are more noted to be defect-prone. This paper proposes a prediction approach based on conventional radial basis function neural network (RBFNN) and the novel adaptive dimensional biogeography based optimization (ADBBO) model. The developed ADBBO based RBFNN model is tested with five publicly available datasets from the NASA data program repository. The computed results prove the effectiveness of the proposed ADBBO-RBFNN classifier approach with respect to the considered metrics in comparison with that of the early predictors available in the literature for the same datasets.

This paper proposes a methodology for the development and its Verification and Validation(V&V) of safety-rated software. The development methodology is based on the structured analysis and structured design methodology, which has been proven in the field of safety software development during long period. The suggested the development and the V&V methodology additionally focuses on the quality attributes 3C+T (completeness, Correctness, Consistency and traceability), which are important criteria in IEC international standards. The software development life cycle is compiled from IEC international standardization, which are of the requirements analysis phase, design phase, implementation phase, testing phase, installation/commissioning phase, and operation & maintenance phases. The activities of the development process method were defined from requirements analysis to implementation, and the activities of the verification and validation were defined to include the scope of the developer's activities and then to include the test phase, installation/commissioning phase, and operation phases additionally. In other words, testing phase performed by the developer was defined as informal testing, and testing performed by the verifier according to test criteria, test plans, and test procedures was defined as formal testing. According to proposed methodology, the requirements phase defines the sequence of Entity Relationship Diagram (ERD)-Context Diagram-Data Flow Diagram (DFD), functional decomposition process and defines operational scenario. In the design phase, module design such as task analysis and task allocation were defined. In the implementation phase, we listed the coding guidelines that must be followed for safety-related system. The test phase defined the test criteria, test plan, test procedure, and test result report activities. In the installation/commissioning and operation phases, recommendations for improving reliability, quality, and safety were proposed for deliverables such as user documentation and technical documentation.

Software process is the most important part of software project management, and software process models are important means of implementing the software process in any software organization. When there is need to improve the software process, then the need to improve the work-task part (software process models) of the software process must arise. As, there is need of increasing the commitment of software project managers through out the software development life cycle (SDLC), so we need to give them the list of activities in Waterfall Model, which should be made efficient by the software development team, to get the 80% productivity (output) easily, by reducing the effort of software development and ultimately increasing the performance of the software process. So, the idea of 80/20 rule (Pareto Principle, 1935) can be applied in the software engineering process model, in this regard. The Pareto Principle (1935) directed us to focus on what is really important in any field and field's work. Software process is most important part of software project management (SPM). This is also then ultimately needed for software project management (SPM) improvement. Our main research work is to improve the work-task part of the software process (i.e. software process models by applying the Pareto Principle - 80/20 Rule (1935) (or law of vital few) (1935), in the software engineering process models (or work-task part of the software process). This will be to facilitate the software project manager, using the software process models practically more efficient than without application of 80/20 Rule in software engineering Waterfall model. This has resulted in the reduction of the software development effort and increase in the performance of the software process. The results (efficient and improved software process models) will be implemented in the software industry, by software project managers, by focusing on the list of activities giving 80 percent of the overall productivity of the software process. The results will be the list of activities having the capability to give 20 percent of the overall productivity of the software Waterfall process, to be ignored, eliminated or designated to reduce the effort.

CloudTeams: Bridging the Gap Between Developers and Customers During Software Development Processes