Faculty of Science, Engineering and Computing
- Critically analyse and explain the concepts, strengths, limitations and suitability of agile development techniques;
- Select and apply object oriented development techniques within an agile development environment;
- Critically discuss social and professional issues associated with Information systems Project Management.
- Manage the development of a system by applying an agile framework.
Assignment Brief and assessment criteria (these will be discussed within a formally timetabled class)
Coursework 2 Assignment Brief and assessment criteria
Please read these instructions before you start your Coursework 2 which is an individual report.
Who you are:
You are part of a team of systems analysts working for an IT consulting firm that have been hired to develop a specialised system for the government of Lazarus Island. The IT consulting firm has its own staff with skills of Agile Project Management, business analysis, system development, programming and testing.
The island is located in the South Pacific, about 350 miles from Ecuador and has a population of 80,000.
Your team have been developing systems using an Agile Methodology for the last 10 years and they are very competent in using the DSDMAgile Project Management Framework and the SCRUM methodology. The team have decided that this particular project will adopt the DSDM Agile Project Management framework to develop the system.
What you are getting yourself into:
As mentioned earlier, your firm has been commissioned by the government of Lazarus Island to design and build a specialised system for them. The island has been subjected to a number of natural disasters such as cyclones, hurricanes and recently an earthquake. The government receives a lot of offers of assistance, donations and actual resources such as food, clean water, medical supplies, temporary shelters etc. whenever disaster struck but their approach to handling relief (and the disasters in general) has been poorly coordinated.
To add some perspective, dealing with disasters is a complex process and managing a disaster is usually done in 2 stages:
You can learn more about Disaster Relief and Coordination from various resources such as: the Emergency Management UK portal
Also there are some useful articles on Disaster Management e.g. DEC, which brings together several UK charities, and Red Cross:
You should carry out further literature review to help you understand the requirements in more detail.
The System that needs to be created:
The system that needs to be created would be used in the response stage of disaster management, specifically the part that deals with ensuring the basic needs of people affected by the disaster are met by government agencies and humanitarian organisations. This is a crucial stage in response to a disaster as people are cut off from basic supplies and left in exposed, substandard living conditions can fall foul of disease and malnutrition.
Your role is to draw up a specification for a system that will help them to better coordinate their relief effort. This system should be web based so computers and mobile devices can access it. The system needs to be secure and only people authorised to use the system should be able to access it. The disaster relief coordination system (code-named Aegis) should be designed to enable government and non-government organisations to coordinate efforts in the relief phase following a natural (or man-made) disaster. The system should be made up of a number of modules that enable these organisations to work together and share information on the disaster so that resources can be deployed in the most effective way possible.
The Aegis System is made up of the following sub-systems:
- Mapping and Geo-locationSystem (using the Google Maps API or a more reliable mapping API)
- Resource Management System (for cataloguing and tracking inventory such as medicines, equipment, etc.)
- Organisation Management System (where staff are associated with organisations)
- Situation Management System (allowing situations to be ‘raised’ that list requirements)
All organisations can add markers onto an interactive map highlighting areas of need, current locations of relief workers, camps, supply points, last location of missing/found people etc. These different marker groups can be activated and deactivated as needed to improve readability and focus of the map. Organisations will be able to communicate with one another through messaging services and can add workers’ mobile numbers so that they can send/receive status updates.
Part of the requirements for the system is that it will need to incorporate a submit/approve process whereby a non-governmental organisation can submit information that needs to be approved by the appropriate government agency. This only applies to certain requests such as medical supplies, desalination equipment, shelter construction and support request that go beyond basic grain, milk, water and emergency shelter provision. The process is also used in confirming situations raised by workers from Non-Government Organisations. You can consider a typical ‘situation’ as being the discovery of local(s) directly affected by the disaster and in need of resources that will provide for their basic needs and health.
Who are the users:
A number of people will be stakeholders regarding the development of the Aegis system. Only the hands on users, those that directly use the system as a core part of their job are listed here along with their basic use of the system. It is likely that there are other users of the system that have not been listed below.
Government Agency Administrator: They would be using the system to enrol and manage Non-Government Orgainsations (NGO) e.g. Red Cross, Oxfam.
The government agency administrators would setup/confirm requests for resources as well as manage and allocate resources to NGOs. Resources are stored at resource hubs and are then despatched to places that are requesting them. Resources are never requested or allocated individually. They are bundled up into resource packages that contain essential resources.
The administrator would also identify situations from information provided by the national and local emergency services. They would also have to approve situations proposed by NGOs. Both would result in a request for assistance being generated that they could allocate to an NGO to deal with. A situation will only be approved by a government admin as soon as one of the emergency services (police, ambulance, fire brigade etc.) have visited the situation and confirmed that it is real.
NGO Administrator: These individuals act as the main contact and coordinator between government administrators and the NGO. They identify their main base camps, update worker lists and profiles and also ensure that the last known locations of workers have been updated. They also identify and build teams from their worker lists to deal with requests for support.
They can identify situations for approval by government admin and offer to respond to requests for assistance.
An NGO admin can request resources for teams that are dealing with support requests.
NGO Worker: They are the ones who are out in the field providing the relief work. Workers in the field can keep their profile up to date ensuring that their correct skills and expertise are stored. Workers can also update their current location so that NGO administrators know where they are and how far they are from areas that need assistance.
Workers can request resource packages for use in situations that they are providing assistance for. They can also suggest certain configurations for resource packages so that they better suit the situation that they are supporting.
As the workers are operating in the areas affected by the disaster they may spot situations that have not been set up on the Aegis system. NGO workers can then declare the situation that they have identified via the system.
Example of system use – Responding to a request for support
This example describes an indicative, not comprehensive use of the system. It involves more than one of the Aegis sub-systems but does not cover all of them.
An NGO administrator notices a support request that requires the construction of emergency shelters and the provision of desalinated water for a group of around 200 locals that are cut off from travelling to the nearest refugee camp some 25 miles away. The administrator looks through their NGO worker lists and identifies a number of individuals who are currently available with the required skills to meet the request. She narrows and adjusts the list by specifying the maximum distance that the last known location of the NGO workers should be. She does this so that workers can get to the area and administer relief as soon as possible. The administrator accepts the support request and the system is updated with the information that the request is being handled by her organisation. This makes the support request unavailable to other NGOs. The administrator then creates a team by adding suitable workers from the worker list and then assigns the team to the request. The workers who have been added to the team receive a text message via their mobile phone letting them know they have been tasked and advising them to access the Aegis system for more details. The message also includes the location information required to get to the affected locals.
Steve, and NGO worker uses the location information to head directly to the area. He arrives just as a government truck is bringing in some resources to construct temporary shelters. The other NGO workers are already on the scene installing the desalination equipment and giving out essential items such as food and fresh water. There are reports that some of the people have got malaria but no malaria medicine was included in any of the resources they received. Steve calls one of the NGO administrators who is supporting the team to request a supply of malaria pills. The administrator does a search on the NGO inventory and finds that they have got some, and then she allocates this resource to the team. A few hours later the pills have been delivered and Steve is able to distribute them to the infected people
What you need to deliver:
After several facilitated workshops some useful information has been put together as described in the case study description above. From those sections above you must submit a report that includes the following:
- A critical explanation, based on a literature review, of why an agile approach should be used to develop this system. Include the strengths and limitations of using an agile approach and in particular why use the Agile Project Management Framework in this case. [20 marks]
- A description of the stakeholders and explain their roles within Agile Project Management Framework. Also include the roles within your IT consulting firm who will build the system.
‘Alien baby’ identify the stakeholders – who is the business sponsor who is the visionary and if it is not there you need to add it. Scrum roles…
- Explain why MoSCoW technique is used. Present a list of high-level MoSCoW prioritised business process requirements in a table format (Prioritised Requirements List [PRL]). include estimates for each requirement as number of days. The requirements should form the basis for four separate High-Level Use Case Diagram, including the users of the system, based on the 4 subsystems identified.
- Total of 4 users stories based on the MUST HAVE requirements. One User story for each of the 4 subsystems for the use cases identified in q3. Use the template: “As a <role>, I want <goal/desire> so that <achievement/benefit>” and the associated Acceptance Criteria for each user story.
4 USER STORIES:
In the back you do the acceptance criteria which is the testing
- Choose 2 user stories to focus on from the 4 user stories above in q4. Develop two paper prototypes, one for each of these 2 user stories.
THE SEQUENCE OF SEVERAL SCREENSHOTS OF 2 PROTOTYPES FORM THE USERS STORIES ABOVE
1 of the prototypes present a description of the iterative development that takes place. Show the time-box planning or sprint planning for the development of this prototype. Show some changes to prototypes as a result of user feedback. Include filled in change request form. Also show the final prototype after the changes.
SRAM OR DSDM
DESCIBE THE FLOW RELATED TO THE CASE STUDY
ONE EXAMPLE YOU TAKER ONE PROTOTYPE LIKE LOGIN AND IT SHOWS USER AND IT SHOWS I WANT TO CHANGE THIS, THIS AND THAT… BUT DON’T USE THIS EXAMPLE. IT MUST BE MADE DIGITALLY. This is the interaction inside one sprint…
- A first cut class diagram(showing only the class names and attributes and relationships that will form the basis of the database for the information system that will be developed.
Each class need Name attribute and relationship. A little explanation of how and why you made like this the class diagram.
- Quality of the Assignment report structure, clarity, and format [8 marks]
END of Coursework 2 Brief
Feedback (including details of how and where feedback will be provided)
Students will be provided formative feedback on their initial plans for the assignment during the class near the end of the week. Students will be provided final summative feedback, whichwill be provided via Canvas in the form of a written feedback do