Part 1.

[30 marks] – A post project review of product and process

This report is aimed at the management and staff of your development company (not the
client). It should summarise the process and the final product, including:
• an appraisal of the quality of the product (the team report) and the extent to which it
met the requirements;
• an appraisal of the process (working as a team) including an explanation of any
problems faced, and how they were addressed;
• lessons learned and recommendations.

We have provided a document Post Project Reviews giving some background

information on this topic and you should read that document before writing your own
review.

You are advised to make your report dispassionate and impersonal (it should not be an
exercise in blaming individuals) but it is important to be frank and face up to problems.
Similarly, although it may be appropriate to explain how you would have acted differently
on some issues, had you not been constrained by team decisions, it should be to
highlight lessons to be learned by the organisation and not an exercise in self
exoneration.

Throughout, remember this is a formal report that is part of the internal project
documentation. It should inform co-workers and senior managers and help plan future
projects.

This post-project review has been divided into six parts: appraisal of final product,
best practices adopted, problems faced (including points on working as a team),
recommended improvements, lessons learnt, proposals for further work.

Appraisal of final product

Functional and non-functional requirements from the client were identified via textual
analysis and validated during team discussions.

Overall, the team report meets the requirements of the client. If Specialist Publication
Company were to build a system according to what is laid out in the report, the
company would find that the system is capable of replacing the manual work they
currently do to manage articles and authors.

An assessment of quality was made across multiple dimensions (based on the

content of Unit 1 of ADITSAD, as agreed among the team members), assigning a
high-medium-low score to each material element of the report across each
dimension.
In terms of functionality – the rating is consistently “high”, as the system covers all
the requirements of the client.

In terms of reliability – while the designs for the system are able to meet user needs
under normal circumstance, it is observed that the designs lack detailed measures to
allow for fault tolerance (the ability for the system to function despite issues with the
hardware or software) or recoverability (the ability for the system the recover the
data stored on the system in case of a system failure).

In terms of efficiency – the rating is consistently “high”, as it is assumed that the

system would be able to execute its functions in a time-efficient manner, in line with
the expectations of the client.

In terms of security – provisions have been discussed in the team, and incorporated
in the system designs – to ensure that a level of access control is present in the
system. Specifically, users are asked to login into the system using a username and
password (provided at the time of first access and registration onto the system), and
different user rights exist for the different categories of users (e.g., editors and
authors) and for individual users part any user category. However, more could be
done to further ensure that the data in the system is secure, for example by
improving the system’s protection of sensitive user information, or using a tiered user
authentication system.

In terms of usability – the designs provide a good degree of accessibility and error
protection, with several scenarios illustrating what would happen in the system in
case deviations from the standard scenario were to happen (e.g., the system does
not contain information on any authors). Opportunities for improving further in this
space exists. One could expand on additional designs to cover additional deviations
from the standard scenario, and write user guides and training materials, especially
for what concerns units 9 and 10, as not all users may be knowledgeable about the
SQL and PostgreSQL syntaxes.

In terms of maintainability – overall, the system is in a good position when it comes

to the testability of its different components, as well as the ability to modify, expand,
or re-use those components. It should be observed that improvements could be
made to make the system more modular, since, as of now, there are strong
dependencies between the different components of the system, meaning that a fault
in one component would impact the ability to function of the entire system.

In terms of compatibility – overall, the system contains information that would enable
it to be linked to other systems (e.g., accounting system used to book fees for
authors writing articles, based on e.g., author information contained in the system).

Best practices adopted

A Functional architecture diagram (not included in assignment submission) was
created, to illustrate, at the onset of the project, what is in and what is out of the
system. This was used as reference for work done in the different activities of the
project.
Furthermore, agile ways of working were used. We agreed in our introductory
meeting on who will be writing the different activities, to be then reviewed as a group,
both during writing process as well as at the end, ahead of the submission. However,
as we progressed in the project, we had to partially change our allocation of work, as
different activities appeared to be strongly interrelated and, in our minds, it would
have been best to have the same person draft them in the first instance. For
example, for activity 8, work was allocated to a specific person at the onset of the
project, but later on it was decided that the first drafting should be assigned to the
same person who had been tasked with writing activities 6 and 7. The first draft was
then further detailed out by the person who had originally received the task of writing
a first draft at the onset of the project.
There was also use of online, shared resources (OneNote, online editable word file,
online agenda, draw.io UML diagrams, and real time communication using Microsoft
Teams) as opposed to offline editing of files and sharing those via email.
A weekly stand-up was used to discuss status of work against agreed schedule, and
any issues or risk regarding the activities, and any doubts or opinions about how the
design choices followed in the writing of activities.
Additionally, an activity log was used, to record all contributions made by the
different team members throughout the duration of the project.

