 Today, we'll talk about developing and maintaining custom applications, as well as using custom applications that have been developed by someone else in your DHS2 implementation. At the end of this session, you should be able to list the topics to evaluate when developing or using a custom application, you should be able to discuss the trade-offs and risks associated with custom app development or adoption, and you should be able to model the costs and resources required to customize DHS2 for a particular use case. Let's get started. First, we'll talk about the phases of application development. When developing a custom application for DHS2, there are several steps that you need to take. First, it's important to design and then develop in an iterative process the application that will address the needs for your particular DHS2 implementation. This involves requirement gathering, prototyping, and then development and evaluation. And because this is an iterative process, you'll go through each of these steps multiple times. After completing development of an application, it's important to take into account the maintenance and ongoing compatibility requirements for that application's lifecycle after the initial development has been completed. Throughout this process and especially when planning for the development of a new application, it's important to ensure that there is adequate funding and time allocated for the design activities to help produce an application that is relevant and usable for the local needs of your DHS2 implementation. It's also critical to include local users in the design and development process rather than designing, assuming that you know what they need or what they want. This is important because it allows the design of the application to be appropriate for the context and suitable for the needs of actual users in the field. The first stage of development of an application is requirements gathering. The aim of requirements gathering is to develop a set of concrete requirements for the application and to specify what those requirements are and how they should be implemented in the development of the application. This can be done through interviews, field observation, participatory engagement with users in context, and many other mechanisms for getting feedback from users on what they actually need or how they are going to go about using this application to accomplish their tasks. It's important not only to focus on technical requirements, but also how the application and the DHS2 use case will fit into the work practices, challenges, and needs of the end user. This entire process will help to select and design useful features to include in your application and is in a critical part of the entire development process. Requirements gathering often involves multiple cycles of gathering insight, analyzing it, and formalizing it as concrete specifications and mockups. This process is often carried out by HISP groups, both implementers and developers, and can involve input from the DHS2 core team at UIO as well. The next phase of application development is prototyping. The aim of prototyping is to explore the various dimensions of the app, such as its general concept, concrete features, and user interfaces with relevant stakeholders. End users are frequently a key stakeholder group in app design, but they're not always the only one. There might be other stakeholders as well. When prototyping, a prototype will evolve over time. First, these prototypes might take the form of paper mockups, which serve as an efficient and effective way of evaluating early ideas. After evaluating the ideas on paper, a digital mockup, which requires a bit more time to develop, can be helpful to evaluate and plan for efficient user interaction. Finally, once a working app has been developed, this is also an opportunity to get feedback from users. It becomes an evolutionary prototype, which is interactively evaluated and refined over time. The planned prototyping stages should be based on what is to be evaluated with stakeholders. This is important because prototyping takes time and needs to have an associated budget. The next phase of development of a DHS2 application is development and evaluation. The aim of this phase is to create an application based on the requirements and prototypes we completed in the previous phases. Development may be organized through various software development methodologies, one of which is the agile development framework. In agile, development is completed in short sprints and the result of that development cycle is quickly analyzed and the next iterative process takes place afterwards. There are other development methodologies you can explore as well. It's important to have a clearly established process for managing app development. This ensures that the scope of the project won't change underway without approval and involves reviewing the potential budgetary implications of any changes to requirement or changes to the estimated level of effort to complete the application development. Testing of the application involves both usability testing, which is similar to what we saw in the prototype process previously, and evaluation of the app against the requirements we gathered in the first phase. Finally, security and performance reviews are recommended for any application that's developed in DHS2. Once an application has been developed, the project is not yet complete. A project rarely ends when the first version of the app is developed and deployed. This is because new requirements may be introduced, bugs or security issues may be discovered, and in most applications there are several bugs in any production deployment. New problems may arise that the app is expected to address, and other changes to standards or practices may influence what the application is expected to perform. Finally, regular maintenance is required to maintain functionality when the DHS2 server version is updated. An important way to ensure the longevity of a DHS2 application is to define and clearly communicate who is the long-term owner of that application. This owner will address the needs that we mentioned on the previous slide as they arise. There will often be ongoing maintenance costs which should be planned and budgeted for early in the process, and these may change over time and need adjustments to those budgets and time estimates. Next we will discuss the considerations which should be taken into account when developing applications. The first consideration is non-recurring engineering level of effort and cost. This is the cost and the time it must take to develop an application from scratch. The developing organization, which oftentimes involves professional software engineers, can provide an estimate based on the scope and initial requirements. However, this estimate may change depending on the final requirements established during the course of the process. The second consideration is around maintenance, resourcing and costs. Budgeting for post-deployment development to support users, to fix bugs and to iteratively improve the application is critical. It is also important to consider the infrastructure needs which might be server resources or cloud computing resources the development and use of the application may require. The budget for these services must be planned for as well. The DHS2 software is continuously updated and new versions are often available. The implementation that is running your application may upgrade the version of DHS2 and this is highly recommended by the core team. In the long-term maintenance plan for developing a DHS2 application it's important to ensure that there is budget for application updates to support new versions of DHS2 at least approximately once per year to support these new versions. It's also important to ensure that there are issue tracking and roadmap management processes in place so that users of the application and stakeholders can provide feedback, report bugs and have their voices heard in planning for future features and functionality within the application. It can be tempting to develop new applications to address new needs. However, this is not the only solution to most problems. It's important to keep in mind that there are limited resources available to work on DHS2 application development in a particular context and that the development of an application needs to fit in with the long-term plans of other needs within that context. It's worth considering whether a sufficient degree of the desired functionality can be provided using existing DHS tools or other existing DHS2 applications. Next we'll discuss the considerations which should be taken into account when using applications that have been developed by others. DHS2 applications are available for download and install from the DHS2 app hub. These are developed by other organizations such as HISP groups and non-governmental organizations in the larger DHS2 community and these go through a vetting process before they are made freely available to download and install into a particular DHS2 instance. It's also possible to reach out to the DHS2 community to see what has already been developed and implemented. In many cases, someone else in the community has already developed a solution which might meet some or all of the needs of your implementation. It's advantageous to make use of these existing applications or to collaborate on their development in order to avoid duplication of effort. There are several important considerations to take into account when installing applications that have been developed by another organization. The first is software supply chain risk. This refers to the risk involved in using software that you do not fully control or have not developed yourself. And it also applies to the dependencies of that application which might be developed by yet another organization. When installing a DHS2 application into a DHS2 instance, it's important to do some review of the source code and dependencies of the application that you are installing and to ensure that you trust the developer of that application. The second important consideration is the responsiveness and liability of the application developer. If the app is from a trusted member of the DHS2 community, oftentimes there is a mechanism by which you can communicate and discuss the ongoing needs of your DHS2 implementation with that developer. It's also important to ensure that you can influence the further design of the app if you need to. Developers of DHS2 applications often have their own priorities and it's important to ensure that your priorities align with those of the organization developing that application or that you have some way to influence the further design of that app. It's also important to consider who is responsible for maintaining the app, including compatibility with newer DHS2 versions. It's important to ask whether ongoing development has already been funded or if there is an opportunity for you to financially support the developers maintaining the application. Remember that the ongoing development of DHS2 applications is not free. Finally, it's important to consider the compatibility of the application with your particular DHS2 instance and the metadata configuration that has been set up in your DHS2 instance. In conclusion, development of custom applications in DHS2 can involve adding budget lines for things such as requirement gathering and prototyping as well as development of the application, pilot testing and review of the application in real-world contexts. And finally, post-deployment adjustments and evaluation of the application once it has been fully developed. There are other costs which might be recurring and need to be planned for. This includes ongoing maintenance of the application, bug fixing, version updates, and support for future versions of DHS2. In summary, there are many different considerations which are involved when developing custom apps or using existing custom apps which have been developed by someone else to extend DHS2. When developing a custom application yourself, it's important to plan for an iterative design and development process to implement project management and cost controls to plan for ongoing maintenance of that application and to establish clear, long-term ownership. Similarly, when evaluating an existing DHS2 application to be used in your DHS2 implementation, it's important to consider the supply chain risk, developer reliability and responsiveness, and updates and future compatibility for that DHS2 application.