Unit 2

Learning Outcomes Achieved

1. Identify and apply appropriate software engineering and project management methodologies, tools and techniques for the development of solutions to real-world problems
2. 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 roles and team organisation

Forum Discussion: Peer Responses

This week, students were required to further discuss the topic of common reasons for software project failure. In my first response, I engaged with the subject on a deeper level, by looking into academic opinions on software project failure, and also what the future of risk management may look like in software engineering project management (which could involve revitalising old risk management frameworks). In another reply, I discovered other software engineering case studies which failed for reasons that were similar to what a classmate of mine mentioned.

My thinking was challenged by my classmate’s response because he highlighted how scope management has persisted as a challenge in project management despite the advent of Agile methodologies, and this encouraged me to think deeper about what SDLC approach should be selected for the assignment. There is no perfect answer, rather, advantages and disadvantages to different methodologies- for example, waterfall relies on defining requirements upfront (Adobe Workforce, n.d.), which could be more beneficial for the assignments in this module, since it might be difficult to meet with the other team on an ongoing basis. Knowing how to compare different methodologies for the assignment improves my confidence in my team’s success with the assingments because I now know how to bring up a discussion on picking something fit for purpose. This is something which we should be discussing soon.

By exploring risk and its relationship to software project failure, and by having my thinking challenged in the forum discussion, I’ve achieved learning outcome 1 because I now have a better understanding of what influences risk in software projects.

By developing a better understanding of how to pick an SDLC methodology for the assignments, I have achieved learning outcome 1 because I’ve developed a better understanding of how to critically approach the topic.

References

Adobe Workfront. (n.d.) Waterfall Methodology. Available from: https://www.workfront.com/en-gb/project-management/methodologies/waterfall [Accessed 12 March 2022].

Requirements Gathering: Team 2 Meeting

This week, my team and I met with team 2 to initially discuss which requirements we’d like to have in the product made for our team, and which we would not be able to accept for the project which we need to develop. We both discussed the nature of the products we wanted and afterwards, I made a suggestion that both teams internally discuss which features to accept, which to reject, and then present a document containing details on both. I’ve attached our team’s list below.

This sequence of events was similar to real-world negotiations in some ways, and in completing this and producing a final list as an outcome, I achieved learning outcome 4 because I had to use effective communication to move the meeting forward- I wanted to keep the discussion focused on outcomes to prevent the conversation going in circles (and conversation seemed to be reaching this point), which is why I suggested creating a final document so everyone would have the time and space to gather their thoughts. To bring this up and get buy-in, I had to be polite yet firm, and also explain how this approach benefits everyone. This is a communication strategy that I can copy and apply in my career, and it is extremely useful based on how it worked in this situation.

Seminar

I wasn’t able to attend the seminar due to a scheduling conflict, but I have completed the preparation exercise (my chosen example was creating a shell script) and attached the .features file in the artefacts section.

By completing this task, I acheived learning outcome 1, because I learned how to use Gherkin statements to gather requirements, which acts as a methodology that can be used to solve the problem of understanding what a customer really wants. I will apply this concept to my team’s group assignment, as it makes it easier for us to ensure that we’re building the right features from the customer’s point of view (and making the features fit the Gherkin format also makes our features testable).

Artefacts

Meeting Notes (I wasn’t able to attend this one)
Project Summation Document (list of requirements from team 2 that were accepted/rejected) Peer Responses
Seminar Preparation (.feature file)