An Insight into the Difficulties of Software Development Projects in the Pharmaceutical Industry

Hajou, A.; Batenburg, Ronald; Jansen, Slinger

doi:10.7763/lnse.2015.v3.202

Cited by 6 publications

(12 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Though the documentative culture caused by the need for compliancy to regulations and the fear for regulatory inspections [37] may prevent agile working, developing teams may still employ these methods to ensure the quality of the product. The idea is to create a process based on empirical logic that in the end fits into the defined logic of the company standards.…”

Section: Agilementioning

confidence: 99%

Quality Assurance When Developing Software with a Medical Purpose

Coffa,

van den Berg

2024

Quality Control and Quality Assurance - Techniques and Applications

View full text Add to dashboard Cite

In the field of development of scientific or medical software, questions may arise, such as how we define if software has a “medical purpose,” what regulations may apply and how they influence the (projected) pathway. We may find ourselves embroiled with the new “In Vitro Diagnostics Regulation” (IVDR) and its implementation in organizations. In this chapter we will attempt to summarize and order key bits of information, as found in these standards and related publications, that seemed relevant along the way in our software development processes. After this we will try to expose possible pitfalls that could be encountered. We also reach out to (existing) methodologies that may aid in the endeavor to the realization of software. Top-down risk approaches consider hierarchical ordering of priorities based on process levels where context and meaning play a more significant role over content and documentation. To honor the different sources, we will seek to outline how this led to a form of understanding that allowed the development of software. Maintaining a high standard of risk control while keeping focus on product realization. Hopefully these outlines and referred source materials may bring slight relief to others on a similar quest.

show abstract

Section: Agilementioning

confidence: 99%

Quality Assurance When Developing Software with a Medical Purpose

Coffa,

van den Berg

2024

Quality Control and Quality Assurance - Techniques and Applications

View full text Add to dashboard Cite

show abstract

“…Documentation is a cornerstone of the regulatory process norms and criteria. Regulations and the prospect of regulatory inspections encourage substantial record keeping [40]. Agility's low or nonexistent attention on documentation is inadequate to identify the quality of safety-critical systems, hence regulatory authorities will not consent to less documentation.…”

Section: Light Documentationmentioning

confidence: 99%

Applying Scrum Development on Safety Critical Systems

Rahman¹,

Islam²,

Fardous³

et al. 2022

IJITCS

View full text Add to dashboard Cite

Scaled agile approaches are increasingly being used by automotive businesses to cope with the complexity of their organizations and products. The development of automotive systems necessitates the use of safe procedures. SafeScrum® is a real example of how agile approaches may be used in the creation of high-reliability systems on a small scale. A framework like SAFe or LeSS does not facilitate the creation of safety-critical systems in large-scale contexts from the start. User stories are a wonderful approach to convey flexible demands, the lifecycle is iterative, and testing is the initial stage in the development process. Scrum plus extra XP approaches may be used to build high-reliability software and certification by the IEC 61508 standard is required for the software. This adds a slew of new needs to the workflow. Scrum's quality assurance measures proved to be inadequate in a recent industry situation. Our study's overarching goal is to provide light on the Scrum development process so that it may be improved for use with life-or-death systems. Our study of the business world was a mixed-methods affair. The findings demonstrated that although Scrum is helpful in ensuring the security of each release, it is less nimble in other respects. The difficulties of prioritization, communication, time constraints, and preparing for and accepting new safety standards were all discussed. In addition, we have had some helpful feedback from the business world, but the generality issue arising from this particular setting has yet to be addressed.

show abstract

“…Challenges Meshing approach The use of documentation 1. Providing the appropriate amount and the right kind of documentation for proving the safety of the software (Gary et al 2011;Hajou et al 2015a;Sidky and Arthur 2007;Wäyrynen et al 2004) 2. Handling change management and maintaining traceability (Drobka et al 2004;Kasauli et al 2018;McHugh et al 2014a;McHugh et al 2014b;Notander et al 2013a;Rottier and Rodrigues 2008;Sidky and Arthur 2007) • Treat documentation as part of the product requested by the customer (McHugh et al 2012) • Consider the purpose of the documentation and only provide what is required (Grenning 2001;Misra et al 2010) • Produce the documentation before development, but cumulatively (Van Schooenderwoert and Shoemaker 2018) • Treat the documentation as a separate activity during each iteration (Stålhane et al 2012) • Use sub-teams in charge of documentation (Paige et al 2008) Engineering requirements…”

Section: Area Of Concernmentioning

confidence: 99%

“…The use of documentation of safety-critical software gets much attention in the research literature as it is considered a primary challenge for applying agile development (Heeager and Nielsen, 2018). Documentation is essential for providing what is called the safety argument in the development of safety-critical software, and agile processes do not provide enough documentation or provide the wrong kind of documentation for this purpose (Hajou et al 2015a;Sidky and Arthur 2007;Wäyrynen et al 2004). Because of the flexible nature of agile processes, it has been concluded however that the amount of documentation in safety-critical projects is not in itself an issue (e.g.…”

Section: The Use Of Documentationmentioning

confidence: 99%

“…The focus on documentation can however harm the agility and flexibility of the development (Jonsson et al 2012), and the regulatory bodies are not likely to agree to less documentation on software requirements and design (Vogel 2006). While Hajou et al (2015a) stated that the lack of documentation can be harmful to the quality of the software, Shafiq and Minhas (2014), on the other hand, suggested that agile processes might even result in higher quality software than the plan-driven processes, despite the lower focus on documentation. However, it remains open-ended in the existing research literature as to how flexible processes and the rigor of documentation can be reconciled.…”

Section: The Use Of Documentationmentioning

confidence: 99%

See 1 more Smart Citation

Meshing agile and plan-driven development in safety-critical software: a case study

Heeager

Nielsen

2020

Empir Software Eng

View full text Add to dashboard Cite

Organizations developing safety-critical software are increasingly seeking to create better practices by meshing agile and plan-driven development processes. Significant differences between the agile and the plan-driven processes make meshing difficult, and very little empirical evidence on using agile processes for safety-critical software development exists. There are four areas of concern, in particular, for meshing the development of safetycritical software concerning: documentation, requirements, life cycle and testing. We report on a case study of a pharmaceutical organization in which a Scrum process was implemented to support agile software development in a plan-driven safety-critical project. The purpose was to answer the following research question: For safety-critical software, what can a software team do to mesh agile and plan-driven processes effectively? The main contribution of the paper is an elaborated understanding of meshing in the four areas of concern and how the conditions for safety-critical software influence them. We discuss how meshing within the four areas of concern is a contribution to existing research.

show abstract

An Insight into the Difficulties of Software Development Projects in the Pharmaceutical Industry

Cited by 6 publications

References 7 publications

Quality Assurance When Developing Software with a Medical Purpose

Quality Assurance When Developing Software with a Medical Purpose

Applying Scrum Development on Safety Critical Systems

Meshing agile and plan-driven development in safety-critical software: a case study

Contact Info

Product

Resources

About