Unit 1

Learning Outcomes Achieved

1. Identify & manage security risks as part of a software development project
2. Critically analyse development problems and determine appropriate methodologies, tools and techniques to solve them
3. Systematically develop and implement the skills required to be effective member of a development team in a virtual professional environment, adopting real-life perspectives on team roles and organisation

Collaborative Discussion 1

A task given was to create a UML diagram which shows how a OWASP vulnerability could be created in an information system. I initially used an activity diagram to represent how an attacker could gain access to user accounts via the discussed vulnerability (an insecure password reset system), however, I wanted to find ways of improving its design. After some reflection and additional research, I realized that the behavior could be better represented as a sequence diagram. The reason for this is that a sequence diagram represents all objects that are interacted with to accomplish some task, and the messages that are passed between each of those objects. In the context of demonstrating a vulnerability, a sequence diagram models threats more effectively because message chains can be modeled as threat scenarios which map to specific objects (Mohanty et al., 2019), making it easier for developers to identify not just the origin of a vulnerability, but how an application’s messages could be exploited in the context of the entire system. An activity diagram is not able to capture this level of detail and therefore provides a less comprehensive view of vulnerabilities in a system.

I intend to make use of this learning in two ways. The first way will be by prioritizing the use of sequence diagrams in the design document due in Unit 6. Sequence diagrams have the advantage of succinctly representing security threats to the system as a whole, and can maintain clarity despite the large amount of detail contained within, which will help mitigate the challenges imposed by the assignment’s word limit. Secondly, in the workplace, when working on new projects with new architectures, I will look to use this diagram type to improve the overall planning and discussion phases of our development cycle. I typically use flowcharts or activity diagrams to clarify new products and features with my team, however, I’ve found that one challenge with this approach is that it makes it harder to reason about solution architectures at a higher level, which has the effect of making it harder to discuss ambiguous areas of development, and their security impacts (if any). Sequence diagrams could address this challenge by ensuring that all roleplayers in development have an unambiguous starting point for how the system will appear. One disadvantage of applying sequence diagrams in this way, however, is that sequence diagrams focus on the flow of messages as opposed to the flow of control and behavior, which is a necessity for planning and discussion. Despite this, if I use advanced UML notations such as CombinedFragments and Coregions (Object Management Group, 2015), a sequence diagram can maintain some representation of the application’s flow control, reducing the impact of this drawback.

Creating this artefact and reflecting on it, helped me achieve learning ourcomes 1 and 2, because I learned how to identify threats to applications by consulting OWASP and MITRE CWE, and then find ways of addressing the discovered risk, either through changing the implementation of the RNG used, or adapting a load-balanced, microservice-based approach, which would prevent RNG states from being enumerated.

Collaborative Discussion Artefacts

Link to Initial Post

Group Project

During the unit, I was also introduced to the group that I would be working with. We had a discussion via Zoom regarding a team contract, and how everyone would work together. A key intention of mine is to learn from the work experiences of my teammates, and use the project as an opportunity to learn new ways of development by consulting academic literature and different practices as opposed to completing the project by using approaches I am already comfortable with.

During the meeting, I was selected as project manager. Working on a project in this capacity is new to me, and a recurring challenge I’ve faced in my work (both academic and commercial) is time estimation. Project managers are expected to provide accurate estimates for deadlines, and the module projects are no exception. I therefore began research into this area of study, hoping to discover more accurate ways of creating time estimates. In academia, this area of study is more formally known as software development effort estimation. Current research is currently largely focused on statistical/data-driven approaches to estimating development efforts (Carbonera et al., 2020), however, due to real-world limitations, I focused on finding manual estimation methods which would be easy to implement. One useful insight I have found is creating estimates as a team and using checklists specialized to the project at hand- this prevents bias in estimation, improves team awareness, and reduces the risk of forgetting details which may influence time requirements (Jorgensen, 2014; Łabędzki et al., 2017). Another useful estimation method which I found is the use of “story points” (Łabędzki et al., 2017); that is, assigning a core user story an arbitrary (or time-based) point value which quantifies how much effort would be required. After that, other user stories would be assigned points based on how complex they are to implement, relative to the initial story selected. The abstract nature of this approach improves the accuracy of estimations because it is not reliant on time; as the authors note, time estimations can be volatile due to differences in skill and gains in experience during development. These methods seem promising, and I will be applying them to both projects in this module and will make note of my experiences in using them.

Overall, this experience helped me achieve learning outcome 4, because I began to establish a solid theoretical foundation for project management skills, allowing me to improve efficiency when working with a remote team.

Group Project Artefacts

Link to team contract

References

Carbonera, C., Farias, K. & Bischoff, V. (2020) Software development effort estimation: a systematic mapping study. IET Software 14: 328-344. DOI: https://doi.org/10.1049/iet-sen.2018.5334

Mohanty, S., Acharya, A., Mishra, D. & Panda, N. (2019) Security Testing of Web Applications Using Threat Modeling: A Systematic Review. International Journal of Computer Science and Mobile Computing 8(1): 50-57.

Jorgensen, M. (2014) What We Do and Don’t Know about Software Development Effort Estimation. IEEE Software 31: 37-40. DOI: https://doi.org/10.1109/MS.2014.49

Łabędzki, M., Promiński, P., Rybicki, A. & Wolski, M. (2017) Agile effort estimation in software development projects - case study. The Central European Review of Economics and Management (CEREM) 1(3): 135-152. DOI: http://dx.doi.org/10.29015/cerem.359

Object Management Group. (2015) OMG Unified Modeling Language ™ (OMG UML) Version 2.5. Available from: https://www.omg.org/spec/UML/2.5.1/PDF [Accessed 03 September 2021].