Software Engineering Project Management

Final reflections on the module

1089 words

What

After finalising module 4, where we studied the concepts of Information Security, Risk Management and Risk Assessment, this module presented a critical topic: Software Engineering Project Management (SEPM).

The Software Engineering Project Management module reviews the fundamental concepts of SEPM and introduces other concepts like Behaviour-driven Development (BDD). This module introduces the traditional tools used in project management, including estimating, planning, and scheduling, as well as those of software architecture and engineering disciplines (University of Essex, N.D.).

This is one of the most important modules and one of the reasons I enrolled in this course. Initially, I felt the need to clarify to myself what being a project manager means, as sometimes, at work, we manage small projects, but this does not give us the entire understanding of the role. How much of what we do at work is done following current trends? What are the most used models and techniques? How do we concatenate estimating, planning and risk? These were some of the questions I had at the beginning of the module.

So What?

Module content & tools

To start, we went through the fundamental concepts of project management and established the differences with SEPM. The essential aspects were gaining knowledge on the importance of SEPM and what certifications I could acquire as a project manager. The relationship between project management and the Software Development Life Cycle (SDLC) is another critical topic, as the SDLC needs to be wrapped up by project management.

We opened with a discussion on why a software project can fail. This discussion was beneficial as it allowed me to learn from different cases what the most common reasons for project failure are. Lack of proper communication and misunderstanding of the requirements were the most common reasons, and our fellow students and I agreed during the discussion. It is essential to consider these reasons when managing projects and avoid falling into the issues that lead these projects to fail.

Knowing the issues that can cause projects to fail, the next step was to learn about how to mitigate the effects of these reasons using the most adequate techniques. In my understanding, it is not possible to avoid issues, so a way to mitigate their effects becomes a key responsibility of the project manager to plan and apply the mitigations.

I found that the Gherkin language and its application are only one element of behaviour-driven Development (BDD). BDD was a concept I saw before but never stopped to analyse and understand properly. BDD is business-driven, and its benefit is noticed when the users interact with an interface to the application (Behaviour Driven Development, 2020).

The importance of TDD lies in the interaction between technical and non-technical teams. This interaction requires a natural way (natural language) of describing requirements; Gherkin language helps with this purpose. If we get all stakeholders involved, there are more chances that the final product will satisfy all of them.

The most challenging part of this module was, without a doubt, the project estimation. Initially, I needed to clarify how I would perform these activities (estimation, plan, and risk management). However, I then noticed some familiar concepts I studied in my first university degree, like COCOMO or Expert Judgment. The benefit of this module lies in the resources it provides to do activities that are hands-on, like cost estimation. Going through the historical estimation methods and learning about frameworks for risk assessment, like Open FAIR, provided the knowledge to position ourselves better when choosing appropriate tools to support our work as project managers.

There was a connection between the content from the previous module, where Risk Management and Information Security were studied. I used this knowledge as a base to understand the new concepts of this third unit.

Using Linters to monitor code quality was reassuring because we used them in the third module, where I focused on using Pylint and Flake8. It feels complementary to use other tools like Pyflake, Pycodestyle and Pydocstyle.

Working in a team

Although in my previous experience within a team, we achieved good results and work was fairly shared between all members of the group, there were times when things were over-discussed and ended in meetings that lasted around 2 hours. Being more practical, I wanted to go straight to the discussion of the interesting points and start working.

After the first meeting, I was pleased all team members were really committed to doing a good job and were always present for the online meetings. We held meetings every Wednesday for the first part of the project, and for the second part, we also met on Sundays, being these meetings a bit shorter in duration.

For the first part of the project, my contribution was the definition of the scope and the Gherkin scenarios for the software specifications. We quickly identified software and hardware requirements, continued with the costing, and elaborated on the plan. As in my previous experience, getting everyone involved in all activities dropped productivity a bit; this time, we were only informed about our progress during the meetings held.

Using project management tools like Confluence, collaboration with Slack, and instant communication with WhatsApp resulted in a productive way of working.

For the second part, I analysed the new requirements so we could update the proposal for building a new machine. This analysis was done quicker than expected because, in the project descriptions, the buyer company sent their own list of requirements, so adding this to the original specifications did not take long.

Now what?

At work, I have been taking ownership of some small projects, and I have applied some of the project management principles. When starting this module, I expected to study these principles further and obtain a schematic of the activities and responsibilities of a Software Project Manager (SPM). To have a map of how to approach a project as a manager is essential. This map is one of the most important things I gained during this module, and I will be using it when the time to confidently take on large projects arrives.

On monitoring quality, Pylint can give suggestions that all other tools we used in this module can, and it is clear that they can be used together as each of them can contribute with specific and detailed suggestions. This is an important outcome I plan to apply at work.

Each time we start a new module, my aim is to update my knowledge and gain future trends. This is happening, and overall, I am satisfied with the knowledge I am acquiring.

References

Behaviour Driven Development (2020) The Gherkin language. Available from: https://behave.readthedocs.io/en/stable/philosophy.html [Accessed 25 November 2023].

The University of Essex (N.D.) MSc Computer Science. Available from: https://online.essex.ac.uk/courses/msc-computer-science/ [Accessed 30 November 2023].