Problems faced
There was a problem with uploading images in the submission file. Time was
consumed at end of project to get images with the right resolution – more time could
have been spent on quality assurance had this not happened.
Team members had different interpretations of assignment brief. Team members
had different interpretations about what parts of the brief implied in terms of
requirements for the system. This was addressed by initiating discussion in the
weekly stand-up, to find a common ground among the different team members.
Additionally, team members had different interpretation to how to represent objects
(specifically, objects for “specialism” and “level of expertise”) in the assignment. This
was the subject of debate during two weekly stand-ups, and required re-work of
sequence diagrams and class diagrams.
Team members also had different views regarding methodologies to follow.
Specifically, there were different views in the team regarding whether an activity
should be completed based on directions from a video explanation shared by one of
the course’s tutors, or based on the (different) directions provided in materials from
the relevant ADITSAD unit.
Furthermore, the latest version of activities in one source (OneNote) did not always
match last version in online .word file, creating the perception that work was behind
schedule.
Finally, since requirements were not clear enough to inform a decision on what
constraints to include in activity 10, there was a need to have additional, time-
consuming discussions among team members, to reach a shared agreement over
what constraints could be assumed for the system, and what SQL or PostgreSQL
expression should be written to represent those constraints.

Recommended improvements
First, agree beforehand what items of a submission need to be included as picture,
and devise painless to include all images in one place (e.g., do not include images in
word file, only include as separate attachment).
Second, set aside time in weekly stand-ups to discuss different interpretation of
assignment arisen in the group. The aim should be for the team to find a common
group as a group, with agreement to move forwards shared between all team
members.
Third, agree beforehand what application is to be used in different phases of the
project (e.g., use only OneNote for drafting phases, and use an online .word file
when the documents are in final draft form).

Lessons learned
It is important to define what is in and out of the system at the beginning of a project
like this. This is something that to an extent can be revisited during the project, but
an initial understanding of the boundaries of the system helped the team getting
started with the different activities. Had this not happened, there would have been a
higher risk of having work done by different people on different activities diverge.
From my conversations with people who worked in other teams in unit 5, this is
something that happened with some recurrence.
It is important also to discuss issues in an ordinate manner in meetings in between
“sprints” were work gets done – this allows divergences in opinions to be addressed
early on, thus minimising the impact on the overall quality of the project.
Furthermore, it is important to manage time spent on different project phases
efficiently. The team observed that comparatively too much time (roughly 1/3 of the
time available to complete the assignment) was spent on the initial phase of the
project (e.g., completing a functional architecture view and refining a textual analysis
of the assignment), leaving less time for the subsequent phases where materials for
inclusion in the team’s submission were written.
Proposals for further work
The team should define roadmap for system implementation and budget needed to
implement, and the proceed with articulating proposal to the management of
Specialist Publication Company.
The team should choose together with the company the best software development
methodology to build the system (e.g., choosing an incremental delivery model
versus an evolutionary process model).
The team and the company should define prioritisation for different functions in the
target state system – prioritisation to enable for most critical functions to be
developed and made available first.
The development team should add elements to the system that allow for improved
fault tolerance (e.g., by using a load balancer with multiple servers to ensure no
single server fails due to excessive user traffic, or by improving redundancy by
adding redundant power supply units, that can replace the primary power supply unit
in the event of failure)
The development team should also add elements to the system that allow for
improved recoverability (e.g., by adding a secondary, disaster recovery site for the
system, to be used as data storage and rapid recovery in case disaster strikes, or by
moving the system to the cloud and benefiting by the disaster recovery offering
provided by cloud services providers such as Microsoft Azure, AWS, Google Cloud).
More should also be done to improve security of the system by introducing multi-
factor authentication, replacing the standard login procedure requiring user ID and
password.
When moving to the system implementation phase – the development team should
use techniques that allow the system to be built in distinct modules, minimising inter-
dependencies between different system components. One way this can be done is
by following the principle of information hiding, by designing modules with small,
simple interfaces but lots of functionalities (that can be modified with little or no
impact to the other modules in the system).
Finally, the team should also explore opportunities to link the system with other
software used at the company. As an example, one could think of linking the process
for commissioning articles to specific authors in the system with the process of
paying out commissions to authors writing those articles. If, e.g., one could have the
same user ID for authors in the two different systems (i.e., the accounting system
and the system designed as part of the unit 5 group exercise), one could automate
the pay out of commissions to authors based on the articles written by them, without
the need for Special Publication Company staff to manually verify which authors
write what articles in one system, and then proceeding to paying moneys to the
authors using the other system.

