Genventory reflection: a postmortem of a computer science capstone project

This thesis outlines the methodologies and framework developed by the Genetics Biology Clinic Team in making a centralized genetic database, "Genventory," for the Jorgensen Lab enhancing my undergraduate interdisciplinary education. The project addresses limitations in current systems, such as Google Sheets and File Maker, by implementing a user friendly interface database architecture optimized for genetic research. This centralized system supports seamless data management, secure backups, and real-time integration with the WormWorld database. Key aspects of this development include utilizing Django for backend development, React with Vite for frontend implementation, and AWS for scalable cloud services. Additionally, features such as user-friendly UI/UX, data visualization tools, and authentication mechanisms are incorporated to enhance user experience and data accessibility. Future development will focus on expanding data types within Genventory, ensuring comprehensive coverage of genetic data, including CRISPR modifications, strain lineage tracking, and phenotype annotations. Additional features, such as interactive visualization tools for tracking genetic relationships and integrating automated gene crossing simulations, will further enhance the platform's utility. These future improvements will allow national genetics labs to utilize this tool by streamlining experimental planning and providing intuitive tools for large-scale data analysis. Moreover, improvements in API connectivity will facilitate seamless integration with external databases, promoting collaboration and data standardization across research institutions. With these capabilities, Genventory aims to establish itself as a foundational tool for genetic research, adaptable to various laboratory environments worldwide.

