Attention!
The content on this site is a materials pilot. It represents neither changes to existing policy nor pending new policies. THIS IS NOT OFFICIAL GUIDANCE.
Course overview
As we work our way through the lessons, things become more nuanced. In lesson three, we take a look at some of the medium and lower priority dimensions of the rubric that help deepen our understanding of the principles behind software development health.
| Health indicator | Topic |
| Outcomes-orientation | User outcomes |
| State capacity | Questioning the teams |
| Procurement flexibility | Managing data |
| Iterative development | Data: The database |
| Iterative development | Data: Migration |
| Admin | Course three- Report out |
What this course covers
In the third course, we begin our exploration of the nuances of contracting and some of the more subtle aspects of thinking about software as an ongoing service obligation (as opposed to a one-and-done product purchase). We also learn a little about data to help you recognize best data management practices in software projects.
Outcomes-orientation - User outcomes
In this lesson, we’ll shift our focus from considering user experience as an testing metric to considering user experience as an outcome. We’ll learn why it’s just as important to think about users at the beginning of a project as it is throughout the project’s development. We'll also discuss accessibility concerns and how to ensure that what we're building is as inclusive as possible.
Ask how feedback from users impacts priorities.
Ask how the state ensures services are accessible for all.
- Bad: The team has no information about the current user experience.
- Meh: The team has information about the current experience but has not spoken directly to users.
- Good: The team has collected feedback from end users directly and can demonstrate how they apply what they learn.
State capacity - Questioning the teams
To have a functioning software team, you gotta get folks on the same page. This lesson helps you figure out whether everyone on the team knows the story and how well they know it.
Ask detailed questions about technology, program goals, end users, etc.
Pay attention to who answers each question.
- Bad: Team members can't answer questions about the project or issues in plain language.
- Meh: Team members rely on vendors to answer questions, but answers are in plain language.
- Good: All team members (including IT and procurement) can speak in plain language about the project.
Procurement flexibility - Managing data
Data is big business. Many contractors have learned that if they build a system that "locks in" the government, they not only "own" the data (potentially tying the government to them as a vendor in perpetuity), but the data itself becomes a valuable commodity to be resold on the open market. Neither of these outcomes necessarily serves the people.
Ask how the state manages and accesses system data.
- Bad: The state has little or no visibility into how data is stored or accessed.
- Meh: The state can use the vendor's tools to access data, but does not own the data.
- Good: The state owns and controls access to all data.
Iterative development - Data: The database
An application involves both data and processes that operate over that data. Without the data, the application is nothing. As a result, how that data is organized, where it is stored, and who controls it all become critical questions in the lifecycle of a long-running software project.
Ask how the state approaches security, performance, and migration testing.
Ask how project leads interact with the testing process.
- Bad: The team cannot answer what types of testing they are doing, only that they test at the end of the process.
- Meh: The team can describe their testing approaches but testing is done by a siloed team.
- Good: The team can demonstrate their testing approaches. Testing and development is done by the same team.
Iterative development - Data: Migration
Security in applications for federal agencies is absolutely critical. Our work is held in the public's trust and it is up to us and our vendors to make sure that trust is not broken. Likewise, having migration strategies and practices in place means that we know how an application will grow, change, and accommodate the needs of users over time--another kind of security.
Ask how the state approaches security, performance, and migration testing.
Ask how project leads interact with the testing process.
- Bad: The team cannot answer what types of testing they are doing, only that they test at the end of the process.
- Meh: The team can describe their testing approaches but testing is done by a siloed team.
- Good: The team can demonstrate their testing approaches. Testing and development is done by the same team.