References:
Fortinet (ND). What is fault tolerance? [online] Available from:
https://www.fortinet.com/resources/cyberglossary/fault-tolerance (accessed 03 July
2021)
IBM (ND). What is a disaster recovery (DR) plan? [online] Available from:
https://www.ibm.com/uk-en/services/business-continuity/disaster-recovery-plan
(accessed 03 July 2021)
Oxford University Department of Continuing Education (2020). Unit 1 Topic 4
Business aspects of software product management. Advanced Diploma in IT
Systems and Design [online]. Available from:
https://study.conted.ox.ac.uk/mod/book/view.php?id=53506 (Accessed 03 July 2021)
Ousterhout, J. (2018). Modular Design [online] Available from:
https://web.stanford.edu/~ouster/cgi-bin/cs190-
winter18/lecture.php?topic=modularDesign (accessed 03 July 2021)
Petterson, D. et al. (2002) Recovery Oriented Computing (ROC): Motivation,
Definition, Techniques, and Case Studies [online] Available from:
http://roc.cs.berkeley.edu/papers/ROC_TR02-1175.pdf (accessed 03 July 2021)

Part 2. [30 marks] – A personal reflection

Write a personal reflection on your contribution to the team project and what you
learned from taking part in it. This is a less formal report than the report in part 1 and
should be about your own engagement with the project and what you gained from it.

a) The success of a team project depends on team members making contributions of

different kinds and it is not always the biggest contributor that is the most important.
Nevertheless, it is important that each member engages with the team and
contributes to the project. Here we ask you to reflect on the ways in which you
engaged with the team and contributed to the to the project result. [15 marks]

When it comes to working in a team, a factor that I find to have a significant impact
on the performance of the team is how effectively the people part of the team are
able to interact. I find the ability to interact effectively to be a function of how
compatible the different people in a team are, in terms, for example, of academic
background and personality.
Regarding the team I was assigned to for this last unit of ADITSAD, I was part of a
team of three, where the other two people in the team happened to have a
background fairly different from mine. My background is in business while the others
two team members had backgrounds as computer engineers.
As I found out after our very first meeting, the fact that both were engineers meant
that they had prior experience of designing a system, and that, as a consequence,
they had views about what to do to complete each activity at a very granular level.
This meant that both were able to contribute very relevant ideas to approach the
different activities, going beyond the content covered in the previous units of
ADITSAD. However, I also found that having substantial prior experience in
designing systems meant that both team members had strong views about how
specific parts of the different activities should be done, and I observed, throughout
the duration of the project, that when their views diverged, they would engage in
prolonged discussions to restate their arguments in the hope of convincing the other
person to change their mind.
In this setting, I was able to add value to the teams’ efforts by acting as a mediator,
facilitating agreement over what route to take when deciding the approach to follow
for the activities of the project. From conversation with other students from the Java
group, I found out that in a number of other unit 5 teams there were instances of
individuals deciding to work on specific activities in separation from the rest of the
team, arguing that that would have been easier than doing that same work in with
the rest of the team. Had I not acted as a mediator in the team, it is not unrealistic to
assume that something similar may have happened in my team as well, with the risk
of negatively affecting the final project output, or requiring last-minute work to review
the work of other team members, and fix any issues.
Another way in which I feel I managed to add value to the team’s efforts was by
putting together sequence diagrams for activity 8, and the related walkthroughs. That
was an area where I performed exceptionally well in the previous units of ADITSAD,
and I feel like the detail I added to activity 8 (e.g., with sequence diagrams for
alternative scenarios), contributed to the overall high quality of the team report.
Finally, I think I was able to share good ideas in the final meeting we had to close the
project. I feel my contribution led to an agreement over a series of guiding points that
each team member would use to write a Post Project Review report. Each team
member brought a series of points that they felt would have been good to include in
the report, and, after some discussion, we were able to agree on a number of points
around opportunities for improvements, lessons learned, problems faced, best
practices adopted, and quality of the final report.

