Software Engineering Project Management

Unit 1: Introduction to Software Engineering Project Management

First group meeting notes:

Unit 2: Study: Why Projects Fail and Gathering Requirements Exercise

Forum Discussion

Question 1: Three Most Common Reasons for Project Failure

Software project failures most frequently originate from errors introduced during the early stages of development, particularly requirements analysis and system design. 
Three common reasons for failure can therefore be identified: deficient analysis, poor design decisions, and organisational pressures that amplify these weaknesses. Poor analysis occurs when requirements are accepted without sufficient validation or domain understanding. Importantly, this should not be interpreted as a simple lack of available knowledge. In line with contemporary literature on information overload, the issue lies in the difficulty of filtering, interpreting, and applying relevant knowledge effectively. Poor design often follows flawed analysis, resulting in architectures that are misaligned with business processes, overly rigid, or unnecessarily complex.  Organisational constraints are classified as "Organisational Influence Errors" that contribute to failure by creating breakdowns that lead software designers to make mistakes during the design phase. These errors are root causes of subsequent software design faults and failures.
Specific organisational factors that can negatively affect productivity and design quality include:

• Restructuring and Interruptions: These often cause delays and interruptions, reducing productivity and impacting the quality of output.
• Budget Constraints: Limitations on budget can restrict the availability of necessary tools and resources for software designers.
• Organisational Culture and Pressure: Organisational policies, culture, and constant pressure from upper management to deliver contribute to errors.
• Flawed Teamwork: Poor planning, flawed communication, and poor coordination can result in a poorly conceived design.
By reducing the impact of these organisational policies and decisions, organisations can improve overall software quality and prevent the reoccurrence of errors.

Question 2: Examples

1. The Horizon Post Office Failure:  The Horizon Post Office IT system in the UK caused widespread accounting errors, leading to financial losses and wrongful prosecutions. The failure stemmed - among other things - from poor requirements analysis, inadequate validation, and design flaws that did not account for operational realities. Organisational pressures amplified these issues, illustrating how deficient analysis and organisational influence contribute to project failure.

2. The UK's National Programme for IT (NPfIT):  NPfIT attempted a ‘big bang’ deployment across multiple NHS systems, resulting in delays, cost overruns, and unmet objectives. Poor initial analysis, overambitious design decisions, and organisational constraints - such as tight deadlines and pressure to deliver - mirrored the three common failure reasons identified. This case exemplifies how organisational influence and flawed design decisions cause large-scale software project failures.

References
Agrawal, T., Walia, G.S. and Anu, V.K. (2024) Development of a software design error taxonomy: A systematic literature review. SN Computer Science, 5: 467. DOI: https://doi.org/10.1007/s42979-024-02797-2

Second group meeting notes:

Unit 3: Estimating, Planning and Risk

Third group meeting notes:

Unit 4: Estimating Tools and Risk Assessment

Activity

Read the articles by Verner et al (2014) and Anton & Nucu (2020) and then answer the following questions:
What are the main risks that the authors identify?
Which of the frameworks discussed in the Unit 3 Lecturecast would you use to capture and categorise the risks?
Add a risk and a suggested mitigation to the module forum.

Verner et al. (2014) discuss a range of risks that commonly affect global software development projects. A major theme in their findings is the increased difficulty of communication and coordination when development teams are geographically dispersed. Differences in language, culture, and time zones can hinder collaboration and make it harder to share knowledge effectively. The authors also highlight project management risks, including limited visibility of project progress, ineffective task distribution, uncontrolled changes to requirements, and inconsistencies in development practices across locations. In addition, outsourcing arrangements introduce further uncertainty, such as unfamiliar legal environments, political instability, and inaccurate cost estimates. Anton and Nucu (2020) focus on risks related to how organisations manage risk at an enterprise level. They argue that risk management frameworks are often adopted formally but not embedded effectively within organisational processes. Insufficient senior management involvement, weak governance structures, and poor alignment between risk management and strategic objectives can reduce the value of enterprise risk management and leave organisations exposed. To capture and categorise these risks, the ISO 31000 framework is appropriate, as it supports a structured and organisation-wide approach to risk identification, analysis, and monitoring. An additional risk in global software projects is misaligned expectations between stakeholders. This can be mitigated through clear documentation, agreed communication standards, and regular coordination meetings across all project sites.

