I have been providing technical assistance for Jhpiego's CDC-funded UTAP (University Technical Assitance Program) program in Mozambique for a few years now. Initially, I got involved to help develop a web-based version of TIMS (Training Information Monitoring System) - a database used to monitor in-service training events - for the MISAU (Ministerio de Saude). I was actually very lucky to get this opportunity because the main technical lead on the project was leaving Jhpiego and there was nobody else who could pick up the work (at that point I was working in the MIS department and focusing exclusively on internal, administrative systems development).
Out of that project came SIFo (Sistema de Informacao de Formacao) . SIFo is an ASP.NET application that was developed entirely in Mozambique by a local software development shop. A large part of my work involved writing the initial RFP and analyzing the submitted proposals (the team developed a quasi-mathematical process for scoring the proposals based on criteria in the RFP and we also conducted in-person interviews to get additional insight into the vendors). I also made a few follow-up visits during the first training sessions and also to conduct an assessment following a pilot period.
Fast-forward two years... Today, we're working with the MISAU on a new application: SIFIn (Sistema de Informacao de Formacao Inicial). This application will support the Ministry's pre-service education programs. We're following essentially the same process we used for SIFo but this time there are a few differences: we have a larger number of proposals (13 vs. 4), the proposed solutions are more varied (existing, platform-based and completely new applications vs. only applications developed from scratch) and there is more interest in (and concern about) proprietary vs. open source software.
Unfortunately, I will not be able to join the team in Mozambique for the analysis process and won't have a lot of time to participate in the coming weeks (I'll be spending all of February in southern Africa focusing on learning technology work in Zambia, South Africa and Botswana). Since I won't be as involved and won't be as available to answer technical questions, I realized that it was important that the team (and the stakeholders from the MISAU and CDC) understand a few key concepts. What follows is essentially a set of terms with definitions and special notes that the team will need to keep in mind while going through the analysis process. I'm writing them here not only for my own benefit (so I can easily find them later :P) but, more importantly, to share them with others who may find themselves needing to take a critical look at software development proposals. So, without further ado...
Oh, wait. Before I get to the concepts, I don't want to forget to share a great resource that my old friend, Jon Dyer, shared with me: Open Options | Arguments about open source. While written for use in a K-12 environment, it contains a lot of great information and presents it in a way that is easy for non-techies to understand and digest.
Alright. So, for real this time, here are the terms and notes. And please, if I forgot something or provided incorrect information, please leave a comment. Thanks! :)
Cost: This can be the cost for the software itself or costs for licenses for use of the software. Software licenses are generally provided at multiple levels: site/organizational (unlimited number of users and connections), user (individual users of the system), connection (unlimited number of users but only a certain number can connect at the same time). Sometimes, an additional cost for user support and maintenance & upgrading of code may be included.
Licensing: Separate from licenses for using a product, this is licensing that pertains to intellectual property. Traditionally, software has been distributed under very restrictive proprietary licensing (e.g. that doesn't allow one to access source code or redistribute the software). Today, it is common to find "open source" software that does not have restrictions on access to source code (for reading and/or modification) and may also allow for redistribution. There are many different types of proprietary and open licenses (and even a third category called "free").
NOTE: It is important to draw the distinction between cost and licensing: some software is free but distributed in such a way that the source code is not accessible and some software can be purchased for a cost but provide free access to the source code. Also, keep in mind that while some software is free, the human resources necessary to install, configure and support it most likely will not be.
Tools & Languages: Applications are developed using a programming language (e.g. Java, C#, PHP) in combination with other tools such as databases, web servers, operating systems, etc.
Platform: Some applications are developed using a platform (Java Runtime Environment, .NET, Adobe AIR) which is a pre-fabricated set of software components, written in a specific programming lanaguage, that can be combined in various ways and connected to various tools to create applications.
Application code: The unique logic required to implement a tool is specified in the application code. This can be code that connects existing platform components or that directly accesses underlying tools (e.g. a database) to implement particular functional requirements.
NOTE: Tools, languages, platforms and application code can have associated costs (software, license, support, maintenance) and can be distributed using a proprietary or open license. A complete application may contain something from each of these categories, so it is important to look at each and understand what the associated costs are and how they are licensed.
Customization:
-Existing application: Customization of an existing application would be the quickest solution since all of the code is already written and would only require modification to meet unique functional requirements; however, there is generally a limit to the amount of customization that can be done. Because both the user interface and business logic are already developed it may not be possible to modify the application to meet completely the expectations for "look & feel" and functionality. Most importantly, one must be careful not to choose an application that is so inflexible that it requires them to change their business processes to meet the application's features.
-Platform-based application: At a very basic level, most applications share functionality. Turning that shared functionality into a platform allows one to more rapidly develop applications since the same code does not need to be rewritten every time. While development will not be as rapid as customization of an existing application, it can be significantly faster than developing something from scratch. This approach can also be very flexible and more likely to meet unique business requirements than a customization of an existing application since the platform code focuses on the low-level, routine tasks that are common. The high-level, unique requirements will be met by writing new code and linking together platform components. Sometimes, functionality may not be met, even by the existing platform components, and new ones will need to be developed or existing ones will need to be modified. Once this is done, the components will be available for use in other existing application or for applications that will be developed in the future.
-Completely new: An application can be developed completely from scratch, starting with nothing but a programming language and a collection of necessary tools (e.g. a database and web server). Taking this approach will generally take more time than customizing an existing application or building one based on an existing platform; however, if the project requirements are highly unique, this may be the only solution. Most applications are not that unique.
0 comments:
Post a Comment