DNA Paternity Testing Software Project

Photo by Ousa Chea on Unsplash

Introduction

Last month, two teammates (Victoria Bench and Sanah Hanif) and I (group Beta) created a DNA Paternity Testing Software Program for our university course Professional  Practice and Software Development. Below is some of the key diagrams for this project as well as some of the professional skills I learned. I have also included the brief at the bottom. All documentation and the program can be viewed upon request. What follows is an explanation of the features of the project and reflections on what I learned.

The purpose of the Beta Paternity Testing Software program is to support the National Health Laboratory Services family testing unit in determining the probability that two people are related and to manage and archive the results. At the most basic level, the program must allow a user to input the genotypes of a mother, father and child, compare these results to an allele frequency table and calculate the total paternity index. The results should then be generate and store reports of the case.The software should have a considerably high level of security to avoid fraud. Beta has been assigned the task of creating, and maintaining a DNA analysis program for the National Health Service Laboratory’s family testing unit. The project is budgeted at R710 000 for 2 years of work.

Screenshots of the final web application made with Django

Features of Prototype

  • Logging in and out(authentication by
    login/password)
  • Admin Page
    • Adding new users
    • Logging of user activity.
    • Changing user roles.
    • Adding comments by users
  • Functioning web-based GUI on a local host
  • Simple trio paternity test
  • Web-based application on a local host
  • use of SQLite to store and retrieve people and
    cases
  • Create and store reports for Court, Family and
    Medical Scientists
  • Interfaces between UI, Statistics, Databases,
    Security and Auditing
Flow diagram of the entire program

Technologies Used

  • Python Libraries and Packages
    • JSON – storing files
    • Reportlab – generating PDF reports
    • Pandas – reading Excel file
    • Xlrd – reading Excel file
    • Django – UI
  • Planning Assistance: Google Docs, Google Slides,
    Overleaf, Lucid Charts, Fluid UI and dbdiagram.io
  • Communication: Slack and Workast
  • Code Management: Github
  • Testing and Deployment: Python unit tests(written
    in PyCharm), coverage, SQL (SQLite for underlyingdatabase) and Jenkins
  • Software Architecture: Python, Linux(VirtualBoxused inside Windows), Test-Driven Development
Model View Controller diagram of the process of entering and viewing DNA

Reflection

Skills learned

  • GitHub – the terminology and mindset of always sharing your code online for your team to collaboratively use
  • Project Planning – breaking your project into small iterative cycles that help your team stay motivated and focused
  • Linux command line – running powerful instructions from a few instructions
  • Django – Library to make web applications
  • Python – Technical skill I am sure I will now use to write all programs in the future as of the extensive libraries that can be added onto it testing and coverage – the mindset of test-driven development and how to systematically test your code

Improvements

  • GitHub – place items on GitHub from the start. This will allow the team to easily integrate their code from the start and avoid a messy integration later
  • Use templates – We tried reinventing the wheel at first with components such as the databases when in face Django has built in SQLite support, which we could have used from the start
  • Project Development Structure – Instead of splitting the project into Databases, UI and statistics, I feel the group should have worked on each section together, and split up the sections over time. This would mean there would not need to be any merging of vastly different sets of code, but merging of smaller sections
  • Costing – I feel the costing was as accurate as it could be with what we knew at the time. However, the slow integration process should have been factored into the time taken and therefore the costing.

What to avoid

  • Not communicating with the client enough – Ask questions as they come up to the client about what they would want for a certain aspect to avoid work doing work that is unnecessary

Conclusion

The prototype for this project was developed and the results of this are presented in this blog post. The program can enter people, place these people into a case and calculate the Paternity Index of this case. These cases are then stored in an SQLite database and displayed using the web-development framework Django. The reports generated from the Paternity Index results can then be viewed in a PDF.

Acknowledgements

Professor Scott Hazelhurst (University of the Witwatersrand) – Our client and adviser for this project.

The Brief