Copyright © Kishan Thambu 2025 All Rights Reserved For my parents and my team members CONTENTS ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii CHAPTERS 1. 2. 3. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 1.2 1.3 1.4 Motivation and Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Collaborative Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 3 4 CONTRIBUTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Team Member Responsibilities Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Personal Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 SOFTWARE DEVELOPMENT METHODOLOGIES . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 3.2 3.3 3.4 3.5 3.6 4. FUTURE DIRECTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 4.2 4.3 4.4 5. Development Model: Agile with Iterative Releases . . . . . . . . . . . . . . . . . . . . . . 8 Tools and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Team Organization and Task Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Frontend and Backend Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Successes and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Data Type Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interactive Visualization Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulation of Automated Gene Crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scalability and Cloud Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12 13 13 INTERDISCIPLINARY AND ACADEMIC REFLECTION . . . . . . . . . . . . . . . . . . 15 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 APPENDIX: GENVENTORY DESIGN DOCUMENTATION . . . . . . . . . . . . . . . . . . . . 18 ABSTRACT This thesis outlines the methodologies and framework developed by the Genetics Biology Clinic Team in making a centralized genetic database, “Genventory,” for the Jorgensen Lab enhancing my undergraduate interdisciplinary education. The project addresses limitations in current systems, such as Google Sheets and File Maker, by implementing a userfriendly interface database architecture optimized for genetic research. This centralized system supports seamless data management, secure backups, and real-time integration with the WormWorld database. Key aspects of this development include utilizing Django for backend development, React with Vite for frontend implementation, and AWS for scalable cloud services. Additionally, features such as user-friendly UI/UX, data visualization tools, and authentication mechanisms are incorporated to enhance user experience and data accessibility. Future development will focus on expanding data types within Genventory, ensuring comprehensive coverage of genetic data, including CRISPR modifications, strain lineage tracking, and phenotype annotations. Additional features, such as interactive visualization tools for tracking genetic relationships and integrating automated gene crossing simulations, will further enhance the platform’s utility. These future improvements will allow national genetics labs to utilize this tool by streamlining experimental planning and providing intuitive tools for large-scale data analysis. Moreover, improvements in API connectivity will facilitate seamless integration with external databases, promoting collaboration and data standardization across research institutions. With these capabilities, Genventory aims to establish itself as a foundational tool for genetic research, adaptable to various laboratory environments worldwide. CHAPTER 1 INTRODUCTION Scientific investigation has always depended on sound practices for recording, structuring, and sharing data. With the big data era and multilateral research teams, its need only grew, In genetic research, where progress depends on tracking large amount of experimental data—such as DNA sequences, strain phenotypes, and allele differences—the old standbys like spreadsheets no longer do the job. This challenge was starkly apparent in the Jorgensen Lab at the University of Utah, a robust research group in the genetics of neurotransmission in the model organism Caenorhabditis elegans. 1.1 Motivation and Context Genetic research labs want to understand how genes influence biological traits, disease, and molecular functions. They want to know answers to questions such as: What is the role of a specific gene? How do mutations influence phenotypes? How do genes function together in larger biological systems? To answer these, scientists carry out experiments that generate masses of structured data. This information can be in the form of gene names, functional annotations, chromosomal positions, phenotypic results, experimental conditions, and references to related genetic entities such as plasmids or strains [1] Good and usable data is the key to deciphering genetic processes. For example, relating a phenotype observed to a specific mutation requires careful documentation of allele differences, their line sources, and how those lines were treated or manipulated within the laboratory. In the same manner, finding patterns between experiments hinges on the ability to look up and compare records from the past. Essentially, without such orderly data, the findings genetic investigation seeks to disclose are hidden or lost. Although vital to the success of research, data infrastructure remains ad hoc throughout most of the university research laboratory—spreadsheet, shared folder, and paper-based management of genetic records. These are error-ridden, hard to search, and tedious to 2 maintain in the long run. The net result is inefficiency, duplicate effort, and lost institutional memory as students and researchers work in the lab. This problem was especially apparent in the Jorgensen Lab at the University of Utah, which studies the genetics of neurotransmission using the model organism Caenorhabditis elegans. C. elegans is a small, transparent nematode that has become a canonical model for genetics and developmental biology because of its rapid life-cycle, invariant cell lineage, and fully sequenced genome[2],[3]. The lab stored central genetic data in Google Sheets and predominantly in FileMaker programs that, while functional, were not intended for large-scale biological data management. Scientists reported problems with usability, consistency, and data backup. New laboratory members found the records difficult to decipher, and in practice data upkeep became a liability rather than an asset. 1.2 Project Overview To address this problem, our senior capstone team developed Genventory, a webbased, centralized system for managing genetic information tailored explicitly for use in the Jorgensen Lab. The goal was simple: replace antiquated solutions, such as Filemaker and Google Docs collecting, with a unified solution improving usability, security, and ease of expansion—but remains easy to utilize for scientists who have already had experience utilizing the database. Genventory provides an easy-to-use interface, enabling users to enter and manage simple types of genetic information: DNA/plasmids, alleles, and strains. It supports complete records, aided data entry, advanced searching and filtering, and exportability. Even old experimental results can be imported and Genventory synchronized with foreign databases like WormWorld for constant data exchange. WormWorld is a software tool designed to assist geneticists in the Jorgenson Lab in creating and managing breeding plans for Caenorhabditis elegans (C. elegans) strains. It offers tools for designing genetic crosses, calculating expected offspring ratios, and organizing breeding schedules. Inside the software, Genventory employs a contemporary and solid technology stack. The backend leverages Django, a high-level Python web framework that encourages rapid, secure development through its model–template–view architecture [4], [5]. The frontend employs React, a component-based JavaScript library for declarative user-interface con- 3 struction [6], [7]. Production deployment on Amazon Web Services allows scaling via managed services eliminating fixed infrastructure costs [8], [9]. Application containers are orchestrated with Docker, providing reproducible builds and isolated dependency managemen [10], [11]. Vite is an add-on to React that provides a faster and more efficient development experience by offering instant server startup and rapid updates when code changes. Genventory’s schema is organized around a handful of core entities—such as strains, alleles, and plasmids—together with supporting tables for reagents (e.g. antibodies, primers), experimental artifacts (images), and storage logs. Key relationships include a many-to-many join between strains and alleles, plus one-to-many links from strains to images and storage entries. This design keeps data very earnest (no duplicated fields). Yet, expressive enough to capture complex lab workflows, mapping which genetic variants each strain carries, tracking sample movement over time, and associating files or reagents with their biological context. Overall, it is a moderately complex relational model: it enforces key database schema building practices through clear foreign-key constraints while remaining straightforward to extend as new data types emerge. 1.3 Scalability Genventory is more than a technological advancement because it positively improves the research process for geneticists by solving problems that thwart or slow scientific activity. The platform enables scientists to focus on experimentation and discovery rather than wrestling with their tools, providing easier and more reliable data entry, retrieval, and sharing. Beyond the Jorgensen Lab, Genventory is designed to be scalable. Its modular nature, front-end customizability, and plugin-friendly architecture enable it to be readily repurposed to support other labs of genetics with minimal setup. Through doing so, this project not only addresses an immediate need in one lab but demonstrates a replicable model for augmenting digital infrastructure in academic science more broadly. 4 1.4 A Collaborative Effort This project also demonstrates the value of interdisciplinary collaboration. While the software was developed by a team of computer science students , it was informed at every step by practical input from biology researchers Matt Rich and Wayne Davis at the Jorgenson Lab. In mapping user needs onto software functionality, we bridged the gap between two fields and developed a tool that is both technically sound and pragmatically valuable to genetic research. Genventory has been developed after months of iterative development, testing, and feedback. The system architecture, design choices, development process, and directions for future research will be explained in the subsequent chapters for this thesis. The individual contribution and lessons learned during the project will also be emphasized. CHAPTER 2 CONTRIBUTIONS This chapter captures all team member contribution to Genventory project and personal contribution to Genventory Software development. 2.1 Team Member Responsibilities Overview • Ahmed Al Hikmani Coordinated UI/UX designing that involved table layout configuration, freeze request process workflows, and frontend visual aesthetics. Assisted in error logging and data export functionalities. • Iris Yang Committed to data import systems (CSV parsing and upload) and backend schema completion, custom sequence visualization tools. Committed to database model implementation and plugin development. • Min-Gyu Jung Was committed to backend infrastructure as lead architect, database schema, system bootstrapping, AWS cloud deployment, user authentication (JWT), and Docker configuration. Was committed to DevOps-related activities and permission management system implementation. • Kishan Thambu Contributed to API integration, data linking (e.g., genotype crossreference), frontend testing, and backend infrastructure features relating to system stability and usability. Worked to enhance cross-feature usability from a bioinformatics standpoint. 2.2 Personal Contributions During my undergraduate studies as a Computer Science student with specific interest in data-intensive applications and bioinformatics, my Genventory contributions involved the intersection areas of where the backend database, frontend User Interface, and domainlevel requirements of workflows performed in genetic research overlap. In my work, I 6 sought to ensure both technological execution of things and respect for the ways in which our patches addressed the need of biology research scientists at the Jorgensen Lab. Data Handling and Backend Infrastructure Identifying and implementing error handling and logging were among my most critical jobs. Because genetic information stored on older methods like FileMaker was sensitive and nuanced, it was necessary to ensure that incomplete or inconsistent records weren’t entered into the system. I assisted in designing frontend and backend layer validation logic to make sure that user inputs such as allele names, strain sources, or genotype formats adhered to a predetermined requirement set. These validations reduced data corruption risks and enhanced the stability of the system in the long run. In addition, I implemented API integration to retrieve data. Using Django REST Framework, I authored views and serializers that allowed frontend to retrieve latest genetic data. The work made it easy for React-based user interface to interact with PostgreSQL-backed database. Frontend Features and Usability Enhancements Frontend, I was also involved in the following UI/UX enhancements: Specifically aimed at simplifying navigation and visual simplicity for technically naive researchers. Included form element editing to automatically fill known data in the database, reworking dropdown menus so that users had faster access to data selection, and helping decide how the form validation errors were informed to users. One of my own contributions was the incorporation of hyperlinked data fields between genotypes and strains. It is crucial in genetic research to keep records of and trace inter-relationships among biological materials. I provided clickable links among related database records so that users could move around easily between similar data—for example, viewing a strain and jumping directly to the alleles it references. This feature enhanced the research team’s capability to cross-reference data efficiently during analysis. Request Systems and Testing I also constructed the frontend and backend components of the thaw request system, which allows lab technicians to place requests for access to frozen genetic samples. This 7 feature emulated an actual lab process and served as an operational hub between digital and physical lab processes. I worked with Ahmed on synchronizing form layout, request routing, and status monitoring. To ensure that all features are reliable, I led the adoption of automated frontend testing using tools that were effective for our React and Django technology stack. I authored unit tests to simulate user interaction and catch UI bugs early in development. This proactive testing improved system stability and made it easier to deploy new features without sacrificing existing functionality. Summary Overall, my time in Genventory went towards designing the platform for frontend to backend interfacing especially with genetic collection tasks like thaw requests and interfacing to enable the user interface to become intelligent and comprehensive with testing. Along with all these deliverables, I participated in team discussion for database design, helped in deployment workflow testing, and remained involved continuously with group debugging and QA. This initiative helped ensure that Genventory’s interface was not only technically accurate but also reflective of actual lab use. CHAPTER 3 SOFTWARE DEVELOPMENT METHODOLOGIES In developing Genventory, our development process was a pragmatic and iterative software development that struck a balance between formal planning and real-world flexibility. The challenge of designing a full-stack web platform for genetic research. This chapter captures the methodologies, tools, and team dynamics that shaped our development process, together with the issues we faced and how we handled them. 3.1 Development Model: Agile with Iterative Releases Right from the start, we structured our workflow according to agile principles. We used short development cycles—typically one to two weeks long—to plan, develop, and test features incrementally. Instead of following a rigid long-term plan, we prioritized features by regularly getting feedback from our sponsor and internal testing from our team. This iterative approach allowed us to build working prototypes for key milestones throughout the academic year. We delivered an interim prototype following the fall/winter semester and alpha, beta, and production release versions subsequently throughout the winter/spring semester. Each was followed by usability feedback and bug testing to further solidify the system one additional time. This plan–build–review cycle maintained our product in user alignment and allowed us to identify and rectify design shortfalls early on without delay. 3.2 Tools and Infrastructure The main goal of this software was to develop a functional database tailored to the Jorgensen Lab’s data and to provide an extremely user-friendly interface for all its members. We used GitLab as our principal version control, issue tracking, and team coordination tool. All members of our team worked on feature-specific branches and merged onto 9 the main branch after code review only. GitLab also made it easy for us to keep track of development decisions through issues, merge requests, and a local project wiki. Our backend technology stack was Django and PostgreSQL. Django gave us a nice model-view template layout and came with authentication, migration, and testing libraries included. PostgreSQL was used since it supports advanced relational data, specifically its transactional schema migrations and its ability to support complex queries. On the client side, we used React to build dynamic, component-based UIs, and Vite to facilitate faster development builds. We deployed the platform on AWS and used Docker to containerize the environment, which made it possible to reproducibly deploy among team members and remote servers. After receiving feedback from the biology lab members, 5 out of 6 members who tested have mentioned our product being extremely user friendly as this was the main goal on top of having a functional database. 3.3 Team Organization and Task Assignment First, there was no formalized division of duties among our team structure. Too often, the team members overlapped into responsibilities of each other, leading to redundant work, unmixed branch code, and incompatible design sets. Communication loopholes in the early phase caused the backend adjustments to not fit suitably into the frontend, and someone might at times ask an activity of many people unaware of the overlapping. But then, mid-project, we formalized weekly meetings and began using GitLab’s issue board to delegate tasks and roles. This change really improved coordination. Tasks became more specific, expectations were clear, and members could plan their work without repeating each other’s efforts. We also learned to document changes better—keeping our shared GitLab wiki up to date within our issue and planning board. 3.4 Frontend and Backend Division One of the most effective strategies we employed was the division of the team into backend and frontend developers. The division allowed each developer to concentrate on his or her strength and become very familiar with his or her domain. This allowed sepearation of concern as backend developers could spend more time on optimizing data models, writing API endpoints, and ensuring data consistency, while frontend developers 10 concentrated on user experience, form layout, and interactivity. This organization not only increased development speed but also led to features of higher quality. It encouraged domain ownership and allowed peer code reviews to be more effective since each member reviewed features within their domain knowledge. 3.5 Successes and Challenges Here are some challenges faced: • Initial Communication Breakdown: With no established roles at the start, redundant work and frontend-backend mismatches were happening. • Underestimated Complexity: Interoperation of models of genetic data like genotype maps and related allele forms was more involved than initially anticipated. • Dropped Features: Certain features like complete integration with WormWorld and web infrastructure autoscaling were not included due to timing constraints and shifting priorities. Some things about our development process worked especially well: • Modular Development: Dividing the system into independent features facilitated easier testing and integration. • Rapid Prototyping: Frequent releases enabled us to receive initial feedback from users and make frequent iterations. • Tooling and Automation: Postman, Swagger, and Django’s testing framework were the tools used to automate error checks and enforce consistency at the backend. • Cross-functional Testing: Not just developers, but also members of the biology lab tested workflows, providing feedback from a live user’s point of view. 3.6 Reflection Overall, our software development process evolved radically throughout the project. We moved from an ad hoc coordination process to a structured, task-based process supported by automation and regular feedback loops. While we did have some technical and 11 organizational failures, they were learning experiences that both improved our product and our collaboration. The final product was a stable, flexible, and user-focused web site that surpassed the goals set forth by our patron and showed the value of adaptive, team-based software development. CHAPTER 4 FUTURE DIRECTIONS Genventory constitutes an innovative step in the central repositories for genetic data management among the Genetics/Biology Clinic Teams. Using the underlying model of this software, there await further enhancements that would address the needs of more genetic research laboratories in the forward loop. The rest of the chapter will describe the future advancements and deploying methods of this application. 4.1 Data Type Extension In the light of increasing complexity in genetic research, newer iterations of Genventory will provide for relevant data types, including CRISPR edits, strain lineage tracing, and phenotype annotation [12]. Adding CRISPR data will allow for proper documentation and assessment of gene-editing experiments. Strain lineage tracing will allow scientists to see genetic variation across generations, while phenotype annotation will enable one to correlate phenotypes with gene edits [2], [3]. This enhancement would then require a set of new relations and entities to be incorporated into the existing database schema. With Django’s Object-Relational Mapping capability, we will be able to easily map these conceptual data types onto the backend infrastructure [4], [5]. 4.2 Interactive Visualization Tools An improvement of data visualization schemes in Genventory is essential for intuitive data interpretation. Interactive features like dynamic graphs and heatmaps will enable the easy exploration of genetic relationships and trends. Such innovative tools can provide knowledgeable insights in real-time. Frontend development will take full advantage of the component-based architecture of React to build reusable and generic visualization components [7]. Libraries such as D3.js or 13 Chart.js are promising candidates for responsive and interactive visual components. Vite will be integrated as the build tool for efficient development and optimized performance. 4.3 Simulation of Automated Gene Crossing In an attempt to aid researchers in the design of their experiments, considerations are being made to enhance Genventory with automatic gene crossings simulation. The feature would aim at predicting genetic crossing outcomes by predicting the genotype and phenotype distribution with the help of Mendelian laws of inheritance. This would require algorithms to model genetic crosses based on principles like dominance of alleles and linkage. The backend functionality would be developed in Python, with the support of scientific libraries like NumPy for speeding up the computations. The results should then be presented in the form of relevant graphical outputs via a userfriendly interface. In addition, cooperation with different genetic databases, such as WormWorld, will only enhance how relevant the simulations are to Genventory. The simulations will become more accurate in predicting experiments and designing them as they will get used of real genetic data like functions of genes, phenotypic traits, and recent strain information. 4.4 Scalability and Cloud Deployment Genventory has been designed with meticulous care to address the particular requirements of the Jorgensen Lab, such as efficient handling of genetic materials such as plasmids, DNA constructs, and strains. The platform design is set up to support the lab’s specific workflows, thaw/freeze status, strain lineage tracking, and phenotype annotations. The central schema of the database is made up of highly established tables for strains, DNA sequences, and plasmids with clearly established relationships and fields. Modularity enables the system to integrate into the lab’s current data handling needs and provision for future expandability. For scalability and flexibility purposes, Genventory uses containerization through Docker to facilitate consistent deployment across various environments [11]. Genventory is hosted on AWS, where services such as Elastic Beanstalk for application deployment, RDS for databases, and S3 for file storage are utilized [8]. The cloud platform provides dynamic 14 resource assignment, whereby the system can handle increased data loads and user traffic as the lab’s research activity increases. Besides, database design scalability means that Genventory can be easily expanded to support new data types and functionality [12]. For instance, addition of new modules for simulated gene crossing or enhanced data visualization features can be achieved without impacting the existing system. This is the reason why Genventory is a starting solution for genetic data management not just for the Jorgensen Lab but also for other research laboratories with the same requirements. CHAPTER 5 INTERDISCIPLINARY AND ACADEMIC REFLECTION The Genventory project was a real-world intersection of my academic training in computer science and biology at the University of Utah. It brought together significant principles in genetics, software engineering, and database design into a single interdisciplinary solution for improving data management in lab research. Classes such as BIOL 2030: Genetics and BIOL 5960: Eukaryotic Genetics and Molecular Biology Lab provided us with basic knowledge of the biological background of our project. These classes emphasized the importance of correct allele tracking, genotype correlations, and experiment reproducibility—concepts we applied directly to Genventory’s database schema with experiments on C. Elegans. Understanding how genes are manipulated, recorded, and shared in a research environment allowed us to develop forms and relational models that reflected the real-world needs of laboratories like Dr. Jorgensen’s. In terms of technique, CS 5530: Database Systems was most influential. It taught basic relational modeling concepts, schema normalization, and transactional integrity—all of which informed our implementation of PostgreSQL for Genventory. Some of the decisions made about table relationships, foreign keys, and best-practice querying were a direct consequence of techniques explored in this class. I applied these principles in working with others on creating the backend to ensure that our schema was logically accurate and scalable for future lab use. Besides, CS 3505: Software Practice II introduced me to object-oriented design, version control procedures, and collaborative software development—factors important to this project. Applying patterns such as MVC (Model-View-Controller) in Django, participating in Git-based code branching and code reviews, and coding with readability, modularity in mind were all shaped by this course. It also affected the way our team structured sprints, 16 tested, and defined feature boundaries across the frontend and backend. Aside from classroom work, my undergraduate studies in bioinformatics, deep learning, and computational biology influenced this project as well. Experiencing genetic data visualization gave me a good sense of how biological datasets must be structured and queried to be applied scientifically. Genventory was naturally the next step—a practical system that applies classroom theory and research principles to real problems in the lab. In truth, Genventory was not just a capstone but an interdisciplinary integration and a hands-on exercise of decades of interdisciplinary education at the University of Utah. REFERENCES [1] Rhee, S. Y., Wood, V., Dolinski, K., & Draghici, S. (2008). Use and misuse of the gene ontology annotations. Nature Reviews Genetics, 9(7), 509–515. [2] Brenner, S. (1974). The genetics of *Caenorhabditis elegans*. Genetics, 77(1), 71–94. [3] Stiernagle, T. (2006). Maintenance doi:10.1895/wormbook.1.101.1 of *C. elegans*. WormBook. [4] Holovaty, A., & Kaplan-Moss, J. (2013). The Django Book (2nd ed.). Apress. [5] Django Software Foundation. (2025). Templates — Django documentation. Retrieved April 1, 2025, from https://docs.djangoproject.com/en/5.2/topics/templates/ [6] Facebook, Inc. (2013). React – A JavaScript library for building user interfaces. Retrieved April 1, 2025, from https://legacy.reactjs.org/ [7] Facebook, Inc. (2025). facebook/react: The library for web and native user interfaces. GitHub. Retrieved April 1, 2025, from https://github.com/facebook/react [8] Amazon Web Services. (2024). Overview of Amazon Web Services — AWS whitepaper. Retrieved April 1, 2025, from https://docs.aws.amazon.com/whitepapers/ latest/aws-overview/introduction.html [9] Amazon Web Services. (2025). AWS Elastic Beanstalk — AWS Documentation. Retrieved April 1, 2025, from https://docs.aws.amazon.com/elasticbeanstalk/ latest/dg/Welcome.html [10] Merkel, D. (2014). Docker: lightweight Linux containers for consistent development and deployment. Linux Journal, 2014(239). [11] Docker, Inc. (2025). Get started with Docker. Retrieved April 1, 2025, from https: //docs.docker.com/get-started/ [12] Bard, J. B. L., & Rhee, S. Y. (2004). Ontologies in biology: design, applications and future challenges. Nature Reviews Genetics, 5(4), 213–222. APPENDIX GENVENTORY DESIGN DOCUMENTATION Genetics/Biology Clinic Team Genventory Senior Capstone: Design Document Genventory Design Document Biology Team Version 1.1 Table Of Contents 1. Executive Summary/Introduction/Abstract 1.1 Abstract 1.2 Executive Summary 2. Background and Technical Requirements 2.1 Background 2.2 Required Technology and Features 3. Requirements Analysis 3.1 System Architecture 3.2 Personnel 3.3 System Features 3.3.1 Base Features (Infrastructure and Core Functionality) 3.3.2 Planned Features 3.3.3 Advanced Individual Features 4. Software Engineering Tools and Techniques 5. Timeline 3 3 3 4 4 3 6 6 6 7 6 6 7 7 10 6. UI / Use Case Appendix 7. Revisions Appendix 12 24 Genventory Design Document Biology Team Version 1.1 1. Executive Summary/Introduction/Abstract 1.1 Abstract The biology clinic team consists of members Ahmed Al Hikmani, Iris Yang, Kishan Thambu, and MinGyu Jung who are working along with the Dr. Jorgensen Lab to create a centralized genetic database. Many genetic databases including Dr. Jorgensen Lab utilizes google sheets and file maker for data storage and retrieval which is not user-friendly and creates security issues for data backups. The proposed system adopts a user-friendly interface, ensuring that researchers, even those with minimal technical proficiency, can input, modify, and retrieve genetic data on DNA/plasmids, alleles, and strains with ease. Underlying this interface is a robust database architecture optimized for the specific data storage needs of genetic research that can be accessed via a web server. Through the use of database relations technology, our database aims to seamlessly interact with another genetic database named "Worm World", allowing for real-time data import. In addition, our database system aims to be compatible with other genetic labs to replace any obsolete software for data storage with a database system that is centralized. 1.2 Executive Summary In the intricate landscape of genetic research, notable labs like Jorgensen Lab, which delves deep into the genetic analysis of neurotransmission in the fascinating worm species, Caenorhabditis elegans, often struggle with traditional data storage solutions like Google Sheets and File Maker. Such systems, while functional, are not inherently designed for presenting usability challenges for newcomers and lacking robust measures for secure data backups. This is where the Biology Clinic Team steps in, driven by an unwavering commitment to innovate. Our vision is a centralized genetic database tailored for Jorgensen Lab's unique needs but scalable enough to benefit other genetic labs worldwide. Imagine a platform where anyone, irrespective of their technical background, can effortlessly navigate, input, and retrieve data. Our design encompasses not only an intuitive user-friendly interface but also a secure user authentication system, web-server based remote accessibility, and a state-of-the-art database architecture finely tuned for genetic research's intricacies. However, our ambitions don't stop there. We're setting our vision to expand our impactful technology to other genetic labs and facilitate seamless integration with another advanced genetic database, WormWorld. A final touch to our solution aims to incorporate comprehensive data visualization tools for the stored data of allelic variations, phenotypic expressions, and DNA/plasmid structures. Why does our initiative matter? It’s a step into a future where outdated and non-robust data systems are not Genventory Design Document Biology Team Version 1.1 the bottle-neck in research pipelines especially for genetic research. We're not just storing data; we're enhancing the very foundation that allows researchers to unravel mysteries like those within C. elegans. The Biology Clinic Team is determined to transform the workflow for genetic researchers, lab technicians, and academic scholars, ensuring they have the best tools at their disposal for their invaluable work. Join us as we reshape the horizons of genetic research data management. 2. Background and Technical Requirements 2.1 Background Numerous genetic databases including Dr. Jorgensen Lab utilizes google sheets and file maker for data storage and retrieval which is not user-friendly and creates security issues for data backups. The proposed system adopts a user-friendly interface, ensuring that researchers, even those with minimal technical proficiency, can input, modify, and retrieve genetic data on DNA/plasmids, alleles, and strains with ease. Similar Ideas REDCap Many medical research labs including University of Utah use the Research Electronic Data Capture (REDCap) software to build and manage online surveys and databases for patient’s medical information. Since they focus on security and privacy, execution time on the database depends on the size of the database. If we have a massive amount of data stored in a database, then retrieving the data will take a while. Our sponsor stated the software does not need to encrypt data to obtain higher security so our proposed software would have faster execution and operation time than the Red Hat. Dotmatics Dotmatics is a virtual lab notebook software that captures and stores experiments and shares with internal and external collaborators in a single, intuitive framework to support data-driven decisions. Using flexible templates incorporate guidelines in maintaining a laboratory notebook effectively. Their templates are focused on chemistry, material, and biology experiments which would not be efficient for our sponsor Dr. Jorgensen Lab. Therefore our proposed system will provide user-friendly templates related to genetics experiments such as DNA/plasmids, alleles, and strains with ease. LabArchives Harvard LabArchives is a secure and intuitive cloud-based electronic lab notebook application enabling researchers to easily create, store, share and manage their research data from computer or mobile device. It is a flexible and extensible platform that can be easily customized to match each lab's workflow. The current cost for a professional academic lab is $230 per user per year. And if we want to customize to fit within the genetics lab, the price increases. Assume there are 5 people in the lab, the price starts at $1150 per year. 2.2 Required Technology and Features Our client had three specific requirements: low cost, data stability, and user-friendly UI/UX. Django Django is a well-known high-level framework used for the back-end. It comes with a wide range of libraries, including login, sign-in, and data parsing. Furthermore, since our client is Genventory Design Document Biology Team Version 1.1 not concerned about performance, and all of our teammates are familiar with Python, we have decided to use Python for the back-end. PostgreSQL According to Django's Migrations documentation, it states that "PostgreSQL is the most capable among all the databases here in terms of schema support." PostgreSQL is the only one that supports Transactional DDL, ensuring that changes to the database schema remain consistent with other data changes and helps protect data. Additionally, PostgreSQL is an object-relational database, whereas others are relational databases. React + Vite We will use React for the front-end. However, instead of using npm CRA (create-react-app), we will use the "Vite" build tool. CRA has long been the go-to tool for most developers for scaffolding React projects and setting up a development server. However, CRA uses Webpack under the hood, which can lead to performance issues. Vite focuses on speed and performance by not building the entire application before serving. Additionally, Nginx offers high performance and stability compared to Apache, and we can configure Nginx as a reverse proxy for HTTP, which ultimately aids in load balancing and web acceleration, as a reverse proxy can act as a cache or buffer to reduce latency. https://docs.djangoproject.com/en/4.2/topics/migrations/ AWS We have chosen to use AWS for our cloud services. AWS offers numerous benefits, including cost savings, increased efficiency, and strategic value when compared to traditional on-premises IT infrastructure. One of the most significant advantages of AWS is its flexibility. All the services seamlessly integrate and communicate with our applications. Additionally, our team is more familiar with AWS compared to Azure and GCP. Furthermore, as long as our customers require data stability, cloud computing remains one of the most important solutions. Cloud services, such as AWS, provide robust data protection and recovery mechanisms, alleviating concerns about data loss or crashes, and offering us a high level of security. 1. 2. 3. 4. 5. 6. Visual Studio Windows 10 Ubuntu Docker Internet Google account Genventory Design Document Biology Team Version 1.1 3. Requirements Analysis 3.1 System Architecture 23.2 Personnel Ahmed Al Hikmani - Ahmed is a senior Data Science student and has completed courses in Database Systems, Visualization for Data Science, and Designing Human-Centered Experiences (UI/UX). He has also interned for Petroleum Development Oman, where he worked on prototyping software solutions, specializing in management dashboards. His academic Genventory Design Document Biology Team Version 1.1 background and professional experience make him well-equipped to handle: UI/UX Database Design and Management Front-End Development Iris Yang - Iris has a strong background in mathematics, algorithm, data management, and technical programming. As such, she will primarily be responsible for: Data management Develop automated test Kishan Thambu - Kishan has extensive background in data science and bioinformatics research that can translate to accurately developing genetic relational database management system User-Interface / User-Experience design and development Assisting Team members in implementation of their role tasks when required Min-Gyu Jung - Min-Gyu has experience building a personal web page and deploying it on AWS. He will be responsible for: Design System architecture, AWS deployment, cloud services, Backend, Frontend, Database work and Working Model -View- Template design patterns 3.3 System Features 3.3.1 Base Features (Infrastructure and Core Functionality) 1. Core Database Tables/Interactions: ● Creation of essential database schema for genetic data, including tables for DNA/plasmids, alleles, strains, etc. ● Basic Create, Read, Update, Delete operations for these tables. ● Implement error handling and logging invalid data operation. 2. Basic UI/UX for Main Functionality: ● Development of a Model / View / Controller (MVC) for the user interface that allows for data entry and retrieval. ● Navigation structure that supports the workflow of genetic research. 3. Local Host Implementation: ● Configuration of the system to run on a local server for development and testing purposes. ● Setup of Django backend and React frontend to work together seamlessly on a local machine. 4. Exemplar of Plugin System: ● Implementation of a basic plugin system that demonstrates the core functionality, such as data import/export or search capabilities. 3.3.2 Planned Features 1. User/Roles - Authentication and Authorization: ● Setup of a user authentication system that handles different user roles and permissions. ● Integration of user management features that allow for account creation, password recovery, lab user privileges manager, and role assignment. Genventory Design Document Biology Team Version 1.1 ● Implement error handling and logging mechanisms for user system 2. Database/Data Management: ● Implementation of advanced database management features, including auto-backup and version control. ● Optimization for performance to handle large datasets efficiently. 3. Core UI/UX Enhancements: Enhancement of the user interface to improve the experience based on user feedback from the alpha phase. 4. Software Engineering Practices: ● Setup and integration of cloud deployment using AWS to ensure scalability and data stability. ● Documentation of the API and creation of a comprehensive test suite for automated testing. ● Establishment of a CI/CD pipeline for continuous integration and delivery. 3.3.3 Advanced Individual Features 1. Integration with WormWorld: ● Development of a feature that allows for seamless data exchange with the WormWorld database. ● Tools to map and cross-reference data between the two systems. 2. Advanced Data Visualization Tools: ● Creation of complex algorithms that can predict phenotypic expressions from genetic markers. ● Machine learning integration for predictive analytics and pattern recognition. 3. Admin Dashboard with Data Visualizations: ● A sophisticated admin panel that provides comprehensive data visualizations. ● Real-time analytics and reporting tools for quick decision-making and research insights. 4. Auto-scaling Web Server Configuration: ● Implementation of an auto-scaling solution for the webserver to handle variable loads for intra-genetic lab deployment. ● Advanced caching mechanisms for performance optimization. ● 4. Software Engineering Tools and Techniques ● Agile vs. Traditional, e.g., how far ahead do you think you can plan? ○ Agile, with short iterative cycles (1-2 weeks each). Fully flexible and adaptable to project requirements and scope. ● Tools (as appropriate) ○ IDEs. ○ Visual studio code. ○ Main libraries Genventory Design Document Biology Team Version 1.1 ○ React, psycopg2, etc… ○ Swagger/Postman, ○ ‘drf-yasg’ or ‘django-rest-swagger’ are packages that will be used with Django REST ○ Postman will be used for manual and automatic testing. ○ Testing Plans and Tools, ○ Unit Testing - testing for model, view, and backend functionality. ■ ‘Unittest’ is Django’s built-in framework ○ Integration Testing- Django’s test framework for internal integrations ○ Performance Testing - make sure database model and https system does not face any strains under certain loads ■ ‘locust’ for load testing ○ End-to-End Testing - lab technicians will be testing user scenarios from user registration, data input/output, and integration with wormworld ■ Selenium can also be used as a supplemental E2E testing for functional testing as well ○ Bug Tracking ○ We will simply use Gitlab’s Error Tracking to track bugs. ○ Versioning ○ x.y.z ■ X = main version ■ Y = feature number increase this number if new features added ■ Z = hotfix number, Increase this number if it contains bug fixes. ○ Issue Tracking ○ We will simply use Gitlab’s issue board to track Issues. ● Code Reviews, e.g., "entire team" vs "single signoff" ○ To contribute to the overall improvement of code quality, collaboration and knowledge sharing with our team, we will do an entire team code review. ● Documentation - Global : If there is any change of plan such as method or tool, update Wiki on GitLab (https://capstone-cs.eng.utah.edu/groups/biology_clinic/-/wikis/Design-Document) - Local : Put a comment on the code file if there is any change of code. Push code to GitLab repository with a well-described comment and make sure to share the change in the team’s Discord. - Commenting will be done as code is being developed ● Team Communication - Chat within our team : Discord - Chat within sponsors : Slack - Request related code & project management : GitLab ● Team Meetings Genventory Design Document Biology Team Version 1.1 - Regular team meeting : Monday after 8 pm Sponsor meeting : Tuesday 11 am - 12 pm Class staff meeting : Friday 4 pm - 4:30 pm 5. Timeline Release Ahmed Hikmani Iris Yang Kishan Thambu Min-Gyu Jung Week 1 DB schema DB schema Design Alleles, Strains, and plasmid(Frontend) DB schema & Django models Week 2 Insert datas Insert datas Design Alleles, Strains, and plasmid(Frontend) Add search function (Making queries) Week 3 Working frontend Login feature Login (Frontend) Login feature (Backend) Week 4 Migration Migration Login (Frontend) Migration Alpha Testing Alpha Week 5 Week 6 Design Dashboard, main function page (Frontend) Add more require features Design Dashboard, main function page (Frontend) Add more require features Week 7 Design Dashboard, main function page (Frontend) Design Dashboard, main function page (Frontend) Design Dashboard, main function page (Frontend) Containerize, Design Dashboard, main function page Week 8 Design Dashboard, main function page (Frontend) Deploying, more Backend work Design Dashboard, main function page (Frontend) Deploying Design Dashboard, main function page (Frontend), Backend work Week 9 Design Dashboard, main function page (Frontend) Beta Testing Design Dashboard, main function page (Frontend) Beta Testing Beta Week 10 Beta Testing Week 11 Finalize with Sponsors Genventory Design Document Biology Team Version 1.1 Week 12 Testing Week 13 Stabilize & Bug fix Week 14 Final Week 15 User Documentation Week 16 Presentation preparation Genventory Design Document Biology Team Version 1.1 6. UI / Use Case Appendix Number Title Rationale Actor/User User Story Use Case 0 Login User wants to login to website Lab Technician / Any Researcher with no technical background As a lab researcher, I want a website where I can save data. 1. Go to genventory.com with pc Course of 2. Sign up Events 3. Admin will authorize their account 4. Login to the Genventory ● Exception : Exceptions/ o Wrong password ▪ System alert to user to try with different password Alternates o Forgot password ▪ Reset password Related UI BIO-UI-00 Genventory Design Document Biology Team Version 1.1 Number Title Rationale Actor/User Use Case 1 Add DNA/Plasmids User wants to add a new DNA/Plasmids to database Lab Technician / Any Researcher with no technical background As a lab researcher, I want to input new DNA/Plasmids genetic element records efficiently, ensuring that all necessary details are captured, so User Story that we have a comprehensive and up-to-date database of our genetic materials. 1. Do experiments to gather all necessary information 2. Log into the database client. 3. From Tabs, select the DNA/Plasmids section. 4. Click “Add” button to input relevant details a. Position b. Name c. Type d. Drug e. Short Description f. Gateway Course of g. Date / lab source/ outside source Events h. Resource i. bacteria? (Y/N) ii. DNA? (Y/N) iii. Sequence (Y/N) i. Resource details 5. Click “finish” button to save 6. System validates the input ensuring all mandatory fields are completed 7. After validation, the system confirms the successful addition of the record ● Exception : Exceptions/ o DNA/Plasmids already exists on the database o Invalid data format Alternates ▪ System prompts user to correct data o Mandatory field left empty ▪ System alerts user before add on database Related UI BIO-UI-01 Genventory Design Document Biology Team Version 1.1 Number Title Rationale Actor/User Use Case 2 Add Alleles User wants to add a new Allele to database Lab Technician / Any Researcher with no technical background As a lab researcher, I want to input new Alleles genetic element records efficiently, ensuring that all necessary details are captured, so that we User Story have a comprehensive and up-to-date database of our genetic materials. 1. Do experiments to gather all necessary information 2. Log into the database client. 3. From Tabs, select the Alleles section. 4. Click “Add” button to input relevant details a. Allele b. Source c. Isolation Name d. Mutagen e. Phenotype f. Qualifiers Course of g. Gene Events h. Chrom i. Notes j. DNA sequence (drop down and autofill search to selected entered DNA from database) k. Genes covered l. Data 5. Click “finish” button to save 6. System validates the input ensuring all mandatory fields are completed 7. After validation, the system confirms the successful addition of the record ● Exception : Exceptions/ o Allele already exists on the database o Invalid data format Alternates ▪ System prompts user to correct data o Mandatory field left empty ▪ System alerts user before add on database Related UI BIO-UI-02 Genventory Design Document Biology Team Version 1.1 Number Title Rationale Actor/User Use Case 3 Add Strains User wants to add a new Strain to database Lab Technician / Any Researcher with no technical background As a lab researcher, I want to input new Strain genetic element records efficiently, ensuring that all necessary details are captured, so that we User Story have a comprehensive and up-to-date database of our genetic materials. 1. Do experiments to gather all necessary information 2. Log into the database client. 3. From Tabs, select Strains section. 4. Click “Add” button to input relevant details a. Position b. Strain c. Isolation # d. Source / Name e. Notes f. Genotype g. Location Summary Course of i. Location Events ii. Tube in Box? iii. Date iv. Enlisted / verified by h. Detailed Genotype i. Alleles (drop down and autofill search to selected entered Alleles from database) ii. Full Genotype 5. Click “finish” button to save 6. System validates the input ensuring all mandatory fields are completed 7. After validation, the system confirms the successful addition of the record ● Exception : o Strain already exists on the database Exceptions/ o Invalid data format ▪ System prompts user to correct data Alternates o Mandatory field left empty ▪ System alerts user before add on database o Does not have related Alleles in Alleles database Related UI BIO-UI-03 Genventory Design Document Biology Team Version 1.1 Number Use Case 4 Title View Plasmids / DNA information with search and sort features Rationale User wants to have a summary list to search and copy DNA / Plasmids Actor/User Lab Technician / Any Researcher with no technical background As a lab researcher, I want to retrieve data for specific genetic materials User Story with search and sort features so I can gather desired information. Course of Events Exceptions/ Alternates 1. User logs into the database client. 2. From Tabs, select Plasmids / DNA section. 3. User is given a list of alleles to scroll through all database entered plasmids / DNA that displays: a. Position b. Name c. Type d. Drug e. Short Description f. Gateway g. Date / lab source/ outside source h. Resource 1. bacteria? (Y/N) 2. DNA? (Y/N) 3. Sequence (Y/N) i. Resource details 4. User accesses the search functionality. 5. If necessary, user inputs search criteria (e.g., type of genetic material, acquisition date range) 6. For advanced searches, a dropdown on the search enables filtered searches from DNA / plasmid data types from above such as position, name, type, drug, etc. 7. The system displays a list of records matching the criteria. 8. User selects a specific record to view its detailed information. 9. A user copy can be done by clicking the clipboard button at the top right corner of each data. 10. User can click on column header dropdown for Sort/Filter options 11. User press export button from current view of allele (selected sort and filters) as .csv file type ● Exception : o No matches found ▪ System informs the user and suggests refining search criteria. o Multiple matches found Genventory Design Document Biology Team Version 1.1 ▪ System provides options to filter or sort results. Related UI BIO-UI-04 Number Use Case 5 Title View Alleles information with search and sort features Rationale User wants to have a summary list to search and copy Alleles Actor/User Lab Technician / Any Researcher with no technical background As a lab researcher, I want to retrieve data for specific genetic materials User Story with search and sort features so I can gather desired information. Course of Events Exceptions/ Alternates 1. User logs into the database client. 2. From Tabs, select Alleles section. 3. User is given a list of alleles to scroll through all database entered plasmids / DNA that displays: a. Allele b. Quantifier c. Gene d. Chrom e. Phenotype f. Source g. Isolat name h. Notes 4. User accesses the search functionality. 5. If necessary, user inputs search criteria (e.g., type of genetic material, acquisition date range) 6. For advanced searches, a dropdown on the search enables filtered searches from DNA / plasmid data types from above such as position, name, type, drug, etc. 7. The system displays a list of records matching the criteria. 8. User selects a specific record to view its detailed information. 9. A user copy can be done by clicking the clipboard button at the top right corner of each data. 10. User can click on column header dropdown for Sort/Filter options 11. User press export button from current view of allele (selected sort and filters) as .csv file type ● Exception : o No matches found ▪ System informs user and suggests refining search criteria. o Multiple matches found Genventory Design Document Biology Team Version 1.1 ▪ System provides options to filter or sort results. Related UI BIO-UI-05 Number Use Case 6 Title View Strains information with search and sort features Rationale User wants to have a summary list to search and copy Strains Actor/User Lab Technician / Any Researcher with no technical background As a lab researcher, I want to retrieve data for specific genetic materials User Story with search and sort features so I can gather desired information. Course of Events Exceptions/ Alternates 1. User logs into the database client. 2. From Tabs, select the Strain section. 3. User is given a list of alleles to scroll through all database entered plasmids / DNA that displays: a. Position b. Strain / Name c. Genotype / Background – (link to sourced allele in database) d. Notes e. Source f. Action – Link to freeze/thaw requests g. Location h. Tube status i. Date 4. User accesses the search functionality. 5. If necessary, user inputs search criteria (e.g., type of genetic material, acquisition date range) 6. For advanced searches, a dropdown on the search enables filtered searches from DNA / plasmid data types from above such as position, name, type, drug, etc. 7. The system displays a list of records matching the criteria. 8. User selects a specific record to view its detailed information. 9. A user copy can be done by clicking the clipboard button at the top right corner of each data. 10. User can click on column header dropdown for Sort/Filter options 11. User press export button from current view of allele (selected sort and filters) as .csv file type ● Exception : o No matches found ▪ System informs user and suggests refining search criteria. Genventory Design Document Biology Team Version 1.1 o Multiple matches found ▪ System provides options to filter or sort results. Related UI BIO-UI-06 Number Use Case 7 Title Import past experiment data in different file type User wants User wants to import old data into the server to Lab Technician / Any Researcher recorded their experiments somewhere Actor/User else, not our database. As a lab researcher, I want to import my old experiment data into a new User Story database with all the details Course of Events Exceptions/ Alternates 1. User logs into the database client. 2. Navigate to the “import section”. 3. Uploads a compatible file (such as .csv) containing the data. 4. The system parses and confirms the data with the user. 5. User reviews and confirms the details. 6. System adds all reagents to the database. ● Exception : o Inconsistency or issue with data file ▪ Notify the user and suggest corrections. Related UI BIO-UI-01, BIO-UI-02, BIO-UI-03 Genventory Design Document Biology Team Version 1.1 Index of UI Sketches UI sketch Number UI Sketch Description BIO-UI-00 Login BIO-UI-01 Add DNA/Plasmids BIO-UI-02 Add Alleles BIO-UI-03 Add Strains BIO-UI-04 View DNA/Plasmids BIO-UI-05 View Alleles BIO-UI-06 View Strains BIO-UI-00 Genventory Design Document Biology Team Version 1.1 BIO-UI-01 BIO-UI-02 Genventory Design Document Biology Team Version 1.1 BIO-UI-03 BIO-UI-04 Genventory Design Document Biology Team Version 1.1 BIO-UI-05 BIO-UI-06 Genventory Design Document Biology Team Version 1.1 Name of Candidate: Kishan Thambu Birth date: August 22, 2002 Birth place: Rockford, Illinois Address: 444 E Stephie Marie Ln, Salt Lake City, UT