Agile Development Techniques For Disaster Relief Coordination System

Critical Explanation

The DSDM or Dynamic Systems Development Method is a part of the agile approach. Like every agile approach, the DSDM method also has its own unique features and advantages. The proposed system is a disaster management system that can make sure that each people affected by the disaster can get proper assistance from humanitarian and government agencies. The main purpose of the system will be able to establish a better communication among the relief efforts. From the brief description of the system it can be stated that it will be a very complex one and needs to be accessible all the time. The scale of the system is very high and requirements of the system will not be clear from the beginning of the project. Thus, it is suitable to use an agile approach to meet the project perquisites. The agile approach allows the system analyst to communicate with the users and also collect business requirements throughout the system development process. This way the missed requirements can be inserted into the project of Disaster Relief Coordination System very easily at any stage. Moreover, the users and developers of Dynamic Systems Development Method will find the methodology very easy to use and make changes in the project output.

The main principle of the DSDM is involvement of the users actively. Disaster management is a very critical process which often has unconventional ways to approach a situation. Thus getting the insights of the user activities in a disaster management system from various best practices and government documents is not an accurate approach. Through communicating with the persons who actively work in the after disaster situations, the system analysis can properly acquire the required information for meeting the user requirements. Meeting the user requirements is a very important act in the disaster management systems. Through working closely with the users, the system analyst can easily define the functions of the Disaster Relief Coordination System that supports what the user needs. The user requirements allow the system analyst to capture the reality of the situations in which the system will operate. The project is undertaken by the government. The government employees may not be able to provide the support or time which the system needs. For this reason, the project team must be able to make decisions during the project development. In one side, the DSDM method focuses on meeting the user requirements Then on the other side, it makes sure that all the business are fulfilled. No matter how much user centric the system is, the government and humanitarian organizations must have proper control and monitoring empowerment  on the activists and processes done to manage the after disaster situation.

The Dynamic Systems Development Method is a five phase SDLC model. The first phase is the feasibility analysis. The team will define the problem and provide various technical solutions to counter that problem. Those solution will go through technical feasibility analysis for verifying the desired application. This phase makes sure the solution is fool proof and capable of meeting the requirements. The system will be web based one which can also be used in mobile phones. This means that website must be responsive. The RAD or Rapid Action Development model will be suitable for the creation of the responsive website. The next phase is the business study. In this phase, the system analyst will review the processes of overall business, in this case coordination of disaster management actions, for the proposed system. The system analyst will create the fundamental architecture framework of the proposed disaster management system which will serve as the basic idea behind the whole system design.

The Dynamic Systems Development Method

The website will be created based on incremental implementation. Therefore, the DSDM allows a highly maintainable rapid action development approach to the project team. The complex and big system of Disaster Relief Coordination will be efficiently developed through the RAD approach and all the parts of the requirements can be met during development. The project team will develop standards regarding the quality control activities. This standards will be followed throughout the development process. This way the DSDM approach will be a very suitable approach for developing and guiding the system. There are two iterative approaches in the DSDM method. The functional model iteration is focused on developing the prototypes of the system iteratively and obtaining the reviews from the users. As discussed above, the proposed system will be a very complex and big one. The requirements of the system cannot be identified in one attempt. The prototyping will allow the project team to eliminate the misunderstanding regarding requirements and gather new ones. The prototypes are easy to develop and cost effective solution. Using the prototype approach for gathering requirements can significantly reduce the cost of the project. The disaster coordination system will be used in highly severe situations and it must operate properly all the times. For this reason, the gathering of requirements is extremely important for the project. The prototyping enhances the quality of the gathered requirements and increases the possibility of highly effective final project outcome.

The design and build iteration on the other hand, is used for verifying that developed prototypes are accurately engineered and also satisfactory. In order to make the system requirements more clear and accurate, the prototypes will be refined in this phase.

