Team Members:
Xuanzhen Chen
Longji Li
Steph Beneschan
Kevin Mo
Dongqing Lin
Introduction Video
Danaher DX is a diagnostics company that employees a large, diverse work force. Consequently, Danaher employees need a tool that helps them find other employees in the company with expertise in specific fields, to collaborate with them on various business projects. Our solution is to build search engine software that allows a Danaher employee to enter a field of expertise as search input, and receive a detailed list of the Danaher employees who are most skilled in that field.
In general, we would have 7 sprints following the agile programming methodology to split up a total 4 main phases
The members of Danaher who we talked to the most had limited technical experience, so the first stage of development was to analyze the sponsor's needs. By holding meetings with them and asking questions about how they function and how they hope to use the system, we started to see their vision for InDbX. As we came to realize that building an employee search system of this form has been a struggle in information retrieval for years. But there was a specific and clear requirement about the scope of data sources, we had a more concrete understanding of what Danaher wanted for the project
We proceeded to implement the main functionality in two main phases. Given the complexity of search engine software, we split the team into a couple of sub-teams: one for the backend, and one for the frontend. We created a prototype of the system, which we showed to Danaher in the form of an interactive demo. This helped the sponsor team see how we interpreted their vision for the project, which helped them guide us and re-evaluate their goals. We proceeded to build upon this demo, adding new features to the UI and bringing sources of information into the system from PubMed and USPTO.
Ultimately we arrived at the delivery phase, where we wrote extensive documentation to explain the system to Danaher so that they would be able to operate and improve on the system independently of us once the project is finished. We also spent some time tweaking the system and fixing a few bugs during this time.
Generally speaking, we have one sponsor meeting once a week. During this meeting, we update all our features and documentation progress as they make feedback and new requests. During the delivery phase, we added one weekly standing meeting with the technical staff in the sponsor group to give them a better understanding of the technical principles of the project.
Phase 1: Sprint 1
Collect and analyze the requirements, verifying the scope of data sources with use of Agile prgramming methologies
Phase 2: Sprint 2-3
Use computer science knowledge to design the system architecture and the user interface by the scope of PubMed and build and deploy the first generation of our prototype
Phase 3: Sprint 4-5
Use computer science knowledge to update the system architecture and the user interface by the scope of PubMed and USPTO and build and deploy the second generation of our prototype
Phase 4: Sprint 6-7
Release and update final prototype demo website. Prepare to transfer the system to Danaher.
Feedback and Reflection
Learning how to change and manage our sponsor’s expectations within our capability and knowledge in order to complete a realistic final prototype that both our team and our sponsors will accept proved to be the most crucial task that we faced in creating the InDbX system.
The most important thing about this project for us is this: We have never been this close to the user. A commercial product to be user-oriented must consider how to make it easy for users to understand: how they use the product; how the product works. Because initially, our explanation of the principle in the main design was too complicated for the sponsor to understand in a short period of time. But with their guidance, we quickly understood what the client wanted.
We can't just treat this project as one technically agile development, nor can we be limited to the frameworks we've learned in past classes. We will strive to provide users with easy-to-understand product instructions, product parameters, and schematic diagrams.
Make-Buy Report
The make-buy report consists of two sections. The first section details what will be necessary for Danaher to complete--that is, to make--the system after the conclusion of this project, if Danaher decides to move forward with the system. The second half of the report provides a competitive analysis of solutions currently available on the market, that Danaher could purchase to serve as the InDbX system if building it in-house proves unfeasible.
We were initially surprised when Danaher asked us to conduct market research. But we came to realize that our purpose is not simply to build software, but to help the company find a solution to their problem; we now understand why this document was critical for Danaher.
Make-Buy Report
System Modification and Maintenance Guide Series
The SMM guides explain how to operate and build onto the prototype system. For example, we wrote a set of detailed instructions for backing up the database. This will guide Danaher as they independently add more features to the project.
System Modification and Maintenance Guide
Debugging Spreadsheet
The debugging spreadsheet chronicles the bugs that are currently known to exist with the prototype. This will allow Danaher to anticipate any unpredicted behaviors in the system, rather than encounter them with no prior warning.
Debugging Spreadsheet
Requirements and Design Document
The RDD explains our understanding of Danaher's requirements for the system, as well as our technical analysis of those requirements.
Persona from Requirements and Design Document
Sprint Report Series
For each of our two-week sprints, we penned a report of what work we sought to accomplish during that time, how much of that work we successfully realized, and our communications with the sponsor during that time. This is to help Danaher better understand the InDbX development process.
Sprint Report Series
In general, we used the idea of black box testing as a guiding principle for development. We would test our system by creating a living demo, hosted on the same website as we updated it, where members of the sponsor team could test the frontend application without knowledge of the implementation details. Thus, we were able to understand how they tried to interact with the system, what their expectations were, and whether the system met those expectations.
We used the same approach to design several application scenarios to test the accuracy of search results. For example, we would ask an employee from the sponsor team to tell us about a PubMed article which they know that they have authored. We would then enter that person's name as a search in the InDbX system, and check whether that paper is present in the search results.
The InDbX system consists of a few different components: the frontend application, the InDbX web crawlers, the database, and the HTTP request handler.
The frontend application, hosted online and accessible to Danaher employees, allows a user to see information for Danaher employees with expertise in a particular field of study. This information is gathered in advance by the web crawlers and stored in the database, which allows the data to be quickly retrieved when users make searches. The HTTP request handler takes care of communication between the frontend and the backend, to help keep Danaher's data secure.
Currently, InDbx is able to access the PubMed database (mostly consisting of references to biomedical articles and life science journals) and the USPTO database of publications and patents.
Feature:
Login:
System users and administrators have access to a special "login" page, where they need to use their Danaher accounts to log in to the tool system then get started to execute the next operations for system and information security. (Currently, this feature is not fully functional, due to reasons involving company confidentiality.)
Search by Field:
InDbx allows the user to search for a field of expertise: for example, if the user wants to find employees who have done research on MS2 bacteriophages, they can type in "ms2." The system will then find the Danaher employees most relevant to the query, based on PubMed papers, patents, or patent publications that they have authored.
Search by Name:
Alternatively, the user can search for a specific employee by name; this will allow the user to see all resources authored by that employee that the InDbX web crawlers have found. The search filters out employees who do not work in Danaher DX, so users can focus on connecting with other Danaher employees. (For example, in the screenshot you can see that Richard Pattis, a UCI professor, does not appear in the search results.)
Collapsing multiple results:
By default, the list of resources (patents, articles, etc.) for each employee is collapsed to only show five items. This lets the user more efficiently navigate the list. If the user needs more information for a particular employee, they can easily click the "Show More Resources" button to display the full resource list.
Download results:
After conducting a search, the user can download the search results as an Excel file via the "Export result to Excel File" button. This allows users to, for instance, print out the search results and review them with their peers.
Update employee master list (admin feature):
System administrators have access to a special "admin" page, where they can upload an Excel spreadsheet containing a list of employee names. The InDbX application will then read those names from the file, and store them in the InDbX database. This lets the web crawlers know to search for, and only for, resources authored by those employees (so if Danaher hires a new employee, an administrator can upload a new spreadsheet containing that employee's name, and they will be registered in the InDbX system). (This feature is not functional in the current demo, mainly for information security purposes.)