Python Development Environment: Deployment & Capability Validation Lab
Determining whether the classroom lab can support professional Python development workflows inside a managed enterprise environment.
Mission Briefing
Before any software development team can work effectively, the host organization must first determine whether its systems can actually support the required tools, dependencies, and workflows. In industry, this process is called environment qualification — and it is performed before the first line of production code is ever written. Skipping it leads to lost engineering hours, broken builds, and an inability to ship.
Today, you are not "learning to code." You are acting as an IT Deployment Specialist and Software Validation Technician. Your task is to determine whether the lab computers in this room can realistically support local Python development — and to produce a professional report documenting your findings.
These machines operate inside a managed enterprise-style environment: software policy is centrally controlled, accounts are domain-joined, network traffic is filtered, and not every operation will succeed. That is normal. Discovering and documenting what does not work is just as valuable as confirming what does. Real organizations rely on technicians who can systematically verify capability and report it accurately — not technicians who give up when something is restricted.
By the end of this block, your team will deliver a Python Development Environment Capability Report that an IT manager could read and use to make a real procurement or curriculum decision.
Your Role Today
Job Title: IT Deployment Specialist / Software Validation Technician
Reports To: Lab Supervisor (Mr. Johnston, acting as roaming support tier)
Authority: You may install end-user software permitted by district policy, run validation scripts, and document system behavior. You may not attempt to escalate privileges, disable security software, bypass content filters, or modify other students' machines.
Communication: Work independently or in small troubleshooting groups (2–3). Escalate blockers to the supervisor only after attempting at least one documented workaround. Bring the exact error message with you.
Continuity Protocol — How to Keep Working When Something Fails
In a real deployment, things will fail. The mark of a professional is not "everything worked," it is "I kept the project moving and I documented what happened." This lab is intentionally designed so that no single failure stops you. Read this section before you start.
Three rules of continuity for today:
- A failure is data, not a dead end. Capture the exact error text and a screenshot, write it into your test matrix as
FAILorRESTRICTED, and move to the next step. Documented failures are worth full credit on the report — the deliverable is your validation findings, not a successful install. - Every Phase 2 test is independent. If pip is blocked, you can still test tkinter, turtle, internet access, and file I/O. If CMU Graphics will not install, you can still complete every other row of the matrix. Skip the dependent tests, mark them
N/A — depends on Test 2.X, and keep going. - If your machine is unworkable, partner up. If you cannot get past Phase 1 after twenty minutes of documented troubleshooting, do not sit idle. Either (a) move to a different open lab machine and restart Phase 1 there — comparing two machines is a Phase 3 finding anyway, or (b) pair with a classmate whose machine works. You then continue as a two-person validation team on their machine, and your "stuck" machine becomes a documented Phase 1 case study in your report.
What is not acceptable: giving up, sitting idle, putting your head down, or saying "it didn't work" without an error message and a screenshot. The supervisor will check on this.
Lab Manual Contents
Suggested Pacing for the 3-Hour Block
| Time | Phase |
|---|---|
| 0:00–0:15 | Mission briefing review, machine assignment, sign-in |
| 0:15–1:00 | Phase 1: Deployment & Configuration |
| 1:00–1:55 | Phase 2: Capability Testing & Environment Validation |
| 1:55–2:25 | Phase 3: System Boundary & Limitation Testing |
| 2:25–2:55 | Phase 4: Capability Report Drafting & PDF Export |
| 2:55–3:00 | Final submission to Schoology, log out, secure workstation |
Pacing is a guideline. The deliverable is what matters — manage your own clock professionally.
Objective: Install and configure Microsoft Visual Studio Code and Python 3 on your assigned lab machine. Confirm that both tools are functional, that the system PATH resolves correctly, and that a simple Python program executes from both the terminal and the VS Code IDE. Document everything you do.
STEP 1.1 Pre-Flight System Inventory
Before installing anything, document baseline system information. A real deployment specialist always begins with an inventory.
Open Windows Terminal or PowerShell (press Win + X, then choose Terminal or Windows PowerShell) and run each command below. Capture the output — screenshot or copy/paste — into your working notes.
PS> # Identify the machine PS> hostname PS> whoami PS> # Operating system version PS> (Get-CimInstance Win32_OperatingSystem).Caption PS> (Get-CimInstance Win32_OperatingSystem).Version PS> # Check if Python is already deployed PS> python --version PS> py --version PS> # Check if VS Code is already deployed PS> code --version
Documentation Checkpoint
Record the hostname, OS version, your username, and the result of each version check. If a tool is "not recognized," that is data — write it down. You will compare hostnames with classmates later.
STEP 1.2 Verify Python 3 (Pre-Deployed via Software Center)
Python is already deployed to these lab machines through the district Software Center. Your job is to verify the deployment — confirm it is present, confirm it is on the PATH, and confirm it actually runs. This is exactly what an IT technician does after a managed software push.
Verification: Open a fresh terminal (PowerShell or Windows Terminal — important to use a fresh one, since PATH only refreshes for new shells) and run:
PS> python --version PS> pip --version PS> where python
If all three commands succeed, Python is deployed correctly — record the version and the install path, then move on to Step 1.3.
If any command fails: the Software Center deployment did not land cleanly on your machine. Open the Software Center app from the Start menu, search for Python, and click Install (or Repair / Reinstall if it shows as already installed). Wait for it to finish, then close and reopen the terminal and re-run the verification commands.
If Software Center reinstall still fails or the package is missing: these are documented fallback deployment paths. Try them in order, stopping at the first that succeeds. Whichever you used, write it in your report — different machines using different install paths is itself a deployment-drift finding.
- Microsoft Store: Open the Microsoft Store, search for
Python 3.12(or the latest 3.x), and click Install. The Store version installs per-user and usually works without admin rights. - python.org installer: Visit python.org/downloads and download the Windows installer. Run it and — critically — check the box "Add python.exe to PATH" on the first screen.
Troubleshooting
- "python is not recognized as an internal or external command" — PATH was not updated, or you are still in the terminal that was open before the install. Close every terminal window and open a new one. If it still fails, try
py --version. If that works, the py launcher is installed but thepythonalias is missing — note that in your report and usepyin place ofpythonfor the rest of the lab. - Software Center button is greyed out / "Already installed" but verification fails — try Software Center → Installation Status → Python → Reinstall. If reinstall is not offered, screenshot the state and proceed to the Microsoft Store fallback.
- The installer asks for an admin password — choose the option to Install for current user only (no admin needed) or fall back to the Microsoft Store path.
- Microsoft Store opens a placeholder Python page — that placeholder appears when
pythonis typed but no real Python is installed. Click Get on the real Python listing, not the placeholder. - Antivirus / Defender blocks the installer — stop. Do not attempt to disable security software. Document the block, screenshot the warning, and switch to the next fallback path.
- Cannot get any Python to run after 20 minutes — apply Continuity Rule 3 from the protocol above. Move to a different lab machine, or pair with a classmate, and continue.
STEP 1.3 Deploy Visual Studio Code
Attempt the deployment paths in this order:
- Software Center / Company Portal: Search for
Visual Studio Codeand install if available. - Direct download: Visit code.visualstudio.com/download and choose the User Installer (64-bit). The User Installer does not require administrator privileges.
Verify:
PS> code --version
If code still is not recognized but VS Code does open from the Start menu, launch VS Code, press Ctrl + Shift + P, and run Shell Command: Install 'code' command in PATH.
STEP 1.4 Install the VS Code Python Extension
Open VS Code. Click the Extensions icon in the left sidebar (or press Ctrl + Shift + X). Search for Python (publisher: Microsoft) and click Install.
Test the install: open the Command Palette (Ctrl + Shift + P) and run Python: Select Interpreter. The Python you installed in Step 1.2 should appear in the list. Select it.
Troubleshooting
- Extension marketplace is blocked — document the block. Try downloading the
.vsixfrom marketplace.visualstudio.com and installing it via Extensions: Install from VSIX... in the Command Palette. If that is also blocked, that is a documented finding for your report. - "No interpreter selected" warning — re-run Python: Select Interpreter. If your Python is missing from the list, click Enter interpreter path... and paste the full path from
where python.
STEP 1.5 First Python Program — Terminal Path
Create a working folder and a first script. Use your own name in the folder.
PS> cd $env:USERPROFILE\Documents PS> mkdir python-validation-lab PS> cd python-validation-lab PS> notepad hello.py
In Notepad, paste the following code, save, and close:
import sys
import platform
print("Hello from", platform.node())
print("Python version:", sys.version.split()[0])
print("Executable path:", sys.executable)
Run it from the terminal:
PS> python hello.py
Capture Evidence
Take a screenshot showing the terminal command and its output. Filename suggestion: phase1_terminal_hello.png. You will need this for your report.
STEP 1.6 First Python Program — VS Code Path
In VS Code, choose File > Open Folder... and open the python-validation-lab folder you just created. Open hello.py.
Run the file three different ways. Confirm each works and document any that do not:
- Press the Run (▶) triangle in the top-right of the editor.
- Open the integrated terminal (Ctrl + `) and run
python hello.pyfrom inside VS Code. - Right-click in the editor and choose Run Python File in Terminal.
Capture Evidence
Screenshot VS Code with the integrated terminal showing successful output. Filename suggestion: phase1_vscode_hello.png.
Phase 1 Sign-Off Checklist
Before moving to Phase 2, work through this list. You do not need every item to be a green check to continue. Mark each item ✅ (passed), ❌ (failed — error captured), or ⚠️ (partial / workaround applied), and proceed.
- Hostname and OS version recorded
- Python 3.x verified (Software Center install or fallback);
python --versionworks in a fresh terminal pip --versionworks- VS Code installed;
code --versionworks - Microsoft Python extension installed; interpreter selected
hello.pyruns from terminalhello.pyruns from VS Code Run buttonhello.pyruns from VS Code integrated terminal- Screenshots captured for terminal and VS Code execution (or for the failures, if any)
Cannot Pass Phase 1 Sign-Off? Read This Before Moving On.
You can still complete Phase 2, Phase 3, and the final report. Pick the option that fits your situation:
- Python runs but VS Code does not — proceed using the terminal only. Phase 2 tests do not require the VS Code IDE; they only require a working Python interpreter and a way to edit text files (Notepad is fine).
- VS Code runs but Python is broken — try a different lab machine. Without a working interpreter, none of Phase 2 will execute.
- Both are broken — apply Continuity Rule 3 (move machines, or partner up) and continue. Document the failed deployment as your primary Phase 1 finding in the report. A clean, detailed write-up of why a managed deployment failed is itself a high-value professional artifact.
Objective: Determine which Python capabilities are available on this managed lab system. For every test, record one of three results: PASS, FAIL, or RESTRICTED. A restricted result (the action was blocked by policy) is just as important as a pass.
Tests Are Independent — Skip Around If You Need To
Every test in the matrix below is independent, with one exception: Test 2.3 (CMU Graphics window) requires Test 2.2 (CMU Graphics install) to have succeeded. If a test fails, mark it and move to the next one. Do not stop the matrix because one row failed.
If pip is completely blocked, you can still complete tests 2.1, 2.4, 2.5, 2.6, 2.7, 2.8, and 2.9 — that is seven of nine rows. A pip-blocked machine still produces a complete validation report.
Test Matrix You Will Complete
Use this exact table format in your final report. Fill it in as you work.
| # | Capability Test | Result | Evidence / Error / Notes |
|---|---|---|---|
| 2.1 | pip works (pip list) | PASS / FAIL / RESTRICTED | — |
| 2.2 | pip can install a package (cmu-graphics) | PASS / FAIL / RESTRICTED | — |
| 2.3 | CMU Graphics window opens locally | PASS / FAIL / RESTRICTED | — |
| 2.4 | tkinter opens a window | PASS / FAIL / RESTRICTED | — |
| 2.5 | turtle graphics renders | PASS / FAIL / RESTRICTED | — |
| 2.6 | External image file loads in Python | PASS / FAIL / RESTRICTED | — |
| 2.7 | External sound file plays | PASS / FAIL / RESTRICTED | — |
| 2.8 | Python can reach the public internet | PASS / FAIL / RESTRICTED | — |
| 2.9 | Python can read/write a local file | PASS / FAIL / RESTRICTED | — |
TEST 2.1 pip Functionality
PS> python -m pip --version PS> python -m pip list
If pip list prints a table of packages (even a small one), pip is functional. Note whether you needed to upgrade pip:
PS> python -m pip install --upgrade pip
TEST 2.2 Install CMU Graphics via pip
CMU Graphics is the same library used in the CMU CS Academy online environment. Determining whether it can be installed locally is a major decision point for whether this lab can host serious Python coursework offline.
PS> python -m pip install cmu-graphics
If the install fails because of a permission error, retry with the user flag:
PS> python -m pip install --user cmu-graphics
Verify the install completed:
PS> python -m pip show cmu-graphics
What if the install fails?
Failure is a valuable finding, not a setback. Capture the full error text — especially any line containing "SSLError," "Could not find a version," "PermissionError," "proxy," or "blocked." That error is the data your report needs to cite. Do not attempt to disable certificate verification (--trusted-host hacks) — that is exactly the kind of unsafe workaround a professional report should flag, not perform.
TEST 2.3 CMU Graphics — Local Execution
If Test 2.2 succeeded, create cmu_test.py with the following content and run it:
from cmu_graphics import *
Label('Lab Validation: CMU Graphics OK', 200, 100, size=18)
Rect(50, 150, 300, 50, fill='lightBlue', border='black')
Circle(200, 250, 30, fill='red')
cmu_graphics.run()
You should see a graphics window open with text, a rectangle, and a red circle. Close the window when done.
Capture Evidence
Screenshot the running CMU window. If the window does not appear, screenshot the terminal error. Either outcome is a valid evidence artifact.
TEST 2.4 tkinter (Built-in GUI)
tkinter ships with most Python distributions. Run the built-in self-test from the terminal:
PS> python -m tkinter
A small "TK" window should appear with a "Click me!" button and a "QUIT" button. If it does, screenshot it and close it.
Then create tk_test.py and confirm you can build your own:
import tkinter as tk
root = tk.Tk()
root.title("Lab Validation Window")
tk.Label(root, text="tkinter is functional on this machine.").pack(padx=20, pady=20)
tk.Button(root, text="Close", command=root.destroy).pack(pady=10)
root.mainloop()
TEST 2.5 turtle Graphics
turtle is also built in. Create turtle_test.py:
import turtle
t = turtle.Turtle()
t.shape("turtle")
for _ in range(6):
t.forward(80)
t.left(60)
turtle.done()
You should see a hexagon traced by a small turtle.
TEST 2.6 Loading External Image Assets
Place any .png file in your python-validation-lab folder (download a small image, or grab one from the school site). Then create image_test.py:
import tkinter as tk
root = tk.Tk()
root.title("Image Load Test")
img = tk.PhotoImage(file="test.png") # adjust filename to match yours
tk.Label(root, image=img).pack()
root.mainloop()
If the image displays, the file system + GUI pipeline supports asset loading. Note whether the image renders, errors, or is silently blocked.
TEST 2.7 Audio Playback
Place any short .wav file in your folder. Then run:
import winsound
winsound.PlaySound("test.wav", winsound.SND_FILENAME)
If audio plays, sound output is available to Python. If not, document whether the failure is a missing codec, a permission issue, or simply muted hardware.
TEST 2.8 Internet Access from Python
This is one of the most informative tests in a managed environment. Create net_test.py:
import urllib.request
url = "https://example.com"
try:
response = urllib.request.urlopen(url, timeout=5)
print("STATUS:", response.status)
print("FIRST 200 BYTES:", response.read(200))
except Exception as e:
print("BLOCKED OR FAILED:", type(e).__name__, "-", e)
Possible outcomes — all of them are findings worth recording:
- Status 200 — open internet from Python
- SSL error — content filter is intercepting HTTPS
- Timeout — outbound traffic blocked at the firewall
- 403 / proxy authentication — district proxy in front of all traffic
TEST 2.9 Local File Read & Write
Run the following from the integrated terminal in VS Code:
PS> python -c "open('write_test.txt','w').write('ok'); print(open('write_test.txt').read())"
Repeat the test, but write the file to a Documents subfolder and to your Desktop. Some managed environments allow writing to Documents but block Desktop, and some redirect both to OneDrive without telling the user. Note any redirection.
Objective: Probe the boundaries of what this managed system permits — professionally. This is capability validation, not "trying to break things." A real IT manager needs to know where the operational edges of the platform are before a curriculum or product depends on those edges.
Rules of Engagement
You may only test boundaries with software you legitimately use as a student. You may not attempt to access another user's account, escalate privileges, disable security tools, evade content filters, or modify shared infrastructure. If a test would require any of those, do not run it — note it as "out of scope per policy" and move on. The maturity to know when to stop is part of being a professional technician.
BOUNDARY A Extension & Package Installation Limits
- Install one additional, harmless VS Code extension (e.g., Code Spell Checker). Does it install? Does it require admin?
- Try
python -m pip install requests. Does pip respect proxy settings? Is there an SSL trust issue? - Try installing a package that is large, like
numpy. Note install time — is the network bandwidth comparable to a pro environment, or visibly throttled?
BOUNDARY B Performance Under Load
Create perf_test.py and run it. This is a deliberately heavy loop to expose CPU performance characteristics on the lab hardware.
import time
start = time.perf_counter()
total = 0
for i in range(10_000_000):
total += i * i
elapsed = time.perf_counter() - start
print(f"Sum: {total}")
print(f"Elapsed: {elapsed:.3f} seconds")
Run it three times. Record the median elapsed time. Compare with a classmate on a different machine — are the numbers consistent across the lab, or do some machines run noticeably slower?
BOUNDARY C Animation & Real-Time Behavior
If CMU Graphics installed in Phase 2, try a continuous animation:
from cmu_graphics import *
ball = Circle(50, 200, 20, fill='red')
app.dx = 4
def onStep():
ball.centerX += app.dx
if ball.centerX > 380 or ball.centerX < 20:
app.dx = -app.dx
cmu_graphics.run()
Does the animation run smoothly, or does it stutter? Does the window remain responsive while the script runs? Inconsistent frame rates between machines indicate uneven graphics driver deployment.
BOUNDARY D Cross-Machine Consistency
Walk through the lab with your notes and compare results with at least three other classmates on different machines. For each test in the Phase 2 matrix, note where machines disagree:
- Did everyone get the same Python version?
- Did pip succeed on every machine?
- Did internet access behave identically?
- Did CMU Graphics open everywhere or only some places?
Inconsistencies between machines indicate deployment drift — a real-world IT problem that managers care about deeply, because it means students cannot rely on identical behavior across the lab.
BOUNDARY E Documented Restrictions
List every action that the system actively blocked today. Include the exact error text. Examples might include:
- "This app has been blocked by your system administrator"
- "The requested operation requires elevation"
- HTTPS certificate intercept warnings
- OneDrive folder redirect notices
- Group Policy-enforced password prompts
This list, by itself, is one of the most professionally useful artifacts you will produce today.
Objective: Compile your findings into a Python Development Environment Capability Report. Submit as a PDF through Schoology. The report must be written in a tone that an IT manager — not a teacher — would recognize as professional documentation.
Required Report Sections
Use these section headings, in this order, in your PDF.
- Report title
- Your name and class period
- Date of validation
- Lab machine hostname(s) tested
One paragraph an IT manager could read in 30 seconds. Answer: Can these lab machines support real Python development? Yes, no, or with caveats? Lead with the verdict.
- Hostname, OS, OS version
- Python version installed and install method used
- VS Code version and install method used
- Account type (standard user, admin, etc.)
Document which deployment paths worked and which did not. Include the screenshots of hello.py running from terminal and from VS Code.
Reproduce the full PASS / FAIL / RESTRICTED matrix from Phase 2, with evidence column filled in. Include screenshots for every PASS that has visual evidence and the exact error text for every FAIL or RESTRICTED.
Performance numbers, cross-machine comparison, and the documented-restrictions list.
A clean, bulleted list of every blocker you encountered, with the literal error text. No commentary.
Based on the data — not feelings — what should the teacher and IT department know? Examples: "Microsoft Store Python deployed cleanly on all five machines tested; recommend it as the standard install method," or "pip installs over the district network averaged X seconds; large packages will be slow."
Restate, in one sentence, whether this lab is suitable for local Python development workflows — and what the major caveats are.
Optional. Raw command output, additional screenshots, anything that supports the report but would clutter the body.
Producing the PDF
Author the report in Microsoft Word, Google Docs, or any equivalent tool. To export to PDF:
- Word: File > Save As > PDF (*.pdf)
- Google Docs: File > Download > PDF Document (.pdf)
- Any app: File > Print > Microsoft Print to PDF
Filename convention: LASTNAME_FIRSTNAME_PythonCapabilityReport.pdf
If your capability report is drafted and you still have block time remaining, pick one or more of the following. These are technically aligned with the lesson — they all deepen your validation findings or expand the deployment surface you've tested. Document anything you do here in the report's Appendix.
Build a tkinter Diagnostic GUI
GUI tkinter ~30 min
Write a small tkinter app with three buttons: "Run Network Test," "Run File I/O Test," "Show Python Info." Each button runs the relevant Phase 2 test and prints the result inside the window. You're effectively turning your capability matrix into a tool. Submit a screenshot in the appendix.
Turtle Animation Stress Test
turtle performance ~20 min
Write a turtle script that draws 1,000 expanding spirals or randomly-positioned shapes. Time it. Compare on a second machine. Does the visual frame rate hold up? At what shape count does it start to lag?
Recreate a CMU Academy Interaction Locally
cmu-graphics ~45 min
Pick a small graphical interaction you've previously built in CMU CS Academy (a click-counter, a moving character, a simple menu) and rebuild it locally using cmu-graphics. Document any behavioral differences between the cloud version and the local version.
Benchmark Python Versions
benchmarking ~25 min
If a classmate has a different Python version installed, run your perf_test.py on both. Record the runtimes. Is one version faster? By how much? This is real procurement data — newer Pythons are often substantially faster, and that matters when buying lab software stacks.
Local File Handling Audit
filesystem ~20 min
Use Python to write a test file to: Documents, Desktop, OneDrive, the temp folder, and a path you don't normally have access to. Record which succeeded, which failed, and which were silently redirected. Map the writable/read-only zones of the filesystem.
Generate a QR Code Locally
pip imaging ~20 min
Try python -m pip install qrcode[pil]. If it succeeds, generate a QR code that links to your school's homepage and save the image. This is another data point on whether pip-based imaging libraries deploy cleanly on this network.
Plot Lab-Wide Performance
collaboration data ~30 min
Collect perf_test.py times from five classmates. Build a small chart (Excel or matplotlib) of the spread. Drop the chart into your Appendix. This is exactly how a real IT team identifies hardware outliers in a deployment.
Document a "Day 2" Onboarding Guide
documentation ~25 min
Write a one-page "How to Set Up Python on a Fresh Lab Machine" guide based on what you learned today, including only the deployment paths that worked. Imagine the next student sitting down at this machine and needing nothing but your guide.
Submission & Grading
Where to submit: Schoology — the assignment titled Python Development Environment Capability Report.
What to submit: A single PDF named LASTNAME_FIRSTNAME_PythonCapabilityReport.pdf containing the ten sections listed in Phase 4.
When: Before the end of the block. Late work follows the standard PIT late-work policy.
How you'll be graded: Your report is evaluated on the same criteria a real IT deployment report would be:
- Completeness — all required sections present, all Phase 2 matrix rows filled in
- Evidence — screenshots and exact error text included
- Accuracy — claims match the captured evidence
- Professional communication — tone, clarity, formatting, proofread
- Insight — the recommendations and verdict are grounded in your data, not guessing
Honest "FAIL" and "RESTRICTED" results — when documented well — are worth full credit. Inflating results or copying a classmate's findings is academic dishonesty and will be treated under the standard PIT policy.
TEKS Alignment — §130.312 Practicum in Information Technology
This lab is intentionally aligned with the following Texas Essential Knowledge and Skills:
- (c)(1)(E) — solve problems and think critically (troubleshooting deployment failures, isolating root causes from error text)
- (c)(1)(F) — function effectively as a team member (troubleshooting groups, cross-machine comparison)
- (c)(1)(I) — demonstrate planning, time-management, and project-management skills (self-paced 3-hour block, four phases, professional deliverable)
- (c)(3)(A) — proper use of written, verbal, and visual communication consistent with IT industry standards (formal capability report, captioned figures, exact error quotation)
- (c)(4)(A)–(B) — identify a problem in IT and apply a top-down research approach (defining "is this lab capable of supporting Python?" and decomposing into testable capabilities)
- (c)(5)(A)–(C) — apply critical-thinking strategies and decision-making to technological solutions (choosing between deployment paths, recommending a standard install method)
- (c)(6)(C) — identify areas where quality and reliability can be designed in (cross-machine consistency findings, deployment-drift identification)
- (c)(6)(D) — develop and implement a security management plan (operating within rules of engagement, refusing to bypass policy)
- (c)(6)(F) — develop an evaluation method for analyzing the effect of the product or service (structured PASS / FAIL / RESTRICTED test matrix, executive summary verdict)
- (c)(6)(G) — develop a project portfolio that documents the research and development process (the capability report itself, suitable for portfolio inclusion)