 Good evening to you all. My name is Elisha Pitzenga from Zimbabwe, Africa. As you can see, I'm ready to present my presentation on how to develop open source business applications. That's my presentation, a second one after the France one in 2019 or as is. Then this is the tweet from the Lennard Foundation promoting my talk. As you can see, in this talk, we are going to learn how to develop open source business applications. From me, I'm also available on Twitter, as you can see. Then from my presentation, you're going to learn how the African societies all about, African cultures all about, especially in beer brewing events. Open source in Africa has been there for a long time. As we have experienced through my, I've lived in raw areas where there was this beer brewing ceremony. In which each and everyone, all age groups and gender, they could come together and begin to do something like beer brewing. Everyone will be there and everyone will be assisting, like the boys will be cutting fire with the women, we'll be fetching some water and preparing the beer. Here is the process it goes like. So simple. Firstly, they soak the rapok or maize for several days in water moisture and they let it drain the moisture, drain the water and after that they let it begin to sprout. After that, they spread the ingredient mixture in the sun as you can see from the slide. After that, they ground it into a meal. Then they add some cold water while boiling and repeating the process. They repeat the process then, then, then after that, which means after seven days, the traditional beer would be ready. As we are here in open source North America summit, this is the way we used to do it in Africa and also that the way we do it in application development and how you are going to learn, how you are going to learn the open source application development is how we prepare our traditional BIA in Africa. Then we move on to the modern world. As you are seeing from the slide, business applications, they started early in the late 80s where there's CAD-CAM software, pioneered by the Hewlett-Pecad and IBM. And that one, we have some challenges with it. As you can see, we have so many people working around, facilitating the business to move forward but to solve that, they come up with the software, business software in order to reduce the labor but it was expensive. Then they were dramatically shifting in the development of business software, where the business software which was developed, especially software like Microsoft Excel, Lotus 123 and that one, it leads to the early 90s where there's a massive shift in supply in software development, which is the globalism. In the 1990s, when we see the SAP software being pioneered during the process and that one was mainly used in supply chain vendors, for example, then move on to the current where we are. Currently, where we are in the robotic process automation period, where we see some of the tasks which we need to, which has been repetitively done but we need to afford some errors when doing business. That's when we move on to the robotic process automation period, in order to improve efficiency, reduce cost as well as human error. Then as we move forward, as we move forward, as we move forward, in this presentation, we are going to learn software development methodologies. We are now in the main presentation. Thank you for joining me as we move on software development methodology. This track that organizations use to plan and control development of information systems and new web business applications. We are all in our organizations. We need some applications, but we need to plan for it in order to develop our software and business application. Just because we are in the era of fast increasing in system complexity, we need to implement new systems in order to be competitive in the market. Open source practitioners in software development have to adopt this way so that the organization can strive for it. Then we go on to the business application development life cycle. This business application development life cycle we can call BED. It's BED Life, as you can see. It is a life cycle where each phase is an incremental step that lays foundation for the next one to ensure effective management and control in business applications. As you can see from that, we deploy an application. We do some maintenance. We retire that application. And that process keeps on repeating itself as you are seeing from this slide. But the next software we are going to make after following this process, which I'm going to take you through, is the better version of the previous one. So we move on to the categories in which business applications are being made. Firstly, we have organization-centric business applications and user-centric business applications. Firstly, I'm going to talk about the organization-centric business application. Its objective is to facilitate business on a need-to-know basis. As you know, in organizing, we have so several departments in which each and every department has got its own work. Like here, we collect some information. We collect it and restore it. We archive it and we share it to the users, customers, vendors. That's what organization-centric business applications is to do. Then we go on to the business software methodology. We are continuing the software development methodology. As you are seeing, we use the sales data so that they will be available to accounts, admin, and the government agencies or levy payments. And also, business applications are essential, mainly into the regulatory area, especially in the levy fulfillment and in-text compliance, which is addressed by those organization-centric applications. Organization-centric application projects usually use STRC methods, which is a more detailed software engineering approach. More detailed to mean it is well-defined and it is clearly stated. Each and every one understands it. That's all it is about, the organization-centric application. Then we move on to the second one, which is user-centric business application. User-centric business applications mainly provide an objective or provide a different view of data. We have our applications, but we need that data to be presented in a presentable way. For example, we have the C&S support system or geographic information system, which we use. They use a centric post. They need to provide a different view of data for performance optimization. This user-centric application, they use alternative development approaches. While the organization-centric, they use the more defined or traditional software development methodologies. Then we move on to how do we come up with those business-centric applications? We need to have some key drivers. What is happening? What is going on? A business application is developed, a project usually generally initiated as a result of the following. Firstly, we have a new opportunity that relates to new or existing business practices. What is a new opportunity? Here in Africa, the opportunities are limitless. There are so many opportunities, but with the use of a business application, we can formulate a new application, a new business application. Secondly, we have an opportunity for an organization to take advantage of technology. Like here, we are in the time of COVID-19. For some business, it's an opportunity. For some, it's a loss. That's business. That's all about it. But we need some applications to know that facilitate us forward. Thirdly, we have alignment of business applications with business partners or industry standards. If we are in the industry, which is highly regulated like the health industry or the financial industry, there are some standards which need to be followed. There are some standards and some practices which require us to be guided. So that one is one of the key drivers that can lead us to business application development. Then fourthly, we have the problem that relates to existing business processes. The existing business processes we are doing, we are having some problems in and out. We might encounter that by developing a new business application. Then we move on to a problem with current technology. We might have a problem with current technology. That might be a key business driver, a game changer. Then we go on to the next slide, which we are going to talk about these attributes of business functions. What are the attributes of business functions? Like here in open source projects, objectives have to be translated. That's some of the attributes which we use to achieve the behavior and implementation of business functions, to achieve the strategic goals. That's all critical in open source objectives. Those key business drivers have to be translated to all parts involving business operations so that everyone will understand we can move on with the projects we are doing. Then we go on to what those objectives have to be learned. They need to be smart so that they can be expressed in a scorecard form which allows the objectives to be collected in order to measure the business value of an application and prioritize requirements. The key benefit of this approach is that a common and clear understanding of business objectives and how they contribute to business functions. Additional conflicting key business drivers such as the cost and functionality and mutually dependent key business drivers have to be detected and resolved early in the stages of project development so that we only have hiccups during the way. Then we move on. How do we communicate those business needs to management or to the stakeholders in the business? Firstly, we need to identify a problem. What is the problem we are facing? What is the problem we encountered? We need to identify a need or a problem in order for our applications to be successful in our business. What are the needs we need to address? What is the problem we need to tackle? From there, we need to specify a decided solution. What is the solution we can talk about? We can work around this problem we have identified with. Currently, we have COVID. Here in Africa, we have some communicable diseases like malaria. It is a problem. But what is the solution? We need to specify a decided solution to that problem. And after that, we let potential benefits to the organization. After identifying the need, we identify the solution, we let the potential benefits to the organization. What is that problem? How are we going to fit it into our organization structure so that we can come up with an application we can develop an application that will be successful in the market. Or the internal and external factors affected by the problem should be identified. We need to identify the internal and external factors in order for our applications to be successful. Then we move on to the software development models. We have the traditional water format, we have the fish-shaped model with iterative model. So I am going to talk about them one by one. Firstly, we have the traditional STRC model. STRC stands for software development lifecycle. As you can see, software development lifecycle, we start to analyze the situation. We design an application, we implement it, we test it, we deploy it, we do some maintenance. So it is a cycle which goes around, goes around like that. This model normally falls the lifecycle verification approach that ensures potential mistakes are corrected early and solely during the final acceptance testing. Then there is the orders and widely used in developing applications. It works when the project's requirements are stable and well defined. As you can see, it facilitates the determination of a system architecture relatively in the development effort. It is based on a systematic and sequential approach to software development. And the primary advantage to this is it provides a template into which methods requirements can be placed. As you can see. Then we go on to the shortfalls of this approach. Shortfalls of this approach, we have some problems with it. And anticipated events can be in iterations, creating problems, difficult in obtaining explicit set of requirements, managing requirements and convincing the user about undue or added requirements. The necessity of customer patience, which requires the approach, this working version of the systems program and also changing business environment can alter the requirements that are going to be delivered. Then we go on to the second one. The second one is iterative model. This one is a cyclical process in which business requirements are developed, tested in iterations until the entire application is developed. During each iteration, the development process goes through each phase from the requirements through testing and each subsequent incremental improvement process. As you can see from the diagram, we have set of requirements. What are the requirements for this application? We do the first plot or first phase application. We do some design and development, we test it and we implement it. After implementing it, we see some problems. Then we go on, on that same first build, we do a second build, second version of it. We do some design and development, which is improvement of the build one. We do some testing, we implement it in the other model. After that we have some problem. We do a build three, we design, we develop, test it and implement it. So that's how it goes until we have the final version of what we want. Then we have the last one, the last one, which is the verification and validation model. The verification and validation model, which is the Fee model. Fee model emphasizes the relationship between development phase and testing phase. If we develop something like a code, we need to do some testing of it. So that to validate if that code works. The most granular testing is the unit test. Okay, okay, immediately after the code is being written. Testing occurs to validate the detailed design. As you can see, we do some component testing to see the general design specification. We do some unit testing to feel the detailed design specifications. And we do some accepted testing to see if the requirements matches what they use our hand. So system testing relates to the architectural specification of the system. Why do the final user accepted testing reference the requirements? If you make the requirements, we do the final user accepted testing with the customer accept those requirements. We have made it. That is the success of our application. So I'm done with my presentation. And the last slide is just to thank you all. The last slide is just to thank you all. Thank you so much. Thank you so much for joining me. Thank you so much. The Linux Foundation, thank you so much. The team behind the scenes. Thank you very much. We can say it in our local language. Thank you very much. I'm ready to entertain your questions.