b) Like all assignments in this course, the unit 5 project is part of the learning
process, and we ask you here to reflect on what you have learned from your
involvement in the project about the methodologies you have used, and about the
skills required for working in a team. Give examples of any issues or situations
during the project that illustrate your narrative. [15 marks]

I feel the team project was a good opportunity to put what was studied in ADITSAD
to the test in an environment different – and in my view, more challenging – than the
one seen in the previous units of ADITSAD. While previous assignments required to
demonstrate a good understanding of the content studied for a unit with individual
assignments, the final assignment was about doing something similar, but in
alignment with other team members. Also, while the previous units of ADITSAD
involved a degree of team interaction via the forums, and a number of non-graded
team projects, I feel this final assignment was also about testing the ability of each
team member to deliver an end-to-end product (in this case a report) while working
as part of a project team – which is what would happen if a similar product happened
to be commissioned to a team of software engineers in the real world.
In this sense, I feel that the unit 5 assignment required not only to use methodologies
specific to the production of software artefacts, such as level 1 diagrams and UML
diagrams, but also methodologies that are about working effectively as a team.
With regard to the skills needed to work in a team, the elements that in my view are
the most important are awareness of self, and the ability to understand what the
strengths, weaknesses and overall personalities of the other team members are.
These two elements combined allow to get a clear picture of what each team
member can contribute to the team, and organise work in a way which allows each
team member to play to their strengths to generate the best outcome for the team. I
am convinced that by organising work in the way that can best suit each team
member’s skills and inclinations can also contribute to good results, as each team
member is in a position to add value to the end result. Enabling team members to
add value with their work is a good way to generate a positive team spirit and a
desire to strive for success. As such, the team where the allocation of work allows for
its team members to feel they are contributing to a good end result is a team that is
more motivated to go above and beyond what is required to meet the minimum
threshold for success.
One thing I learned from a teamwork standpoint in unit 5 is the importance of
negotiating the work that the team is going to get done. This is relevant in terms of
both the work that you will be doing as an individual, and the work that other team
members will do. The ultimate objective should be to balance the desire for people to
do what they feel is right to complete a task, and doing what is required to do well on
that task, as there are instances where the two things do not fully overlap. One
example that comes to mind from the unit 5 team project is about an episode where
one of the team members proposed to do a substantial amount of pre-work – which
we called “activity 0” – before getting started on the actual activities of the
assignment. This was raised during the first project team meeting, and, while myself
and the other team member agreed that investing a lot of time in “activity 0” would
not be best use of the team’s time, the other person insisted that this would be of
great help to them and to the team as a whole. What we managed to agree as a
team is that the person who came up with the idea should spend a reasonable
amount of time doing this preliminary work, while the other two team members would
get started on other activities. In the end, the outcome of this negotiated agreement
was good in that “activity 0” work provided a level of guidance on some of the
subsequent activities, and was completed without excessive time commitment. It
was later on agreed that, overall, “activity” 0 and the rework of activities 1, 2, 3 that
the team had to do as a result of “activity 0” took up too much of the team’s time at
the beginning of the project. This is the reason why this point was mentioned as a
lesson learned in part 1 of this assignment.

In terms of learnings from a methodological perspective, I was happy to learn about

how to effectively build a functional architecture diagram to define what to consider
as a function being part of the target system, and what should not be. This is a point
that was raised by the other two team members – both of whom had experience of
building software systems as part of their job – and I felt this was a great way of
setting up activity 1 and some of the work for the other activities. It is worth noting
that I would have probably not built this type of diagram had I had to work on the
assignment by myself, as I was not aware of its existence, but I was happy to be
challenged on what I thought would be the best way to approach activity 1, and learn
about a new methodology which I could also use again when working on similar
tasks in the future.

Finally, I would say that the team project was a good opportunity to learn how to use
agile methodologies in a real-world setting. We used our weekly meetings in a way
akin to how agile teams use stand-ups during sprints, i.e., to discuss the tasks that
the team would need to do work on before the next meeting, and divide work
between team members based on abilities, workload, and estimated time to
complete. The final meeting was also a good opportunity to test how to do a project
retrospective, and reflect on how the team could have performed better.

References:
Beck, K. et al. (2001). The Agile Manifesto [online] Available from:
https://agilemanifesto.org/ (Accessed 03 July 2021).