No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
Abstract
This paper describes the experience of applying agile approaches to the development of firmware for the Intel® Itanium® processor family. Embedded development (i.e. firmware) projects are quite different from object-oriented and pure software endeavors, yet they face many of the same challenges that agile software development practices address. Several unique challenges are described, including team members' specialized domain knowledge, technical backgrounds and attitudes toward change, and the impact hardware plays in firmware design. We found agile approaches to be well-suited for our project, despite the fact that most agile methodologists come from very different backgrounds.
... These practices are suggested to address the project scope management in CPS projects: application of international standards, estimations based on use case points and hardware points, software and frameworks for requirements analysis, specific modeling languages for requirements elicitation and system architecture visualization, requirements review through peer reviewing and Scrum boards, development of design models, specific development approaches, meet-ings with live demonstrations, analysis-driven design, lists of requirements, modeldriven design and new process models for scope management and project development [20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39]. ...
... As for the project human resource, the following practices are suggested to address this knowledge area in CPS projects: acquisition of a multidisciplinary and expert team; definition of specific key-roles usually needed for the team members; distribution of tasks considering the team members' profile and expertise; statistical estimation and classification of familiarity of team members, according their profiles and requirements; training in specific development methods, such as goal-driven, model-driven and extreme programming; and skill based human resource management [20,22,23,40,25,41,29,30,31,34,36,35]. ...
... Finally, these practices are suggested to address project stakeholders in CPS projects: identification of stakeholders and assignment of tasks following systematic algorithms and norms, assignment of stakeholders within the organization, involvement of stakeholders during the transition between development phases, face-to-face meetings, workshop meetings and specific stakeholders management approaches such as the evolutionary development and the constructive SoS integration model [20,22,23,25,29,31,32,42,34,36]. ...
We propose specific practices for managing Cyber-Physical Systems (CPS) development projects. Our approach is named CPS-PMBOK as it is based on the Project Management Institute’s PMBOK body of knowledge. CPS-PMBOK is focused on the integration, scope, human resource and stakeholder knowledge areas; which were chosen considering some particularities of CPS, such as multidisciplinary team and high innovative aspect. The proposed approach was assessed with managers and developers of a R&D organization, who identified that the proposed practices can improve several aspects related to CPS projects.
... A broader view of the literature about embedded systems reveals possible adoptions of Software Engineering methodologies and tools in hardware-related development [22][23][24][25]. Ronkainen et al. described challenges with hard real-time requirements, prototyping, documentation, and testdriven development in Agile hardware development [22]. ...
... Ronkainen et al. described challenges with hard real-time requirements, prototyping, documentation, and testdriven development in Agile hardware development [22]. Greene reported a positive experience of applying Agile approaches in firmware development at Intel [23]. Adopting XP practices, Santos et al. showed a successful software version created for control of a satellite camera [24]. ...
... Our cases also demonstrate the adoption of Agile methodologies in the context of Internet-of-Things. Agile adoption has been previously reported in the context of embedded systems [22][23][24][25]. We also noticed similar challenges with hardware-related development, such as hard real-time requirements, prototyping, documentation and test-driven development [22]. ...
Internet-of-Things applications are not only the new opportunity for digital businesses but also a major driving force for the modification and creation of software systems in all industries and businesses. Compared to other types of software-intensive products, the development of Internet-of-Things applications lacks a systematic approach and guidelines. This paper aims at understanding the methodological commonalities among startups who are developing Internet-of-Things products. Using the SEMAT Essence framework, we captured common team compositions, common types of Minimum Viable Products and common way of working in early stage Internet-of-Things startups. We found that startups include various engineering and business competence, but do not cover all of what is needed. The development of Internet-of-Things applications adopts certain speed-favor approaches, i.e. rapid prototyping, iterative development and outsourcing. The finding implies some recommendations for both researchers and practitioners in the area of Internet-of-Things development.
... The following practices are suggested to manage scope in CPS projects: software and frameworks for requirements analysis; application of international standards; estimations based on use case points and hardware points; specific modeling languages for requirements elicitation and system architecture visualization; requirements review via peer reviewing and Scrum boards; development of design models; specific development approaches; meetings with live demonstrations; analysis-driven design; requirements lists; model-driven design; and new process models for scope management (Greene, 2004;Jun et al., 2007;Madachy et al., 2007;Madachy, 2008;Silva et al., 2009;Shatil et al., 2010;Berger and Rumpe, 2010;Garay and Kofuji, 2010;Savio et al., 2011;Rong et al., 2011;Helps and Mensah, 2012;Huang et al., 2012;Penzenstadler and Eckhardt, 2012;Insaurralde and Petillot, 2013;Zhu and Mostafavi, 2014;Parkhomenko and Gladkova, 2014;Yue and Ali, 2014;Sapienza et al., 2014;Faschang et al., 2015;Lattmann et al., 2015). ...
... For human resource, these practices are suggested to CPS projects: distribution of tasks considering the team members' profile and expertise as well as statistical estimation and classification of familiarity of team members, according to their profiles and requirements; definition of specific key-roles needed for the team; use of an expert and multidisciplinary team; training in specific development methods, such as goal-and model-driven and extreme programming; and skill-based human resource management (Greene, 2004;Madachy et al., 2007;Madachy, 2008;Chen and Wei, 2009;Shatil et al., 2010;Wolff et al., 2011;Rong et al., 2011;Helps and Mensah, 2012;Huang et al., 2012;Zhu and Mostafavi, 2014;Yue and Ali, 2014;Parkhomenko and Gladkova, 2014). ...
... Finally, considering the project stakeholders, the following practices are suggested to address this knowledge area in CPS projects: identification of stakeholders and assignment of tasks following systematic algorithms and norms; assignment of stakeholders within the organization; involvement of stakeholders during the transition between development phases; face-to-face meetings; workshop meetings; and specific stakeholders management approaches such as the evolutionary development and the constructive SoS integration model (Greene, 2004;Madachy et al., 2007;Madachy, 2008;Shatil et al., 2010;Rong et al., 2011;Huang et al., 2012;Penzenstadler and Eckhardt, 2012;Zhu and Mostafavi, 2014;Yue and Ali, 2014;Singh, 2013). ...
Cyber-Physical Systems (CPS) represent the convergence of physical processes and computational platforms into technological solutions composed by sensors, actuators and software. Such as for other types of projects, project management practices can benefit a CPS development project. Due to some particularities of CPS, such as multidisciplinary team and high innovative aspect, generic project management practices may not be enough to enhance project success. Therefore, specific practices are proposed for better managing CPS projects, called CPS-PMBOK approach. CPS-PMBOK is based on the Project Management Institute's PMBOK body of knowledge. It is focused on the integration, scope, human resource and stakeholder knowledge areas; which were chosen considering a systematic literature review conducted to identify the main CPS challenges. Managers and developers of a R&D organization evaluated the approach. According to the practitioners consulted, the proposed practices can improve several aspects related to CPS projects.
... Advanced technologies and tools for modelling, simulation has enabled the adoption of shorter cycles of hardware-related product development [29,30]. Research has shown several positive experience using Agile methodologies in embedded systems [31][32][33][34][35]. Greene reported a positive experience of applying Agile approaches in firmware development at Intel [31]. Cordeiro Sone research has been done on how start-ups developed software products that reflect various types of software MVPs and MVP prototyping practices [5,6,11,20,[25][26][27][28]. ...
... Advanced technologies and tools for modelling, simulation has enabled the adoption of shorter cycles of hardware-related product development [29,30]. Research has shown several positive experience using Agile methodologies in embedded systems [31][32][33][34][35]. Greene reported a positive experience of applying Agile approaches in firmware development at Intel [31]. ...
... Advanced technologies and tools for modelling, simulation has enabled the adoption of shorter cycles of hardware-related product development [29,30]. Research has shown several positive experience using Agile methodologies in embedded systems [31][32][33][34][35]. Greene reported a positive experience of applying Agile approaches in firmware development at Intel [31]. Cordeiro et al. proposed a new platform-based design using Agile approaches that substantially reduced development time in three hardware development projects [32]. ...
Internet of Things applications are not only the new opportunity for digital businesses but also a major driving force for the modification and creation of software systems in all industries and businesses. Compared to other types of software-intensive products, the development of Internet of Things applications lacks a systematic approach and guidelines. This paper aims at understanding the common practices and challenges among start-up companies who are developing Internet of Things products. A qualitative research is conducted with data from twelve semi-structured interviews. A thematic analysis reveals common types of Minimum Viable Products, prototyping techniques and production concerns among early stage hardware start-ups. We found that hardware start-ups go through an incremental prototyping process toward production. The progress associates with the transition from speed-focus to quality-focus. Hardware start-ups heavily rely on third-party vendors in term of development speed and final product quality. We identified 24 challenges related to management, requirement, design, implementation and testing. Internet of Things entrepreneurs should be aware of relevant pitfalls and managing both internal and external risks.
... These practices were found to manage scope in CPS projects: software and frameworks for requirements analysis, application of international standards, estimates based on use case points and hardware points, specific modeling languages for requirements elicitation and system architecture visualization, requirements review through peer reviewing and Scrum boards, development of design models, meetings with live demonstrations, and requirements lists and model-driven design [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31]. ...
... As for the project human resource, these practices were found to CPS projects: use of an expert and multidisciplinary team, statistical estimates and classification of familiarity of team members, training in specific development methods, such as goal-and model-driven and extreme programming, and skill-based human resource management [12], [14], [15], [32], [17], [33], [21], [22], [23], [26], [28], [27]. ...
... Finally, considering the project stakeholders, these practices were found as suggestions to address this knowledge area in CPS projects: identification of stakeholders and assignment of tasks following systematic algorithms and norms, assignment of stakeholders within the organization, involvement of stakeholders during the transition between development phases, and workshop meetings and constructive SoS integration model [12], [14], [15], [17], [21], [23], [24], [26], [28], [34]. ...
In this paper, specific practices are proposed for better managing Cyber-physical Sytems (CPS) projects, called CPS-PMBOK approach. CPS-PMBOK is based on the Project Management Institute's PMBOK body of knowledge. It is focused on the integration, scope, human resource and stakeholder knowledge areas; which were chosen considering a systematic literature review conducted to identify the main CPS challenges.
... are applying agile methods in one way or another. However, based on the literature review, most related work about the utilization of agile methods is centered around embedded software development while hardware is left out the scope of agile practices [15] [16] [17]. Additionally, it has been concluded that agile development can even be applied to mass-produced embedded systems where the full R&D process cannot be agile [18]. ...
... One change may affect the whole system. The interactions between hardware and software are sensitive to changes [15]. Any changes in the design can cause variations in timing or other behavior inside the system. ...
... The most closely related theory from the existing literature [12] [13] [14] presents benefits and drawbacks connected to the use of agile methods in pure software development. Also, [15] [16] [17] suggest that there is need for modifications to agile methods in embedded context but analyze the situation only from the embedded software development point of view thus omitting the hardware development. ...
Agile methods are widely utilized in software development but their usage in embedded system development is often limited to software. A case study of three industrial cases was carried out to understand how to tailor agile methods effectively including also hardware development. Agile practices, mostly derived from Scrum, were tailored to fit the needs of each team and the method development was closely followed. Surveys conducted in the beginning and in the end of the cases were compared and complemented with interviews to understand the new working methods and their effects. Case evidence shows that interdependencies between work of each developer were taken into account better, visibility over the whole product increased and need for internal documentation diminished due to improved communication, but dividing hardware tasks into iterations was experienced difficult. With some tailoring, agile practices are beneficial also in the embedded system development. To successfully adopt agile methods into embedded system development, the team must consist of all the project members, the natural cycle lengths of different disciplines and different knowledge between the developers must be accepted and built upon, and the progress of the product must be presented or visualized in the end of each iteration.
... When the pair split for a pair swap, the knowledge spread to all four participants. At Intel, two projects reported higher knowledge transfer through the pair programming method: in the IXP2xx project, developers believed they learned quite a lot from each other (Fitzgerald and Hartnett, 2005); in another project that developed firmware for processors, cross-training happened when pair programming was practiced even though it was not to the extent as the developers had hoped (Greene, 2004). Ambler (2007) programming was a tool to mitigate the risk of relying on highly skilled individuals to produce results (Ambler, 2008). ...
... This view was echoed by Fitzgerald and Hartnett (2005) which noted the difficulty for one partner to reflect and concentrate with someone by his/her side. Taking this further, Greene (2004) reported that even though pair programming worked well, in general, at Intel, hard deadlines created problems for pair programming when one developer had more domain knowledge. He suggested at crunch time it was more expeditious for the expert to work on the implementation alone; pairing with another developer would reduce productivity. ...
... Williams and Kessler (2003) noted it was crucial to overcome management resistance (chapter 4, pp.33-44): pair programmers create noise and resolving this problem may require a commitment from the organization in terms of a facility change or equipment purchase; pairing can also be difficult if cubicles or desks are arranged improperly. At Intel, managers tore down cubicle walls to lower the physical barriers to communication and introduced a new individual evaluation criterion: teamwork that reinforced the value of collaborative work (Greene, 2004). ...
... In spite of that, short-time boxed iterations with adaptive, evolutionary refinement of plans and goals is a basic practice that these methods share [3,8]. Although this apparently contradicts the agile method principles, the use of these methods in the development of embedded systems has also been explored [9,10,11]. The aim of these experiments has been to explore and adapt such methods in order to build embedded systems more effectively. ...
... Through the primary studies identified in our systematic review, we can observe that agile methods, their adaptations, and their practices have been experimented within real projects of industrial organizations. Greene [9] (study S4) describes an experience in applying agile approaches to the development of firmware for the Intel Itanium processor family. Studies S12 and S13 present the development of a digital softstarter [23] and of a induction motor simulator prototypes, respectively [24]. ...
... They combine these practices with hardware/software co-design in order to manage the cost, development time, and risk of a project involving embedded systems. With respect to pair programming, Greene [9] (study S4) says that it is the most controversial practice, whereas the most valuable practice is unit testing. This study also combined the practices of Scrum and XP into its own running method. ...
Embedded systems are widely used in diverse areas, such as avionics, consumer electronics, and medical equipments, causing a considerable impact on modern society. Since these systems sometimes deal directly with human lives, and require a considerable level of quality, their development should be subject to a rigorous process. In another perspective, agile methods (or agile processes) have been adopted by the software industry as a lightweight, iterative, and collaborative approach for developing software systems. Although agile methods do not seem to be suitable to embedded systems, they have been successfully used for building such systems. However, there exists no detailed and analytical overview of the use of such methods in the embedded systems domain. The main objective of this paper is to present a detailed view of how agile methods have been used in the development of embedded systems, and to describe their benefits, challenges, and limitations. For this, we have applied Systematic Review, a technique for systematically exploring, organizing, summarizing, and assessing potentially all works conducted in a specific research area. As the main result, we have observed that agile methods have brought advantages to embedded systems development; however, more studies should be conducted. Furthermore, this work is also intended to contribute to the identification of important new research lines.
... In order to ensure some use of PP they started to require everyone to work one day per week with something else than their core expertise. [13] In Guidant Corporation PP was added to a quite traditional development process. Rules for the practicalities of PP were established but the developers were allowed to choose between PP and their old way. ...
... In one XP team PP was reported to be used for all tasks. [15] 30% of time [16] application all design and some programming [12] detailed design and initial coding [13] each task was assigned to a pair, but the degree of working together varied [14] solving problems and technical difficulties, not for trivial tasks [15] difficult tasks and teaching, later all tasks [7] limiting factors expected effort increase [12] no time for PP due to deadline pressure [13] only peer reviews before check-in [5] developers cannot work with everyone [16] organization's culture [15,17] ...
... In one XP team PP was reported to be used for all tasks. [15] 30% of time [16] application all design and some programming [12] detailed design and initial coding [13] each task was assigned to a pair, but the degree of working together varied [14] solving problems and technical difficulties, not for trivial tasks [15] difficult tasks and teaching, later all tasks [7] limiting factors expected effort increase [12] no time for PP due to deadline pressure [13] only peer reviews before check-in [5] developers cannot work with everyone [16] organization's culture [15,17] ...
The interest in pair programming (PP) has increased recently, e.g. by the popularization of agile software development. However, many practicalities of PP are poorly understood. We present experiences of using PP extensively in an industrial project. The fact that the team had a limited number of high-end workstations forced it in a positive way to quick deployment and rigorous use of PP. The developers liked PP and learned it easily. Initially, the pairs were not rotated frequently but adopting daily, random rotation improved the situation. Frequent rotation seemed to improve knowledge transfer. The driver/navigator roles were switched seldom, but still the partners communicated actively. The navigator rarely spotted defects during coding, but the released code contained almost no defects. Test-driven development and design in pairs possibly decreased defects. The developers considered that PP improved quality and knowledge transfer, and was better suited for complex tasks than for easy tasks
... Debido a la gran importancia en nuestra vida cotidiana que tienen hoy los sistemas embebidos, ha ido creciendo el interés por diseñar y desarrollar este tipo de sistemas para que sean robustos, confiables y de calidad que cumplan con requerimientos como tamaño, ahorro de energía y bajos costos de producción [4], entre otros, lo que ha originado idear metodologías y técnicas que permitan mayor rapidez en su diseño, desarrollo e implementación. A continuación, se dará una breve introducción de algunas de las metodologías de diseño de HW/SW de sistemas embebidos que se consideran adecuadas [16,17] para este tipo de soluciones. ...
... Un ejemplo de este tipo de sistemas es aquel que se encuentra en electrodomésticos como el horno de microondas. Debido a su naturaleza cambiante y a la complejidad que en la actualidad demanda el diseño y desarrollo de este tipo de sistemas, las metodologías empleadas no pueden ser las mismas que para aquellas empleadas para sistemas de propósito general como las PCs[16].En el diseño, desarrollo e implementación de este tipo de sistemas, existen dos metodologías principales como las metodologías de diseño de HW/SW y las metodologías para la planeación de proyectos de desarrollo de HW/SW[17]. Con las primeras se intenta armar la arquitectura del sistema y con las segundas, se identifican los pasos a seguir en el diseño y desarrollo de un producto final.En las siguientes subsecciones solo se mencionarán las metodologías correspondientes al diseño de HW/SW. Las metodologías para la planeación de proyectos no es tema del presente trabajo de tesis, pero es necesario entender la diferencia de estos dos conceptos. ...
Ante la reciente necesidad de automatizar el monitoreo de entornos tanto internos como externos, surge la necesidad de encontrar tecnologías que lo permitan. Una de ellas es implementar una red inalámbrica de sensores (WSN, Wireless Sensor Networks) en la que se distribuyen sistemas embebidos autónomos de bajo costo conocidos como Motes. Estos Motes contienen en su interior, Software embebido personalizado y por lo general, se emplean dos o más microcontroladores en su desarrollo, pero sin seguir una metodología de desarrollo además de ser difíciles de programar. Lo anterior, incrementa el costo de las WSN, su consumo de energía y tiempos de desarrollo. En este artículo se presenta una metodología genérica basada en componentes virtuales de Hardware para implementar una WSN de forma ágil y a bajo costo. Dicha metodología facilita el trabajo no solo del programador a nivel de Hardware sino del programador a nivel de aplicaciones.
... Continuous Delivery (CD) can handle this adaptation, such as automating the build, test, and delivery process achieving better time to market, better customer satisfaction, and good product quality [Chen 2015a]. Applying CD in the hardware and firmware development implies various challenges as a resistance of the professionals in using agile practices [Greene 2004, Srinivasan et al. 2009]. This research aims to propose and evaluate a conceptual model capable of assisting in planning continuous delivery pipelines for IoT systems focused on the hardware and firmware development. ...
... Greene [Greene 2004] cited several unique challenges in the embedded software development as many firmware developers are not classically trained software engineers but often have electrical engineering backgrounds and pick up programming as needed to solve reluctant to adopt the latest software tools and methodologies. They strive to develop code as expediently as possible. ...
The development of IoT systems brings the adequacy of software engineering to current paradigms, such as IoT, industry 4.0, smart cities and environments, and wearable devices. IoT systems require the integration of different technologies such as sensors, actuators, edge devices, cloud computing, big data, artificial intelligence, and IT operations. The successful delivery of products depends directly on the continuous cooperation of professionals with different skills. However, we noticed a specific resistance in carrying out continuous and automated software deliveries to hardware devices by professionals. This research investigates the practices and technologies for the continuous software delivery pipeline on hardware devices that make up an IoT system.
... Table 1 summarizes key differences between a typical software development and hardware development process. Even though it is a popular perception that hardware systems are associated with waterfall development methodologies, research has shown several positive experiences using Agile methodologies in embedded systems [5,[8][9][10]. Greene reported a positive experience of applying Agile approaches in firmware development at Intel [8]. ...
... Even though it is a popular perception that hardware systems are associated with waterfall development methodologies, research has shown several positive experiences using Agile methodologies in embedded systems [5,[8][9][10]. Greene reported a positive experience of applying Agile approaches in firmware development at Intel [8]. Adopting XP practices, Santos et al. showed a successful software version created for control of a satellite camera [9]. ...
Hardware startups, i.e., wearable devices, robotics, and Internet of Things, are a significant sector of technology startups, in which software development is relevant and needed. Compared to pure software startups, hardware development in startup contexts lacks a systematic approach and guidelines. This chapter describes an empirical model that captures common elements in product development approaches among many hardware startups. Grounded from insights of 18 active hardware startups, we constructed a trilateral model of resource, speed, and quality in early-stage product development. For startups with relevant contexts, the work suggests the preparation of internal, external resources, and good practices of prototyping and matching prototypes to business activities.
... CI enables test-driven development, a practice in which a test is written prior to functional implementation. Developers alternate between writing tests and implementing functionality on a minuteby-minute basis (Beck 2003), which is a significant change of habit from the traditionally sequential process of implementing and testing (Toleman et al. 2004;Greene 2004;Stober and Hansmann 2010;Nyman et al. 2010). To achieve large code coverage, i.e. tests exist for a large part of the source code, a high granularity of testing is aimed at. ...
... A more sophisticated strategy is establishing a testing hierarchy, with tests of single code fragments on the lowest level and usage behavior tests on the highest level, respectively. Depending on the level, tests are carried out at different frequencies (Greene 2004;Jääskeläinen et al. 2008;Ali et al. 2012;Rogers 2004). For example, Jääskeläinen et al. (2008) propose to perform unit tests with every code check-in, while executing use case tests less frequently. ...
Despite being a cornerstone of agile development, surprisingly little is known about how organizations assimilate continuous integration (CI) and what organizational changes the practice implies. Through a systematic literature review complemented by case study research we address this gap and develop a conceptual framework describing organizational implications of CI assimilation. We employ adoption theory of technology-induced innovation as theoretical lens and argue that as organizations transform through the assimilation stages, ambiguity increases, forcing them to think in alternatives and take trade-offs. To the existing body of knowledge on agile development assimilation we add an in-depth study of a distinct agile practice.
... Embedded software development teams usually do not make use of system development methodologies or any other more complex software engineering concept [9]. There are different reasons that explain this fact, but the main one is the developers' lack of maturity related to software engineering practices. ...
... One of the results from our bibliographical review is a paper that describes the experience of applying Agile approaches to the development of firmware for the Intel Itanium processor family [9]. In this paper, Greene identified the agile practices that his team successfully applied, but he did not take into account the hardware related development, one of the main parts of this kind of development. ...
Arterial oxygen saturation and heart rate measured by pulse oximetry is widely used to monitor critical care patients. This kind of system is classified as embedded hard real-time system and requires rigorous development methodologies to guarantee the correctness and timeliness of the application. Therefore, the proposed development methodology combines agile principles with organizational patterns and adapts them to build medical devices focusing on the issues related to the system's constraints and safety. Strong unit testing is the foundation of the proposed methodology for ensuring timeliness and correctness. Moreover, platform-based design approach is used to balance costs and time-to-market in view of performance and functionality constraints. We conclude that the proposed methodology reduces significantly the design time and cost as well as leads to better software modularity and safety.
... Embedded software development teams usually do not make use of system development methodologies or any other more complex software engineering concept [9]. There are different reasons that explain this fact, but the main one is the developers' lack of maturity related to software engineering practices. ...
... Nevertheless, we identified in the literature through a bibliographical review, different development methodologies that allowed us to evaluate the state of the art in this context and to support us during the definition of our proposed approach. One of the results from our bibliographical review is a paper that describes the experience of applying Agile approaches to the development of firmware for the Intel Itanium processor family [9]. In this paper, Greene identified the agile practices that his team successfully applied, but he did not take into account the hardware related development , one of the main parts of this kind of development. ...
... Taking Scrum as an example, we identified the following practices associated to it [4,36,44]: 1) specification of requirements in the format of user stories; 2) elaboration of the product backlog containing the user stories of the product to be developed; 3) decomposition of development in sprints; 4) sprint planning meeting; 5) elaboration of sprint backlog at the start of each sprint; 6) sprint review meeting; 7) retrospective meeting at the end of development; 8) use of burndown graphs to monitor progress within a sprint; 9) removal of impediments; 10) flexible delivery (make flexible what will be delivered, but always have regular deliveries); 11) small teams; 12) encourage object-oriented programming; 13) definition of three roles (Scrum master, product owner, and development team); and 14) daily meeting. ...
This work proposes a set of complementary practices to agile methodologies, aiming at adapting them to the development of critical aerospace embedded systems by distributed teams. To identify the main gaps in this context, two approaches are used. The first one confronts the main activities required by aerospace standards for the development of critical embedded systems with a set of compiled agile practices derived from a review of the most common agile methodologies. The second one confronts the same set of compiled agile practices with the main problems of distributed development. The two approaches resulted in the identification of four gaps related to software integration, software traceability, communication management, and organizational differences. One complementary practice is then proposed for each gap. Two case studies were performed to assess the gaps and evaluate the proposed practices. Both emulate the development of critical embedded systems by distributed teams using agile methodologies. The case studies were performed with and without the use of the complementary practices. The results confirmed three of the four identified gaps and pointed to a clear contribution of the complementary practices.
... Moreover, OTA is essential in order to ensure that existing infrastructures will be able to address future security flaws without requiring the substitution of massive amounts of old units or manual flashing procedures. In fact, the application of continuous development and continuous integration techniques that make use of underlying OTA technologies may result in mitigating and preventing some of threats and vulnerabilities previously described [29]. While OTA is a crucial requirement for massive IoT deployments in smart cities, it cannot be denied that it also constitutes a potential vulnerability: ...
Smart cities rapidly deploy infrastructure for information and communication technologies (ICTs) and digitize the available information, creating models reflecting specific interactions and domains. The "Internet of Things" (IoT) is a prominent key technology that enables connections and communications with a vast number of smart city "things". Cybercrime is crime committed using computing and communication systems such as computers and networks. The chapter provides a primer on cybercrime in smart cities and possible technological countermeasures to it. It introduces the threat landscape, both for citizen-facing systems and smart infrastructures, and a survey of real-world incidents of attacks against smart cities. The chapter discusses the security and privacy requirements for IoT-based smart city components and the integration of citizen concerns and considerations in the design. Finally, it describes a list of recommendations for designing and deploying citizen-centric IoT-based systems for future smart cities.
... However, while some works have suggested that Agile methods could be applied for embedded system design [2,129], hardware cannot be easily or inexpensively changed like software, and individual developers may only be experienced in certain domains [269]. To change the hardware components of a large system on each iteration would be unrealistic and expensive. ...
The presence of communicating embedded systems/IoTs in our daily lives have brought a myriad of benefits, from adding conveniences and entertainment, to improving the safety of our commutes and health care. However, the flaws and vulnerabilities in these devices expose their users to risks of property damage, monetary losses, and personal injury. For example, consumer vehicles, both connected and conventional, have succumbed to a variety of design flaws resulting in injuries and death. At the same time, as vehicles are increasingly connected (and in the near future, autonomous), researchers have demonstrated possible hacks on their sensors or internal control systems, including direct injection of messages on the CAN bus.Ensuring the safety of users or bystanders involves considering multiple factors. Conventional safety suggests that a system should not contain software and hardware flaws which can prevent it from correct function. `Safety of the Intended Function' involves avoiding the situations which the system or its components cannot handle, such as adverse extreme environmental conditions. Timing can be critical for certain real-time systems, as the system will need to respond to certain events, such as obstacle avoidance, within a set period to avoid dangerous situations. Finally, the safety of a system depends on its security. An attacker who can send custom commands or modify the software of the system may change its behavior and send it into various unsafe situations. Various safety and security countermeasures for embedded systems, especially connected vehicles, have been proposed. To place these countermeasures correctly requires methods of analyzing and verifying that the system meets all safety, security, and performance requirements, preferably at the early design phases to minimize costly re-work after production. This thesis discusses the safety and security considerations for embedded systems, in the context of Institut Vedecom's autonomous vehicle. Among the proposed approaches to ensure safety and security in embedded systems, Model-Driven Engineering is one such approach that covers the full design process, from elicitation of requirements, design of hardware and software, simulation/formal verification, and final code generation. This thesis proposes a modeling-based methodology for safe and secure design, based on the SysML-Sec Methodology, which involve new modeling and verification methods. Security modeling is generally performed in the last phases of design. However, security impacts the early architecture/mapping and HW/SW partitioning decisions should be made based on the ability of the architecture to satisfy security requirements. This thesis proposes how to model the security mechanisms and the impact of an attacker as relevant to the HW/SW Partitioning phase. As security protocols negatively impact performance, it becomes important to measure both the usage of hardware components and response times of the system. Overcharged components can result in unpredictable performance and undesired delays. This thesis also discusses latency measurements of safety-critical events, focusing on one critical to autonomous vehicles: braking as after obstacle detection. Together, these additions support the safe and secure design of embedded systems.
... Ronkainen et al. framed the development of embedded systems as 'hardware-related' software development [13]. Greene reported a positive experience of applying Agile approaches in firmware development in Intel [14]. Gustavsson reported a positive experience in first time adopting Agile approaches in hardware development in Erisson [15]. ...
[Context]Advancement in technologies, popularity of small-batch manufacturing and the recent trend of investing in hardware startups are among the factors leading to the rise of hardware startups nowadays. It is essential for hardware startups to be not only agile to develop their business but also efficient to develop the right products. [Objective] We investigate how hardware startups achieve agility when developing their products in early stages. [Methods] A qualitative research is conducted with data from 20 hardware startups. [Result] Preliminary results show that agile development is known to hardware entrepreneurs, however it is adopted limitedly. We also found tactics in four domains (1) strategy, (2) personnel, (3) artifact and (4) resource that enable hardware startups agile in their early stage business and product development. [Conclusions] Agile methodologies should be adopted with the consideration of specific features of hardware development, such as up-front design and vendor dependencies.
... Ronkainen et al. framed the development of embedded systems as 'hardware-related' software development [13]. Greene reported a positive experience of applying Agile approaches in firmware development in Intel [14]. Gustavsson reported a positive experience in first time adopting Agile approaches in hardware development in Erisson [15]. ...
Context]Advancement in technologies, popularity of small-batch manufacturing and the recent trend of investing in hardware startups are among the factors leading to the rise of hardware startups nowadays. It is essential for hardware startups to be not only agile to develop their business but also efficient to develop the right products. [Objective] We investigate how hardware startups achieve agility when developing their products in early stages. [Methods] A qualitative research is conducted with data from 20 hardware startups. [Result] Preliminary results show that agile development is known to hardware entrepreneurs, however it is adopted limitedly. We also found tactics in four domains (1) strategy, (2) personnel, (3) artifact and (4) resource that enable hardware startups agile in their early stage business and product development. [Conclusions] Agile methodologies should be adopted with the consideration of specific features of hardware development, such as up-front design and vendor dependencies.
... In many of these cases tailoring [22][23][24] or adaptation [25,26] of agile methods was seen essential, and some decided to utilize only some specific agile practices [27,28]. Also it was noted that agile methods should not be followed dogmatically [29,30] or at least the practices should be carefully selected [31] or the methods should be concentrated on the embedded domain-specific requirements [21,32]. ...
We study in this work piloting agile practices in embedded space system development projects. The case involves three companies acting as last or next to last subcontractors in a space project. Initial interviews and a subsequent survey revealed challenges that embedded space system development poses to the agile software development. These include high specialization and emphasis on individual performance, formal customer interface requiring extensive documentation, and the management of several simultaneous projects. Iterative way of working is characteristic to agile systems development, but novel to the examined project teams. We observed that it enhanced team collaboration through planning and reviewing the work together and in transferring emphasis from the individuals to the team. Resource allocation between projects was taken properly into account when planning the iteration, or when cancelling an iteration for the project. Furthermore, the customer interface was tackled better by utilizing backlogs. According to the end survey and interviews, the main benefits of the agile practices were better communication and knowledge sharing inside the team, enhanced teamwork, and setting the pace for the sometimes slowly proceeding embedded space system development. Also documentation, while it barely changed, was seen more adequate in two of the cases. Overall, the teams felt that they were given a better possibility to affect their ways of working. The case study results show that agile practices can be applied to embedded space system development with notable benefits.
... These two examples defy Boehm's [8] claim that Agile Methodologies might not be suitable for life-critical embedded systems. Greene [9] uses a combination of XP and Scrum practices in the development of firmware for the Intel Itanium processor. Karlesky et al. [10] developed and applied the Model-Conductor-Hardware design pattern in testing embedded software drawing from the Model-View-Presenter and Model-View-Controller design patterns. ...
The traditional software development model commonly named “waterfall” is unable
to cope with the increasing functionality and complexity of modern embedded systems.
In addition, it is unable to support the ability for businesses to quickly respond
to new market opportunities due to changing requirements. As a response, the software
development community developed the Agile Methodologies (e.g., extreme
Programming, Scrum) which were also adopted by the Embedded System community.
However, failures and bad experiences in applying Agile Methodologies to the
development of embedded systems have not been reported in the literature. Therefore,
this paper contributes a detailed account of our first-time experiences adopting
an agile approach in the prototype development of a wireless environment data acquisition
system in an academic environment. We successfully applied a subset of the
extreme Programming (XP) methodology to our software development using the
Python programming language, an experience that demonstrated its benefits in
shaping the design of the software and also increasing productivity. We used an incremental
development approach for the hardware components and adopted a “cumulative
testing” approach. For the overall development process management, however,
we concluded that the Promise/Commitment-Based Project Management (PBPM/CBPM)
was better suited. We discovered that software and hardware components
of embedded systems are best developed in parallel or near-parallel. We
learned that software components that pass automated tests may not survive in the
tests against the hardware. Throughout this rapid prototyping effort, factors like
team size and our availability as graduate students were major obstacles to fully apply
the XP methodology.
... This study adds to the previous study confirming the usage of agile methods in embedded systems (Salo and Abrahamsson, 2008). Greene (2004) described experience of applying agile methods for the development of firmware of Intel® Itaniam® processer family and his findings stated agile methods usage favourable for firmware development. The results are confirmed by another study (Punkka, 2005) in which suitability of agile methods was reviewed for firmware development. ...
This paper presents the introduction of agile methods to the study of industrial electronics education as performed at a public sector university in Pakistan. The application of agile methods i.e. scrum to the projects of industrial electronics course; industrial automation and process control proved to be an innovative and favourable alternative to the previously used traditional phase driven approaches. The emphasis of agile methods on iterative development, team collaboration, and quick feedback are the reasons which triggered the ease and favourability. The quick feedback and incremental development helped the students to improve and revisit their shortcomings and deliver within time. The cross functional teams enabled the students to deal with process management throughout the product development. The findings of the study state that the flexible yet time critical agile methods pledge benefits in meeting ever changing and evolving industry requirements.
... As a part of the plan to adopt agile method, the pilot project is essential to evaluate how "S" environment will be able to move from the previous heavy-weight method to a new light method. Many organizations went through the same experience of running a pilot project especially those companies that have large projects such as Amazon, Yahoo, Microsoft and Intel [14], [15], [16], [17], [18]. After investing the needed time and resources they have reached to a successful adoption of Agile. ...
In the recent few years more and more software development organizations are striving to adopt agile software development methods and techniques. Successful agile adoption leads to producing higher quality software, enhance developers moraland at a lower cost than the traditional water wall model approach. However, Agile adoption always comes with special challenges and accordingly, fundamental organizational changes are necessary for successful outcome. The main contribution of this paper is that we present a case study for agile adoption case in a government entity in the U.A.E and we compare and analyze the outcomesobtained with other published case studies in this domain.
... As per it's manifesto, it can be apply to any team endeavor. It also commonly advocate a barely sufficient process [2], which suits well with hardware engineers [3]. ...
Agile method promotes an iterative process short iterative cycles, actively involve users and developers to establish, prioritize, and verify requirements and rely on a team's tacit knowledge as opposed to documentation. In this pape methodologies and improve its different parameters so that software development industries can adopt it more easily. It describes the improvement of overall understanding of the constituent parts of agile systems development methodologies and some improvement of different parameters. In our proposed method we design a Tool of adoption matrix which will help software development industries for adoption decision solution of the Improved Agile Methodology. We have described the assessment will be used to assess the existing agile system and the improved agile system. The result from this tool will help software industries to apply the improved agile methodologies.
... PP has also been studied in the context of training and mentoring, but not always with a positive effect. For example, in the context of developing firmware for processors, Greene (2004) found that the training effect of PP was not as high as expected, which may be due to the very specialized and complex domain knowledge needed in that context. On the other hand, Williams et al. (2004) investigated PP for mentoring and hence focused on pair constellations with different levels of expertise. ...
Whilst knowledge transfer is one of the most widely-claimed benefits of pair programming, little is known about how knowledge transfer is achieved in this setting. This is particularly pertinent for novice−expert constellations, but knowledge transfer takes place to some degree in all constellations. We ask “what does it take to be a good “expert” and how can a “novice” best learn from a more experienced developer?”. An in-depth investigation of video and audio excerpts of professional pair programming sessions using Interaction Analysis reveals: six teaching strategies, ranging from “giving direct instructions” to “subtle hints”; and challenges and benefits for both partners. These strategies are instantiations of some but not all teaching methods promoted in cognitive apprenticeship; novice articulation, reflection and exploration are not seen in the data. The context of pair programming influences the strategies, challenges and benefits, in particular the roles of driver and navigator and agile prioritisation which considers business value rather than educational progression. Utilising these strategies more widely and recognizing the challenges and benefits for both partners will help developers to maximise the benefits from pairing sessions.
... In literature many organizations went through the same experience of running a pilot project especially those companies that have large projects in comparison with S such as Yahoo! [10], [11], Amazon [12], Microsoft [13] and Intel [14]. After investing the needed time and resources they have reached to a successful adoption of agile. ...
Agile software development methods and techniques have gained attention in the recent few years. The main motive behind adopting agile software development approach is to improve end-product quality, enhance developer's moral and achieve stakeholder satisfaction. However, Agile adoption always comes with special challenges and thus fundamental organizational changes are necessary for successful outcomes. In this paper we present an in-depth case study for adopting agile methods to a government entity in the United Arab Emirates (U.A.E). The government entity software development teams have used the traditional waterfall approach for many years and decided to move to agile software development approach. This study highlights the challenges faced during the adoption of the Scrum method. Without proper preparation, the challenges will be significant enough to put the agile adoption on hold and make the software development teams go back to the traditional waterfall method.
... Few intrepid practitioners have braved this new domain deep in the " plumbing " layer of small embedded systems [3] [5] [6]. ...
Despite the existence of 75 “different” xUNIT frameworks, their domain of application differs only in the programming language, compiler or operating system supported.
If one is working in the embedded world, unit testing is still needed, but now our “testing requirements” differ significantly
from the testing framework needed for the desktop world. Embedded systems often have significant non-functional requirements,
which demand validation at the unit level. In addition, they interact intimately with hardware resources and often have only
very limited input/output capabilities – imagine a xUNIT framework where printing to the screen is a technical challenge!
... Over the last 20 years, software's impact on embedded system functionality, as well as on the innovation and differentiation potential of new products, has grown rapidly. The consequence of this is an enormous increase in software complexity, shorter innovation cycle times, and an ever-growing demand for extra functional requirements at affordable costs [7]. Moreover, these embedded systems' complexity is increasing, and the amount and variety of software in these products are growing. ...
While software process improvement methods appear to be well suited for embedded systems development, their use has not become an organized practice. In the same way as that of software development, the embedded systems development could be failing due a bad management in the development process. In this paper we introduce the SPIES methodology that integrates the CMMI-DEV v1.2 Level 2 process areas to specify a process for developing embedded systems. This methodology incorporates principles to support the lack of management and improve the process specification. To illustrate this methodology, we design an experimental system to manage a traffic light system.
Embedded systems design increasingly uses Commercial-Of-The-Shelf (COTS) components in order to reduce cost and time-to-market. Nevertheless, integrating COTS in the design alters the development process. In fact, COTS, designed for a general use, do not guarantee specification compliance especially for real-time embedded systems. We propose a development methodology based on the combination of Iterative and Incremental development (IID), Component Based Design (CBD), Test Driven Development (TDD) and Agile Principles to cope with COTS-Based Embedded systems constraints. The proposed methodology is followed to design an embedded platform that is intended to support a Global Positioning System (GPS)-based navigation system for a micro-fixed-wing Unmanned Aerial Vehicle (UAV).KeywordsEmbedded systemsCOTSDesign methodologyUAV
Hardware startups are increasingly popular due to recent advancements in hardware technologies. Nowadays, hardware product development involves the process innovation not only at the hardware level but also at software components. The scarcity of knowledge on hardware startup product development motivates the authors to carry out an empirical investigation on five hardware startup companies. They found some common good practices among hardware startups (i.e., process definition, evolutionary development process, and document management). They reveal several factors that are different from software startups, such as low priority of product quality, product pipeline, and unrecognized product platform. They proposed an integrative process model of hardware product development that shows the connections between human factors in the startups, their speed-prioritized development processes, and the consequence of hindered productivity in the later phases. The model has some implications for hardware startup founders to plan for the trade-off between team, speed, quality, and later productivity.
This book discusses important topics for engineering and managing software startups, such as how technical and business aspects are related, which complications may arise and how they can be dealt with. It also addresses the use of scientific, engineering, and managerial approaches to successfully develop software products in startup companies.
The book covers a wide range of software startup phenomena, and includes the knowledge, skills, and capabilities required for startup product development; team capacity and team roles; technical debt; minimal viable products; startup metrics; common pitfalls and patterns observed; as well as lessons learned from startups in Finland, Norway, Brazil, Russia and USA. All results are based on empirical findings, and the claims are backed by evidence and concrete observations, measurements and experiments from qualitative and quantitative research, as is common in empirical software engineering.
The book helps entrepreneurs and practitioners to become aware of various phenomena, challenges, and practices that occur in real-world startups, and provides insights based on sound research methodologies presented in a simple and easy-to-read manner. It also allows students in business and engineering programs to learn about the important engineering concepts and technical building blocks of a software startup. It is also suitable for researchers at different levels in areas such as software and systems engineering, or information systems who are studying advanced topics related to software business.
The great advantages of open source code-based projects like the case of open source firmware (OSF) are flexibility and freedom of customization. However, the difficulty inherent to their development process, which can be seen as a software composition issue, is the lack of structured approach and a teachable methodology for efficiently tackling such project. In this paper, we propose a 5-step pedagogical OSF’s customization approach, coupled with an agile development process to guide the learner and ease his comprehension. We experience this approach to prototype WiAFirm, an OpenWRT-based firmware for operating IEEE 802.11x enabled WAP. Two groups of 04 students each were involved. After 2 months of experimentation, the group that applied the approach was able to integrate into the core OpenWRT a custom WifiDog captive portal feature as a built-in package; while the other group had barely understood the goal of customizing an OSF.
Safety critical embedded software is a software that needs to provide correct functionality to avoid loss of human life. Embedded software controls much of the functionalities in Medical, Automotive, Aerospace and Cyber-Physical-Systems. The development of embedded software is different from ordinary software development as such development needs to be coordinated with the hardware development. Additionally, regulation processes and audits are also in place before placing the products to market. The objectives of this study are to understand the challenges of embedded safety critical software development, to investigate agile practices which have been in use in the domain, the factors affecting agile implementation in embedded safety critical software development. We have performed a systematic review to achieve these objectives. Our review has identified challenges related to hardware development, team-based communication and regulation process. This paper outlines the result of the systematic review.
Features
Covers main areas of Human-Computer Interaction and Human Factors in cybersecurity
Includes information for IT specialist who often desire (or IT specialists then desire) more knowledge about the human side of cybersecurity
Provides a reference for other disciplines such as psychology, behavioral science, software engineering, and security management offers a source of information for cybersecurity practitioners in government agencies and private enterprises
Includes the review of laws and regulation in the new areas such as Internet of Things
Summary
Cybersecurity, or information technology security, focuses on protecting computers and data from criminal behavior. The understanding of human performance, capability, and behavior is one of the main areas that experts in cyber security focus on, both from a human computer interaction point of view, and human factors. This handbook is a unique source of information from the human factors perspective that covers all topics related to the discipline. It includes new areas such as smart networking and devices and will be a source of information for IT specialists, as well as other disciplines such as psychology, behavioral science, software engineering, and security management.
Unbelievable, we have reached the seventh edition of the XP2k+n conference! We started at the outset of the new millennium, and we are still proving that agile pr- esses were neither a millennium bug nor a YAF (yet another fad). In its first editions, this conference was a get-together of a few pioneers who - bated about how to make agile processes and methods accepted by the mainstream researchers and practitioners in software engineering. Now agile approach to software development has been fully accepted by the software engineering community and this event has become the major forum for understanding better the implications of agility in software development and proposing extensions to the mainstream approaches. These two aspects were fully reflected in this year’s conference. They were - flected in the keynote speeches, which covered the background work done starting as early as the early eighties by Barry Boehm, definition of the field by Kent Beck, a successful industrial application in a success story by Sean Hanly, the perspective and the future of agile methods in large corporations by Jack Järkvik, and even some - sightful views from a philosopher, Pekka Himanen.
Scrum, a form of agile project management methodology, comes with many benefits derived from the iterative form of software development. Various organisations within South Africa have implemented Scrum within their development teams and are fast receiving positive benefits from it. While Scrum, in many aspects of the methodology, is highly effective and successful within different organisations, there are always going to be pitfalls and negative attributes associated with the adoption and use of a new methodology. The purpose of this research is to determine the factors leading to interruptions in the middle of a sprint while using Scrum. Case studies were conducted which included 3 companies in Johannesburg and Cape Town that have implemented Scrum. In particular, data was collected through the following methods: 12 face-to-face, one-on-one interviews with participating Scrum team members; and 1 group discussion with 8 participating Scrum team members. After analysis, five theoretical statements were formulated pertaining to: poorly understood and defined objectives from clients, management's lack of understanding of Scrum processes, high workload, ad-hoc requests mid-sprint, and low interdepartmental communication. Results from this study reveal the need to conduct possible future research on: ways to prevent these forms of sprint interruption from having negative effects on the Scrum team and the project; and the effect that these interruptions have on the relevant stakeholders involved. The results of the study thus provide managers with the opportunity to take a deeper look into the sources of their Scrum problems and provide them with an understanding as to how they may prevent these interruptions from causing long term, negative effects on the project and the team.
This paper addresses Scrum and how to fit it to Faisalabad electric supply company (FESCO) computer center, Faisalsabad. FESCO computer centre develops in-house projects. The purpose of the study is to propose improvements in the software development process in FESCO computer center, by finding an appropriate method. To find appropriate method, a case study was performed on two projects Project-MI and project-MII. Project-MI was based on method MI (Scrum and XPM) and project-MII was based on method MII (lwei-Scrum). Issues during project-MI were identified and the influence was then tested in project-MII using Lwei-Scrum (lightweight Scrum with two developers) as development method. Lwei-Scrum was defined to fit the organization needs. To assess whether the objective of achieving higher productivity and quality (customer satisfaction) is met with implementation of MII it was compared to a waterfall project carried out at FESCO computer center in year 2008. Research results show significant increase in productivity and quality with the implementation of MII. Further results indicate, of two methods MI and MII, MII is better and among other things thought lwei-Scrum gave developers a better focus and structure for their work.
When individual teams in mechatronic organizations attempt to adopt agile software practices, these practices tend to only affect modules or sub-systems. The short iterations on team level do not lead to short lead-times in launching new or updated products since the overall R&D approach on an organization level is still governed by an overall stage gate or single cycle V-model.
This paper identifies challenges for future research on how to combine the predictability and planning desired of mechanical manufacturing with the dynamic capabilities of modern agile software development. Scaling agile in this context requires an expansion in two dimensions: First, scaling the number of involved teams. Second, traversing necessary systems engineering activities in each sprint due to the co-dependency of software and hardware development.
Platform-based development is one of the most successful paradigms in software engineering. In embedded systems, the reuse of software on several processor families is often abandoned due to the multitude of compilers, processor architectures and instruction sets. In practice, we experienced that a lack of hardware abstraction leads to non-reusable test cases. We will demonstrate a re-engineering process that follows test-driven development practices which fits perfectly for migration activities. Moreover, we will introduce a process that provides trust for the test cases on a new hardware.
With software defects reducing profits in many fields, it is worthwhile to consider moving key defect reducing strategies from one development area into another. However, inadequate tool support has compromised attempts to transfer Agile methodology’s successes from “business systems” to embedded system development. We outline the advantages of adding an Agile test support (ATS) co-processor to provide low overhead hardware-assisted test insertion capabilities into testing frameworks for test-first (Agile) and test-last hardware-software design philosophies. We propose the development of an ATS FPGA co-processor using an extension to the eXtreme Programming Inspired (XPI) embedded lifecycle. The performance of a prototype ATS co-processor is compared to the existing instruction watch (low overhead) and data watch (high overhead) debug hardware present on Analog Devices ADSP-BF5XX Blackfin processors.
Previous systematic literature reviews on pair programming (PP) lack in their coverage of industrial PP data as well as certain factors of PP such as infrastructure. Therefore, we conducted a systematic mapping study on empirical, industrial PP research. Based on 154 research papers, we built a new PP framework containing 18 factors. We analyzed the previous research on each factor through several research properties. The most thoroughly studied factors in industry are communication, knowledge of work, productivity and quality. Many other factors largely lack comparative data, let alone data from reliable data collection methods such as measurement. Based on these gaps in research further studies would be most valuable for development process, targets of PP, developers’ characteristics, and feelings of work. We propose how they could be studied better. If the gaps had been commonly known, they could have been covered rather easily in the previous empirical studies. Our results help to focus further studies on the most relevant gaps in research and design them based on the previous studies. The results also help to identify the factors for which systematic reviews that synthesize the findings of the primary studies would already be feasible.
Pair Programming (PP) is a software development practice where two programmers share a mouse and keyboard while working together on one computer. A concern among some practitioners is that PP might be a waste of resources if developers have a very low equity of participation, for example, when one developer is doing all the work and the other is not contributing at all. This paper investigates this concern by analysing the equity of participation in industrial pair programming sessions. It quantifies two different types of contributions: verbal contributions and driving contributions. As a result, we found that two thirds of the PP sessions are not equitable. Based on interviews with the developers, we analyse which factors influence the equity of participation. We found that the choice of the workstation, personal preferences, PP experience, work style and skill differences influence who is driving. Additionally, we discuss the implications of sessions that are not equitable and whether the concept of equity of participation could be used as metric to evaluate PP.
There is a wide area of applications that use embedded systems, and the number of such systems keeps growing. The required functionality and complexity of embedded systems are also constantly increasing, and development of such products is becoming increasingly harder. This requires new thinking on the product development processes, and one such emerging philosophy is the agile methods. These methods were created by the software engineering community where they are commonly used. Since then, they have been adopted in embedded systems development; however, whether they can improve the embedded systems product development processes remains an open question. This study aims to bring forth what is known about agile methods in embedded systems development and to find out if agile practices are suitable in this domain and what evidence is there to support the findings. We conducted a literature review and a mapping study to answer these questions. The scope of this study is not only limited to embedded software development, but also to embedded hardware and integrated circuits. We have found that agile methods can be used in the embedded domain, but the methods and practices need to be adapted to suit the more constrained field of embedded product development. Furthermore, the field of embedded product development has wide diversity of products with different needs and domain-specific problems so that no single method is applicable, but rather many methods and practices are needed for different situations.
Applying pair programming in industrial settings can be challenging. This study extends the existing knowledge on applying pair programming in industrial settings by interviewing 31 developers from 4 different companies. We investigate how often developers practice pair programming as opposed to working by themselves, whether developers would prefer to use PP more often or less often, and which aspects hinder the use of pairing. We found that the majority of developers use PP only for 10% of their development time but would like to use it more often. Moreover, our results indicate that organisational issues can hinder the use of PP.
In the business world, the use of Agile methodologies has been demonstrated as providing a pro-active, rather than reactive,
path for the developer to create defect-free products. Although similarities exist with business desktop and line-of-business
systems, the closer connection of signal processing systems to the hardware side of a product, and associated physical constraints,
makes the adaption of desktop Agile methodologies for the embedded world difficult; and the adoption of these methodologies
by developers problematic. We focus on our experiences in developing test frameworks to support transforming a subset of extreme
programming from the world of desktop applications into a suitable embedded domain production methodology. Details are provided
of the issues surrounding an Embedded xUnit testing framework that will permit development of digital signal processing applications on a wide range of standalone and
multi-processor systems in research, teaching and commercial development environments.
Given the plethora of advantages attributed to agile methodologies, why are there only infrequent reports of their application in the embedded systems world? We believe this has two principal causes. First, embedded applications go through a life cycle that differs from desktop life cycles, so that desktop application production processes must be significantly altered to meet the demands of this new domain. Second, without providing for full life-cycle tool support, no change to embedded production processes will ever succeed, and again desktop tools must be adapted to meet the new environment's constraints. Here, the authors discuss their thoughts on an XP-inspired embedded life cycle and their successes in developing, extending, and using embedded test-driven development frameworks for customers (Matlab-Fit and Embedded-FitNesse) and developers (MUnit and Embedded-Unit).
Software development paradigms are shifting. The development group's "team" ability, and the effects of the individual developer, become more important as organizations recognize that the traditional approach of increasing process pressure and overworking team members is not getting the job done. The pioneers of Agile methodologies question the preconceived processes within which development teams work. Rather than adding to the burden of the individual developer, Agile asks "how can we change the process so that the team is more productive, while also improving quality?" The answer is in learning to play the "game." Written for developers and project managers, Agile Software Development compares software development to a game. Team members play the game knowing that the ultimate goal is to win---always remembering what they have learned along the way, and always keeping in mind that they will never play the same way twice. Players must keep an open mind to different methodologies, and focus on the goal of developing quality software in a short cycle time.
Agile Software Development Methods: When and Why Do They Work? Full Text at Springer, may require registration or fee
In the past few years there’s been a rapidly growing interest in “lightweight” methodologies. Alternatively characterized
as an antidote to bureaucracy or a license to hack they’ve stirred up interest all over the software landscape. In this essay
I explore the reasons for lightweight methods, focusing not so much on their weight but on their adaptive nature and their
people-first orientation. I also give a summary and references to the processes in this school and consider the factors that
should influence your choice of whether to go down this newly trodden path.