1. The biggest advantage of the DSDM approach for the undertaken Disaster Relief Coordination System project is the time and budget efficient solution. The project team will easily reduce the cost of the project and fit it into the budget.  Maintaining the timeline of the project activities is also easy for this method.
2. The complex projects must be done through simple and easy to understand methods. It is because, the project has many challenges and issues which are very hard to overcome. At this point, maintaining the criteria and constraints of development methodology can be a very critical effort. As the DSDM approach can be easily used by the project team as well as quickly accessed by the potential users, the approach can be a very suitable solution.
3. Developing the basic functions is a very important part of complex projects. If the basic functions are identified then other related requirements can be easily identified. The Dynamic Systems Development Methodology allows the project team to identify and model the fundamental requirements. These functions can be easily verified through the prototyping approach. The refinement of the functions are easily done in the DSDM approach and that is why it is a big advantage of this methodology.
4. Including the end users are always a big factor in the big projects. The system will be operating closely with the activists and other stakeholders like NGOs, Government agencies and more. In this situation, understanding the user needs is a great perquisites of the project. The DSDM allows the team to include users into the project.

1. In case, the government wants the project to be developed one time, then the DSDM is not a good solution. DSDM does not suit the small budget projects.
2. The DSDM is a comparatively new methodology, this means that very few experts are available today who have proper knowledge about this methodology. If the project team is not skilled enough the project will surely fail.
3. The DSDM methodology requires continuous user involvement in the project. This can be severe some times as the users do not have proper technical knowledge. By assuming any technical aspect that they do not understand while providing feedback, they can corrupt the feedback information.
4. The DSDM cannot be completed without skilled people in both the business and technical areas. It is not possible to make up the faults other teams can make. Each people must contribute their hundred percent with integrity. This can be a real issue for big projects as people can leave a project in the middle or miscommunication can occur among team members and users.
5. The project team may focus on the RAD approach so extensively that codes of the product loose its robustness

Lazarus Island Government: Lazarus Island Government is the owner of this project. The government will provide the capital for the development of this project. The government will look into the big picture of the project and that is if the output of the project is successfully attained or not. The owner of the disaster coordination system development project will be all in all. The owner can call to pull off the project any time they want. The project manager will be responsible for providing the reports of project progress to the owner. The main role of the owner will be providing support to the project at all times.

Government Agency Administrator: The government agency administrator will have the full control over the system. They can add, remove or modify the user’s account of the system. The administrator can add donors and manually change various things. If a donor is not able to send money through online, the administrator can add the donation details in the system manually. They can adjust various things in the system like change of minimum donations, change resource allocation protocols and many more. The government agency administrators can monitor any activity in the system. The system will develop reports for the coordination messages and resource allocation. The government administrator will allocate resources to the NGOs. They also responsible for approving the situations that are being informed by the NGOs.

Strengths of DSDM

NGO Administrator: The non-government organization administrator will be the primary communication between the NGOs and the government. They will also coordinate the messages and other communication information between those two stakeholders. The NGO administrators identify and often update the base camps of the NGOs. They are also responsible for updating the list and profiles of the NGO worker. As the worker are directly employed by the NGOs, they have all the information of each worker. The NGO allocate the workers on different situations and those information are properly updated within the system. The NGO administrators build various teams who are deployed in different locations for dealing with the situations. The administrators can create various resource hubs that can be used at the time of disaster. They can also submit a request to the system for teams.

NGO Worker: Only this stakeholder work in the field to provide relief work to the needed people. They are responsible for keeping their profile up-to-date while working on the field to make sure that their proper contact information and expertise are showed in the system. They can frequently check their profiles and if any issue occurs then contact the NGO administrator. They must update their location properly so that NGO administrator can locate them. They can request for resources to use in various situation but they need to submit a proper reason for the request. Configurations for resource packages can also be provided with the request. They also can declare various situations that are not set up by the Aegis or Disaster Coordination System.

