Systems Development Life Cycle (SDLC)

1. Planning and Requirement Analysis

This phase is driven by a combination of community feedback, internal strategic planning, and agile development principles.

  • Source of Requirements: Development priorities are formally established through feedback and discussion with the Specify Collections Consortium (SCC) Board of Members, User Advisory Committee, and Technology Advisory Committee. Specify staff also provide regular feedback on usability and inform requirements for upcoming milestones. Day-to-day input comes from member interactions via support emails, meetings, and the Specify Community Forum.
  • Milestone Management: All work for an upcoming tagged release is captured in a GitHub Milestone
    • Milestones are planned 2+ milestones in advance and are generally limited to fewer than 15 issues to ensure focus. If a new item is added to a milestone, another is expected to be removed. All staff are expected to review future milestones to provide feedback before development begins.
  • Issue vs. Feature Request:
    • Bug Reports: Any discovered bug or issue is reported by creating a new issue in the specify/specify7 repository, following the bug report template. This includes searching for duplicates and attempting to recreate the issue on the latest tagged release (v7).
    • Feature Requests: Suggestions for new functionality begin as a new feature request discussion to be considered by the community before being formalized on GitHub.

2. Design

The design phase is highly collaborative, emphasizing group consensus, thorough documentation, and strict scope management.

  • Collaborative Design: For complex issues, developers are expected to call a meeting to discuss the implications of different solutions. A summary of the discussion and the agreed-upon solution must always be posted publicly on GitHub.
  • Usability Team Consultation: The development team consults regularly with the Usability Team to ensure new features meet requirements and prioritize user experience.
  • Scope Management: Developers must not expand the scope of a pull request beyond the requirements as written in the associated issue. If the implementation or original requirements are deemed unsatisfactory during review, desired changes must be documented in the original issue or captured in new issues for future work.
  • Requirements delivery: Full requirements with user cases and examples will be delivered 6 weeks before the beginning of development. A draft of said requirements will be provided before the strategic priorities meeting. This in order to better estimate the time needed for the development of a new feature.

3. Development (Implementation)

This phase follows Agile development practices, emphasizing small, manageable tasks, regular check-ins, and clear ownership.

  • Agile Development: Features are broken down into the smallest possible, manageable tasks. Work is prioritized in short sprints (1-2 weeks) with clear goals. Developers are expected to focus on completing tasks thoroughly rather than multitasking.
  • Version Control & Branching: Git is used for version control. Developers create a new branch for each issue and are required to check in code changes regularly. To reduce conflicts, developers merge the main branch into their working branch regularly.
  • Implementation Rules:
    • Developer Notes: Every PR must include developer notes summarizing the implementation, the reasoning behind significant decisions, and, for bug fixes, the cause of the bug and the solution.
    • Isolated Migrations: Every database migration must be in its own PR and must include a revert script that has been tested by the developer.

Acceptable vs. Unacceptable Beta Issues

Category Acceptable Unacceptable
UI & Edge Cases Very small inconsistencies Data loss or core workflow failures
Performance Non-critical inefficiencies Any data corruption or security flaw
Missing Enhancements Secondary features deferred Blocking or critical features missing

Issues that do not block core functionality can be deferred to future milestones.

4. Testing

Testing is a thorough, multi-stage process involving developers, dedicated testers, the Usability Group, and automated checks, with clear guidelines for providing feedback.

  • Developer Testing: Before requesting a review, developers must thoroughly test their changes, including running all previously-passing tests to check for regressions. Every migration’s revert script must also be tested.
  • Formal Review Process: A PR generally requires 2 developer approvals and 2 UX (tester) approvals before it can be merged. If changes are made to a PR after it has been approved, the developer must re-request review.
  • Tester Guidelines:
    • Scope: Testers must distinguish between issues that are “in scope” (directly related to the PR’s requirements) and “out of scope” (unrelated bugs, new feature ideas). Out-of-scope issues must be submitted as new bug reports or feature requests.
    • Feedback: Comments on a PR are organized into categories: Improvements and Bugs. Improvements are integrated if possible, otherwise are moved to separate issues. Bugs, if they are within the scope of the PR, are to be resolved.
  • Automated Testing:
    Unit tests are automated assessments that validate the functionality of individual elements in isolation, ensuring code components perform correctly. This enhances the overall reliability and maintainability of the application.
    • Frontend Unit & Snapshot Tests: The frontend utilizes the Jest Testing Framework
    • Unit tests focus on the correctness of the code (e.g., fetchPickListItems), while snapshot tests concentrate on the visual integrity of the UI by comparing UI output to stored reference images.
    • Backend Unit Tests: The backend utilizes the testing framework within Django. These tests use mock data to test code functionality.
    • Database-Agnostic Approach: All automated testing procedures are designed to be completely separate from the application database. This isolation ensures that tests are not affected by database issues and that tests do not inadvertently modify real data, preserving data integrity.

5. Deployment (Release)

The release process is managed through GitHub Pull Requests with strict merging rules and clear communication.

  • Merging Rules: A PR with the required approvals that is part of the current milestone is to be merged immediately.
  • Capturing Future Work: Before a PR is merged, all known bugs or desired improvements discovered during the review process must be captured as new issues. A note is left on the PR linking to these new issues.
  • Release Cycle: The team produces new capabilities in regular software releases and fixes bugs in minor updates.

6. Maintenance and Support

Maintenance is a structured part of the development cycle, with clear procedures for handling user issues and onboarding new members.

  • Issue Tracking: All support and maintenance tasks must be tracked as GitHub issues. This helps the team identify recurring problems and address underlying design flaws, documentation gaps, or training needs.
  • Bug Triage: When a bug is reported, support staff and developers will work to discover the cause and thoroughly document the issue on GitHub, noting the reporting collection or institution.
  • Security: If a security vulnerability is found, our team follows the process described here: Patch Management and Security Update Policy
  • Onboarding and Migration: A significant part of the team’s work involves supporting new members. This includes data analysis, workflow planning, data migration, and training.