136 |
137 |
138 |
139 |
140 |
--------------------------------------------------------------------------------
/assets/discovercadence.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/assets/discovercadence.png
--------------------------------------------------------------------------------
/assets/encasement.mp4:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/assets/encasement.mp4
--------------------------------------------------------------------------------
/assets/modular-experience-deck.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/assets/modular-experience-deck.jpg
--------------------------------------------------------------------------------
/assets/modular-experience2021.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/assets/modular-experience2021.pdf
--------------------------------------------------------------------------------
/assets/product-architecture-demo.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/assets/product-architecture-demo.jpg
--------------------------------------------------------------------------------
/assets/search-prototype-high-level-technical-overview.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/assets/search-prototype-high-level-technical-overview.pdf
--------------------------------------------------------------------------------
/assets/worklevels.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/assets/worklevels.png
--------------------------------------------------------------------------------
/azure-devops/DeploymentPipeline.md:
--------------------------------------------------------------------------------
1 | # Create an Azure DevOps CI Pipepline
2 |
3 | ## Sign into Azure DevOps
4 | 1. Obtain a valid Azure DevOps login with access to the Alaska DHSS portal
5 | 2. Navigate to the [DHSS Azure DevOps Portal](https://alaskadhss.visualstudio.com/Dpa)
6 | 3. Enter credentials to sign-in
7 |
8 | ## Create ASP .Net Application
9 | 1. Navigate to Build/release
10 | 2. Click +New
11 | 3. Search for ASP.NET Core and click "Apply"
12 | Name: (e.g. Dpa-Eisr-UnifiedSearch Production)
13 | Agent Queue: (e.g. "Hosted VS2017")
14 | 4. Click "Get sources" in the task pane
15 | 5. Select "This Project" for "From" section.
16 | 6. Select (e.g. "Dpa-Eisr-UnifiedSearch") for "Repository"
17 | 7. Select "Master" for "Branch"
18 | 8. Select "False" for "Clean"
19 | 9. Click on "Restore" and change version to "2.* (preview)"
20 | 10. Click on "Build" and change version to "2.* (preview)"
21 | 11. Click on Test and change version to "2.* (preview)"
22 | 12. Click on Publish and change version to "2.* (preview)"
23 | 13. Click on "Triggers"
24 | 14. Click on "Enable Continuous integration" to enable
25 | 15. Click "Save"
26 | 15. Leave "Select Folder" to "\" which is the root
27 | 16. Click "Save"
28 |
29 | ### Add specific build steps
30 |
31 | Add these build steps before the "Publish" steps
32 |
33 | 1. Add "Node Tool Installer" step and match the version specified by the code,
34 | 2. Add "PowerShell" step to execute client-side build script included in the codebase
35 |
36 | >Note: At this point you can click "Queue" to kick off a build to test to see if things have been setup correctly.
37 | ### Create Release Definition with CI enabled
38 |
39 | 1. Click on "Releases"
40 | 2. Click "+" and Select "Create release definition"
41 | 3. Select "Azure App Service Deployment" template and click Apply
42 | 4. Click "+ Add" in the Artifact box
43 | 5. Select "Build" for "Source Type"
44 | 6. Select (e.g. "Dpa-Eisr-UnifiedSearch Staging")
45 | 7. Click "Add"
46 | 8. Click on Lighting Bolt icon in "Artifacts"
47 | 9. Click toggle to "Enabled" to enable Continuous deployment trigger
48 | 10. Add a "Build branch filter", either "staging" or "master". This prevents CI builds on PRs from triggering Releases
49 |
50 | ### Point CI pipeline to publish to Azure Gov
51 | 1. Click "1 phase, 1 task" under "Environments"
52 | 2. Type in “Web” for "Environment name"
53 | 3. Select "DHSS Azure Government" for "Azure subscription"
54 | 4. Select (e.g. "DPAEisrUnifiedSearch") for "App service name"
55 | 5. Click “Deploy Azure AppService” release step
56 | 6. Check “Deploy to Slot”
57 | 7. Select “ResourceGroup” (e.g. “DPAEisrUnifiedSearch”)
58 | 8. Select “Slot” “Staging”
59 | 9. Under “Package or folder” click … and select Web.zip as the package to deploy.
60 | 10. Add an Environment and repeat the previous block of steps for the “Api” project/environment.
61 | 11. Click "Pipeline" to view Artifacts and Environments settings
62 | 12. Click "Save" button on the top right hand side of the screen
63 | 13. Click "Pipeline" to view Artifacts and Environments settings
64 | 14. Click "Save" button on the top right hand side of the screen
65 |
66 | ***Add Veracode***
67 | - Click [HERE](Veracode.md) to view Veracode setup documentation
68 |
--------------------------------------------------------------------------------
/azure-devops/GitBranchingStrategy.md:
--------------------------------------------------------------------------------
1 | # Git branching strategy
2 |
3 | We will have two long-lived git branches, `master` and `development`.
4 |
5 | `master` will continuously deploy to our staging environment.
6 |
7 | `development` will continuously deploy to our development environment.
8 |
9 | We have a development and staging environment as an Azure AppService.
10 |
11 | ## Starting new work
12 |
13 | When someone begins new work, they cut a new branch from `development` and name it after their work, perhaps `feature1`. New changes are pushed to the feature branch origin (DevOps) often. CI is configured to build all pull-requests (PRs) but new commits to `feature1` will not trigger a new build.
14 |
15 | ## Merging to `development`
16 |
17 | When new work is complete, we set up a Pull Request (PR) from `feature1` to `development`. Discussion about, and approval of changes happens in the PR interface in DevOps.
18 |
19 | Once this new work is approved we close the PR, which merges the code. From here, our CI pipeline will build the new changes on the `development` branch. Next, our CD pipeline will deploy the new work to our development environment.
20 |
21 | ## Merging to `master`
22 |
23 | Once a new body of work is merged to `development` (likely via multiple PRs) and any manual QA work has finished in the development environment, we set up a PR from `development` to `master`.
24 |
25 | This constitutes a new production release candidate. Any last-minute discussion, as well as approval happens in the PR interface. Once approved and merged, CI runs for `master`. Finally, CD runs and deploys the `master` branch to the staging environment.
26 |
27 | ## Race conditions on merges to development
28 |
29 | Imagine two PRs called A and B are open against the `development` branch. The two PRs both change code in the same file. Now, we merge PR A to development. After this merge PR B will report that it is "unmergeable" in DevOps. This is because `development` contains the changes from PR A, but PR B does not contain those changes -- git doesn't know what to do.
30 |
31 | In this case we have a couple options.
32 |
33 | 1. Rebase: `git rebase B_branch development`. Rebasing the branch replays all of the commits from B on top of the _new_ `development` branch (which now contains changes from A). Rebasing is the preferred method for handling these issues. Push the `B_branch` and you'll be able to use DevOps to close the PR.
34 | 2. Manual conflict resolution. Instead of using the DevOps UI to merge the PR, execute the merge locally. `git checkout development && git merge B_branch`. Git will report merge conflicts, which you can resolve locally, manually, using your editor. When you're done push the `development` branch and DevOps will automatically close the open PR.
35 |
36 | ## Patching production/master
37 |
38 | Imagine that many PRs have been merged to `development`, and you find a problem in production that needs a quick fix. At this point `development` has moved far past `master`. In this case we code the fix to production in a new branch cut from `master`, maybe called `prod_fix`. We set up a PR against `master` for review and discussion.
39 |
40 | Any QA or manual testing will take place in a one-off environment deployed from the `prod_fix` branch; with the Azure PaaS we could manually deploy to an empty Deployment Slot. Once the PR on `master` is merged CI/CD takes care of deployment to the production environment.
41 |
42 | Now we have to bring those new changes in master back into development. We use rebase again: `git rebase development master`.
43 |
44 | ## Incorporating fixes into a Release Pull Request
45 |
46 | A Release Pull Request is a PR that is set up from a "frozen" branch, usually to `master`.
47 |
48 | The code in a PR may need to be updated to pass a build, or to incorporate feedback, or for some other reason.
49 |
50 | After our PR code looks good, we need to `cherry-pick` these changes back into our development stream.
51 |
52 | Here are steps that cut a new Release branch from master, make some changes, then re-incorporate those changes into the development stream.
53 |
54 | ```
55 | git checkout development
56 | git pull
57 | git checkout -branch sprint-1-release
58 | git push
59 |
60 | # At this point, set up a PR from `sprint-1-release` -> `master` in DevOps.
61 | # Problems were found in the `sprint-1-release` branch, so you made fixes, added, committed, and pushed them to `sprint-1-release`
62 |
63 | git log
64 | #From the log output, gather the commit SHAs for any changes that you made. Let's say we have two, `SHA1` and `SHA2`
65 |
66 | git checkout development
67 | git cherry-pick SHA1
68 | git cherry-pick SHA2
69 | git push
70 | ```
71 | Now, you have pulled two specific commits from the release branch, and applied them to the development stream.
72 |
--------------------------------------------------------------------------------
/azure-devops/Veracode.md:
--------------------------------------------------------------------------------
1 | # Veracode Azure DevOps Integration
2 |
3 | See [Instructions for the Azure DevOps Veracode plugin](https://marketplace.visualstudio.com/items?itemName=Veracode.veracode-vsts-build-extension&targetId=3a6fdb87-28e4-40c1-95d9-87028e93af8f) for information used to create the following procedure. You will need to do the following to integrate Azure DevOps and Veracode:
4 |
5 | ## Veracode portal configuration
6 |
7 | **Option1:** Setup using Veracode generated API Credentials and Secret key
8 |
9 | 1. Obtain a valid Veracode login with access to the State of Alaska portal and the EISR application
10 | 2. Login to [Veracode portal](https://analysiscenter.veracode.com)
11 | 3. Hover over the "State of Alaska" dropdown link - a menu drops down
12 | 4. Click on "API Credentials" menu item - the _API Credentials_ page loads
13 | 5. Click on "Generate API Credentials, this will create an API ID and Secret Key
14 | 6. Copy and store these credentials in a secure place (after creation you can revoke the credentials, but cannot access them)
15 | 7. Go to the target application in Veracode and ensure a Sandbox is setup associated with the API credentials.
16 |
17 |
18 | **Option2:** Setup using Veracode API Account
19 | Veracode portal using Veracode API account
20 |
21 | 1. Obtain a Veracode API Account username and password information with access to the State of Alaska portal and the EISR application. The account should have the following roles set.
22 | a. Mitigation API
23 | b. Upload API
24 | c. Upload API - Submit Only
25 | d. Results API
26 | 2. Go to the target application in Veracode and ensure a Sandbox is setup associated with the API credentials.
27 |
28 | Note: At this time we are choosing option 2. The endpoint can be used agains multiple branches (i.e. staging and production)
29 |
30 | ## Azure DevOps Veracode plugin configuration
31 |
32 | 1. Add the "Upload and scan" Veracode plugin task to the Azure DevOps build definition
33 | 2. In the Upload and scan Veracode Azure DevOps build plugin task, select the _Endpoint_ connection source from the _Select Connection Source_ radio button options
34 | 3. If there is a Veracode endpoint defined in the _Select Endpoint_ droplist select it and skip to step (9), otherwise click the _+_ symbol to the right of the _Select Endpoint_ field
35 | 4. Choose the _Veracode Endpoint_ radio button
36 | 5. Name the endpoint
37 | 6. Paste the Veracode API ID obtained in step 4 of Veracode configuration into the _ID_ field
38 | 7. Paste the Veracode API Secret Key obtained in step 4 of Veracode configuration into the _key_ field
39 | 8. Click _OK_ and make sure the Veracode endpoint is selected in the _Select Endpoint_ droplist
40 | 9. Create a build definition variable called Veracode.AppName, e.g., "ARIES-WP" as the value (note: this ties the code scan to the licensed app in Veracode, in these instructions the example "ARIES-WP" ties to the Aries worker portal license. Work with the DHSS Veracode administrator if setting up for scan of something besides the ARIES worker portal.)
41 | 10. In the Upload and scan Veracode Azure DevOps build plugin task, enter _$(Veracode.AppName)_ into the _Application Name_ field
42 | 11. Expand _Advanced Scan Settings_ and enter the name of the Veracode Sandbox
43 | 12. Enable the Upload and scan Veracode Azure DevOps build plugin task
44 | 13. Click the _Save & queue_ button to save the build definition and queue a build to test the task
45 |
46 | If this is the first time you are submitting a scan for the particular app/sandbox you will need to do the following after the build started in step 13 has finished uploading binaries to Veracode.
47 |
48 | 1. Login to [Veracode portal](https://analysiscenter.veracode.com)
49 | 2. Click on Application
50 | 3. Click on the link for the build started in step 13 in the previous section.
51 | 4. Hit refresh until the status states "Select Modules to be scanned".
52 | 5. Scroll down through the list of binaries and validate the modules you want scanned are selected.
53 | 6. Click on the "Scan" button at the bottom of the page to start the scan.
54 |
55 | ## Troubleshooting
56 |
57 | ### No files found
58 |
59 | If Azure DevOps build reports the build artifacts were not found, ensure there is a publish step that moves the build artifacts to the Build.ArtifactStagingDirectory
60 |
61 | ### Veracode upload and scan task timeout
62 |
63 | Azure DevOps build tasks timeout by default after 60 minutes of waiting for the scan to complete. There are three scenarios we have seen with these timeouts:
64 |
65 | 1. Scan actually took longer than 60 minutes
66 | 2. Scan got stuck and needs action on the Veracode portal
67 | 3. Something else went wrong and file upload failed in-progress
68 |
69 | We diagnose and resolve all scenarios in the Veracode portal.
70 |
71 | ### Scan took longer than 60 minutes
72 |
73 | Sandbox scans are appropriately used for scanning of pre-production (dev, test) code, but Veracode gives sandboxes lower priority in resource scans. This appears to mean that sometimes a sandbox scan will pause inexplicably. This is rare, but it does happen. When this occurs you can see in the Veracode portal that the scan is in progress and there are no errors or prompts, or you see that the scan completed. _Note that in this case, the scan does (eventually) finish without intervention and subsequent builds will be able to scan, i.e., no additional intervention is required to avoid breaking the build.
74 |
75 | ### Scan got stuck
76 |
77 | Sometimes we have seen scans get stuck when they use the "Previous Selection" for the modules file selection. This selection is found in the sandbox:
78 |
79 | 1. Click _{ScanID}_
80 | 2. Click _Review Modules_
81 | 3. Click _Simple Mode_ tab
82 | 4. Within the _Uploaded Modules_ _Scan Details_ section review the _File Selection_
83 |
84 | When this scenario occurs, _File Selection_ will be "Previous Selection". Change the value in _File Selection_ to "Veracode Default", then click the _Start Scan_ button (will become enabled after _File Selection_ change). This will start the scan and it typically completes within a reasonably short time frame.
85 |
86 | ### Something else went wrong
87 |
88 | Once or twice we have seen a scan get stuck where the file upload failed in progress. In this case, the only option is to delete the scan and re-queue the build in Azure DevOps.
89 |
90 | ### Veracode account does not have correct privileges
91 |
92 | The Veracode API account needs to have the appropriate privileges. For our endpoint we need ensure the account have the following user roles:
93 |
94 | 1. Mitigation API
95 | 2. Upload API
96 | 3. Upload API - Submit Only
97 | 4. Results API
98 |
99 | ### Build Failed : Exit From Scan Inspection Process, Cannot Find New Scan Build ID
100 |
101 | This error happens when multiple builds are queued on the same Veracode Sandbox. Azure DevOps build logs should also contain the following text, though it it not called out as an error:
102 |
103 | ```
104 | * Action "UploadAndScan" returned the following message:
105 | * App not in state where new builds are allowed.
106 | * A scan is in progress or has failed to complete successfully. Wait for the current scan to complete or delete the failed scan from the Veracode Platform and try again.
107 | ```
108 |
109 | #### Final notes about scan timeouts
110 |
111 | Note that whenever a scan is stuck, Veracode will not allow further scans within that sandbox. The problem must be resolved in the Veracode portal before Azure DevOps builds queued that target that Veracode sandbox will succeed. Until then the stuck scan results in breaking the build.
112 |
--------------------------------------------------------------------------------
/code-review.md:
--------------------------------------------------------------------------------
1 | # Code Review Process
2 |
3 | ## Introduction
4 |
5 | It is important to approach a code review with the right frame of mind:
6 |
7 | * Expect to ask lots of questions, not as an interrogation, but as an ongoing conversation, taking place between DOH and the vendor.
8 | * This is an Agile process and, as such, we treat the output of every sprint as a completed product. Security, accessibility, UX, tests, browser compatibility, etc. are not features, to be implemented in future sprints, but are things that we expect to be incorporated constantly, and completed at the end of each sprint.
9 | * Remember that we are all learning together here. If you see something in the code that you don’t understand, it’s incumbent on you to say so. Maybe you know something that the developer doesn’t, maybe the developer knows something that you don’t, but they only way to find out is to ask.
10 |
11 | ## What we look for
12 |
13 | Code reviews are about keeping code clean and limiting technical debt. We will look for things that increase technical debt or create an environment where technical debt can be introduced easily later.
14 |
15 | ### Untested code
16 | We’re mostly going to look at new and changed code. For changed code, we’ll check the existing tests to make sure they’ve been updated if necessary. For new code, we’ll check that new tests were created.
17 |
18 | ### Does not contain secrets
19 | We look to ensure that new and/or changed code does not contain secrets (account names, passwords, private keys, private hostnames, service endpoints and other confidential secrets).
20 |
21 | If a confidential secret is committed and is discovered during code review, it needs to be [removed from history](https://help.github.com/articles/removing-sensitive-data-from-a-repository/). Creating a new commit that deletes the secret but leaves it discoverable in the git history is not sufficient.
22 |
23 | ### All logical paths are tested
24 | Tests should cover all branches of logical decisions (e.g., if statements). We’ll check this by looking at a code coverage report that shows which lines were executed.
25 |
26 | ### Logical AND and OR operations are tested
27 | Boolean operations can be somewhat hidden logical paths. That is, a code coverage report will show every line is tested, but if boolean parts of a condition aren’t fully exercised, then some logical paths aren’t actually tested. We’ll check the tests to make sure they check both sides of logical operations.
28 |
29 | ### Test names describe what the tests are doing
30 | Test names shouldn’t be overly technical. Ideally folks outside the development team can read the tests and know what’s passing and what’s failing. Test names should describe their behavior and not just be the name of the method being tested. We’ll check the test names to make sure they’re descriptive.
31 |
32 | ### Tests actually do what they’re supposed to
33 | It’s easy to get to 100% code coverage without actually testing anything. We’ll look at the tests themselves to make sure they’re actually making the right assertions about the methods under test.
34 |
35 | ### Cyclomatic complexity, code depth, and method lengths are reasonable
36 | We’ll use automated tools to do [static source analysis](https://18f.gsa.gov/2016/10/04/what-is-static-source-analysis/). Anywhere the metrics are higher than what we’d generally like, we’ll look at the code itself to see if they make sense. We’re going to take a more in-depth look when we a cyclomatic complexity above 10, a code depth above 5, or a method length above 25 lines.
37 |
38 | ### Opportunities to abstract and refactor
39 | We’ll look for duplication in the code where it might make sense to break functionality into methods that can be reused.
40 |
41 | ### Unwieldy methods
42 | Methods that are hard to reason about are also difficult to test, difficult to maintain, and prone to bugs. We’ll look out for methods that are complex and suggest either refactoring that method or possibly breaking it into smaller pieces.
43 |
44 | ### Meaningful method and variable names
45 | Method names should accurately reflect what the method does, and variable names should pretty clearly indicate what data they’re holding. Don’t be afraid of long names. This also applies to method argument names. Ideally, someone looking at a method signature should be able to infer what it does without any additional documentation. We’ll look at these names to be sure they make sense. Good naming practices contribute to self-documenting code and reduce the manual documentation burden.
46 |
47 | ### Commented-out code
48 | With good version control, it should be unnecessary to comment out blocks of code — just delete them and get them from source history if you really need them again in the future. Obviously it’s fine to comment out code while you’re developing, but once a feature is ready to merge, that former code should just be removed. We’ll be looking for these commented code blocks.
49 |
50 | ### Necessary comments
51 | Comments in the code should describe complex bits of logic that aren’t easily glanceable — if someone new to the code can’t skim it and understand it, a comment might be in order. As we’re reviewing the code, if we find a bit we can’t understand quickly from the code and context, we’ll be looking for a comment that explains it. Comments should appear with the code they’re describing.
52 |
53 | ### Documented APIs
54 | If code exposes a public API — whether that’s public methods on a class or HTTP endpoints in a REST service — those public methods should be documented. We like documentation that can be extracted into some pretty markup (e.g., .NET’s XML comments, jsdoc, or [OAS](https://www.openapis.org/) — formerly Swagger). We’ll check that any public-facing methods have useful documentation.
55 |
56 | ### Adherence to the project’s style guide
57 | The project should adopt a code style guide and code should conform. Which guide the team chooses is less important than the consistency that comes from actually using it. We’ll check to make sure there’s a linter configured to check code style, that it passes, and that any exceptions are documented and explained in the code.
58 |
59 | ## What we’ll do
60 |
61 | ### We’ll be nitpicky
62 | Code is a UX. Its users are other developers. In the spirit of user-centered design, we’ll be interested in the experience of future developers. We’ll look at code with this question in mind: “Would I want to work on this?”
63 |
64 | ### We’ll be thorough
65 | After the work to write the code, it deserves for us to give it proper attention. We’ll take the time to carefully look over it and give our feedback.
66 |
67 | ### We’ll ask questions
68 | If we’re not sure about something, we’ll ask for clarity. We may ask a lot.
69 |
70 | ### We’ll be kind
71 | We wouldn’t want anyone being mean to us because of an oversight, mistake, or just a different idea, and we’ll extend that courtesy to others. Code reviews are really conversations, not dictates. We’ll make suggestions rather than simply saying, “that’s wrong.”
72 |
73 | ## Checklist
74 |
75 | We use this list when performing a code review to ensure that all tasks have been completed.
76 |
77 | - [ ] review the pull request itself, to get oriented
78 | - [ ] read the description of the pull request, which should summarize the changes made
79 | - [ ] read through every task on the Scrum board that's encompassed by this pull request
80 | - [ ] read the description of every commit that comprises the pull request
81 | - [ ] deploy the site on your local system
82 | - [ ] test all functionality in all major browsers, emphasizing the functionality that this pull request addresses
83 | - [ ] the browser to test the most thoroughly is Internet Explorer 11 on Windows 10
84 | - [ ] also test in Edge, Chrome, and Firefox
85 | - [ ] use an automated audit tool for code quality and practices (recommended: Chrome Audit)
86 | - [ ] look at efficiency of page loads, asset sizes, HTTP connection management, etc.
87 | - [ ] review for accessibility
88 | - [ ] use an automated audit tool, such as Chrome Audit or aXe
89 | - [ ] navigate site only with the keyboard
90 | - [ ] use VoiceOver or Narrator to navigate the site with audio only
91 | - [ ] manually test anything that pa11y cannot test automatically (e.g., contrast of text over images)
92 | - [ ] review static code analysis results, make sure everything is OK
93 | - [ ] critically read all new code, in the context of existing code, [looking for problems](#what-we-look-for), e.g.:
94 | - [ ] make sure names of methods and variables are sensible
95 | - [ ] make sure code does not contain secrets
96 | - [ ] be suspicious of commented-out code
97 | - [ ] any code with a purpose that isn’t immediately clear should have a comment explaining it
98 | - [ ] check that code style is consistent
99 | - [ ] be suspicious of any code that accepts input from the outside world, ensure that it doesn’t enable any kind of buffer overflows or SQL injection attacks
100 | - [ ] tests
101 | - [ ] look at code coverage of tests on Azure DevOps
102 | - [ ] review all new tests for correctness, quality of naming
103 | - [ ] determine what code isn’t tested, review that carefully
104 | - [ ] review documentation to ensure that it matches changes
105 | - [ ] comment on Azure DevOps
106 | - [ ] for comments that are tied to a particular line of code, use Azure DevOps's line-commenting functionality
107 | - [ ] for comments are are more general, comment on the pull request itself
108 | - [ ] open an Azure DevOps bug report for each feature-level bug (i.e., it’s working as designed, but designed wrong), putting it in the backlog
109 |
--------------------------------------------------------------------------------
/first-buy-postmortem.md:
--------------------------------------------------------------------------------
1 | # Alaska’s Eligibility Information System Modernization Project Post-Mortem
2 |
3 | ## Reflecting on the good and the bad from Alaska and 18F’s first contract
4 |
5 | July 25, 2018
6 |
7 |
8 | ## Background
9 |
10 | In December 2017, Alaska’s Department of Public Assistance [announced the award](https://github.com/AlaskaDHSS/EIS-Modernization/blob/ffe20eeb7f7ca2b3b5606ddc5ee26838ee05f80f/vendor-info/RFP-Search-Unification-Award.md) of their first agile software development contract to Resource Data, Inc., an Alaskan company based out of Anchorage, AK. Work began in January, and concluded at the beginning of June. This was the first of many smaller contracts that Alaska is going to award as part of implementing their modular approach to modernizing their Eligibility Information System (EIS). See Alaska’s GitHub repositories for additional background information on the [modernization strategy](https://github.com/AlaskaDHSS/EIS-Modernization/blob/master/README.md) and the first RFP that will update the [Search](https://github.com/AlaskaDHSS/RFP-Search-Unification/blob/master/README.md) functionality of the existing systems. An [initial post-mortem about the RFP process](https://github.com/AlaskaDHSS/RFP-Search-Unification/blob/master/post-award-vendor-info/Post-Mortem_on_the_first_Alaska_buy.v2.pdf) was held after the contract was awarded, but before work had started; this post-mortem was held in June, after the vendor’s work had been completed.
11 |
12 | ## Purpose
13 |
14 | On June 14, 2018, the EIS-R (Replacement) Product Team from Alaska and 18F held a "Post-Mortem" session as part of our commitment to continuous improvement. In thinking about the first buy in our modular procurement strategy, we considered what things worked well, and what things did not work well. The context for this exercise was the post-award period, during which [Resource Data, Inc.](https://www.resourcedata.com/) (RDI) was working.
15 |
16 | ## What worked well?
17 |
18 | The team was asked to identify a number of items that worked well during the procurement, whether it was under our team’s control or not.
19 |
20 | ### The vendor’s work was very good
21 |
22 | The team agreed that the work of RDI was high-quality, and that they proved to be a good partner.
23 |
24 | - "Selected vendor did a solid job on delivery."
25 | - "Procurement resulted in very clear top candidates."
26 | - "Good trust with vendor."
27 | - "What they said, they did."
28 | - "This vendor was real from the get-go, and delivered what we asked for."
29 |
30 | ### DPA’s capacity for "owning product" and product management *grew significantly* over the course of the engagement
31 |
32 | The team noted that DPA staff on the team had improved in their own work during the five-month process.
33 |
34 | - "There was a great escalation in DHSS’ work over the course of the project."
35 | - "Got to try out new things and experiment with new ways of working."
36 | - "After some initial process hiccups, State tech staff got into delivery pattern for our responsibilities."
37 | - "State staff paired well into new processes like code reviews."
38 | - "Alaska started taking on more and more of the code reviews from 18F."
39 | - "We hit a rhythm with regard to our process about halfway through."
40 |
41 | ### The vendor and DPA collaborated well
42 |
43 | RDI worked in the style that DPA is transitioning to working in, and proved a good partner for this first procurement because of that.
44 |
45 | - "The tone of the engagement was really trusting, open, and collaborative."
46 | - "RDI led in the ways that we needed them to lead (crucially for this first procurement), and followed in the ways that we needed them to follow."
47 | - "There were several occasions when we needed RDI to be flexible, and they did so well."
48 | - "RDI called out issues when the State wasn’t doing what they committed — the contract document actually provided useful guidelines."
49 |
50 | ## What didn’t work well?
51 |
52 | ### DPA is yet to deploy software to users
53 |
54 | While the product was built incrementally each sprint, the DPA team failed to successfully facilitate deploying that code to end-users at the end of each sprint, or even by the end of the engagement, failing to employ agile correctly and gain the associated benefits. This was primarily the result of security policies and practices, crafted for monolithic software procurements that are not compatible with the rapid delivery of user-tested software increments, that resulted in extensive Authority to Operate (ATO) work which is ongoing. Although the software produced during this buy was informed by user research, and iteratively built, users were not able to interact with functional code and reliable data and provide direct feedback on the built product, missing the benefits of the agile feedback loop.
55 |
56 | - "We got stuck when it came time to actually access data and put it in front of users."
57 | - "The failure to actually employ agile — delivering value to end-users — was far and away the biggest problem."
58 | - "Delivering iteratively to actual users, and getting their feedback into the process, was a persistent challenge."
59 |
60 | #### Action Items
61 |
62 | - Do not begin agile projects without a clear path to deploy to staging at the end of the first sprint, and to production early and frequently.
63 | - Ensure that projects under development have access to test data that is a realistic, complete simulation of the live data.
64 | - Unblock the organizational obstacles to a path to deployment (which are specified as other issues, below).
65 |
66 | ### DPA and DHSS aren’t yet set up to support agile fully
67 |
68 | It is not enough to hire an agile development team and have a DPA product team work with them in an agile fashion, because the entire process is dependent on people within DPA and DHSS who are not a part of that process, and may not have benefited from the resources and freedoms afforded to the product team. This disconnect, between those who were part of the process and those who weren’t, prevented the development team and the product team from completing their work.
69 |
70 | - "Tension between a new approach and old one."
71 | - "Now we’ve had to deal with a whole bunch of security issues we’ve never had to deal with before. Trying this in a new way uncovers those issue."
72 | - "We’re not across the chasm of DevOps."
73 | - "We focused on ’security plan,’ but we missed prioritizing and prototyping make-or-break technical security controls."
74 | - "The state wasn’t able to keep pace with the vendor because of infrastructure/security issues."
75 |
76 | #### Action Items
77 |
78 | - Before beginning any new projects, research and document the security requirements, and engage with the security team as early as possible.
79 | - Do a better job of helping the security team to perceive the time- and resource-saving value of DevSecOps.
80 | - DHSS needs to adequately staff the security office. All indications are that three people is an insufficient number.
81 | - Ensure that there is buy-in at all levels to help remove unnecessary friction when working with security, network, and ops teams.
82 |
83 | ### Critical design work fell to 18F
84 |
85 | The initial design work was not what we believed that the project needed, necessitating a significant correction. That happened at a crucial point early in the development process, and required that we lean heavily on 18F to perform design work, to ensure a smooth transition and to keep the team from losing velocity. This was handled quickly and smoothly by all involved, and little time was lost as a result.
86 |
87 | - "Initial design approach and subsequent need for 18F to establish the initial design direction to keep things moving."
88 | - "Vendor pivoted agreeably"
89 |
90 | #### Action Items
91 |
92 | - When design is a critical part of an increment, be thoughtful about design expertise representation on future vendor-assessment panels.
93 | - Reconsider the point weighting that goes towards design expertise.
94 | - Personnel changes are difficult to anticipate, and must be dealt with _in situ_, but should not be avoided if a course correction is necessary. This case was handled directly, and should serve as a guide for handling similar problems in the future.
95 |
96 | ### Unsustainable levels of involvement were needed from some staff
97 |
98 | Some DPA staff on the project found it challenging to maintain the necessary level of work for their role, due to unrelated obligations on other projects. This sometimes blocked the work of others, preventing progress on the project.
99 |
100 | - "People were spread across too many projects, not as focused as they should be."
101 | - "Lack of availability for product owner in the engagement."
102 | - "There were AK tech staff resource constraints."
103 |
104 | #### Action Items
105 |
106 | - When staffing a project, set expectations for how much time that it is going to require over what duration, and ensure that the necessary supervisors are prepared to support that commitment. This is especially true if the supervisors are in different organizations than most of the product team.
107 | - Get adequate time from a project’s assigned staff, rather than adding additional staff to an inadequately-resourced project, in order to minimize complexity.
108 | - If there is a need for staff that cannot be met with the current team, hire the right kind of talent to fill that staffing need.
109 |
--------------------------------------------------------------------------------
/how-we-work.md:
--------------------------------------------------------------------------------
1 | # How We Work
2 |
3 | ## Principles
4 |
5 | Our basic principles are those familiar to anybody who has contributed to a prominent open source project, or deployed code in a modern software environment.
6 |
7 | * We look to the future. Our objective is that our systems are secure and open source, created and maintained in repositories where code may be inspected by like minded developers who place their trust in it, copy it for use for use by other agencies, and share discovered solutions that increase the functionality or safety of the code.
8 | * We adhere to the basic practices of agile software development, using the Scrum development framework.
9 | * We use a DevSecOps approach that allows us to rapidly develop and deploy improvements to our systems, infrastructure- and configuration-as-code, and CI/CD to ensure that our work is high-quality. We integrate security compliance into the process.
10 | * We practice human-centered design. Everything that we produce is highly accessible, per WCAG 2.0. We build APIs before we build software atop it, and we believe that APIs require a well-designed interface.
11 | * We include and enforce codes of conduct, to foster an open, collaborative, welcoming environment.
12 | * We reduce system modifications to the smallest self-contained module, and procure each of those modifications via a unique RFP.
13 | * Finally, we believe in having the relevant decision-makers at the table during all meetings, to maximize efficiency and maintain momentum.
14 |
15 | ## Product Team
16 |
17 | There is a cross functional product team for the Alaska DOH modernization project (ARIES) comprised of business, policy, security, procurement and technical specialists who are working together to move the entire enterprise forward towards its goals. In addition to this high level team, each of our procurements will be managed by a more immediate set of people who will be working with the product owner and product managers on the Alaska DOH product team to deliver on the prioritized backlog for that particular procurement. This product team will be comprised of the following roles
18 |
19 | * Product owner - Alaska
20 | * Product manager(s) - Alaska
21 | * User Experience designer - Vendor
22 | * Visual designer - Vendor
23 | * Researcher - Vendor
24 | * Developers (Front-end, Back-end, Full-stack) - Vendor
25 | * Technical lead - Vendor
26 | * Scrum Master (or equivalent) - Vendor
27 |
28 | This team will participate in all scrum ceremonies in service of prioritizing, defining and delivering value to the department and the public it serves.
29 |
30 | ## Meetings
31 |
32 | There are two basic meeting rhythms: daily standups and agile sprint rituals. The sprint duration will be determined by the development team's leadership in consideration of the work to be done, and the resources available. The duration of a sprint is typically two weeks, resulting in semi-weekly agile sprint rituals.
33 |
34 | We hold regular, tight 15-minute standups, at a frequency decided by the team.
35 |
36 | As each sprint ritual begins, we conduct backlog grooming (prioritizing work in the backlog) and sprint planning (define the work to be done over the next sprint). Each sprint ends with a sprint review (demonstrate work done, and accept or reject that work) and a sprint retro. In the sprint retro, we review how the sprint went as far as people, relationships, processes and tools, identifying what went well and ways that we can improve quality and effectiveness. These are all held back-to-back, on the same day.
37 |
38 | All meetings are held via video teleconference. A telephone bridge is maintained as a backup method of connecting, but participants are encouraged strongly to join via desktop webcam.
39 |
40 | ## Design Research
41 |
42 | We recognize that the DPA field staff will be critical to helping us develop solutions that will deliver better service to Alaskans. In order to create an open and collaborative space for DPA staff to contribute, we will protect their privacy through the following:
43 |
44 | * Interview notes will be anonymized. The keeper of the key to participants is the state project UI/UX coordinator. (Joan Smith = Participant 1).
45 | * The full product team needs to understand the expectation for privacy around research materials.
46 | * Anonymized raw notes will be available to the small product team doing the work, but not beyond.
47 | * Synthesized notes and conclusions (still anonymous) can be shared publicly, including on Azure DevOps/GitHub as they are fully decontextualized.
48 | * Non-researchers on the product team can and should be involved with research.
49 | * Only research facilitators/observers can be included in synthesis.
50 | * We will inform research participants of these matters at the beginning of research sessions and ask for their consent. See [Research Participant Agreement](https://github.com/AlaskaDHSS/EIS-Modernization/blob/master/assets/20220627Design_Research_Participant_Agreement_ARIES.pdf).
51 | * An overview of our approach to user research, driven by usability testing, is [here](UsabilityResearch.md)
52 |
53 | ## Definition of Done
54 |
55 | So that we can work more efficiently and be confident in the quality of the work we are delivering, we have a clear definition of what it means for a user story to be done, or production-ready.
56 |
57 | * for delivering a user story to the product team
58 | * Story needs to be written in a way that is clear from both a development and a testing standpoint. Stories will need to be reviewed by the product team during creation. (this can be a subset of the whole product team)
59 | * Acceptance criteria should include the relevant tests needed (unit, security, performance, acceptance, etc)
60 | * Acceptance criteria should include the objective of the story, for use in approval by PO or tech team or both
61 | * The delivered functionality should match the acceptance criteria of the user story
62 | * All tests must pass in the staging environment (unit, integration, feature)
63 | * Test coverage must be greater than the percentage described in the Quality Assurance Plan
64 | * The delivered functionality should be 508 compliant
65 | * Security requirements must be met
66 | * All documentation must be up to date (diagrams, training documentation, API documentation, help text, etc)
67 | * The delivered functionality should be compatible with the latest versions of Edge, Firefox, Chrome and Safari
68 |
69 | * for product team to accept the user story and ship it
70 | * The product team has verified the functionality in staging
71 |
72 | ## Accepting Vendor Work
73 |
74 | Acceptance of work happens through the sprint as work is completed. The procedure is as follows:
75 |
76 | 1. Development team completes work - See "for for delivering a user story to the product team" in [Definition of Done](#definition-of-done) above
77 | 2. Development team creates pull request to staging - See [Pull Request Process](/azure-devops/GitBranchingStrategy.md)
78 | 3. The product team has verified the functionality against acceptance criteria in a deployed instance for a feature level pull request
79 | 4. Code review takes place - See [Code Review Process](code-review.md)
80 | 5. Pull request merged to staging DOH product team to accept the user story and ship it" in _Definition of Done_ above, and [Testing Strategy](#testing-strategy)
81 | 7. Product team creates pull request to master
82 | 8. DOH product owner and network services deployment team merges pull request to master
83 |
84 | ## Processes
85 |
86 | ### Tech Strategy
87 | We will move the programs currently in EIS off the mainframe within 5 years. This is a goal of the EIS modernization project. Strategies have been organized in themes. For more details about how we will do this work, see [EIS Replacement Project Technical Strategy](/tech-strategy.md).
88 |
89 |
90 | ### Testing Strategy
91 |
92 | We practice testing at three levels: unit tests, integration tests, and feature tests.
93 |
94 | * **Unit** - Unit tests must be created for all new code, during the sprint in which the code is written, with coverage of at least 90%.
95 |
96 | * **Integration** - Because all new work is integrating with the existing ARIES code base, new code must include tests that verify that interfaces are functioning as designed.
97 |
98 | * **Feature** - New features must have functional definitions of the thing that they are to perform, and a description of human-performable actions to verify that they perform that thing.
99 |
100 | For more information about how to create and maintain unit, integration and feature tests, see [18F’s “Automated Testing Playbook”](https://automated-testing-playbook.18f.gov/).
101 |
102 | ### Pull Request Process
103 | Documented in our [Git Branching Strategy](/azure-devops/GitBranchingStrategy.md).
104 |
105 | ### Code Review Process
106 |
107 | Documented in our [Code Review Process](code-review.md).
108 |
109 | ### DevSecOps
110 |
111 | We rely on [DevSecOps](DevSecOps.md) for automation and monitoring of code integration, testing, and deployment. Our DevSecOps pipeline is built atop Azure DevOps (not GitHub) for deployment to Azure. We practice continuous integration, continuous deployment, and continuous testing (including security testing). All new code has tests developed simultaneously, with cumulative test coverage of not less than 90%. See “Accepting Vendor Work” for more.
112 | For details, see our [“Why DevSecOps?” document](https://github.com/AlaskaDHSS/DevSecOpsMvp/blob/master/DevSecOps.md), in Github.
113 |
114 | ## Tools
115 |
116 | * **GitHub** - We use our [GitHub organization](https://github.com/AlaskaDHSS) for storing both software and collaboratively-maintained text.
117 |
118 | * **Azure DevOps** - We use our [Azure DevOps](https://alaskadhss.visualstudio.com/) repository much like our GitHub repository, but for repositories that either need to be kept private and for repositories that are deployed to Azure.
119 |
120 | * **Microsoft Teams** - We use [Microsoft Teams](https://teams.microsoft.com/l/team/19%3a3ac701697e2f4d279a28c0e33b00a092%40thread.skype/conversations?groupId=6bf46ba5-dd04-4ed8-b1c2-c9152ecddecd&tenantId=20030bf6-7ad9-42f7-9273-59ea83fcfa38) for communication that falls outside of the structure of Azure DevOps or GitHub, but that doesn’t rise to the level of email, or for communication that it’s helpful for everybody else to be able to observe.
121 |
--------------------------------------------------------------------------------
/modular-experience.md:
--------------------------------------------------------------------------------
1 | # Modular product design strategy
2 |
3 | Alaska is shifting development of the ARIES system to a more fully modular approach.
4 |
5 | Beyond technical modularity, which was begun with the initial ARIES development, **we’ll also be utilizing modular procurement and modular product design techniques.**
6 |
7 | ### Implications of modular procurement
8 |
9 | We will be soliciting vendors through a **series of modular contracts** to develop components to improve and extend the functionality of the ARIES system.
10 |
11 | We believe this approach will reduce risk, be a better value to Alaskans, deliver important features to users faster, and increase opportunities for the vendor community to participate. We have greater confidence that we will get working code from vendors into users' hands faster through modular procurements than with a single, traditional, big contract.
12 |
13 | But it also introduces challenges from a product design perspective. How do we keep moving ARIES forward without imposing the burden of maintaining/building upon legacy code on new vendors? How do we incorporate the work of multiple teams into a cohesive overall product architecture?
14 |
15 | We'll do this through an incremental transition to a more modular product architecture.
16 |
17 | ### Incremental transition
18 |
19 | To facilitate this modular approach to system development, we will be incrementally shifting toward a modular product architecture. New development will be "loosely coupled" to the existing product. We'll then incrementally shift responsibilities to the new modules.
20 |
21 | **We've illustrated the strategy in this presentation: ["Incrementally shifting toward a modular experience" presentation](https://github.com/akhealth/EIS-Modernization/blob/master/assets/modular-experience2021.pdf).**
22 |
23 | [Screenshot of presentation](https://github.com/akhealth/EIS-Modernization/blob/master/assets/modular-experience-deck.jpg)
24 |
25 | ### Unified product design
26 |
27 | With multiple parties working on different modules, we want to **provide just enough guidance to free each team to focus on the desired outcomes and user needs pertinent to their module**, not global product design concerns. We want to explain how their modules will fit within the larger whole. At the same time, we are cautious about optimizing too early, or being overly prescriptive at this stage.
28 |
29 | In the long run, we intend to have a unified, shared UI pattern library that will provide a consistent user experience across modules and provide a means for system-wide UI changes. However, we don't want the creation of that library to be overly speculative or delay progress in other areas. It will take work over time, likely through multiple module projects, for those patterns to be identified.
30 |
31 | Our solution at this point establishes a limited number of design constraints that will tie the loosely coupled modules together. This will incur some acceptable technical debt, but it will allow forward progress and can be paid down at the appropriate point in the future as patterns are established through module-based work. We anticipate reassessing this approach as we learn from each module and our users.
32 |
33 | Moving forward we plan to:
34 |
35 | - Adopt a hub-and-spoke global navigation scheme, where the homepage is the hub and modules are the spokes.
36 | - Share identity/authentication across the system for fluid user movement between pages/modules
37 | - Treat the homepage and search as primary means of navigation across the system
38 |
39 | **We have developed a [demonstration website](https://akhealth.github.io/EIS-Modernization/assets/ak-modular-experience/portal.html) that illustrates these patterns.**
40 |
41 | [](https://akhealth.github.io/EIS-Modernization/assets/ak-modular-experience/portal.html)
42 |
43 | For new modules being developed, each will adopt a global header comprised of the ARIES logo/link to home, breadcrumb navigation, link to search start screen, the user's name and office, and logout button. All modules would load efficiently across geographies and display/function properly on different device types and using various modern and necessary browsers. Module teams are not responsible for user interface elements outside of their module.
44 |
45 | **Current expectations for contractors delivering new modules**
46 |
47 | - New modules must meet the needs of their users. As such, contractors should introduce UI patterns that best allow their users to accomplish their tasks.
48 | - Contractors are not expected to adhere to the existing user interface styles or patterns, but recognize that users will be moving between the existing ARIES experience and new module experiences constantly throughout their day.
49 | - Over time, we anticipate shared UI patterns will emerge and shared libraries may be developed. At this time, we do not want to prematurely optimize for that future state.
50 | - The one prescriptive design choice imposed on new modules is that they should institute a global header design including the ARIES logo/link to home, breadcrumb navigation, link to search home, the user's name and office, and logout button.
51 | - For subsequent modules, Alaska will reevaluate this approach and may adjust course as needed.
52 |
--------------------------------------------------------------------------------
/procurement-docs-far/Attachment D - DHSS Information Technology Standards-draft.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/Attachment D - DHSS Information Technology Standards-draft.pdf
--------------------------------------------------------------------------------
/procurement-docs-far/Attachment F - Data Destruction Information and References-draft.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/Attachment F - Data Destruction Information and References-draft.pdf
--------------------------------------------------------------------------------
/procurement-docs-far/QAP-draft.md:
--------------------------------------------------------------------------------
1 | # PERFORMANCE BASED QUALITY ASSURANCE PLAN (QAP)
2 | # FFM Automated Registration (FAR)
3 | ## INTRODUCTION
4 | This Quality Assurance Plan (QAP) has been developed to evaluate contractor actions while implementing [the Scope of Work (SOW)] (NEED TO UPDATE LINK). It is designed to provide an effective method of monitoring contractor performance for each listed objective on the Performance Requirements Matrix. It also provides a systematic method to evaluate the services the contractor is required to furnish.
5 |
6 | ## STANDARD
7 | The contractor is responsible for management and quality control actions to meet the terms of the contract. The role of the Procurement Officer (PO) and ARIES Product Team is quality assurance to ensure contract standards are achieved. The contractor shall perform all work required in a satisfactory manner in accordance with the requirements of the RFP. The Contractor shall notify the Product Manager for appropriate action if it is likely that the contractor will not achieve successful final delivery of the software code in accordance with the performance objectives and acceptable quality levels (AQLs) identified below.
8 |
9 | ## PERFORMANCE REQUIREMENTS MATRIX
10 | The Product Team and PO will evaluate the performance objectives reflected below by reviews and acceptance of work products and services. As indicated, the Product Team and PO will assess progress towards the final delivered software code. Note that the performance requirements listed below are required for the final deliverables. However, the sprints and incremental delivery of code will be assessed by the Department of Health and Social Services to ensure that the contractor is on a path to successful final delivery.
11 | Deliverable or Required Services Performance Standard(s):
12 |
13 | **Deliverable or Required Services** | **Performance Standard(s)** | **Acceptable Quality Level (AQL)** | **Method of Review**
14 | --- | --- | --- | ---
15 | Tested Code | Code delivered under the contract must have substantial test code coverage and a clean code base. | Minimum of 90% test coverage of all relevant code. | Combination of manual review and automated testing, using agreed-upon publicly-available, supported products.
16 | Accessible | Client-side rendering must conform with WCAG 2.1. | 0 errors reported for 508 Standards using an automated scanner and 0 errors reported in manual testing. | Testing method TBD
17 | Deployed | Code must successfully build and deploy into staging environment. | Successful build DHSS managed automated continuous integration processes. | Combination of manual review and agreed upon automated testing.
18 | Documented | All dependencies (and licenses for dependencies) are listed and all major functions are documented. | All dependencies are listed and the licenses are documented. Software/source code is documented. System diagram is provided. | Combination of manual review and automated testing
19 | Available | Code must be stored in a version-controlled open-source repository. | All of the code needed to run the front end of the prototype must be available. | DHSS will assess code availability and access
20 | User research | Design research and usability testing activities must be conducted at regular intervals throughout the development process (not just at the beginning or end) to ensure the user needs are well understood and that design solutions work well for users. | During the first sprint, vendor shall establish a design research plan in collaboration with the Product Team. This plan must account for the availability of resources, articulation of research methods, and delivery of research-related records. In subsequent sprints, research-related records will be delivered in accordance with the aforementioned design research plan. | DHSS will cross-reference research-related records with other project documentation to ensure that research is properly accounted for and communicated.
21 | Secure | Code must be free of medium- and high-level static and dynamic security vulnerabilities. | Clean automated tests from a static testing SaaS, Veracode, and/or documentation explaining any false positives. | Architecture must conform to DHSS IT Standards and project standards |[https://pages.18f.gov/before-you-ship/](https://pages.18f.gov/before-you-ship/).
22 |
23 | ## PROCEDURES
24 | The Product Team and PO, along with the product owner, will inspect all tasks required by the contract to ensure contractor compliance with the contract requirements at the conclusion of each sprint, which shall have a length of two weeks or less, unless agreed upon by the vendor and product team.
25 | The Product Team will create/identify the repositor(y/ies) needed for executing the contract and provide brief documentation on their purpose. If the contractor identifies a need for a change in the repositories, they will submit a request to the product team. The product team will review, discuss as needed, and resolve the request, as agreed.
26 |
27 | Delivery of all software assets will occur via a series of pull requests through the appropriate State of Alaska Git Repositories. A defined code review process will be conducted with a mixed team of State of Alaska technical resources. If inspection results are satisfactory, the pull requests will be merged; otherwise, deficiencies will be noted in the pull requests or through issues as described below. The Product Team and PO may find the delivery satisfactory even though further work is required, provided that the specific requirements of the sprint are met.
28 |
29 | Unless otherwise agreed upon in writing, the contractor shall deliver research-related records to DHSS in accordance with the previously agreed upon design research plan. The design research plan shall be delivered during the first sprint.
30 |
31 | At the conclusion of each sprint, the PO and Product Team will review the completed user stories and related functionality to ensure compliance with acceptance criteria and requirements. Incomplete or inadequate code and user stories will be noted in a mutually agreed-upon issue tracker with links to each issue shared with the PO. The contractor may respond in that tracker as appropriate, addressing the accuracy and validity of the defect as well as any planned corrective action (if not already noted). All clarifications and changes to the scope agreed upon in the issue tracker will be updated as revised acceptance criteria in the incomplete backlog items as part of the backlog grooming process. The contractor team will discuss and document actions to prevent recurrence in the sprint retrospectives.
32 |
33 | At the conclusion of the period of performance, a similar procedure will be followed to document discrepancies and to assess overall performance.
34 |
35 | If any of the services do not conform to the contract requirements, the PO may require the contractor to perform the services again in conformity with contract requirements. Any user stories that are not accepted must be completed in the next sprint, unless the product owner and TTS product manager agree to move it to a later sprint. The PO shall not certify satisfactory performance for the contract until all defects have been corrected. When the defects in services cannot be corrected by re-performance, the State may:
36 |
37 | 1. Require the contractor to take necessary action to ensure that future performance conforms to contract requirements; and,
38 |
39 | 2. Reduce the contract price to reflect the reduced value of the services performed. The Product Manager and PO will maintain a complete quality assurance file. The file will contain copies of all reports, evaluations, recommendations, and any actions relating to the State’s performance of the quality assurance function, including originals of all quality monitoring checklists. All such records will be retained for the life of the contract.
40 |
41 | ## ACCEPTANCE OF SERVICES
42 | Acceptance of services shall be based upon compliance with performance standards described in the RFP and monitoring procedures described in this QAP. Before approving/certifying any contractor invoices, the PO will verify that all invoiced services have been performed in compliance with contract requirements. The PO shall not certify satisfactory performance for the contract until all defects have been corrected.
43 |
--------------------------------------------------------------------------------
/procurement-docs-far/README.md:
--------------------------------------------------------------------------------
1 | # FFM Automated Registration (FAR) Procurement Documents
2 |
3 | * Draft [scope of work](draft-scope.md)
--------------------------------------------------------------------------------
/procurement-docs-far/draft-scope.md:
--------------------------------------------------------------------------------
1 | # Purpose of the RFP
2 |
3 | **Note - this document is currently in draft form. Updates and changes will be made prior to finalizing for inclusion in an RFP**
4 |
5 | The Department of Health and Social Services, Division of Public
6 | Assistance (DPA), is soliciting proposals for a Contractor to
7 | continuously deliver iterations of updated software that automates the
8 | registration of applications received from the Federally Facilitated
9 | Marketplace (FFM).
10 |
11 | ## Background Information
12 |
13 | ### Background
14 |
15 | The background for this project as a whole is
16 | detailed in the project README in DHSS primary [GitHub
17 | Repo](https://github.com/AlaskaDHSS/acq-alaska-dhss-modernization/blob/master/README.md).
18 | For this solicitation we plan to take the lessons we have learned in our
19 | first procurement and apply them to our processes. The ARIES system
20 | connects to the Federally Facilitated Marketplace (Healthcare.gov) to
21 | accept public assistance applications for Medicaid. Alaska is what is
22 | known as a determination state, which means that the federal marketplace
23 | is authorized to make Medicaid eligibility determinations where
24 | possible. At this time roughly half of all applications received are
25 | received with a status of “determined eligible”. The remainder of
26 | applications are received in a variety of statuses that require some
27 | input from eligibility workers. For applications received by DPA from
28 | the FFM, there is an intermediate step inserted into the process to
29 | “register” the application. This registration process is a manual lookup
30 | to ensure that the application is associated with any existing records
31 | for the same client that may exist.
32 |
33 | The changes to this process will move the applications either directly to benefit issuance, or
34 | to a queue to be worked by eligibility workers. This work will necessitate
35 | updates to the business logic used to route applications within the current
36 | ARIES system, as well as visual UI updates to let workers know how to process
37 | incoming work.
38 |
39 | The State of Alaska will provide documentation on how to access data sources, describe
40 | existing authentication systems, and discuss how to continuously deploy work to a staging environment.
41 |
42 | ### Objectives
43 |
44 | * Alaska Department of Health and Social Services (DHSS) goals for the FFM
45 | Automated Registration (FAR) procurement are as follows:
46 |
47 | * Reduce the amount of manual intervention by Division of Public
48 | Assistance (DPA) in processing incoming FFM applications.
49 |
50 | * Decreased burden on DPA field staff as they process incoming
51 | applications for program benefits.
52 |
53 | * Allow DPA application intake staff to focus on registering
54 | applications for other application submission methods.
55 |
56 | * Increase the number of applications processed per worker, per day, so
57 | that potential beneficiaries can get their benefits sooner.
58 |
59 | * Decrease time for FFM applicants to receive their benefits.
60 |
61 | ## Scope of Work
62 |
63 | The scope of this contract is for the Contractor to continuously deliver
64 | iterations of updated ARIES software that automates the FFM application
65 | registration process. Currently this process requires a step where a
66 | clerical office worker reviews the application, and prepares it for
67 | eligibility determination. The changes to this process will move the
68 | applications either directly to benefit issuance, or to a queue to be
69 | worked by eligibility workers. This work will necessitate updates to the
70 | business logic used to route applications within the current ARIES
71 | system, as well as visual UI updates to let workers know how to process
72 | incoming work.
73 |
74 | The State of Alaska will provide documentation on how to access data
75 | sources, describe existing authentication systems, and discuss how to
76 | continuously deploy work to a staging environment.
77 |
78 | ## Requirements
79 |
80 | The Contractor shall provide the following services:
81 |
82 | * Contractor shall update the application workflow to route applications
83 | received from the FFM to either the batch job to automatically process
84 | eligibility or to a work queue to have eligibility determined by an
85 | eligibility technician.
86 |
87 | * Contractor shall update the relevant batch processes that currently
88 | exist within the ARIES system.
89 |
90 | * Contractor shall update the necessary tasks to suppress tasks that no
91 | longer apply and create any new needed tasks
92 |
93 | * Contractor shall review existing research artifacts and conduct
94 | additional user research in order to determine user needs so that the
95 | contractor can design and deliver interfaces/data views that are most
96 | useful.
97 |
98 | * Contractor shall conduct usability testing and gather feedback from
99 | DPA workers on an ongoing basis as solutions are explored and software
100 | is delivered, and incorporate feedback.
101 |
102 | * Contractor shall ensure that automated task generation is updated to
103 | reflect the new workflow.
104 |
105 | * Contractor shall ensure that solution integrates with existing
106 | technology choices and technical stack.
107 |
108 | * Contractor shall continuously deliver working software for use in the
109 | Alaska production environment.
110 |
111 | ## Additional Requirements
112 |
113 | * Contractor shall use proven open source libraries that are
114 | well supported and documented so that future vendors can contribute more
115 | easily. Before any libraries are chosen, the Alaska product team will evaluate
116 | them to determine if they meet these conditions.
117 |
118 | * Contractor shall abide by best practices around unit and integration testing for both front-end and back-end components.
119 |
120 | * Contractor shall ensure the design aligns with the modular product design strategy from the beginning so that future vendors can integrate more easily with the overall experience.
121 |
122 | * Contractor shall ensure pages load efficiently across geographies and display/function properly on different device types and using
123 | various modern and necessary browsers.
124 |
125 | * Contractor shall ensure pages load efficiently across geographies and display/function properly on different device types and using
126 | various modern and necessary browsers.
127 |
128 | * All software code delivered under this order shall comply with the 18F open source policy in effect as of the date of award.
129 |
130 | * All software code delivered under this order shall comply with the 18F accessibility guidance in effect as of the date of award.
131 |
132 | * APIs should comply with the 18F API standards.
133 |
134 | * Work will be conducted in two-week sprints and reviewed at
135 | the end of each sprint for acceptability before moving on.
136 |
137 | * Contractor shall ensure that system documentation is as
138 | automated as possible so that it does not have to be updated manually.
139 |
140 | * Contractor shall work with the State of Alaska to ensure
141 | that support and operations teams are trained.
142 |
143 | * Note the following tasks are not required:
144 | Vendor will not be required to handle any of the following
145 | tasks:
146 | * Provide or configure hosting of the data or the site
147 | * Directly create, update, or delete the data
148 |
149 |
150 |
151 |
152 |
153 |
154 |
155 |
156 |
157 |
158 |
159 |
--------------------------------------------------------------------------------
/procurement-docs-far/media/image1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image1.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image10.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image10.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image11.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image11.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image2.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image3.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image4.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image5.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image5.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image6.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image6.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image7.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image7.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image8.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image8.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/image9.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/image9.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/seal.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/seal.png
--------------------------------------------------------------------------------
/procurement-docs-far/media/standard-agreement-form.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/akhealth/EIS-Modernization/39872addbb9d528bbabb28b26a53f179fbef7bba/procurement-docs-far/media/standard-agreement-form.png
--------------------------------------------------------------------------------
/procurement-docs-search/README.md:
--------------------------------------------------------------------------------
1 | ## Information for Interested Vendors
2 |
3 | The RFP and related documents for `RFP #180000022 ELIGIBILITY INFORMATION SYSTEM - ENHANCED SEARCH TOOL` can now be found in a [new repository](https://github.com/AlaskaDHSS/RFP-Search-Unification). Questions about this RFP should be [posted as an issue](https://github.com/AlaskaDHSS/RFP-Search-Unification/issues) in the new repository.
4 |
5 |
--------------------------------------------------------------------------------
/procurement-strategy.md:
--------------------------------------------------------------------------------
1 | # EIS-M Procurement Strategy
2 |
3 | ## Modular Procurement Overview
4 |
5 | Modular procurement is an acquisition strategy that breaks up large, complex procurements into multiple, tightly-scoped projects to implement technology systems in successive, interoperable increments. It is an approach that can help reduce vendor lock in, mitigate risk, and encourage the delivery of working software to users more rapidly.
6 |
7 | The Alaska EIS-M project will employ a modular procurement strategy to modernize, and eventually replace, the state's existing public benefit eligibility systems. To support this work, the product team has endorsed a number of principles to guide future procurements.
8 |
9 | ## Modular Procurement Principles
10 |
11 | Ultimately, the state’s investment should be measured in working software, not phase documents or milestones. Only working systems are of value to real constituents. Based on that premise, teams are only able to measure the success of a waterfall project after most costs have been incurred, because that is the first time working software is delivered. This is a huge risk. Modular procurements allow the state to measure success at more regular intervals, and reduce the overall risk to the state.
12 |
13 | ### Working in the open
14 |
15 | We [embrace](https://github.com/AlaskaDHSS/EIS-Modernization/blob/master/how-we-work.md#principles) the use of open source software, and share the code that is developed as part of this effort openly in public repositories. This will help us reduce overdependence on a single vendor, will help us build trust with the vendor partners that we work with and foster reuse both within the State of Alaska, and with other states.
16 |
17 | ### Breaking up work into modules
18 |
19 | We aim to break up the large amount of work required for the overall EIS-M effort into smaller, less risky, more achievable pieces. Our goal is to run multiple, smaller procurements in sequence and iteratively deliver increased value to those we serve. This will help us reduce risks, and deliver working software the end users more quickly.
20 |
21 | ### Reduced proposal size
22 |
23 | We desire to reduce the size of proposals that we receive from vendors, by deobligating them from crafting lengthy responses to RFPs. This goes hand-in-hand with breaking work up into smaller pieces by reducing the overhead of responding to solicitations and fostering a more engaged vendor community.
24 |
25 | ### Articulating goals, not requirements
26 |
27 | We want our solicitations to focus less on prescribing specific business requirements and more on the solutions and outcomes we hope to achieve with our vendor partners. This will allow vendors to offer more creative, innovative approaches to the challenges we face.
28 |
29 | ### Vendor collaboration
30 |
31 | We seek to foster collaborative relationships with our vendor partners, and to build an ecosystem of vendors that are skilled in agile software development, product thinking, human-centered design and DevSecOps.
32 |
--------------------------------------------------------------------------------
/tech-strategy.md:
--------------------------------------------------------------------------------
1 | # EIS Modernization Project Technical Strategy
2 |
3 | Goals, vision and strategies described herein were derived from Technical Strategy workshops conducted by 18F with the EIS modernization product and technical teams.
4 |
5 | | Action | Date |
6 | | ----------- | ----------- |
7 | | Committed to GitHub | December 2018 |
8 | | Reviewed | June 2019 |
9 | | Updated | August 2021 |
10 | | Updated | July 2022 |
11 |
12 | **Challenge**: We will move the programs currently in EIS off the mainframe within 5 years. This item identified by the team as a strategy is in fact a goal of the EIS modernization project.
13 |
14 | ## Vision Statements
15 | * IT staff are stable and empowered. We use commonly-supported technologies that we understand well. We clearly identify, describe, and prioritize our work, document our code and open APIs, and work on clean codebases. We deliver value to our users quickly and regularly.
16 | * Our DevSecOps approach allows us to rapidly develop and deploy improvements to our systems. Our project, code, build, and release process is transparent and accessible. Our simplified operating environment allows us to interact with developers and vendors effortlessly and supports a healthy rotation of vendor contributors. Our data flows between systems through existing or homegrown APIs.
17 | * Our systems are modern. We have incrementally replaced mainframe and poorly supported legacy systems with new, modular, cloud-based solutions built on commonly-supported technologies. We utilize a service-oriented architecture and aligned data architecture.
18 | * We look to the future. Our systems are secure and open source. We embrace and anticipate a mobile user base, and seek opportunities to employ emerging technologies when they'd benefit our users and beneficiaries.
19 |
20 | ## Strategies
21 | Strategies have been organized in themes. The themes are a synthesis of specific cards produced and voted on in the sessions. Strategies that apply across themes are represented in each of the themes they apply.
22 |
23 | ### Create and maintain a simplified operating environment
24 | 1. We will simplify the operating environment, progressively adopting technologies we are well suited to support and reuse and sun-setting costly, outdated, or non-standard technologies.
25 | 2. We will replace legacy functionality incrementally, building new functionality alongside the old, connecting systems.
26 | 3. We will embrace a service-oriented architecture model, moving towards many experiences built using many distinct components that effortlessly interact through APIs and building new functionality modularly, using technologies we can effectively support and modify, rather than investing further resources in systems we cannot.
27 | 4. We will improve our cloud posture by progressively shifting newly developed applications and related data to the cloud.
28 |
29 | ### Develop and use Agile and DevSecOps methodologies, tools and architectures that support full-lifecycle (`vision => acquisition => operations and maintenance => continuous improvement`), and decreased time to value.
30 | 1. We will support DevOps, infrastructure- and configuration-as-code, and CI/CD.
31 | 2. We will continually work with the DSO to integrate security compliance into the development process, creating a true DevSecOps model.
32 | 3. We will embrace architecture and processes that support rapid development and deployment using technical prototyping to evaluate feasibility, direction, and assumptions, and do what's needed to establish a culture of experimentation.
33 | 4. We will improve dev cycle time, outcomes, strategic alignment through innovation using prototyping and fail-fast strategies.
34 | 5. We will explore and experiment with emerging technologies to support business needs.
35 | 6. We will ensure that our systems meet our [definition of done](/how-we-work.md#definition-of-done) so that new AK developers and new vendors can easily work to modify and extend those systems.
36 |
37 | ### Promote seamless user-experiences through training on and use of enabling technologies
38 | 1. We will integrate internal and external DPA systems across the eligibility process.
39 | 2. We will embrace a service-oriented architecture model, moving towards many experiences built using many distinct components that effortlessly interact through APIs.
40 | 3. We will embrace mobility of our workforce and clients and ensure our systems work anywhere.
41 |
42 | ### Leverage and enhance DOH, State of Alaska and federal partner technology standards and processes
43 | 1. We will leverage and enhance DOH IT standards and OIT guidance (does not imply complete adherence).
44 | 2. We will move to a service-oriented architecture, consistent with MITA and CMS Seven Conditions and Standards.
45 | 3. We will maximize use of department Health Information Technology (HIT) expenditures through reuse of shared technology and business services.
46 |
47 | ### Support open and transparent government at the system acquisition and information system implementation level
48 | 1. We will work in the open to the greatest extent possible and share our work as open source software.
49 |
50 | ### Develop and embrace a cloud first approach to technology design and implementation
51 | 1. We will develop a draft department-wide cloud strategy, circulate it within the department, and operationalize it for our project.
52 | 2. We consider compliance, security, and other empirical (cost, support, availability, latency, resiliency, long term supportability, etc.) requirements for systems and applications to guide appropriate cloud technology.
53 | 3. We will explore and experiment with emerging technologies to support business needs.
54 | 4. We will improve our cloud posture by progressively shifting newly developed applications and related data to the cloud.
55 |
--------------------------------------------------------------------------------
/technical-prototyping-ffm-automated-registration.md:
--------------------------------------------------------------------------------
1 |
2 | ## FFM Automated Registration (FAR) prototyping
3 |
4 | The next procurement in this effort will deal with inbound FFM referrals for individuals who apply for benefits directly through [healthcare.gov](https://www.healthcare.gov/), and whose Medicaid eligibility has already been determined by the FFM. Currently, all inbound FFM referrals require manual intervention by an agent (even for referrals which have a status of `determined eligible` from the federal marketplace).
5 |
6 | This procurement will automate the registration of applications in the ARIES system received through the FFM, eliminating the need for manual registration (though some manual processing may still be needed for FFM referrals not already designated as `determined eligible`). This effort will:
7 |
8 | * Reduce the burden on field agents, who currently register FFM applications manually.
9 | * Help to reduce the backlog of applications
10 | * Result in speedier issuance of benefits for applicants through the federal marketplace that have been assessed as eligible by the FFM.
11 |
12 | ## Risks
13 |
14 | The list of risks below should be considered preliminary. Refinement of the items listed below, and newly identified risks may be added as work on this procurement progresses.
15 |
16 | | Description | Criticality (1 - 5)* | Status |
17 | |---|---|---|
18 | | Accessing and modifying existing batch jobs that move applications received from the FFM through the ARIES system | 5 | Not yet started |
19 | | Successfully matching applicants that come in through the FFM with existing demogrphic data (in the [MCI](https://github.com/AlaskaDHSS/RFP-Search-Unification/blob/master/4-Prototype-Findings.md#components)) and associating them with existing applications (if they exist) | 5 | Not yet started |
20 | | Establishing a development environment to support the testing of modifications to the batch jobs and other components that might need to be modified to support this work. | 4 | In progress |
21 | | Understanding more fully the process of how FFM appications populate the staging table and, more broadly the boundaries between different system components (Quartz scheduler, Mule ESB, etc.) | 3 | Not yet started |
22 |
23 | * 1 = low criticality; 5 = high criticality
24 |
25 | ## Additional resources
26 |
27 | * Prototyping [strategy session results](https://app.mural.ly/t/gsa6/m/gsa6/1518556396089/5d06a55c138f4ebf7e18dc0a3ac812e888a3f6a7). (Note - access might not be public)
28 |
--------------------------------------------------------------------------------
/technical-prototyping-unified-search.md:
--------------------------------------------------------------------------------
1 | **Update:** The prototyping work for the first procurement is complete and the associated procurement [has been awarded](https://github.com/AlaskaDHSS/EIS-Modernization/wiki/Project-Update-12_19_2017---First-Award-Announced!). The [prototyping findings](https://github.com/AlaskaDHSS/RFP-Search-Unification/blob/master/4-Prototype-Findings.md) are available for review.
2 |
3 | ---
4 |
5 | ## Search unification prototyping
6 |
7 | For our first procurement we are dealing with updating a new legacy code base (ARIES) that is very complex and difficult to understand, a deployment process that is opaque — and on top of that, we want to create new connections between legacy systems ARIES and EIS. The unknowns involved with this work are risky enough that we can't be confident that vendors will be able to deliver anything without more guidance.
8 |
9 | As this is our first prototype, we will be testing out some of the more foundational things, like a vendor development environment and deploy process, that will apply to all buys, as well as setting up the lines of communication with internal technical staff that will be necessary throughout the project.
10 |
11 | ## Risks
12 | Before we write this first RFP, we want to spend time prototyping so we can mitigate the following identified risks:
13 |
14 | | Description | Criticality (1 - 5)* | Status |
15 | |---|:---:|:---:|
16 | | Creating a development and deployment pipeline that will allow vendors to deliver code that can be automatically evaluated and pushed to a staging environment | 2 | In progress. See [DevSecOps Strategy](https://github.com/AlaskaDHSS/DevSecOpsMvp). |
17 | | Creating a process to get the delivered code into a production environment on a continuous basis | 5 | In progress. See [DevSecOps Strategy](https://github.com/AlaskaDHSS/DevSecOpsMvp). |
18 | | Verifying that the existing identity service can be used for user authentication/authorization | 1 | Completed. |
19 | | Accessing data from the legacy EIS system to show in search results | 3 | In progress. |
20 | | Accessing data from the ARIES system and staging table to show in search results | 2 | In progress. |
21 | | Validating that the data coming from multiple systems is potentially reconcilable | 3 | In progress. |
22 | | Deploying existing ARIES code to production | 4 | In progress. |
23 |
24 | \* 1 = low criticality; 5 = high criticality
25 |
26 | Prototype documentation:
27 | * [Prototype findings](https://github.com/AlaskaDHSS/RFP-Search-Unification/blob/master/4-Prototype-Findings.md)
28 | * **[Prototype]** <-- **ADD THIS**
29 | * [Prototype code](https://github.com/AlaskaDHSS/ProtoWebApi)
30 | * [High-level technical overview](https://github.com/18F/acq-alaska-dhss-modernization/blob/master/assets/search-prototype-high-level-technical-overview.pdf)
31 | * [Conceptual Diagram](https://app.mural.ly/t/gsa6/m/gsa6/1489619780239/view/4116522087)
32 | * [Interactive mock](http://gsa.invisionapp.com/share/QDAZYEJPZ)
33 |
--------------------------------------------------------------------------------
/technical-prototyping.md:
--------------------------------------------------------------------------------
1 | # Technical Prototyping
2 | Especially when working with legacy systems, **it's important to test technical assumptions *before* scoping any kind of procurement** because there are almost certainly unknown hazards that can put your procurement at risk. These hazards can't be known unless you start building something.
3 |
4 | Unlike most kinds of prototypes, technical prototypes are not focused on user experience, but rather on the mechanics behind the user's experience. They test things like "Can we really access the data we think we need?", or "How does this external API actually work?"—so they’re pretty bare-bones. They show *just enough* of the user-facing functionality to verify some kind of technical implementation. Practically, the prototype follows some user on a "happy path" user flow through that implementation.
5 |
6 | **Prototyping a small end-to-end user flow is something that teams can do quickly before writing an RFP**, and should help identify any hazards in the code, the deployment process or any other technical aspect of a project. This will help teams properly scope the procurement and build out a reasonable RFP with some useful documentation for buyers and for vendors.
7 |
8 | **Our prototypes:**
9 |
10 | - [Unified search](technical-prototyping-unified-search.md)
11 | - [FFM automation](technical-prototyping-ffm-automated-registration.md)
12 | - [Automated Renewals](https://github.com/AlaskaDHSS/RFP-ARIES-AutomatedRenewals/blob/main/Attachment%2007%20Automated%20Renewals%20Technical%20Prototype%20Findings.md)
13 | - [Modular Experience and API Framework](https://github.com/akhealth/ProtoModExp#readme)
14 |
15 | ## When we prototype
16 |
17 | Throughout this project **we will be using technical prototyping** whenever we are faced with some question about integration with existing systems, the nature of existing data sources, or any other existing technical process that we plan to leverage as part of our planned acquisition. We may change direction at times, based on what we learn through prototyping. We may decide to pursue a completely different implementation, or even a different set of features entirely. Best case is that we can proceed with the original plan, only now with much more information that will help ensure the success of the acquisition.
18 |
19 | ## Why we prototype
20 |
21 | Prototyping is learning. For us, it allows us to learn firsthand about the challenge before us so that we can take on the work from a more empowered position. Technical prototyping helps us:
22 |
23 | - **Reduce risk** | Prototypes help us identify problems fast when the risk is far lower than when time is ticking with a vendor on board so that we can remove barriers to success early.
24 | - **Validate direction** | By testing out our intended vendor _ask_, we can validate if the planned work is viable. If it is, we can proceed. If the planned path proves unviable, we can more easily adjust course.
25 | - **Understand business needs** | By exploring a small end-to-end user flow, our product team surfaces and learns about business and policy needs, developing greater subject matter expertise.
26 | - **Write a good RFP** | The lessons learned through prototyping help inform the content of our requests for proposals, making the project focus sharper and less speculative.
27 | - **Prepare vendors** | Vendors benefit from the investigation by having more detailed and accurate information upon which to build their proposals. After award, they understand the landscape better and can jump right into the work.
28 | - **Develop expertise** | By actively working in system code to prove out hypotheses, we retain and grow in-house technical expertise with our systems and understanding of what vendor developers need to succeed.
29 | - **Refine infrastructure** | Technical prototyping creates opportunities to improve and refine our infrastructure.
30 | - **Be transparent** | By working in the open on our prototypes, we increase visibility for all our stakeholders and the larger Alaska community.
31 |
32 | ## What we prototype
33 |
34 | Technical prototypes should address risks identified by the product team. The approach to using technical prototypes borrows heavily from the idea of a [code spike](http://agiledictionary.com/209/spike/) in agile software development. Code spikes are not meant to produce production ready code, and should be designed to leverage the simplest possible solution to identify solutions to an outstanding question or potential risk. Technical prototypes. like code spikes, should help give the product team clarity on the level of efforts required to address risks that have been identified in the planning process.
35 |
36 | ## Prototyping infrastructure
37 |
38 | Through our initial prototypes efforts, we worked through a variety of initial challenges. Having done so, we are now positioned to more easily and quickly prove out technical questions. We can now take advantage of...
39 |
40 | - **Security plans** - Agreement with state security teams about the applicable security requirements
41 | - **Tailored IT standards** - (Is this similar to the security plans above; should connect to documentation)
42 | - **[Agile and HCD practice](https://github.com/akhealth/EIS-Modernization/blob/master/how-we-work.md)** - DOH has embraced agile and human-centered design practices, works in product increments and sprints, and continuously seeks improvement.
43 | - **Test data** - Test data has been aligned across MCI, EIS, ARIES for UAT and dev environments. A process for adding new test data has been established
44 | - **Azure DevOps** - DOH uses Azure DevOps for version control, teams, git, security scans, etc. More information can be found [in the DevSecOps repo](https://github.com/akhealth/DevSecOpsMvp).
45 | - **GitHub** - While we work in Azure DevOps, we intend to sync our code with GitHub as part of our deployment cycle to ensure our open source software is visible and accessible.
46 | - **Service Proxy** - BizTalk ESB can be used to manage access to MCI, ARIES, EIS
47 | - **Cloud/PaaS/Azure** - DOH has adopted Azure and will be using this PaaS moving forward. More information on access can be found [in the DevSecOps repo](https://github.com/akhealth/DevSecOpsMvp/blob/master/Azure.md).
48 | - **CI/CD pipeline** - Continuous Integration / Continuous Deployment mechanism are now in place and documented [in the DevSecOps repo](https://github.com/akhealth/DevSecOpsMvp/blob/master/vsts/GitBranchingStrategy.md).
49 |
50 | ## People & skills
51 |
52 | Producing technical prototypes requires DOH developers and product managers to devote time and energy working in the systems and building. To do this, we leverage some or all of the following:
53 |
54 | - Familiarity with C# & .NET Core
55 | - Front-end development
56 | - Experience with Azure
57 | - Familiarity with Git, Azure DevOps and an understanding of CI/CD
58 | - Ability to identify risks
59 | - On-prem service/data expert
60 | - An experimental mindset - The team needs to be committed to trying things out, experimenting, and learning from both successes or failures
61 | - A bias toward action - working in a deliberately rough & imperfect way in order to make progress mitigating risk
62 | - Product management - High level vision, roadmap, modular/incremental thinking, prototype scoping
63 |
64 | ## Getting Started
65 |
66 | - Identify the people involved for prototyping efforts to be successful
67 | - Identify required approvals from security office
68 | - Identify the risks (this may be a facilitated session, where a team collectively identifies potential risks)
69 | - Assign criticality level to risks
70 | - Synthesize risks into actionable items, and identify risks outside scope of prototyping activity
71 | - Identify boundaries of concern for prototyping effort (scoped around technical matters)
72 |
--------------------------------------------------------------------------------
/user-story-standards.md:
--------------------------------------------------------------------------------
1 | # EIS-M Project User Story Standards
2 |
3 | The goal of this document is to establish user story minimum acceptable standards that define a common set of core documentation standards that can be used consistently across multiple product teams when developing features for an integrated eligibility system.
4 |
5 | Defining minimum acceptable documentation standards enables product teams to communicate and document epics, features and user stories in a manner that is consistent across teams but flexible and efficient, to support rapid development and deployments.
6 |
7 | Our consistency in approach will assist us with our primary objective to add value to the user in each Sprint. The prioritization of the user stories will be crucial as we discover user needs with each code delivery.
8 |
9 | ## Product Teams
10 |
11 | Each team is a cross functional group of members comprised of business, policy, security, procurement and technical specialists tasked with implementing features to support goals and/or outcomes identified by the primary product team in accordance to its vision.
12 |
13 | ## DOH Vision Statement
14 |
15 | Alaska Department of Health (DOH) is developing a modern, integrated eligibility system that enables staff to more efficiently issue correct and timely benefits to Alaskans who need help meeting their basic needs. Using agile development and modular procurements, DOH has the goal of implementing an eligibility system that not only meets state and federal standards, but is user friendly for our clients, our eligibility staff, and our technical staff.
16 |
17 | Implementing our project’s vision can be decomposed into 4 work levels for execution: Goal/Outcome -> Epics -> Features -> User Stories
18 |
19 | 
20 |
21 | Product Teams will be responsible for developing the Features and User Stories needed to address the Goal/Outcome assigned.
22 | These elements will combine in an iterative process that will better meet our changing landscape of regulatory requirements and technical specifications.
23 |
24 | ---
25 | ## Epic
26 |
27 | An epic captures a large body of work. It is essentially a large user story that can be broken down in a number of smaller Features.
28 |
29 | ## Feature
30 |
31 | A feature is a tangible expression of functionality. It can take several sprints to complete a Feature. Features will be expressed as User Stories, which will contain tasks toward completing the story in Azure DevOps. The tasks themselves might be stories that are children of the parent Story. Each task corresponding to a Feature’s User Story will contribute to the fulfillment of that User Story.
32 |
33 | Examples of Features for Unified Search:
34 |
35 | * Find a Person’s program information using Last Name, First Name
36 | * Find a Person’s information using SSN
37 | * Find a Person’s information using Name
38 |
39 | ## User Story
40 |
41 | A user story describes a specific need, “who” the user is, “what” the user needs and “why” it is required in simple, concise terms.
42 | User stories should be small enough to be independently executable.
43 |
44 | ### Key Characteristics of Stories:
45 | * Contain high-level descriptions of desired functionality/goals
46 | * Are “contracts for conversation”, no all-inclusive requirements
47 | * Pulled into the Sprint Backlog from the Product Backlog
48 | * Contain Acceptance Criteria to define “Done”
49 | * Are vertical slices of the system’s functionality
50 |
51 | ### Field Validation
52 |
53 | For any story in which field validation is necessary, the field validation must be documented in the story included in the acceptance criteria. The story itself may accomplish field validation, such as #578.
54 |
55 | ### Format
56 |
57 | Stories should to be written in Gherkin following a basic template, and in a simplistic manner that identifies the need while providing context.
58 |
59 | Gherkin is a business readable and domain specific language that lets you describe software’s behavior without detailing how that behavior is implemented. The language serves two purposes – documentation and automated tests. Its focus is the specific need, the “what” and “why” that is required, not the “how”. In using this method, we allow for the possibility of creative, agile solutions.
60 |
61 | ## Story Template Elements: Title, Description, Scenarios, Steps
62 |
63 | ### Title
64 |
65 | The title consists of a one line, short descriptive text that should describe an activity.
66 |
67 | ### Description
68 |
69 | The description illustrates the motivation behind the story. This illustration will illuminate what exactly the requirement is, as well as providing guidance to the developers. The Description should be written in the following format:
70 | * ‘As a’… <- Identifies Who? The End User, User Role or Persona
71 | * ‘I want to’… <- Identifies the What? The desired function
72 | * ‘So that’ or ‘Because’… <- Identifies the Why? The end result
73 |
74 | ### Scenarios
75 |
76 | A scenario is a concrete example that illustrates a business rule or capability being achieved by that story. Scenarios are used to test the intended functionality, serving as the basis for the acceptance criteria.
77 |
78 | Note: Stories often require more than one scenario that will illustrate completion of the story.
79 |
80 | Examples of Unified Search Scenarios:
81 |
82 | One Scenario:
83 | * A user navigates to the search page, enters a Social Security number, and returns an ARIES Client ID, and the SSN.
84 |
85 | Multiple Scenarios:
86 | * Search subject has one or more registered application numbers in ARIES which can be viewed on the person details page in descending Application received date order.
87 | * Search subject does not have a registered application number in ARIES which can be viewed on the person details page.
88 |
89 | ### Steps
90 |
91 | Each Scenario should contain the following elements, which can then be translated into steps for test cases:
92 | #### Given
93 |
94 | ‘Given’ steps are used to describe the initial context of the system. Also called “pre-conditions”, it sets the scene of the scenario. It is always something that has happened in the past.
95 |
96 | #### When
97 | ‘When’ steps are used to describe an event, or an action. This can be a person interacting with the system, or it can be an event triggered by another system.
98 |
99 | #### Then
100 |
101 | ‘Then’ steps are used to describe an expected outcome, or result.
102 | In the event there are multiple ‘Given’, ‘When’ and/or ‘Then’ steps, ‘And’ or ‘But’ can be used.
103 |
104 | * Note: An ‘Or’ should not be documented within a scenario. ‘Or’ statement should be broken out into independent scenarios or if the behavior warrants, its own User Story or Feature.
105 |
106 | ### Example 1:
107 | Story Title: Display “Category” only for APA, and Medicaid
108 |
109 | Description: As a user, I want to understand the data labels in my search results.
110 |
111 | Scenarios:
112 | 1. Search subject is associated with a Medicaid case in ARIES, and the "Category" is visible in Person Details.
113 | 2. Search subject is associated with an APA case in EIS and the "Category" is visible in Person Details.
114 | 3. Search subject is associated with a Medicaid case in EIS, and the "Category" is visible in Person Details.
115 | 4. Search subject is associated with an ATAP case in EIS, and the "Category" label is not visible in Person Details.
116 | 5. Search subject is associated with a Food Stamps case in EIS, and the "Category" label is not visible in Person Details.
117 |
118 | #### Steps:
119 | Scenario 1: Search subject is associated with a Medicaid case in ARIES, and the "Category" is visible in Person Details.
120 |
121 | * Given I'm a user
122 | * And I am viewing a person detail page
123 | * And the search subject is associated with an ARIES case
124 | * When ARIES case information is displayed
125 | * Then I will see the "Category" for the ARIES case that the person is involved with.
126 |
127 | Scenario 2: Search subject is associated with an APA case in EIS and the "Category" is visible in Person Details.
128 |
129 | * Given I'm a user
130 | * And I am viewing a person detail page
131 | * And the search subject is associated with an EIS case
132 | * And that EIS case type is Adult Public Assistance
133 | * When EIS case information is displayed
134 | * Then I will see the "Category" for the EIS case that the person is involved with
135 |
136 | Scenario 3: Search subject is associated with a Medicaid case in EIS, and the "Category" is visible in Person Details.
137 |
138 | * Given I'm a user
139 | * And I am viewing a person detail page
140 | * And the search subject is associated with an EIS case
141 | * And that EIS case type is Medicaid
142 | * When EIS case information is displayed
143 | * Then I will see the "Category" for the EIS case that the person is involved with.
144 |
145 | Scenario 4: Search subject is associated with an ATAP case in EIS, and the "Category" label is not visible in Person Details.
146 |
147 | * Given I'm a user
148 | * And I am viewing a person detail page
149 | * And the search subject is associated with an EIS case
150 | * And that EIS case type is ATAP
151 | * When EIS case information is displayed
152 | * Then I will NOT see a "Category" label for the EIS case that the person is involved with.
153 |
154 | 5. Search subject is associated with a Food Stamps case in EIS, and the "Category" label is not visible in Person Details.
155 |
156 | * Given I'm a user
157 | * And I am viewing a person detail page
158 | * And the search subject is associated with an EIS case
159 | * And that EIS case type is Food Stamps (SNAP)
160 | * When EIS case information is displayed
161 | * Then I will NOT see a "Category" label for the EIS case that the person is involved with.
162 |
163 | ### Example 2
164 |
165 | Story Title: User Search Returns No Result
166 |
167 | Description: As a user, I want to know that that a person is not found in either system so that I can open a new case.
168 |
169 | Scenario: A user navigates to the search page, enters search criteria, and returns "not found".
170 |
171 | #### Steps
172 | * Given I'm a user
173 | * And I have navigated to the Search page
174 | * And I can see a way to enter search criteria
175 | * And I can see a method to submit the information
176 | * When I enter search criteria
177 | * Then I see a message indicating that the client is not found
178 |
179 | ### Example 3
180 |
181 | Story Title: Find Application Source in ARIES
182 |
183 | Description: As a user, I need to see the source of an application in ARIES so that I can determine how to disposition the application.
184 |
185 | Scenario: Search subject is associated with an Application in ARIES, and the source of the application can be viewed in the Person Details page.
186 |
187 | #### Steps
188 | * Given I'm a user
189 | * And I am viewing a person detail page
190 | * And that person is associated with an Application
191 | * When ARIES Application information is displayed
192 | * Then I will see the see the source of the application
193 |
194 | #### Sizing
195 | Each user’s story will be ‘sized’ so that the estimation of the feature or epic can be as accurate as possible for completion of the work. Methods of sizing will be chosen at the beginning of an increment, or contract.
196 |
197 | #### Priority
198 | Along with the size estimation, the priority of the story will help determine the direction of the work. Each story should be assigned a priority relative to the body of work, epic or feature, to be completed.
199 |
200 |
201 | ## Acceptance Criteria
202 |
203 | Acceptance criteria for each User story is comprised of the elements in each scenario. Acceptance Criteria for Features consists of the acceptance of all of the associated User Stories.
204 |
205 | ### Example:
206 |
207 | Story Title: Find a name using SSN
208 |
209 | Description: As a user, I want to find the name of a person using a Social Security Number so that I can update it.
210 |
211 | Scenario: A user can enter a Social Security Number, and return one name along with the SSN
212 |
213 | Steps:
214 | * Given I am logged in as a user
215 | * When I navigate to the search page
216 | * Then I see a search page
217 | * And I see a search field to enter Social Security Number
218 | * And I see a method to submit the data
219 | * When I enter a SSN
220 | * Then I see a First and Last Name
221 | * And I see the SSN
222 |
223 | #### Acceptance Criteria:
224 | * There is a search page
225 | * There is a method to enter SSN
226 | * There is a method to submit a search
227 | * A First and Last name is returned when a SSN is submitted
228 |
--------------------------------------------------------------------------------
/using-github-for-procurement-docs.md:
--------------------------------------------------------------------------------
1 | # Using GitHub to Develop Procurement Documents
2 |
3 |
4 | As part of the effort to modernize its existing public benefit
5 | eligibility systems, the State of Alaska DHSS has adopted a modular
6 | procurement strategy, and is using Github to develop and release
7 | [procurement
8 | documents](https://github.com/AlaskaDHSS/RFP-Search-Unification) and
9 | solicit comments / feedback from the vendor community.
10 |
11 | There are a number of [notable examples](https://agile-bpa.18f.gov/) where
12 | federal, state and local governments have used Github to develop
13 | procurement related materials, and to engage with vendors as part of the
14 | procurement process (most notably 18F’s use of Github as the foundation
15 | for it’s [micro-purchase platform](https://micropurchase.18f.gov/)).
16 | Github offers government agencies an opportunity to develop procurement
17 | materials in an open (and even collaborative) fashion, and many features
18 | of the Github platform lend themselves well to interacting with vendors
19 | during a procurements.
20 |
21 | However, the State of Alaska’s use of Github for developing and
22 | releasing procurement documents is new and there are undoubtedly
23 | opportunities for improvement. This document is meant to summarize
24 | feedback from internal staff, 18F and vendors on the use of Github for
25 | developing procurement documents and to identify some steps that could
26 | be taken to improve the process in the future.
27 |
28 | ## Internal and External Feedback on Github
29 |
30 | The State of Alaska DHSS and 18F held an internal retrospective on the
31 | initial eligibility modernization RFP, and the use of Github was raised
32 | during these discussions.
33 |
34 | From the perspective of the state, [Github
35 | issues](https://guides.github.com/features/issues/) presented an
36 | efficient way to both solicit and respond to vendor questions during the
37 | RFP process. The ability to assign issues to individuals for response,
38 | and use labels to organize and filter responses were all helpful. And
39 | the ability to ensure that all questions and answers were viewable
40 | publicly can foster trust in the process and help prevent duplicative
41 | questions.
42 |
43 | State of Alaska DHSS staff raised issues with regard to keeping their
44 | [official vendor document
45 | website](https://iris-vss.alaska.gov/webapp/PRDVSS1X1/AltSelfService)
46 | in sync with changes to procurement documents in Github. Github is ideal
47 | for making iterative changes to documents, and for allowing a variety of
48 | different RFP stakeholders to comment on and offer changes to documents,
49 | but ensuring that all changes made in Github were filtered back to the
50 | state’s vendor website prove cumbersome.
51 |
52 | Vendors generally reported a positive experience using Github to follow
53 | the development of RFP documents on Github, but did raise concerns about
54 | the the ability to be notified when changes were made and determine which changes were substanative or not. It’s not
55 | unreasonable to assume that a technology company will have the
56 | organizational capacity to acclimate to and use Github, but those
57 | monitoring the RFP process at vendor companies are sometime not
58 | technology people, but business development or communications people.
59 | Github may not always be as intuitive to this cohort of users as
60 | initially assumed, and it may be unclear if and when vendors are allowed
61 | to provide comments or suggestions. And even for those more comfortable
62 | with using Github, the signal to noise ratio for notifications from
63 | changes may not be optimal.
64 |
65 | ## Suggested Improvements
66 |
67 | With this feedback in hand, there are several concrete steps that the
68 | State of Alaska DHSS can take to improve it’s use of Github to develop
69 | and issue RFP documents, and to engage with vendors.
70 |
71 | ### Use Github as the Primary Source for RFP Documents
72 |
73 | Instead of trying to keep documents on the state’s vendor website in sync with changes on Github, the state will simply link to the RFP documents housed in Github and use the Github version as the official version of the RFP and associated documents. This will remove the burden of keeping these two separate copies of RFP documents in sync, and will help eliminate confusion from vendors who might be unser where the latest copy of an RFP document is located.
74 |
75 | ### Provide Clearer Guidance Upfront on Contributing
76 |
77 | To better ensure that vendors understand when and how to offer comments or suggestions, the state and 18F should develop a [clearer set of guidelines](https://github.com/AlaskaDHSS/RFP-Search-Unification/blob/master/CONTRIBUTING.md) on contributing that better ensures vendors understand the “rules of the road.” This is particularly important if the representatives from vendor firms are less familiar with Github and contributing to open source projects.
78 |
79 | ### Simplify the Process for Notification of Changes
80 |
81 | While Github provides a [number of options](https://help.github.com/articles/about-notifications/) for configuring how notifications are received, and what actions trigger notifications, the state could take steps to make this process simpler. For example, instead of assuming that vendors are following all changes to a repository, use a specific Github issue to indicate when substantive changes are made to documents. Vendors could be directed to [subscribe to a specific issue](https://help.github.com/articles/subscribing-to-and-unsubscribing-from-notifications/) and follow changes announced there, as opposed to getting notification of all changes in a repo and having to determine which changes are substantive and which are not.
82 |
83 | In addition, a more standard listserv or mailing list for vendors might help cut out some of the noise from Github notifications, and might be attractive for users at vendor companies that are less familiar with Github.
84 |
85 | ### Rethink use of Github’s Wiki Feature
86 |
87 | The state may want to rethink the use of Github’s Wiki feature, which was used to [post updates](https://github.com/AlaskaDHSS/EIS-Modernization/wiki) for vendors during the development of the first RFP. Github’s wiki feature offers limited ways to be notified when changes are made (though it is possible to [subscribe to an Atom feed](https://github.com/AlaskaDHSS/EIS-Modernization/wiki.atom), this feature is not well publicized and might not be practical for those participating from vendor companies).
88 |
89 | One issue with the use of a Github wiki during the development of the first RFP is that the documents were initially developed in a project-level repository (while they were still in draft form) and then were migrated to a standalone repository at the time of RFP release. The wiki for vendor updates remained in the original, project-level repository, potentially creating a disconnect. If a github wiki is used in subsequent procurements, it should reside within the same repository as the RFP documents, and it should be clearly communicated to vendors that it will be the vehicle for communicating changes.
90 |
91 | Some of the vendor feedback suggested the use of a more traditional blog to announce substantial changes to RFP documents. While there are obviously a number of different ways to publish and maintain a simple project blog, one way to do this might be to leverage [Github pages](https://pages.github.com/) to deploy a simple website for RFP document changes.
92 |
--------------------------------------------------------------------------------
20 |