Donor: The donors are a very crucial stakeholder of the system. They will provide various help to the NGOs that will be directly used for the situations. The donor will send money through the website portal. They can also send resources like food and other materials to the NGOs.

Executive Sponsor: The executive officer is also known as the project champion. The project champion is a person from the user organization. They have the authority for allowing funds to the project. They can also commit resources to the project. They are empowered with the ultimate power over the project.

Visionary: This person will verify the essential project requirements and allow the project team to initialize the project. They have the most accurate idea of the system objectives and business objectives. They also supervise the whole project. The visionary guide the project from the beginning to the end.

Ambassador user: They are also part of the client organization and responsible for bringing the user community knowledge to the project. They make sure that the development team receives the user feedbacks properly and in time. They are active only during the development process.

Advisor user: The advisor user is the end user of the system with some viewpoints to share with the project team. They can share their working experiences and requirements from the system.

Project Manager: One of the most important human resource of any project is the project manager. The project manager remains at the highest post of project team and responsibly control the project processes and outcome. The project manager also works as the communication medium between the project team and organization stakeholders.

Limitations of DSDM

System Analyst or Scribe: The system analyst is responsible for collecting data of business and user requirements and converting them into system requirements.

Team Leader: Makes sure that each of the persons, involved in the team are working for meeting the project objectives. They guide and control specific activities of the project.

Development Team: The developers are responsible for doing the actual codes and create a working solution.

Tester: The testing team is responsible for verifying system’s technical and operational feasibility.

The first reason for using the MoSCoW technique for prioritizing business process requirements is its ability to prioritize and rank the items. This results into obtaining a successful final product. Along with this, the MoSCoW method completely based on the opinion of the experts of the project team. The MoSCoW rules are defined such way that it permits the minimum usable subset delivery regarding guaranteed requirements. The potential users of the system and development team together confidently ensure delivery of must have requirements of Aegis system. They can ensure to prioritize every business process requirements of all the four subsystems.

The MoSCoW technique is very simple to use and easy to complete. The requirements of the Aegis system and its subsystem can be categorized into four categories like must have, should have, could have and won’t have.

The biggest advantage of the MoSCoW method is creating definitions of the priorities during the development process. First of all, the Aegis system requirements will be listed. Then votes will be collected for categorizing each requirement into different categories of MoSCoW. In order to allow the project team to use the findings of the MoSCoW method, a written document will be created.

The use case shows that the NGO worker will interact with the system to update their locations. The NGO Admin will identify the worker updated location and also update the base camp location of his/her NGO. The government administrator will identify the location of the system through the system’s mapping API.

The use case above shows that the NGO worker can ask for resources and also configure the resource packages as per the situation. The configure package extends the resource request as the configuration is not always done. The NGO admin can allocate resources to the situations directly. They can also see the requests submitted by the workers. The Government Agency Administrator is responsible for allocating resources to the NGOs, see reports on resource allocation and also create packages of resources.

The above use case diagram shows that the NGO worker will update the details of the profile so that NGO admin and Government Agency Administrator can track their profiles properly. The NGO Admin will use the profile to create the team.

The above use case diagram shows that the NGO worker submit a form for raising the request. The user must login to raise the situation. The government agency administrator will identify the newly raised situation. After verification result is positive, the administrator will confirm the situation. Then the NGO admin will send teams to the situations.

Must Have	Should Have	Could Have	Would Not Have
Make Donation	Allocate Resource to NGO	Update current location	Any loophole in the system that can be exploited
Identify Situation	Identify Main Base Camp	Mobile applications for faster data access and more reliability	Admin access to any person
Approve Situation	Request Resource Package	Suggest Resource Package Configuration	Any malicious software in the admin computers
Find Worker Profile and Last Known Location	Update work list
Build and Identify Teams
See Situations Approved by Govt. Admin
Request Resource
Allocate Resource to Team
Update profile

Stakeholder Description and Roles