Fourth and fifth group meeting notes:

Unit 5: User Experience

Collaborative discussion “Human emotions can affect the user experience, a fact which contributes to the complexity of user satisfaction with a product. Further complicating the process is the fact that user emotions on the first use of a product are likely to be different to their emotions once they become more experienced.  Read Gu et al (2023) and discuss whether you agree with the authors that their findings can improve the accuracy of subjective evaluation.”

I agree with the authors that their findings can improve the accuracy of subjective evaluation because they directly address one of the core weaknesses of traditional UX assessment: cognitive bias. Subjective evaluations are often influenced by factors such as first impressions, memory effects, or the halo effect, which can distort how users judge an interface over time. The authors’ work highlights how these biases can systematically affect user ratings, making purely self-reported measures less reliable. By identifying and empirically demonstrating these effects, the study provides a stronger methodological foundation for interpreting subjective data. I find this particularly valuable at postgraduate level, where emphasis is placed not only on collecting data, but also on understanding its limitations. The authors’ findings encourage evaluators to consider temporal factors and underlying psychological mechanisms when designing studies and analysing results. This leads to more informed judgments rather than taking user ratings at face value. Furthermore, the research supports the integration of complementary evaluation approaches, such as behavioural or interaction-based measures, to contextualise subjective feedback. This alignment between subjective perception and observable interaction helps reduce ambiguity and strengthens validity. Overall, the authors contribute to improving evaluation accuracy by making subjective assessment more structured, reflective, and methodologically robust, which is essential for high-quality UX research and evidence-based design decisions.

Sixth group meeting notes:

Unit 6: Pytest and Test-Driven Development

Hand in of the group assignment

Activity
experimenting with pytest using the Python programming language

If we change the function add_cash to instead subtract money then the tests will fail

Unit 7: Software Development Life Cycles

Activity
In relation to the ‘Components of User Experience’ model from Van der Linden et al., (2019) (below), consider the ‘Emotional reactions’ of user experience.
Question: As a Project Manager, what might be your response to manage the emotional reactions of a customer? You should use at least three academic papers to support your response and write a minimum of 300 words as your response.

Based on the Components of User Experience (CUE) model presented in the figure, managing a customer’s emotional reactions requires a holistic approach that addresses both the functional and psychological aspects of the product. As a Project Manager, I cannot directly control the "Emotional reactions" (e.g., subjective feelings or physiological reactions); instead, I must manipulate the antecedents: the Instrumental and Non-instrumental qualities. First, I would prioritise the optimisation of Perceived Instrumental Qualities (Usefulness and Ease of use). According to Davis (1989) and the Technology Acceptance Model (TAM), perceived ease of use and usefulness are the primary determinants of user acceptance. If a system fails to solve the user's problem efficiently, the "Cognitive appraisal" in the CUE model will be negative, leading to frustration. Therefore, I would implement rigorous usability testing to ensure the "System properties" minimise friction, thereby reducing negative "Motor expressions" or stress. Second, I would invest in Perceived Non-instrumental Qualities (Aesthetics and Symbolic aspects). Hassenzahl (2003) distinguishes between pragmatic (instrumental) and hedonic (non-instrumental) attributes, arguing that while pragmatic attributes facilitate goals, hedonic attributes (stimulation and identification) are essential for evoking pleasure and positive emotional bonds. A purely functional product that lacks aesthetic appeal may be "useful," but it will fail to generate the positive "Subjective feelings" necessary for high customer satisfaction. Finally, I would manage the Context parameters to influence the customer's "Overall judgments." Thüring and Mahlke (2007), whose work underpins the CUE model, suggest that emotional reactions are the result of the interplay between system qualities and user characteristics. By managing client expectations (a context parameter) and ensuring the product’s "Symbolic aspects" align with the customer’s brand identity, I can foster positive "Behavioural tendencies," such as continued usage and favourable choices between alternatives.

