Figure 1 - uploaded by Martin Ward
Content may be subject to copyright.
Transformational programming method of algorithm derivation.
Source publication
Combining formal and agile techniques in software development has the
potential to minimize change-related problems.
Context in source publication
Context 1
... Figure 1 shows, the transfor- mational programming method of algorithm derivation 8 starts with a formal specification of the result to be achieved, together with some in- formal ideas as to which techniques will be used in the implementation. The formal specification is then transformed into an implementation by means of correctness-preserving refinement and transformation steps, guided by the informal ideas. ...
Similar publications
Formal methods and agile software development as part of the software engineering process have sometimes been seen as opposing techniques that are difficult to reconcile. However, in the opinion of the authors, these two approaches are orthogonal and complementary in nature, at least when used judiciously in a real‐world setting. Both methodologies...
Citations
... There are other complementary activities that were also identified as budget control and cost analysis, documentation and process for configuration management, monitoring, definition of processes for the acquisition and contracting of suppliers, definition and inclusion of new management roles, training, design and architectural projects, testing processes, integration and acceptance and change control. (Al-Aidaros & Omar, 2017;Farid et al., 2016;Wautelet & Kolp, 2012;Lee & Yong, 2010;Sundararajan et al., 2014;Surdu & Parsons, 2006;Nuottila et al., 2016;Bowen et al., 2014;Papatheocharous;Andreou, 2014;Kulkarni et al., 2017). ...
The aim of the paper is to analyze how agile management practices are being adopted by specialists from software development technology companies in Brazil, identifying actions that contribute to the success of software implementation, aiming to ensure the survival of organizations in the market. The study counted with a literature review to support the field research with software development specialists who use the agile methodology and work in Brazil in the states of Rio de Janeiro and São Paulo. The results were analyzed through a descriptive statistics and content analysis. The research identified that the companies that adopt agile software management methodology in Brazil prefer the Scrum method and the development teams may be geographically distributed. The main positive points identified when adopting agile methods were the process speed, team involvement, maximization of results, involvement with the client, and simplicity. Most experts identified problems in the implementation of the agile methodology and as points of attention: management of distributed teams, scope estimation and communication. It was possible to identify the existence of a positive financial result by adopting the agile method for software development projects, as well as actions that contribute to the success of these projects, such as controlling quality using different testing techniques, project management, time, stakeholders, scope, and have agile communication, with feedback and good leadership. On the other hand, it was observed in the statistics that, although efficient, this method is still not being widely used. This research can contribute to the managers of software development companies in the use of agile methods as well as improving management decision-making.
... There are several similarities between the students' views and general industry practices. Student developers' treatment of security as an implied requirement is in line with findings that security is often treated as a non-functional feature in agile methods [13,24], and that the requirement is not explicitly stated [12,15]. When asked to describe the features of the classroom discussion app, which had been intentionally chosen as an example of a task with implicit S&P requirements, many students did not consider S&P as an initial priority. ...
The security attitudes and approaches of software developers have a large impact on the software they produce, yet we know very little about how and when these views are constructed. This paper investigates the security and privacy (S&P) perceptions, experiences, and practices of current Computer Science students at the graduate and undergraduate level using semi-structured interviews. We find that the attitudes of students already match many of those that have been observed in professional level developers. Students have a range of hacker and attack mindsets, lack of experience with security APIs, a mixed view of who is in charge of S&P in the software life cycle, and a tendency to trust other peoples' code as a convenient approach to rapidly build software. We discuss the impact of our results on both curriculum development and support for professional developers.
... Bansal and Jolly [40] highlights the lack of security requirements integrated view in agile practices. Authors, such as [7] and [14] depict the importance of integrating security practices into SD process, but not just as an isolated action. From these perspectives, it is urgent to look for ways to integrate the agile development model and the security practices and policies. ...
... Security must be considered a critical non-functional requirement, which needs to be fully incorporated by the development methodologies [40]. Lack of security requirements [40], technical implementation failures, lack of security validation [19] and lack of experience and care with security [14], are a few aspects problems in a mindset that does not include security requirements. ...
... Define Security Requirements aims to identify security-related features, expressed explicitly, within a software project [5,17]. It is necessary to ensure that these requirements are not put aside, due to the focus on functional requirements, so that they are included in the effort necessary to develop the application [14], [18], [22], [35]. ...
In recent years there has been a significant shift from traditional development towards agile. Agile adoption has been reported to result in more efficient and productive projects. Information security is becoming an important entity for most organizations. Cyber security has been a major concern in the digital world. However, despite its importance, agile methodologies hardly address the security requirements. In result, many security problems have been exposed in recent years, often leading to financial and social losses. As software is one of the computational assets most exposed to security threats, it is imperative that its development process includes special attention to security requirements. In this scenario, the need arises to include safety practices in the daily life of agile teams. In this paper, we highlight a security policies that presents practices suitable for agile teams. In order to do that this study (a) synthesizes the extant literature in this domain; (b) prioritizes the agile security practices; (c) groups these practices in policies based on the results of a workshop in a cyber security company (d) evaluates the policies based on security and agile specialist assessment; and (e) considering the feedback, presents the final security policies for software development agile teams.
... This collaboration proved very productive from the start (Siewe, Cau & Zedan, 2003), so much so that Francois is now a Reader at DMU and is Head of the Software Technology Research Laboratory (STRL), which Hussein founded there. I continued to visit Hussein there as an external examiner, as a speaker, and also collaborating on publications (Bowen et al., 2014;2018). ...
It is a sad fact of aging that one’s colleagues start to pass away with the passing years. But for some, this is before their time and this “In Memoriam” article is a tribute to five such colleagues of mine who passed away during 2015 to 2020. It is both a brief record of their achievements, largely based on their Wikipedia pages, and a personal reminiscence recording some memories of and collaborations with each of them. I do not feel too bad about borrowing from the former, since I was the original creator for the Wikipedia articles for all five of them, my own small, more public, and long-lasting tribute to them.
... This collaboration proved very productive from the start (Siewe, Cau & Zedan, 2003), so much so that Francois is now a Reader at DMU and is Head of the Software Technology Research Laboratory (STRL), which Hussein founded there. I continued to visit Hussein there as an external examiner, as a speaker, and also collaborating on publications (Bowen et al., 2014;2018). ...
It is a sad fact of aging that one’s colleagues start to pass away with the passing years. But for some, this is before their time and this “In Memoriam” article is a tribute to five such colleagues of mine who passed away during 2015 to 2020. It is both a brief record of their achievements, largely based on their Wikipedia pages, and a personal reminiscence recording some memories of and collaborations with each of them. I do not feel too bad about borrowing from the former, since I was the original creator for the Wikipedia articles for all five of them, my own small, more public, and long-lasting tribute to them.
... I have expanded my interest in smart cities more generally as well [19]. My involvement in issues concerning the use of formal methods in software development continued with Mike Hinchey and others [248,249]. ...
A personal archive of material related to formal methods has
been deposited at Swansea University by the author in 2018. This
paper documents the contents of the archive and includes
associated publications. The archival material forms part of a larger History of Computing Collection founded by Prof. John Tucker at Swansea in 2007 and held at the University. It is hoped that this paper can aid future archivists with placing the material in context.
... There are several similarities between the students' views and general industry practices. Student developers' treatment of security as an implied requirement is in line with findings that security is often treated as a non-functional feature in agile methods [13,24], and that the requirement is not explicitly stated [12,15]. When asked to describe the features of the classroom discussion app, which had been intentionally chosen as an example of a task with implicit S&P requirements, many students did not consider S&P as an initial priority. ...
The security attitudes and approaches of software developers have a large impact on the software they produce, yet we know very little about how and when these views are constructed. This paper investigates the security and privacy (S&P) perceptions, experiences, and practices of current Computer Science students at the graduate and undergraduate level using semi-structured interviews. We find that the attitudes of students already match many of those that have been observed in professional level developers. Students have a range of hacker and attack mindsets, lack of experience with security APIs, a mixed view of who is in charge of S&P in the software life cycle, and a tendency to trust other peoples' code as a convenient approach to rapidly build software. We discuss the impact of our results on both curriculum development and support for professional developers.
... There are several similarities between the students' views and general industry practices. Student developers' treatment of security as an implied requirement is in line with findings that security is often treated as a non-functional feature in agile methods [13,24], and that the requirement is not explicitly stated [12,15]. When asked to describe the features of the classroom discussion app, which had been intentionally chosen as an example of a task with implicit S&P requirements, many students did not consider S&P as an initial priority. ...
Anyone can learn to code and build software these days. But the intricate and convoluted nature of computer security means that not anyone can write proper secure code. The goal of this research is to help average software developers build secure software with little understanding of security by investigating the security and privacy perceptions, experiences, and practices of current computer science students.
... Formal methods are useful for improving software engineering where high integrity is desirable or required [18,19,28]. Examples of real industrial use are available [3,25,2]. ...
The Z notation for the formal specification of computer-based systems has been in existence since the early 1980s. Since then, an international Z community has emerged, academic and industrial courses have been developed, an ISO standard has been adopted, and Z has been used on a number of significant software development projects, especially where safety and security have been important. This chapter traces the history of the Z notation and presents issues in teaching Z, with examples. A specific example of an industrial course is presented. Although subsequent notations have been developed, with better tool support, Z is still an excellent choice for general purpose specification and is especially useful in directing software testing to ensure good coverage.
The security attitudes and approaches of software developers have a large impact on the software they produce, yet we know very little about how and when these views are constructed. This paper investigates the security and privacy (S&P) perceptions, experiences, and practices of current Computer Science students at the graduate and undergraduate level using semi-structured interviews. We find that the attitudes of students already match many of those that have been observed in professional level developers. Students have a range of hacker and attack mindsets, lack of experience with security APIs, a mixed view of who is in charge of S&P in the software life cycle, and a tendency to trust other peoples’ code as a convenient approach to rapidly build software. We discuss the impact of our results on both curriculum development and support for professional developers.
