Software processes are software too
ICSE '87 Proceedings of the 9th international conference on Software Engineering
A hierarchical and functional software process description and its enaction
ICSE '89 Proceedings of the 11th international conference on Software engineering
ICSE '97 Proceedings of the 19th international conference on Software engineering
The unified software development process
The unified software development process
Agile Software Development with Scrum
Agile Software Development with Scrum
Apel: A Graphical Yet Executable Formalism forProcess Modeling
Automated Software Engineering
Agile Project Management With Scrum
Agile Project Management With Scrum
Flow analysis for verifying properties of concurrent software systems
ACM Transactions on Software Engineering and Methodology (TOSEM)
User guidance for creating precise and accessible property specifications
Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering
Proceedings of the 30th international conference on Software engineering
Succeeding with Agile: Software Development Using Scrum
Succeeding with Agile: Software Development Using Scrum
A benchmark for evaluating software engineering techniques for improving medical processes
Proceedings of the 2010 ICSE Workshop on Software Engineering in Health Care
Automatic fault tree derivation from Little-JIL process definitions
SPW/ProSim'06 Proceedings of the 2006 international conference on Software Process Simulation and Modeling
Analyzing software process models with AVISPA
Proceedings of the 2011 International Conference on Software and Systems Process
Hi-index | 0.00 |
This paper demonstrates how a precise definition of a software development process can be used to determine whether the process definition satisfies certain of its requirements. The paper presents a definition of a Scrum process written in the Little-JIL process definition language. The definition's details facilitate understanding of this specific Scrum process (while also suggesting the possibility of many variants of the process). The paper also shows how these process details can support the use of analyzers to draw inferences that can then be compared to requirements specifications. Specifically the paper shows how finite state verification can be used to demonstrate that the process protects the team from requirements changes during a sprint, and how analysis of a fault tree derived from the Little-JIL Scrum definition can demonstrate the presence of a single point of failure in the process, suggesting that this particular Scrum process may fail to meet certain process robustness requirements. A new Scrum process variant is then presented and shown to be more robust in that it lacks the single of point failure.