References

Davis, Fred & Davis, Fred. (1989). Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology. MIS Quarterly. 13. 319-. 10.2307/249008.
Hassenzahl, Marc. (2005). The Thing and I: Understanding the Relationship Between User and Product. 10.1007/1-4020-2967-5_4. T
huering, Manfred & Mahlke, Sascha. (2007). Usability, aesthetics and emotions in human–technology interaction. International Journal of Psychology - INT J PSYCHOL. 42. 253-264. 10.1080/00207590701396674.

Unit 9: Quality Management Strategy

Activity
Comparison of original article with chose article:
Pargaonkar, Shravan. (2023). A Comprehensive Review of Performance Testing Methodologies and Best Practices: Software Quality Engineering. International Journal of Science and Research (IJSR). 12. 2008-2014. 10.21275/SR23822111402.

The article by Verdugo et al. (2024) and Pargaonkar’s review (2023) differ substantially in how they conceptualise and address software quality. Verdugo et al. adopt a product-centric, standards-driven perspective, focusing on formal evaluation and certification of software quality based on ISO/IEC 25000. Their work emphasises objective, measurable quality attributes, particularly maintainability and functional suitability, and demonstrates how quality can be institutionalised through accredited laboratories, standardised metrics, and certification schemes. Quality is treated as something that can be quantified, validated, and externally verified, with strong links to industry adoption, governance, and long-term sustainability. In contrast, Pargaonkar’s article approaches software quality from a testing-centric and methodological viewpoint, concentrating specifically on performance as a quality attribute. The focus is operational rather than institutional, emphasising testing methodologies, tools, best practices, and practical challenges in performance evaluation. Quality is framed as something that emerges through continuous testing, monitoring, and iterative improvement, rather than through formal certification or external validation. Another key difference lies in scope. Verdugo et al. address software quality holistically within a broader quality model, integrating evaluation into organisational ecosystems and industry–academia collaboration. Their approach highlights structural quality, long-term maintainability, and process alignment. Conversely, Pargaonkar provides a broad survey of performance testing techniques but remains largely tool- and practice-oriented, without embedding these practices within formal quality frameworks or regulatory structures. Methodologically, Verdugo et al. rely on empirical validation, standardised metrics, and accreditation processes, aiming for reproducibility and comparability across products and organisations. Pargaonkar, however, synthesises existing knowledge and best practices, offering descriptive guidance rather than validated measurement models or certification mechanisms. Overall, Verdugo et al. emphasise formalisation, standardisation, and certification as drivers of software quality, while Pargaonkar emphasises practical testing strategies and performance optimisation. The former seeks to institutionalise quality assurance, whereas the latter focuses on improving system behaviour through testing practices. These differences reflect contrasting orientations toward governance versus practice, measurement versus methodology, and structural quality versus performance quality.

Unit 10: Software Quality Monitoring in Python

Activity
Linters for Python Code Quality

Below we see the result of the four linters that were tested. These linters each take a different approach meaning that a developer could chose to use one or more of these at a time. pylint is comprehensive offering feedback on a range of areas, while pyflakes finds logical errors, pycodestyle enforces the PEP-8 code style, and pydocstyle checks documentation.

Pylint:


Pyflakes:


Pycodestyle:


Pydocstring:

Unit 11: Software Engineering Project Management: Future Trends

Hand in of presentation assignment

Unit 12: The Case for the Future Direction of Software Engineering Project Management

Hand in of the portfolio assignment and reflection