Back to PIT Home
INTERNAL // IT DEPLOYMENT WORK ORDER

Python Development Environment: Deployment & Capability Validation Lab

Determining whether the classroom lab can support professional Python development workflows inside a managed enterprise environment.

Block Length: 3 hours (180 minutes)
Format: Independent / Small Troubleshooting Groups
Toolset: VS Code, Python 3, pip, Windows Terminal
Deliverable: Capability Report (PDF via Schoology)

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:

  1. A failure is data, not a dead end. Capture the exact error text and a screenshot, write it into your test matrix as FAIL or RESTRICTED, 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.
  2. 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.
  3. 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.

Suggested Pacing for the 3-Hour Block

TimePhase
0:00–0:15Mission briefing review, machine assignment, sign-in
0:15–1:00Phase 1: Deployment & Configuration
1:00–1:55Phase 2: Capability Testing & Environment Validation
1:55–2:25Phase 3: System Boundary & Limitation Testing
2:25–2:55Phase 4: Capability Report Drafting & PDF Export
2:55–3:00Final submission to Schoology, log out, secure workstation

Pacing is a guideline. The deliverable is what matters — manage your own clock professionally.

PHASE 1

Deployment & Configuration

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
Python 3.12.x pip 24.x.x from C:\Users\...\Python\Python312\Lib\site-packages\pip (python 3.12) C:\Users\...\Python\Python312\python.exe

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.

  1. 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.
  2. 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 the python alias is missing — note that in your report and use py in place of python for 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 python is 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:

  1. Software Center / Company Portal: Search for Visual Studio Code and install if available.
  2. 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
1.95.x abc123def456... x64

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 .vsix from 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
Hello from LAB-PC-## Python version: 3.12.x Executable path: C:\Users\...\python.exe

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:

  1. Press the Run (▶) triangle in the top-right of the editor.
  2. Open the integrated terminal (Ctrl + `) and run python hello.py from inside VS Code.
  3. 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 --version works in a fresh terminal
  • pip --version works
  • VS Code installed; code --version works
  • Microsoft Python extension installed; interpreter selected
  • hello.py runs from terminal
  • hello.py runs from VS Code Run button
  • hello.py runs 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.
PHASE 2

Capability Testing & Environment Validation

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.1pip works (pip list)PASS / FAIL / RESTRICTED
2.2pip can install a package (cmu-graphics)PASS / FAIL / RESTRICTED
2.3CMU Graphics window opens locallyPASS / FAIL / RESTRICTED
2.4tkinter opens a windowPASS / FAIL / RESTRICTED
2.5turtle graphics rendersPASS / FAIL / RESTRICTED
2.6External image file loads in PythonPASS / FAIL / RESTRICTED
2.7External sound file playsPASS / FAIL / RESTRICTED
2.8Python can reach the public internetPASS / FAIL / RESTRICTED
2.9Python can read/write a local filePASS / 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())"
ok

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.

PHASE 3

System Boundary & Limitation Testing

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.

PHASE 4

Documentation & Capability Report

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.

1. Cover Page
  • Report title
  • Your name and class period
  • Date of validation
  • Lab machine hostname(s) tested
2. Executive Summary (≤ 1 paragraph)

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.

3. System Inventory
  • Hostname, OS, OS version
  • Python version installed and install method used
  • VS Code version and install method used
  • Account type (standard user, admin, etc.)
4. Phase 1: Deployment Findings

Document which deployment paths worked and which did not. Include the screenshots of hello.py running from terminal and from VS Code.

5. Phase 2: Capability Test Matrix

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.

6. Phase 3: Boundary & Consistency Findings

Performance numbers, cross-machine comparison, and the documented-restrictions list.

7. Identified Failures & Restrictions

A clean, bulleted list of every blocker you encountered, with the literal error text. No commentary.

8. Recommendations for Future Classroom Use

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."

9. Overall Verdict

Restate, in one sentence, whether this lab is suitable for local Python development workflows — and what the major caveats are.

10. Appendix

Optional. Raw command output, additional screenshots, anything that supports the report but would clutter the body.

Professional Communication Expectations

  • Use complete sentences. Use third person ("the technician installed...") or neutral first person ("I installed...") consistently. Avoid casual phrasing like "stuff didn't work."
  • State facts before opinions. Evidence first, conclusion second.
  • Quote error messages exactly. Wrap them in a fixed-width font or block quote.
  • Label every screenshot with a caption (e.g., Figure 3 — CMU Graphics window confirming successful local rendering on LAB-PC-04).
  • Spellcheck. Proofread. A typo in a deployment report costs credibility.
  • Length is not the goal — clarity is. A tight 3-page report beats a sprawling 8-page one.

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

BONUS

Finished Early? Extension Activities

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)
Back to PIT Home