Req. No.	Req. Name	User	Priority	Estimate (Days)
1	Make Donation	Donor	High	2
2	Identify Situation	Government Admin	High	3
3	Approve Situation	Government Admin	High	1
4	Allocate Resource to NGO	Government Admin	Medium	2
5	Identify Main Base Camp	NGO Admin	Medium	1
6	Update work list	NGO Admin	Medium	2
7	Find Worker Profile and Last Known Location	NGO Admin	High	3
8	Build and Identify Teams	NGO Admin	High	4
9	See Situations Approved by Govt. Admin	NGO Admin	High	1
10	Request Resource	NGO Admin	High	1
11	Allocate Resource to Team	NGO Admin	High	1
12	Update profile	NGO Worker	High	2
13	Update current location	NGO Worker	Low	3
14	Request Resource Package	NGO Worker	Medium	2
15	Suggest Resource Package Configuration	NGO Worker	Low	1

User Story 1: As a Government Agency Administrator, I want to full access over the details of any NGO so that I can properly monitor their activities and resource allocation status to prevent misuse of resources.

Acceptance Criteria: The system will allow only the Government Agency Administrator to access which NGO has which resources in different locations. It will generate a report based on the resources distributed by the NGO and Government to specific situation.

User Story 2: As a NGO worker, I want to update my locations and the profile data such as expertise as soon as I move from one location to another so that I can keep my location and profile data updated to inform the NGO in which area I am in right now.

Acceptance Criteria: The system will include well known mapping API that can support any geographical location no matter how small the area is. The users can easily enter a location and then manually shift the pint to update exact location.

User Story 2: As a NGO Admin I want to create teams so that can send to various situations identified the government and raised by others.

Acceptance Criteria: The system must share the situation results with the NGOs. The NGO Administrator must have access to profiles of workers and their updated locations. Based on the nearby worker list and their expertise, the admin team would get a suggestion of team which can be modified. The team will get notification upon receiving a request to go to the location where situation occurs.

User Story: As a NGO worker, I want to raise a situation so that I can notify the Government about the situation and they send police, ambulance and other people to confirm the situation.

Acceptance Criteria: The system will ask the worker to input the location of the situation and its type. After these two are done, the system will ask for what kind of requirements are needed to handle the situations. All these information are then sent to the Government Agency Administrator who will confirm the situation and ask NGOs to response.

The prototype is designed for the situation raising user story. In this case, the user can use the desktop or mobile for submitting the situation details. However, as the mobile is frequently used by the people and more suitable to carry, the mobile website has been drawn. The prototype shows that the website detects which NGO worker is submitting the form simply by using the login credentials. The website then asks the worker to enter the address of the situation. The worker will also enter the type of situation, how many people would require, when it happened, which resources can be required and many more. The form has one submit and one reset button. The submit button is for submitting the request and reset is for making the form blank again. The prototype has very simple colour combination which is very useful in this situation. The worker can also mention the name of the persons who are presently at the location with him/her. They will see a small button in the top right corner of the form to see the base camps of the nearby NGOs. This feature is installed to make sure that they can collect needful resources that can help them control the situation until the systematic process of sending resources and workers is not completed. However, they have to confirm to which NGO they are going so that system have all the information.

It is crucial to have the profiles and locations of the NGO workers. The workers are preferred to use the mobile devices to access the website. The website is designed such a way that it can provide better experience to the workers for using mobile devices. It is because, in case of situations, the users are intended to use the mobile devices which are less time consuming and handier. The NGO worker will update their profiles like name, other personal details, in which area they have served, their expertise and many more. They will submit the details and it will be updated in the system in a second. The admins of the system will only see the updated values of a worker’s profile and location.

