A spiral model of software development and enhancement

Boehm, Barry

doi:10.1109/2.59

Cited by 2,937 publications

(710 citation statements)

References 12 publications

Supporting

Mentioning

612

Contrasting

Unclassified

Order By: Relevance

“…Even atmospheric scientists using the most advanced analysis and modeling technologies had never used a dynamically adaptive system, so they too had to imagine how they might use it. For these reasons, the team could just as well make an educated guess, develop prototypes, and then get feedback from potential users of the product (Boehm, 1988). Again, to do this, they needed software in hand.…”

Section: Research Versus Developmentmentioning

confidence: 99%

Walking the Tightrope: The Balancing Acts of a Large e-Research Project

Lawrence

2006

Comput Supported Coop Work

View full text Add to dashboard Cite

Abstract. Although e-Research has received much attention and acclaim in recent years, the realities of distributed collaboration still challenge even the most well-planned endeavors. This case study of an e-Research project examines the 'balancing actsÕ associated with multidisciplinary, geographically distributed, large-scale research and development work. After briefly describing the history and organizational design of this information technology and atmospheric science research project, I identify five paradoxical challenges that cannot be resolved: research versus development, harmony versus conflict, consensus versus top-down decision making, frequency and modes of communication, and fast versus slow pacing. Although collaboration and communication technologies supported the projectÕs management and organization, most of the complexities faced by the team were not technological in nature. From the five paradoxical challenges associated with the project, I distill three cross-cutting issues that could be relevant to other e-Research projects of this magnitude: satisfying the multiple needs of a multidisciplinary project, managing information, and engaging all participants. I identify the practical implications of these challenges and issues, specifically that organizational and low-tech solutions -not the introduction of more sophisticated technology tools -are needed to solve these challenges and to better streamline coordination.

show abstract

Section: Research Versus Developmentmentioning

confidence: 99%

Walking the Tightrope: The Balancing Acts of a Large e-Research Project

Lawrence

2006

Comput Supported Coop Work

View full text Add to dashboard Cite

show abstract

“…This allowed to deliver prototypes of the system in time for elections and to setup experimentations during electoral turns. The advantage of the approach, very similar to the spiral development process [16], is that not only we could "observe" electronic elections from a privileged point of view, but also we could use the outputs of the experimentation to drive the development for the next cycle.…”

Section: A Methodology For the Experimentsmentioning

confidence: 99%

Experiments and data analysis of electronic voting system

Weldemariam

Villafiorita

Mattioli

2009

2009 Fourth International Conference on Risks and Security of Internet and Systems (CRiSIS 2009)

View full text Add to dashboard Cite

Abstract-Experimental data sets related to e-voting systems are very demanding in order to improve currently deployed e-voting machines. Unfortunately, the studies of such data about the machines' security, performance and their evolution with respect to the social and technical aspects are still unsatisfactory.During the last four years we have been involved in the development, experimentation, and evaluation of an e-voting system. The system tried out in several regular elections, and also used in two small elections with legal value. Each experiment provided various sociological (e.g. citizens' opinions on the system) and technical data that are related to system's performance and behavior.In this paper, we present various technical insights and the lessons learned during the e-voting experiment. The methodology for the various experiments we have carried-out and the data sets collection process are also discussed. This helps to confirm existing data on the subject (e.g., data related to security, procedures and logistics) and, in some cases, provide novel information or, at least, shed a new perspective on some security-critical factors concerning e-voting systems.

show abstract

“…Yet, if there were changes in the environment that the software was being developed in, or changes in requirements, such a fixed approach found difficulty adjusting to these changes, or being 'agile'. (Dybå & Dingsøyr, 2008) FIGURE 1 TRADITIONAL SOFTWARE DEVELOPMENT LIFECYCLE (SDLC) (BOEHM, 1988) …”

Section: Agile Software Developmentmentioning

confidence: 99%

Why do software developers practice test-driven development?

Kayongo

Chigona

Mabhena

2016

2016 International Conference on Advances in Computing and Communication Engineering (ICACCE)

View full text Add to dashboard Cite

This dissertation describes research that has been undertaken to understand factors influencing software developers' intention to perform test driven development (TDD). Unit tests are a form of testing, where tests are written for small units of software being developed. TDD is a practice where these tests are written before the functionality is written, so as to guide the design of the code for the functionality, as well as to ensure test coverage for all functionality. There has been some research conducted to understand TDD by looking at its effects on both the outcomes and the practice of software development. It has been found to increase quality by decreasing defects, while also increasing the maintainability and the changeability of the code. On the other hand, some research has also found it to increase time spent on completing tasks. Despite this, to the best of the researcher's knowledge, there hasn't been research done to understand the behavioural components of TDD, and in particular, why developers choose to practice TDD.A conceptual model based on the Theory of Planned Behaviour (TPB) is described and used as a lens to understand intention. TPB proposes that intention to perform a behaviour (TDD in this case) is influenced by three factors: attitude towards the behaviour, subjective norm, and perceived behavioural control. This dissertation seeks to build onto this model for the purpose of understanding TDD, and proposes the following determinants of the influences of intention: attitude is influenced by attitude towards time taken, differences in quality, maintainability and developer efficiency; subjective norm is influenced by the perceived perception of the environment regarding changes in quality, time taken, and maintainability of the code. Lastly, perceived behavioural control is posited to be made up of perceived difficulty of TDD, and how much experience a developer has.This model is then tested based on data collected from an online survey distributed around the world. 779 responses were collected from developers in various countries around the world. The majority of the respondents to practice TDD, allowing us to gain greater insight into why those that practice TDD actually do so. Because the study is a psychographic study, perceptions were understood from the developers using an ordinal Likert scale. To analyse this data in order to prove the hypotheses, Chi--square tests with contingency tables, Kruskal--Wallis tests and ordinal logistic regression were used as statistical methods. It is found the data collected does not conform to the model, and recommendations are made for a future study to form a more comprehensive model. III PLAGIARISM DECLARATION

show abstract

A spiral model of software development and enhancement

Cited by 2,937 publications

References 12 publications

Walking the Tightrope: The Balancing Acts of a Large e-Research Project

Walking the Tightrope: The Balancing Acts of a Large e-Research Project

Experiments and data analysis of electronic voting system

Why do software developers practice test-driven development?

Contact Info

Product

Resources

About