The selected prototype is the situation raising process. The iterative model means that the system will be divided into various requirements. The system analyst will find these requirements one by one and the other teams will work on one requirement at one time. The first requirement of this prototype will be login. In order raise a situation, the worker must login to the system. It is because, that any false situation can be avoided. Then the design team will start working on designing the login form, the database team will design the database that can hold login credentials. After the design is complete, the developers will build a prototype that can be used by the users. The users will test the form and submit feedback. Based on the feedback the form will be changed. After everything is perfectly done, the implementation of the prototype will begin.

Simultaneously, while this requirement is in the design phase, the system analyst will find new requirement named submit situation raise form. The design team will design the form and similar database will be designed. The development team will development the prototype. Testing will be then done and based on the gathered feedback, the final prototype will be developed. Based on the final prototype, the final implementation will be done. In the second requirement, the NGO workers can ask for showing nearby based camps of other NGOs so that they can contact them and manually ask for minimum resources. This way the whole situation raising process of the Situation Management System will be implemented through iterative approach.

The iterative model will allow the team of project to develop various requirements while the project is on-going. The project manager can easily measure the progress of the project. The best benefit they can get from the iterative model is the simultaneous development plan. The risks can be identified and mitigated during the iteration which saves a lot of time of the project team. The risk is highly associated with the project and the team will be very pleased to use the iterative approach as it allows very effective risk analysis.

Time box	Nature of the Work Done	Suggested time scale
Kick-off	The login form which will allow the NGO worker to login to the website	2 days
Investigation	The team will develop a form that will create a list of input fields which is accepted and verified while login is done A database that can hold the login credentials of each of the NGO worker individually If the login form can accept the unique identifier of the NGO worker and a password which is associated with the login id	50% of time box
Refinement	The user will ask for the reset button to blank out the fields The user can also ask for a remember me check box which can allow the system to remember the login credentials and automatically login	25% of time box
Consolidation	The testing team will conduct the testing process and protocols on the system. The user feedback will be gathered to get a proper idea of what should be done	10-15% of time box
Close Out	Start a session of user unique identifier to store every action taken by the user	2 to 3 hours

Time box	Nature of the Work Done	Suggested time scale
Kick-off	The situation raising form. This form will allow the NGO workers to raise a situation by providing all the details of the situation along with its location and resources required	4 days
Investigation	The form will consist of various information such as the situation type, location in where the situation has occurred and many other things A database is essential for storing the details of the situation. The database will also store the status of the situation like whether it is confirmed by the government or not. The system can be able to identify each situation individually along with the worker who has raised it. The system can suggest various things that are based on the situation type	50% of time box
Refinement	The user will ask for a near NGO base camp location so that they can contact they directly The NGO administrator can check whether the situation raiser is from their NGO or not	10-25% of time box
Consolidation	The testing team will conduct the testing process and protocols on the system. The user feedback will be gathered to get a proper idea of what should be done	10-25% of time box
Close Out	Start the situation alert so that government administrator can see the situation raise as soon as it is submitted to the system	2 to 3 hours

Users	Change request	Status
NGO Worker	Adding a reset button so that they can reset the entered data and correctly put the data again	Done
NGO Worker	Adding a ‘remember me’ check box so that they do not have to login to the website. This button only works when it is clicked	Done
NGO Worker	Nearby NGO base camp location. So that they can manually reach there and collect emergency resources	Done

As the diagram shows, there are six classes. These classes only have the attributes, not the operations. The relationship among the classes has been properly shown. As the situations are controlled by various workers directly this class has direct association with the situation. The NGOs are consist of the workers and NGO admin so that there is a composition relation among NGO and NGO worker and admin. Every class has an attribute that can be used for uniquely identifying the set of data for each row. As the class diagram is designed as a reference of the database for the proposed Aegis system, it has all the feasible data that is required for operating the system.

Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J., 2017. Agile software development methods: Review and analysis. arXiv preprint arXiv:1709.08439.

Alam, S., Nazir, S., Asim, S. and Amr, D., 2017. Impact and Challenges of Requirement Engineering in Agile Methodologies: A Systematic Review. Int. J. Adv. Comput. Sci. Appl, 8(4).

Al-Saleem, S.M. and Ullah, H., 2015. A comparative analysis and evaluation of different agile software development methodologies. International Journal of Computer Science and Network Security (IJCSNS), 15(7), p.39.

Anwer, F., Aftab, S., Waheed, U. and Muhammad, S.S., 2017. Agile Software Development Models TDD, FDD, DSDM, and Crystal Methods: A Survey. International Journal of Multidisciplinary Sciences and Engineering, 8(2), pp.1-10.

Awan, R., Muhammad, S.S., Fahiem, M.A. and Awan, S., 2016. A Hybrid Software Architecture Evaluation Method for Dynamic System Development Method. The Nucleus, 53(3), pp.180-187.

Chowdhury, A.Z.M., Bhowmik, A., Hasan, H. and Rahim, M.S., 2018. Analysis of the Veracities of Industry Used Software Development Life Cycle Methodologies. arXiv preprint arXiv:1805.08631.

El Hameed, T.A., Latif, M.A.E. and Kholief, S., 2016. Identify and Classify Critical Success Factor of Agile Software Development Methodology Using Mind Map. Int. J. Adv. Comput. Sci. Appl, 7(5).

Fahad, M., Qadri, S., Ullah, S., Husnain, M., Qaiser, R., Ahmed, S., Qureshi, W.A. and Muhammad, S.S., 2017. A Comparative Analysis of DXPRUM and DSDM. IJCSNS, 17(5), p.259.

Faitelson, D. and Tyszberowicz, S., 2017, May. UML Diagram Refinement (focusing on class-and use case diagrams). In Proceedings of the 39th International Conference on Software Engineering (pp. 735-745). IEEE Press.

Margini, A., Cutrona, G. and Fantuzzi, C., 2017. COMPARISON OF DIFFERENT AGILE METHODOLOGIES AND FIT ASSESSMENT IN AN INDUSTRIAL CONTEXT. INTERNATIONAL JOURNAL OF ADVANCED RESEARCH, 5(7), pp.673-690.

Matharu, G.S., Mishra, A., Singh, H. and Upadhyay, P., 2015. Empirical study of agile software development methodologies: A comparative analysis. ACM SIGSOFT Software Engineering Notes, 40(1), pp.1-6.

Rasnacis, A. and Berzisa, S., 2017. Method for adaptation and implementation of Agile project management methodology. Procedia Computer Science, 104, pp.43-50.

Rhazali, Y., Hadi, Y. and Mouloudi, A., 2014. Transformation method CIM to PIM: from business processes models defined in BPMN to use case and class models defined in UML. International Journal of Computer, Electrical, Automation, Control and Information Engineering, 8(8), pp.1453-1457.

Rojas, L.A. and Macías, J.A., 2015, September. An Agile Information-Architecture-Driven Approach for the Development of User-Centered Interactive Software. In Proceedings of the XVI International Conference on Human Computer Interaction (p. 50). ACM.

Rumbaugh, J., Booch, G. and Jacobson, I., 2017. The unified modeling language reference manual. Addison Wesley.

Silva, F.S., Soares, F.S.F., Peres, A.L., de Azevedo, I.M., Vasconcelos, A.P.L., Kamei, F.K. and de Lemos Meira, S.R., 2015. Using CMMI together with agile software development: A systematic review. Information and Software Technology, 58, pp.20-43.

Turk, D., France, R. and Rumpe, B., 2014. Limitations of agile software processes. arXiv preprint arXiv:1409.6600.

Uikey, N. and Suman, U., 2016. Tailoring for agile methodologies: a framework for sustaining quality and productivity. International Journal of Business Information Systems, 23(4), pp.432-455.

Zafar, I., Nazir, A.K. and Abbas, M., 2018. The Impact of Agile Methodology (DSDM) on Software Project Management.