Portfolio, Career & Professional Practiceالملف المهني والمسار الوظيفي والممارسة المهنية

L94 — Version Control with Git: Repositories, Commits & History

Learner file. Answers and model solutions are in a separate instructor-only file. Version: U22 Production v1 · Content date: 27 October 2026. Time estimates are planning estimates until learners have tested them. The commands in this lesson were run with Git 2.43 and Python 3.13.16 on Linux (recorded in D.World's internal Code Test Report). The current Git release is 2.56 (October 2026); every command here works with Git 2.28 or later. Not run on Windows or macOS: on Windows, type the commands in Git Bash, which is installed with Git for Windows.

Your commit hashes (the 7-character codes such as 3f2a9c1) and dates will differ from the ones shown: they depend on your name, email and the time of each commit. Everything else should match.

All businesses are fictional and all data is synthetic.

1. Lesson Identity

Time breakdown (planning estimate): install and concept with worked example 60 min · guided practice 30 min · independent practice 30 min · knowledge check 10 min · AI 5 min (optional) · workplace task and mini challenge 15 min.

What you need: Git installed (https://git-scm.com/install); a terminal (Git Bash on Windows; Terminal on macOS and Linux); Python with pandas from earlier stages; practice_files (u22_data/l94_delivery_project/, u22_data/l94_messy_folder/). Open the terminal in the practice_files folder (in Git Bash: right-click inside the folder and choose "Open Git Bash here").

2. Learning Objective

By the end of this lesson, you will be able to:

• create a Git repository for an analysis project and record your work in small commits with clear messages;
• inspect the history and the differences between versions;
• keep unwanted files (environments, outputs, secrets, large or private data) out of the repository with .gitignore.

D.World approved objective (verbatim): Create a Git repository for an analysis project, record work in small commits with clear messages, inspect history and differences, and keep unwanted files out of the repository with .gitignore.

3. Why It Matters

In October, the operations lead asks why the new Q3 report shows a late-delivery rate of 6.7% when last month's dashboard showed 16.9% for the same deliveries. Someone changed the definition of "late", but who, when, and why? Was it agreed? Which reports used which version? Folders named analysis_v2_FINAL_final.py cannot answer that.

Version control keeps every saved state of a project together with who changed it, when and why. You can compare any two versions, go back to an earlier one, and work with others without overwriting each other. Git is the most widely used version-control system; it was written in 2005 for the development of the Linux kernel and is now used for code, analyses and documentation everywhere. It is not a backup tool (that comes with GitHub in L96): it is a history of decisions.

Key principle: commit small, meaningful steps with messages that say what changed and why; keep outputs, environments, secrets and large or private data out of the repository.

4. Concept

Part A — Install and introduce yourself to Git (once per computer)

Install Git from https://git-scm.com/install (on Windows the installer also gives you Git Bash). Then, in a terminal:

git --version          # the version number differs on your computer

git version 2.43.0

Git records an author name and email in every commit. Set them once (use your name and the email you will use for GitHub; the lesson uses a fictional analyst), and name the first branch main, as GitHub does:

git config --global user.name "Amira Hassan"
git config --global user.email "amira.hassan@example.com"
git config --global init.defaultBranch main
git config --global --list

user.name=Amira Hassan
user.email=amira.hassan@example.com
init.defaultbranch=main

On Windows, the installer's default line-ending setting is fine; Git may print a note such as "LF will be replaced by CRLF". That is a message about line endings, not an error.

Two things that trip up beginners.

• The editor. Every commit in this unit gives its message with -m "...", so no editor opens. If you ever run git commit, git merge or git revert without a message, Git opens a text editor for it, often Vim. To leave Vim: press Esc, type :wq and press Enter to save and continue (or :q! and Enter to cancel). To get a simpler editor instead, run git config --global core.editor nano once (nano comes with Git for Windows and with macOS and most Linux systems; Ctrl+O, Enter saves and Ctrl+X closes it).
• python or python3. This unit writes python. If your terminal says the command is not found (or Windows opens the Microsoft Store), use python3 on macOS and Linux or py on Windows. Inside an activated virtual environment (L97), python always works.

Part B — Three places: working tree, staging area, history

A repository is the project folder plus a hidden .git folder where Git keeps the history. Copy the delivery project and turn it into a repository:

cp -r u22_data/l94_delivery_project cedar_delivery
cd cedar_delivery
ls
git init
git status

README.md
analysis.py
data
Initialized empty Git repository in /home/amira/practice_files/cedar_delivery/.git/
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    README.md
    analysis.py
    data/

nothing added to commit but untracked files present (use "git add" to track)

Git sees three untracked items: it will not record anything until you tell it to.

Part C — Decide what does NOT belong in the repository

Run the analysis once, as you normally would. It creates a results/ folder:

python analysis.py
git status --short

deliveries: 1800 | late rate: 0.169
zone
East      0.276
South     0.189
North     0.156
Centre    0.124
West      0.117
?? README.md
?? analysis.py
?? data/
?? results/

?? means untracked. results/ is an output: the script recreates it every time, so tracking it only adds noise (and outputs can go stale). Some things must never be committed:

A file called .gitignore lists patterns Git should ignore. Create it with your editor, or in the terminal:

cat > .gitignore << 'EOF'
# generated outputs (rebuilt by analysis.py)
results/
# Python and Jupyter clutter
__pycache__/
.ipynb_checkpoints/
# environments and secrets: never commit
.venv/
.env
EOF
git status --short

?? .gitignore
?? README.md
?? analysis.py
?? data/

results/ has disappeared from the list: it is ignored. The small, synthetic delivery file (1,800 rows) is fine to commit; whether real data may be committed is a question of size, privacy and licence (L96).

Part D — Commit in small, meaningful steps

git add puts changes in the staging area; git commit saves them as one commit with a message. Commit the data and documentation first, then the analysis, so each commit has one purpose:

git add .gitignore README.md data/
git commit -m "Add Q3 delivery data, README and .gitignore"
git add analysis.py
git commit -m "Add late-rate analysis by zone"
git log --oneline

[main (root-commit) 0f3dee9] Add Q3 delivery data, README and .gitignore
 3 files changed, 1815 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 README.md
 create mode 100644 data/deliveries_q3.csv
[main 8199b91] Add late-rate analysis by zone
 1 file changed, 12 insertions(+)
 create mode 100644 analysis.py
8199b91 Add late-rate analysis by zone
0f3dee9 Add Q3 delivery data, README and .gitignore

Each line of git log --oneline is one commit: its short hash and the first line of its message. Good messages make that list readable months later:

Convention: a short summary in the imperative mood ("Add", "Fix", "Remove"), about 50 characters; if the change needs a reason, add a blank line and a body.

Part E — See exactly what changed: git diff

Operations decided on 3 October that a delivery up to 5 minutes over the promised time is not reported as late. Open analysis.py in your editor and make two changes: under import pandas as pd, add a blank line and the line GRACE_MINUTES = 5 # operations: up to 5 minutes over the promise is not "late"; then change the late rule to d["actual_minutes"] > d["promised_minutes"] + GRACE_MINUTES. Save the file.

git status --short
git diff

 M analysis.py
diff --git a/analysis.py b/analysis.py
index f3fb907..9397bb3 100644
--- a/analysis.py
+++ b/analysis.py
@@ -3,8 +3,10 @@ from pathlib import Path

 import pandas as pd

+GRACE_MINUTES = 5      # operations: up to 5 minutes over the promise is not "late"
+
 d = pd.read_csv("data/deliveries_q3.csv")
-d["late"] = d["actual_minutes"] > d["promised_minutes"]
+d["late"] = d["actual_minutes"] > d["promised_minutes"] + GRACE_MINUTES
 by_zone = d.groupby("zone")["late"].mean().round(3).sort_values(ascending=False)
 Path("results").mkdir(exist_ok=True)
 by_zone.to_csv("results/late_by_zone.csv")

Lines starting with - were removed and lines starting with + were added; M means modified. Run the analysis, then commit with a body that records the reason:

python analysis.py
git commit -am "Count a delivery as late only after a 5-minute grace" -m "Operations agreed on 3 Oct that up to 5 minutes over the promised time is not reported as late."
git log --oneline

deliveries: 1800 | late rate: 0.067
zone
East      0.110
South     0.086
North     0.063
Centre    0.044
West      0.036
[main 41d91aa] Count a delivery as late only after a 5-minute grace
 1 file changed, 3 insertions(+), 1 deletion(-)
41d91aa Count a delivery as late only after a 5-minute grace
8199b91 Add late-rate analysis by zone
0f3dee9 Add Q3 delivery data, README and .gitignore

The late rate fell from 16.9% (without grace) to 6.7%: a change in definition, not in performance. The history now shows when and why. (-a stages every change to files Git already tracks; new files still need git add.)

Part F — Undo a change you have not committed: git restore

An accidental edit happens: a stray line ends up in the README. To practise, add the line TODO delete me at the end of README.md and save; then check and undo:

git status --short
git restore README.md
git status

 M README.md
On branch main
nothing to commit, working tree clean

git restore FILE replaces your working copy with the last committed version (if you had already staged the file with git add, with the staged version instead), so any unstaged change in that file is lost; check git diff FILE first. To look at any earlier commit, use git show HASH or git log --stat:

git log --stat --oneline -2

41d91aa Count a delivery as late only after a 5-minute grace
 analysis.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
8199b91 Add late-rate analysis by zone
 analysis.py | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Undoing commits safely is L95.

5. Worked Example

Cedar Lane (fictional), synthetic data. The operations analyst puts the Q3 delivery analysis under version control before changing the definition of "late".

Step 1 — Repository: git init in the project folder; name and email configured; branch main.

Step 2 — What to exclude: results/ (rebuilt by the script), caches, checkpoints, .venv/ and .env go into .gitignore before the first commit.

Step 3 — Two purposeful commits: data, README and .gitignore; then the analysis.

Step 4 — The rule change as its own commit: git diff shows exactly two changed lines; the commit message records the decision and its date.

Step 5 — Answer to the operations lead: "The late rate changed because the definition changed on 3 October (commit 'Count a delivery as late only after a 5-minute grace'): 16.9% under the old rule, 6.7% under the new one. Reports before that commit use the old rule."

6. Visual Explanation

 working tree  ──git add──▶  staging area  ──git commit──▶  history (.git)
 (your files)                (next commit)                  a1b2c3d Add data, README, .gitignore
      ▲                                                     d4e5f6a Add late-rate analysis
      └────────────── git restore FILE (discard edits) ◀─── 9f8e7d6 Count late only after 5-min grace
 git status: what changed?   git diff: which lines?   git log: which commits?
 .gitignore: results/  __pycache__/  .ipynb_checkpoints/  .venv/  .env   (never: secrets, environments, outputs)

Alt text: Files move from the working tree to the staging area with git add, and from the staging area into the history with git commit. The history is a list of commits, each with a hash and a message, for example adding the data, adding the analysis and changing the late rule. git restore replaces an edited file with its last committed version. git status shows what changed, git diff shows which lines, and git log shows the commits. A .gitignore file keeps outputs, caches, notebook checkpoints, environments and secret files out of the repository.

7. Guided Practice

In a terminal opened in practice_files:

1. Configure your name, email and the default branch main (Part A).
2. Copy u22_data/l94_delivery_project to cedar_delivery, run git init, and check git status.
3. Run python analysis.py, write the .gitignore, and check that results/ is ignored.
4. Make the two commits of Part D and check git log --oneline.
5. Make the grace-period change, inspect git diff, run the analysis and commit with a message body.
6. Add a stray line to README.md, see it in git status, and restore the file.
7. Write down the three hashes from your own git log --oneline.

8. Independent Practice

Part 1 — The messy folder. Copy u22_data/l94_messy_folder to messy_project and look inside (ls -a, including hidden files). It contains a virtual environment, notebook checkpoints, a Python cache, an output, a 9,000-row export with customer phone numbers, a .env file with a (fake) password, and two versions of the analysis script.

1. For every file and folder, decide: commit, ignore, or delete. Give a one-line reason for each.
2. Write the .gitignore, run git init, and check with git status --short that only the right files are offered.
3. Commit in at least two meaningful steps. Show git log --oneline.

Part 2 — Rewrite a colleague's messages. colleague_commit_messages.txt lists six commit messages with what each commit really changed. Rewrite each message (summary line, plus a body where a reason is needed), and say which commit should not have been made at all.

9. Knowledge Check — Version Control

Q1. What is Git mainly for in an analysis project?

• A) Making copies of the project folder in case the computer breaks
• B) Keeping a history of changes with who made them, when and why
• C) Running the analysis faster by caching its results
• D) Sharing large data files with the rest of the team

Q2. You changed analysis.py and want to see exactly which lines changed before committing. Which command?

• A) git diff
• B) git log --oneline
• C) git commit -a
• D) git init

Q3. Which file belongs in .gitignore for an analysis project?

• A) analysis.py
• B) README.md
• C) requirements.txt
• D) .env with a database password

Q4. What does the staging area hold?

• A) Every earlier version of every file that the project has ever contained
• B) The files Git has been told never to track at all
• C) The changes you have chosen to include in the next commit
• D) A copy of the repository that is stored on GitHub

Q5. Which commit message is best?

• A) final changes
• B) Count a delivery as late only after a 5-minute grace
• C) update analysis.py
• D) fixed it

Q6. The script recreates results/late_by_zone.csv on every run. Why ignore it?

• A) Git cannot store CSV files that are produced by a Python script
• B) Output files are always private data
• C) It is rebuilt from the code, so a tracked copy goes stale
• D) .gitignore deletes the file from your computer after the next commit

Q7. You edited README.md and have not staged or committed the edit. What does git restore README.md do?

• A) Replaces your edited README with its last committed version
• B) Restores the README from the copy of the project that is stored on GitHub
• C) Creates a new commit that undoes the last README commit
• D) Brings back a README that was deleted three commits ago

Q8. Why make several small commits rather than one big one at the end?

• A) Git limits each commit to a few files
• B) Each change can be understood, reviewed and undone on its own
• C) Small commits take up less disk space in the repository than one large commit
• D) GitHub only shows the last commit of each day on the repository page

10. AI in Practice (optional, bounded)

Goal: use an AI assistant to explain a Git message, then check it yourself.

1. Run git commit -m "test" in a folder with no staged changes and copy the message Git prints.
2. Ask: "Explain this Git message and what I should do next: [message]."
3. Before following the advice, run git status and check that the explanation matches what Git shows.

Boundaries: AI is optional. Never paste passwords, .env contents or private data into a prompt. Never run a command an AI suggests if you cannot say what it does, above all git reset --hard, git clean -f or git push --force, which can destroy work.

11. AI Verification

1. Before and after: run git status (and git log --oneline) before and after every suggested command.
2. Destructive commands: look up any command with --hard, --force or clean in Pro Git before running it.
3. Match the message: the AI's explanation must match what git status says.
4. Write down what you changed in the AI's advice.

12. Business Lens

A commit history is an audit trail for analytical decisions. When a number in a report changes, the first question from management is "why?". A project under version control answers it in minutes: the commit that changed the rule, the date, the person and the reason. It also makes reviews possible: a colleague can read one small commit instead of a whole folder. And because secrets and personal data stay out of the repository, the history can be shared safely.

13. Workplace Task — The Commit Policy

Fictional business: Cedar Lane. Write the five-line commit policy (60–100 words) for the analytics team's shared projects: what a commit contains, how messages are written, what is never committed, and when a message needs a body.

14. Mini Challenge — One Big Commit

Fictional business: Cedar Lane. A colleague did a whole week of work in one commit. Compare its statistics with the three commits of Part D and E:

Its repository is in u22_data/l94_one_commit.bundle (a bundle is a whole repository packed into one file; git clone can unpack it).

cd ..
git clone -q u22_data/l94_one_commit.bundle one_commit
cd one_commit
git log --stat --oneline
cd ../cedar_delivery

1b73fe4 week 41 work
 .gitignore             |    8 +
 README.md              |    6 +
 analysis.py            |   14 +
 data/deliveries_q3.csv | 1801 ++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 1829 insertions(+)

1. Before you open the output, predict what the colleague's single commit will show, compared with the three commits you made.
2. From the colleague's history alone, can you tell when the late rule changed? Why or why not?
3. Which of your three commits could you undo without touching the others?
4. Write one sentence your team can keep as a rule about commit size.

Submit before feedback. No solution is provided here.

15. Resources

Required (about 30 min):

• Scott Chacon and Ben Straub, Pro Git (2nd edition), chapters 2.1–2.4 (Getting a Git Repository, Recording Changes, Viewing the Commit History, Undoing Things). Free online; content licensed CC BY-NC-SA 3.0. https://git-scm.com/book/en/v2 (Opened 27 Oct 2026.)

Recommended:

• GitHub Docs: Ignoring files (.gitignore in the repository root, templates, and how to stop tracking a file that is already committed). https://docs.github.com/en/get-started/git-basics/ignoring-files (Opened 27 Oct 2026.)

16. Person to Follow / Role Model

Linus Torvalds.

• Verified fact: Pro Git records that in 2005 the Linux development community, "and in particular Linus Torvalds, the creator of Linux", developed their own version-control tool, Git (chapter "A Short History of Git", opened 27 Oct 2026).
• Why D.World recommends him: Git was built for a large project in which thousands of people change the same files; the habits it rewards (small changes, clear descriptions, review) suit analysis teams too.
• Honest note: follow the history of the tool, not a person's style; check commands against the documentation.
• Try this: read the short history chapter and list the goals Git was designed for. Which of them matter for a two-person analytics team?

17. Glossary

Review: restart and run all (L21) · repeatable workflow (L29) · experiment log (L88).

18. Reflection

1. Which file in one of your earlier projects should never have been shared?
2. Which of your past analysis changes would you have liked to be able to explain with a commit?
3. What will you put in a commit message body from now on?

19. Next Step

Next: L95 — Branches, Merging & Undoing Safely. Try an idea on a branch without breaking the version the business relies on, and undo a mistake without losing later work.

20. Assessment Evidence

References

1. Chacon, S. and Straub, B. Pro Git, 2nd edition (Apress, 2014; online edition at git-scm.com), chapters 1.2 (history), 2.1–2.4. https://git-scm.com/book/en/v2 (PROGIT). Supports: history of Git (quotation), commands, undoing changes.
2. GitHub. Ignoring files. https://docs.github.com/en/get-started/git-basics/ignoring-files (GH-IGNORE). Supports: .gitignore location, templates, untracking files.
3. Git project. Install. https://git-scm.com/install (current release 2.56, Git for Windows released 22 Oct 2026).
4. D.World Stage 5 Detailed Lesson Map v1.0 (L94 row). Internal.

L94 — التحكم في الإصدارات باستخدام Git: المستودعات، والإيداعات، والسجل

ملف المتعلّم. الإجابات والحلول النموذجية في ملف منفصل خاص بالمدرّس فقط. الإصدار: U22 Production v1 · تاريخ المحتوى: 27 أكتوبر 2026. تقديرات الوقت تقديرات للتخطيط إلى أن يختبرها المتعلّمون. الأوامر في هذا الدرس شُغّلت باستخدام Git 2.43 وPython 3.13.16 على Linux (مسجّلة في تقرير اختبار الكود الداخلي في D.World). والإصدار الحالي من Git هو 2.56 (أكتوبر 2026)؛ وكل أمر هنا يعمل مع Git 2.28 أو أحدث. ولم تُشغَّل على Windows ولا على macOS: على Windows، اكتب الأوامر في Git Bash، الذي يُثبَّت مع Git for Windows.

ستختلف رموز الإيداع (hashes) لديك (الرموز ذات السبعة أحرف مثل 3f2a9c1) والتواريخ عمّا يظهر هنا: فهي تعتمد على اسمك، وبريدك الإلكتروني، ووقت كل إيداع. أما كل ما عدا ذلك فيجب أن يتطابق.

كل الأنشطة التجارية خيالية، وكل البيانات مصطنعة.

1. بطاقة الدرس

تفصيل الوقت (تقدير للتخطيط):

• التثبيت والمفهوم مع المثال المحلول: 60 دقيقة.
• التدريب الموجَّه: 30 دقيقة.
• التدريب المستقل: 30 دقيقة.
• اختبار الفهم: 10 دقائق.
• الذكاء الاصطناعي: 5 دقائق (اختياري).
• مهمة العمل والتحدي القصير: 15 دقيقة.

ما تحتاج إليه: Git مثبّتًا (https://git-scm.com/install)؛ وطرفية (Git Bash على Windows؛ وTerminal على macOS وLinux)؛ وPython مع pandas من المراحل السابقة؛ ومجلد practice_files (u22_data/l94_delivery_project/ وu22_data/l94_messy_folder/). افتح الطرفية داخل مجلد practice_files (في Git Bash: انقر بالزر الأيمن داخل المجلد واختر "Open Git Bash here").

2. هدف التعلّم

في نهاية هذا الدرس ستكون قادرًا على أن:

• تنشئ مستودع Git لمشروع تحليل، وتسجّل عملك في إيداعات صغيرة برسائل واضحة؛
• تفحص السجل والفروق بين الإصدارات؛
• تُبقي الملفات غير المرغوب فيها (البيئات، والمخرجات، والأسرار، والبيانات الكبيرة أو الخاصة) خارج المستودع باستخدام .gitignore.

الهدف المعتمد من D.World (بنصّه): Create a Git repository for an analysis project, record work in small commits with clear messages, inspect history and differences, and keep unwanted files out of the repository with .gitignore.

3. لماذا يهمّك هذا؟

في أكتوبر، يسأل مسؤول العمليات لماذا يعرض تقرير الربع الثالث الجديد معدل تأخير في التوصيل قدره 6.7%، بينما عرضت لوحة متابعة الشهر الماضي 16.9% للتوصيلات نفسها. شخص ما غيّر تعريف "متأخر"، لكن من، ومتى، ولماذا؟ هل اتُّفق على ذلك؟ وأي التقارير استخدمت أي إصدار؟ المجلدات التي تحمل أسماء مثل analysis_v2_FINAL_final.py لا تستطيع الإجابة.

التحكم في الإصدارات (version control) يحتفظ بكل حالة محفوظة للمشروع، ومعها من غيّرها، ومتى، ولماذا. تستطيع مقارنة أي إصدارين، والعودة إلى إصدار سابق، والعمل مع الآخرين دون أن يكتب أحدكم فوق عمل الآخر. وGit هو أكثر أنظمة التحكم في الإصدارات استخدامًا؛ كُتب في 2005 لتطوير نواة Linux، ويُستخدم الآن للكود والتحليلات والتوثيق في كل مكان. وهو ليس أداة نسخ احتياطي (هذا يأتي مع GitHub في L96): إنه سجل للقرارات.

المبدأ الأساسي: أودِع خطوات صغيرة ذات معنى برسائل تقول ما الذي تغيّر ولماذا؛ وأبقِ المخرجات، والبيئات، والأسرار، والبيانات الكبيرة أو الخاصة خارج المستودع.

4. المفهوم

الجزء A — ثبّت Git وعرّفه بنفسك (مرة واحدة لكل جهاز)

ثبّت Git من https://git-scm.com/install (على Windows يعطيك المثبّت أيضًا Git Bash). ثم في الطرفية:

git --version          # the version number differs on your computer

git version 2.43.0

(التعليق في الأمر معناه: "رقم الإصدار يختلف على جهازك".)

يسجّل Git اسم المؤلف وبريده الإلكتروني في كل إيداع. اضبطهما مرة واحدة (استخدم اسمك أنت والبريد الذي ستستخدمه في GitHub؛ والدرس يستخدم محللة خيالية)، وسمِّ الفرع الأول main، كما يفعل GitHub:

git config --global user.name "Amira Hassan"
git config --global user.email "amira.hassan@example.com"
git config --global init.defaultBranch main
git config --global --list

user.name=Amira Hassan
user.email=amira.hassan@example.com
init.defaultbranch=main

على Windows، إعداد نهايات الأسطر الافتراضي في المثبّت مناسب؛ وقد يطبع Git ملاحظة مثل "LF will be replaced by CRLF". هذه رسالة عن نهايات الأسطر، وليست خطأً.

أمران يوقعان المبتدئين.

• المحرّر. كل إيداع في هذه الوحدة يعطي رسالته باستخدام -m "..."، فلا يُفتح أي محرّر. لكن إذا شغّلت يومًا git commit أو git merge أو git revert دون رسالة، يفتح Git محرّر نصوص لكتابتها، وكثيرًا ما يكون Vim. وللخروج من Vim: اضغط Esc، واكتب :wq واضغط Enter للحفظ والمتابعة (أو :q! ثم Enter للإلغاء). وللحصول على محرّر أبسط بدلًا منه، شغّل git config --global core.editor nano مرة واحدة (يأتي nano مع Git for Windows ومع macOS ومعظم أنظمة Linux؛ وCtrl+O ثم Enter للحفظ، وCtrl+X للإغلاق).
• python أم python3. تكتب هذه الوحدة python. وإذا قالت الطرفية إن الأمر غير موجود (أو فتح Windows متجر Microsoft)، فاستخدم python3 على macOS وLinux أو py على Windows. وداخل بيئة افتراضية مفعّلة (L97) يعمل python دائمًا.

الجزء B — ثلاثة أماكن: شجرة العمل، ومنطقة التجهيز، والسجل

المستودع (repository) هو مجلد المشروع إضافةً إلى مجلد مخفي اسمه .git يحفظ فيه Git السجل. انسخ مشروع التوصيل وحوّله إلى مستودع:

cp -r u22_data/l94_delivery_project cedar_delivery
cd cedar_delivery
ls
git init
git status

README.md
analysis.py
data
Initialized empty Git repository in /home/amira/practice_files/cedar_delivery/.git/
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    README.md
    analysis.py
    data/

nothing added to commit but untracked files present (use "git add" to track)

يرى Git ثلاثة عناصر غير متتبَّعة (untracked): ولن يسجّل أي شيء حتى تطلب منه ذلك.

الجزء C — قرّر ما الذي لا ينتمي إلى المستودع

شغّل التحليل مرة، كما تفعل عادة. سينشئ مجلد results/:

python analysis.py
git status --short

deliveries: 1800 | late rate: 0.169
zone
East      0.276
South     0.189
North     0.156
Centre    0.124
West      0.117
?? README.md
?? analysis.py
?? data/
?? results/

الرمز ?? يعني غير متتبَّع. وresults/ مُخرَج: يعيد السكربت إنشاءه في كل مرة، فتتبّعه لا يضيف إلا ضجيجًا (وقد تصبح المخرجات قديمة). وبعض الأشياء يجب ألّا تُودَع أبدًا:

ملف اسمه .gitignore يسرد الأنماط التي يجب أن يتجاهلها Git. أنشئه بمحرّرك، أو في الطرفية:

cat > .gitignore << 'EOF'
# generated outputs (rebuilt by analysis.py)
results/
# Python and Jupyter clutter
__pycache__/
.ipynb_checkpoints/
# environments and secrets: never commit
.venv/
.env
EOF
git status --short

?? .gitignore
?? README.md
?? analysis.py
?? data/

(التعليقات داخل .gitignore معناها: "مخرجات مولَّدة (يعيد analysis.py بناءها)"، و"فوضى Python وJupyter"، و"البيئات والأسرار: لا تودِعها أبدًا".)

اختفى results/ من القائمة: لقد أصبح متجاهَلًا. وملف التوصيل الصغير المصطنع (1,800 صف) لا بأس بإيداعه؛ أما هل يجوز إيداع بيانات حقيقية فمسألة حجم وخصوصية وترخيص (L96).

الجزء D — أودِع في خطوات صغيرة ذات معنى

git add يضع التغييرات في منطقة التجهيز؛ وgit commit يحفظها كإيداع واحد مع رسالة. أودِع البيانات والتوثيق أولًا، ثم التحليل، حتى يكون لكل إيداع غرض واحد:

git add .gitignore README.md data/
git commit -m "Add Q3 delivery data, README and .gitignore"
git add analysis.py
git commit -m "Add late-rate analysis by zone"
git log --oneline

[main (root-commit) 0f3dee9] Add Q3 delivery data, README and .gitignore
 3 files changed, 1815 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 README.md
 create mode 100644 data/deliveries_q3.csv
[main 8199b91] Add late-rate analysis by zone
 1 file changed, 12 insertions(+)
 create mode 100644 analysis.py
8199b91 Add late-rate analysis by zone
0f3dee9 Add Q3 delivery data, README and .gitignore

(الرسالتان معناهما: "إضافة بيانات توصيل الربع الثالث وREADME و.gitignore"، و"إضافة تحليل معدل التأخير حسب المنطقة".)

كل سطر في git log --oneline إيداع واحد: رمزه المختصر والسطر الأول من رسالته. والرسائل الجيدة تجعل تلك القائمة مقروءة بعد شهور:

العُرف: سطر ملخّص قصير بصيغة الأمر ("Add" أي أضِف، و"Fix" أي أصلِح، و"Remove" أي احذف)، في حدود 50 حرفًا؛ وإذا احتاج التغيير إلى سبب، فأضف سطرًا فارغًا ثم متنًا للرسالة.

الجزء E — شاهد بالضبط ما الذي تغيّر: git diff

قرّر قسم العمليات في 3 أكتوبر أن التوصيل الذي يتجاوز الموعد الموعود بما يصل إلى 5 دقائق لا يُبلَّغ عنه كمتأخر. افتح analysis.py في محرّرك وأجرِ تغييرين: تحت import pandas as pd، أضف سطرًا فارغًا ثم السطر GRACE_MINUTES = 5 # operations: up to 5 minutes over the promise is not "late"؛ ثم غيّر قاعدة التأخير إلى d["actual_minutes"] > d["promised_minutes"] + GRACE_MINUTES. واحفظ الملف.

(التعليق في السطر المضاف معناه: "العمليات: تجاوز الموعد بما يصل إلى 5 دقائق ليس تأخيرًا".)

git status --short
git diff

 M analysis.py
diff --git a/analysis.py b/analysis.py
index f3fb907..9397bb3 100644
--- a/analysis.py
+++ b/analysis.py
@@ -3,8 +3,10 @@ from pathlib import Path

 import pandas as pd

+GRACE_MINUTES = 5      # operations: up to 5 minutes over the promise is not "late"
+
 d = pd.read_csv("data/deliveries_q3.csv")
-d["late"] = d["actual_minutes"] > d["promised_minutes"]
+d["late"] = d["actual_minutes"] > d["promised_minutes"] + GRACE_MINUTES
 by_zone = d.groupby("zone")["late"].mean().round(3).sort_values(ascending=False)
 Path("results").mkdir(exist_ok=True)
 by_zone.to_csv("results/late_by_zone.csv")

الأسطر التي تبدأ بـ - حُذفت، والأسطر التي تبدأ بـ + أُضيفت؛ وM تعني معدَّل. شغّل التحليل، ثم أودِع مع متن يسجّل السبب:

python analysis.py
git commit -am "Count a delivery as late only after a 5-minute grace" -m "Operations agreed on 3 Oct that up to 5 minutes over the promised time is not reported as late."
git log --oneline

deliveries: 1800 | late rate: 0.067
zone
East      0.110
South     0.086
North     0.063
Centre    0.044
West      0.036
[main 41d91aa] Count a delivery as late only after a 5-minute grace
 1 file changed, 3 insertions(+), 1 deletion(-)
41d91aa Count a delivery as late only after a 5-minute grace
8199b91 Add late-rate analysis by zone
0f3dee9 Add Q3 delivery data, README and .gitignore

(متن الرسالة معناه: "اتفق قسم العمليات في 3 أكتوبر على أن تجاوز الموعد الموعود بما يصل إلى 5 دقائق لا يُبلَّغ عنه كتأخير".)

انخفض معدل التأخير من 16.9% (دون مهلة) إلى 6.7%: تغيير في التعريف، لا في الأداء. والسجل الآن يُظهر متى ولماذا. (الخيار -a يجهّز كل تغيير في الملفات التي يتتبعها Git بالفعل؛ أما الملفات الجديدة فما زالت تحتاج إلى git add.)

الجزء F — تراجع عن تغيير لم تودِعه: git restore

يحدث تعديل عرضي: سطر شارد ينتهي في README. للتدريب، أضف السطر TODO delete me في نهاية README.md واحفظ؛ ثم افحص وتراجع:

git status --short
git restore README.md
git status

 M README.md
On branch main
nothing to commit, working tree clean

git restore FILE يستبدل نسختك في شجرة العمل بآخر إصدار مودَع (وإذا كنت قد جهّزت الملف بالفعل بـ git add، فبالإصدار المجهَّز بدلًا من ذلك)، لذلك يضيع أي تغيير غير مجهَّز في ذلك الملف؛ فافحص git diff FILE أولًا. وللنظر إلى أي إيداع سابق، استخدم git show HASH أو git log --stat:

git log --stat --oneline -2

41d91aa Count a delivery as late only after a 5-minute grace
 analysis.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
8199b91 Add late-rate analysis by zone
 analysis.py | 12 ++++++++++++
 1 file changed, 12 insertions(+)

أما التراجع عن الإيداعات بأمان فموضوع L95.

5. مثال محلول

Cedar Lane (خيالية)، بيانات مصطنعة. يضع محلل العمليات تحليل توصيلات الربع الثالث تحت التحكم في الإصدارات قبل تغيير تعريف "متأخر".

الخطوة 1 — المستودع: git init في مجلد المشروع؛ وضبط الاسم والبريد؛ والفرع main.

الخطوة 2 — ما يُستبعد: results/ (يعيد السكربت بناءه)، وملفات التخزين المؤقت، ونقاط الحفظ، و.venv/ و.env تدخل .gitignore قبل الإيداع الأول.

الخطوة 3 — إيداعان هادفان: البيانات وREADME و.gitignore؛ ثم التحليل.

الخطوة 4 — تغيير القاعدة في إيداع مستقل: يُظهر git diff سطرين متغيرين بالضبط؛ وتسجّل رسالة الإيداع القرار وتاريخه.

الخطوة 5 — الإجابة لمسؤول العمليات: "تغيّر معدل التأخير لأن التعريف تغيّر في 3 أكتوبر (الإيداع 'Count a delivery as late only after a 5-minute grace'): 16.9% بالقاعدة القديمة، و6.7% بالجديدة. والتقارير السابقة لذلك الإيداع تستخدم القاعدة القديمة."

6. شرح بصري

 working tree  ──git add──▶  staging area  ──git commit──▶  history (.git)
 (your files)                (next commit)                  a1b2c3d Add data, README, .gitignore
      ▲                                                     d4e5f6a Add late-rate analysis
      └────────────── git restore FILE (discard edits) ◀─── 9f8e7d6 Count late only after 5-min grace
 git status: what changed?   git diff: which lines?   git log: which commits?
 .gitignore: results/  __pycache__/  .ipynb_checkpoints/  .venv/  .env   (never: secrets, environments, outputs)

وصف الرسم: تنتقل الملفات من شجرة العمل إلى منطقة التجهيز بـ git add، ومن منطقة التجهيز إلى السجل بـ git commit. والسجل قائمة من الإيداعات، لكل منها رمز ورسالة، مثل إضافة البيانات، وإضافة التحليل، وتغيير قاعدة التأخير. وgit restore يستبدل ملفًا معدَّلًا بآخر إصدار مودَع منه. وgit status يُظهر ما الذي تغيّر، وgit diff يُظهر أي الأسطر، وgit log يُظهر الإيداعات. وملف .gitignore يُبقي المخرجات، وملفات التخزين المؤقت، ونقاط حفظ الدفاتر، والبيئات، وملفات الأسرار خارج المستودع. (نصوص الرسم: working tree (your files) = شجرة العمل (ملفاتك)؛ staging area (next commit) = منطقة التجهيز (الإيداع التالي)؛ history = السجل؛ discard edits = تجاهل التعديلات؛ what changed? = ما الذي تغيّر؟؛ which lines? = أي الأسطر؟؛ which commits? = أي الإيداعات؟؛ never: secrets, environments, outputs = أبدًا: الأسرار، والبيئات، والمخرجات.)

7. تدريب موجَّه

في طرفية مفتوحة داخل practice_files:

1. اضبط اسمك وبريدك والفرع الافتراضي main (الجزء A).
2. انسخ u22_data/l94_delivery_project إلى cedar_delivery، وشغّل git init، وافحص git status.
3. شغّل python analysis.py، واكتب .gitignore، وتأكد من أن results/ متجاهَل.
4. نفّذ إيداعَي الجزء D وافحص git log --oneline.
5. نفّذ تغيير مهلة السماح، وافحص git diff، وشغّل التحليل، وأودِع مع متن للرسالة.
6. أضف سطرًا شاردًا إلى README.md، وشاهده في git status، واستعد الملف.
7. دوّن الرموز الثلاثة من git log --oneline الخاص بك.

8. تدريب مستقل

الجزء 1 — المجلد الفوضوي. انسخ u22_data/l94_messy_folder إلى messy_project وانظر داخله (ls -a، بما في ذلك الملفات المخفية). فيه بيئة افتراضية، ونقاط حفظ للدفاتر، وملفات تخزين مؤقت لـ Python، ومُخرَج، وملف تصدير من 9,000 صف فيه أرقام هواتف عملاء، وملف .env فيه كلمة مرور (وهمية)، وإصداران من سكربت التحليل.

1. لكل ملف ومجلد، قرّر: إيداع، أو تجاهل، أو حذف. وأعطِ سببًا في سطر واحد لكل منها.
2. اكتب .gitignore، وشغّل git init، وتأكد بـ git status --short من أن الملفات الصحيحة وحدها هي المعروضة.
3. أودِع في خطوتين ذواتي معنى على الأقل. واعرض git log --oneline.

الجزء 2 — أعد كتابة رسائل زميل. يسرد colleague_commit_messages.txt ست رسائل إيداع مع ما غيّره كل إيداع فعلًا. أعد كتابة كل رسالة (سطر الملخّص، ومتن حيث يلزم سبب)، وقل أي إيداع ما كان يجب أن يُنفَّذ أصلًا.

9. اختبار الفهم (Knowledge Check) — التحكم في الإصدارات

Q1. فيم يُستخدم Git أساسًا في مشروع تحليل؟

• A) عمل نسخ من مجلد المشروع تحسّبًا لتعطّل الجهاز
• B) الاحتفاظ بسجل للتغييرات مع من أجراها، ومتى، ولماذا
• C) تشغيل التحليل أسرع بتخزين نتائجه مؤقتًا
• D) مشاركة ملفات البيانات الكبيرة مع بقية الفريق

Q2. غيّرت analysis.py وتريد أن ترى بالضبط أي الأسطر تغيّرت قبل الإيداع. أي أمر تستخدم؟

• A) git diff
• B) git log --oneline
• C) git commit -a
• D) git init

Q3. أي ملف ينتمي إلى .gitignore في مشروع تحليل؟

• A) analysis.py
• B) README.md
• C) requirements.txt
• D) .env الذي فيه كلمة مرور قاعدة بيانات

Q4. ماذا تحتوي منطقة التجهيز؟

• A) كل إصدار سابق لكل ملف احتواه المشروع في أي وقت
• B) الملفات التي طُلب من Git ألّا يتتبعها أبدًا
• C) التغييرات التي اخترت تضمينها في الإيداع التالي
• D) نسخة من المستودع محفوظة على GitHub

Q5. أي رسالة إيداع هي الأفضل؟

• A) final changes
• B) Count a delivery as late only after a 5-minute grace
• C) update analysis.py
• D) fixed it

Q6. يعيد السكربت إنشاء results/late_by_zone.csv في كل تشغيل. لماذا نتجاهله؟

• A) لا يستطيع Git تخزين ملفات CSV التي ينتجها سكربت Python
• B) ملفات المخرجات بيانات خاصة دائمًا
• C) يُعاد بناؤه من الكود، فتصبح النسخة المتتبَّعة منه قديمة
• D) .gitignore يحذف الملف من جهازك بعد الإيداع التالي

Q7. عدّلت README.md ولم تجهّز التعديل ولم تودِعه. ماذا يفعل git restore README.md؟

• A) يستبدل README المعدَّل بآخر إصدار مودَع منه
• B) يستعيد README من نسخة المشروع المحفوظة على GitHub
• C) ينشئ إيداعًا جديدًا يلغي آخر إيداع لـ README
• D) يعيد README حُذف قبل ثلاثة إيداعات

Q8. لماذا تنفّذ عدة إيداعات صغيرة بدلًا من إيداع واحد كبير في النهاية؟

• A) Git يحدّ كل إيداع ببضعة ملفات
• B) كل تغيير يمكن فهمه ومراجعته والتراجع عنه وحده
• C) الإيداعات الصغيرة تشغل مساحة أقل في المستودع من إيداع واحد كبير
• D) GitHub لا يعرض إلا آخر إيداع في كل يوم في صفحة المستودع

10. الذكاء الاصطناعي في التطبيق (اختياري، وفي حدود)

الهدف: أن تستخدم مساعد ذكاء اصطناعي لشرح رسالة من Git، ثم تتحقق منها بنفسك.

1. شغّل git commit -m "test" في مجلد لا توجد فيه تغييرات مجهَّزة، وانسخ الرسالة التي يطبعها Git.
2. اسأل:

"Explain this Git message and what I should do next: [message]."

وبالعربية: "اشرح رسالة Git هذه وماذا يجب أن أفعل بعدها: [الرسالة]."

3. قبل أن تتبع النصيحة، شغّل git status وتحقق من أن الشرح يطابق ما يُظهره Git.

الحدود:

• استخدام الذكاء الاصطناعي اختياري.
• لا تلصق أبدًا كلمات مرور أو محتوى .env أو بيانات خاصة في الطلب.
• لا تشغّل أبدًا أمرًا يقترحه الذكاء الاصطناعي إذا لم تستطع أن تقول ماذا يفعل، وخاصة git reset --hard وgit clean -f وgit push --force، فهي قد تدمّر العمل.

11. التحقق من مخرجات الذكاء الاصطناعي

1. قبل وبعد: شغّل git status (وgit log --oneline) قبل كل أمر مقترح وبعده.
2. الأوامر المدمّرة: ابحث عن أي أمر فيه --hard أو --force أو clean في Pro Git قبل تشغيله.
3. طابق الرسالة: يجب أن يطابق شرح الذكاء الاصطناعي ما يقوله git status.
4. دوّن ما غيّرته في نصيحة الذكاء الاصطناعي.

12. منظور الأعمال

سجل الإيداعات أثر قابل للتدقيق لقرارات التحليل. عندما يتغير رقم في تقرير، يكون أول سؤال من الإدارة "لماذا؟". والمشروع الخاضع للتحكم في الإصدارات يجيب عنه في دقائق: الإيداع الذي غيّر القاعدة، والتاريخ، والشخص، والسبب. ويجعل المراجعات ممكنة أيضًا: فالزميل يستطيع قراءة إيداع صغير واحد بدلًا من مجلد كامل. ولأن الأسرار والبيانات الشخصية تبقى خارج المستودع، يمكن مشاركة السجل بأمان.

13. مهمة عمل — سياسة الإيداع

نشاط خيالي: Cedar Lane. اكتب سياسة الإيداع في خمسة أسطر (من 60 إلى 100 كلمة) للمشاريع المشتركة لفريق التحليلات: ماذا يحتوي الإيداع، وكيف تُكتب الرسائل، وما الذي لا يُودَع أبدًا، ومتى تحتاج الرسالة إلى متن.

14. تحدٍّ قصير — إيداع واحد كبير

نشاط خيالي: Cedar Lane. أنجز زميل أسبوعًا كاملًا من العمل في إيداع واحد. قارن إحصاءاته بالإيداعات الثلاثة في الجزأين D وE:

مستودعه موجود في u22_data/l94_one_commit.bundle (الحزمة bundle مستودع كامل مضغوط في ملف واحد؛ ويستطيع git clone فكّه).

cd ..
git clone -q u22_data/l94_one_commit.bundle one_commit
cd one_commit
git log --stat --oneline
cd ../cedar_delivery

1b73fe4 week 41 work
 .gitignore             |    8 +
 README.md              |    6 +
 analysis.py            |   14 +
 data/deliveries_q3.csv | 1801 ++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 1829 insertions(+)

1. قبل أن تفتح المخرجات، توقّع ما الذي سيُظهره الإيداع الوحيد لزميلك، مقارنةً بالإيداعات الثلاثة التي نفّذتها.
2. من سجل زميلك وحده، هل تستطيع أن تعرف متى تغيّرت قاعدة التأخير؟ لماذا أو لماذا لا؟
3. أي من إيداعاتك الثلاثة تستطيع التراجع عنه دون المساس بالآخرين؟
4. اكتب جملة واحدة يحتفظ بها فريقك كقاعدة عن حجم الإيداع.

سلّم عملك قبل أن تتلقى الملاحظات. لا يوجد حل منشور هنا.

15. المصادر

مطلوب (حوالي 30 دقيقة):

• Scott Chacon وBen Straub، Pro Git (الطبعة الثانية)، الفصول 2.1–2.4 (Getting a Git Repository، وRecording Changes، وViewing the Commit History، وUndoing Things). مجاني على الإنترنت؛ والمحتوى مرخّص بموجب CC BY-NC-SA 3.0. https://git-scm.com/book/en/v2 (فُتح في 27 أكتوبر 2026.)

موصى به:

• GitHub Docs: Ignoring files (ملف .gitignore في جذر المستودع، والقوالب، وكيف توقف تتبّع ملف أُودع بالفعل). https://docs.github.com/en/get-started/git-basics/ignoring-files (فُتح في 27 أكتوبر 2026.)

16. شخصية تتابعها / قدوة

Linus Torvalds.

• حقيقة مُتحقَّق منها: يذكر كتاب Pro Git أن مجتمع تطوير Linux، "and in particular Linus Torvalds, the creator of Linux" (أي: "وبخاصة Linus Torvalds، مبتكر Linux")، طوّر في 2005 أداته الخاصة للتحكم في الإصدارات، وهي Git (فصل "A Short History of Git"، فُتح في 27 أكتوبر 2026).
• لماذا توصي به D.World: بُني Git لمشروع كبير يغيّر فيه آلاف الأشخاص الملفات نفسها؛ والعادات التي يكافئها (التغييرات الصغيرة، والأوصاف الواضحة، والمراجعة) تناسب فرق التحليل أيضًا.
• ملاحظة صادقة: تابع تاريخ الأداة، لا أسلوب شخص؛ وتحقق من الأوامر مقابل التوثيق.
• جرّب هذا: اقرأ فصل التاريخ القصير واسرد الأهداف التي صُمّم Git من أجلها. أيها يهم فريق تحليلات من شخصين؟

17. المصطلحات

للمراجعة: إعادة التشغيل وتشغيل الكل (L21) · سير العمل القابل للتكرار (L29) · سجل التجارب (L88).

18. تأمّل

1. أي ملف في أحد مشاريعك السابقة ما كان يجب أن يُشارك أبدًا؟
2. أي من تغييراتك السابقة في التحليل كنت تتمنى أن تستطيع شرحه بإيداع؟
3. ماذا ستضع في متن رسالة الإيداع من الآن فصاعدًا؟

19. الخطوة التالية

التالي: L95 — الفروع، والدمج، والتراجع بأمان (Branches, Merging & Undoing Safely). جرّب فكرة على فرع دون كسر الإصدار الذي يعتمد عليه العمل، وتراجع عن خطأ دون أن تفقد العمل اللاحق.

20. أدلة التقييم

المراجع

1. Chacon, S. and Straub, B. Pro Git, 2nd edition (Apress, 2014; online edition at git-scm.com), chapters 1.2 (history), 2.1–2.4. https://git-scm.com/book/en/v2 (PROGIT). يدعم: تاريخ Git (اقتباس)، والأوامر، والتراجع عن التغييرات.
2. GitHub. Ignoring files. https://docs.github.com/en/get-started/git-basics/ignoring-files (GH-IGNORE). يدعم: موقع .gitignore، والقوالب، وإلغاء تتبّع الملفات.
3. Git project. Install. https://git-scm.com/install (الإصدار الحالي 2.56، وصدر Git for Windows في 22 أكتوبر 2026).
4. D.World Stage 5 Detailed Lesson Map v1.0 (صف L94). وثيقة داخلية.

L98 — Data Roles & Market Signals: Reading the Evidence Honestly

Learner file. Answers and model solutions are in a separate instructor-only file. Version: U23 Production v1 · Content date: 27 October 2026. Time estimates are planning estimates until learners have tested them. The code in this lesson was run with Python 3.13.16 and pandas 3.0.5 (recorded in D.World's internal Code Test Report); Python 3.13 is the accepted course version. Not run with Python 3.14 or inside JupyterLab.

Market figures quoted from O*NET, the US Bureau of Labor Statistics (BLS) and the World Economic Forum (WEF) were read on 27 October 2026; they change when those sources update. The practice dataset is synthetic: its markets (Northport, Eastvale) and companies are fictional, and its numbers describe no real labour market.

1. Lesson Identity

Time breakdown (planning estimate): concept and worked example 60 min · guided practice 30 min · independent practice 35 min · knowledge check 10 min · AI 5 min (optional) · workplace task and mini challenge 10 min.

What you need: Python with pandas; practice_files (L98_starter.ipynb; u23_data/postings_2026q3.csv, u23_data/posting_log_template.csv); a web browser for the sources and for your own posting log.

2. Learning Objective

By the end of this lesson, you will be able to:

• compare data roles by the tasks they do and the outputs they deliver, not by their titles;
• interpret market signals (skill shares in postings, wages, growth) together with their source, date, geography and limits;
• start a dated posting log for your own target role and market.

D.World approved objective (verbatim): Compare data roles by their tasks and outputs, and interpret market signals (skill shares in postings, wages, growth) with their source, date, geography and limits.

3. Why It Matters

Career advice about data jobs is full of confident numbers: "Python is required in two thirds of jobs", "data scientists earn $120,000", "demand will grow 35%". Each of these can be true for a specific source, period and place, and badly wrong when carried somewhere else. A US median wage says little about pay in Cairo or Lisbon; a share of postings is not a share of jobs; a job title tells you less than the list of tasks under it.

You have spent four stages learning to ask where a number comes from, what it measures and what it cannot show. This lesson applies the same discipline to the job market, so that the plan you build in L99 and the CV you write in L100 rest on evidence rather than on slogans.

Key principle: describe a role by its tasks and outputs; attach source, date, geography and definition to every market number; and check general signals against a dated log of real postings in your own market.

4. Concept

Open L98_starter.ipynb (or a new notebook) in practice_files, and run each block as you read.

Part A — Role families: tasks and outputs, not titles

Most entry-level data jobs fall into a few role families. They overlap, and companies use the names differently, so describe each by what it does and what it delivers:

O*NET, the US Department of Labor's occupational database, describes Data Scientists in exactly these terms. Its task list (opened 27 Oct 2026) starts with "Analyze, manipulate, or process large sets of data using statistical software", "Create graphs, charts, or other visualizations to convey the results of data analysis using specialized software", "Test, validate, and reformulate models to ensure accurate prediction of outcomes of interest" and "Recommend data-driven solutions to key stakeholders."

The practice dataset holds 360 job postings collected from July to September 2026 in three markets: two fictional cities (Northport, Eastvale) and remote roles. Load it:

import pandas as pd

p = pd.read_csv("u23_data/postings_2026q3.csv")
print(p.shape)
print(p[["posting_id", "collected_date", "market", "title", "level", "role_family"]].head(4).to_string(index=False))

(360, 13)
posting_id collected_date    market                         title  level    role_family
     P0001     2026-07-01 Northport Senior Applied Data Scientist senior Data Scientist
     P0002     2026-07-01  Eastvale                MLOps Engineer junior    ML Engineer
     P0003     2026-07-01  Eastvale                Data Scientist junior Data Scientist
     P0004     2026-07-01 Northport                  Data Analyst    mid   Data Analyst

Job boards repost the same vacancy, so the first step in any posting analysis is to remove copies. Here a repost has the same company, title, market and requirements:

key = ["company", "title", "market", "required_skills"]
print("reposted copies:", p.duplicated(key).sum())
u = p.drop_duplicates(key, keep="first").reset_index(drop=True)
print("unique postings:", len(u))
print(u["role_family"].value_counts().to_string())

reposted copies: 18
unique postings: 342
role_family
Data Analyst       114
Data Scientist      86
BI Analyst          57
Product Analyst     48
ML Engineer         37

Now compare the families by their tasks. str.get_dummies(sep=";") turns a list like write SQL reports;build dashboards into one 0/1 column per task, so a group mean is the share of postings that list the task:

FAM = ["Data Analyst", "BI Analyst", "Product Analyst", "Data Scientist", "ML Engineer"]
SHORT = {"Data Analyst": "DA", "BI Analyst": "BI", "Product Analyst": "PA", "Data Scientist": "DS", "ML Engineer": "MLE"}

tasks = u["tasks"].str.get_dummies(sep=";")
task_share = tasks.groupby(u["role_family"]).mean().T[FAM].rename(columns=SHORT)
print("% of postings listing each task")
print((100 * task_share).round().astype(int).to_string())

% of postings listing each task
role_family              DA  BI  PA  DS  MLE
build dashboards         66  88  44  14    0
build predictive models   4   0  19  87   73
clean data               69  40  38  62   22
define KPIs              39  49  85  28    0
deploy models             1   2   0  33   97
present to stakeholders  52  40  73  55    8
run A/B tests             8   2  79  34   11
write SQL reports        79  79  62  36   16

Each family has a recognisable core: reports and dashboards for DA and BI, tests and KPIs for PA, models for DS, deployment for MLE. Now look at one title:

titled_ds = u[u["title"] == "Data Scientist"]
print(titled_ds["role_family"].value_counts().to_string())
for t in titled_ds.loc[titled_ds["role_family"] == "Data Analyst", "tasks"].head(3):
    print("-", t)

role_family
Data Scientist    39
Data Analyst       9
- write SQL reports;clean data;present to stakeholders;define KPIs
- write SQL reports
- write SQL reports;clean data;present to stakeholders;define KPIs

9 of the 48 postings titled "Data Scientist" describe analyst work: SQL reports, data cleaning and KPIs, no models. A title does not define the work; the task list does. When you search for jobs, search by tasks and tools as well as by titles.

Part B — Skill shares: what "Python 66%" means

O*NET's "Hot Technologies" page for Data Scientists (opened 27 Oct 2026) lists, for example, Python 66%, SQL 51%, R 34%, Tableau 22% and Git 5%. The page states its source and definition: "Lightcast job postings data for the US nationwide between January 1, 2025 and December 31, 2025", and the percentage "represents the ratio of unique postings which mention the skill to all unique postings".

So "Python 66%" means: of unique 2025 US postings for this occupation, 66% mention Python. It does not mean that 66% of data scientists use Python, that 34% of jobs do not need it, or that the same holds in your country this year. Postings mention what employers chose to write, and a skill too obvious to mention can be under-counted.

Compute the same kind of share in the practice data, using the required skills of unique postings:

skills = u["required_skills"].str.get_dummies(sep=";")
skill_share = skills.groupby(u["role_family"]).mean().T[FAM].rename(columns=SHORT)
print("% of unique postings that require each skill")
print((100 * skill_share).round().astype(int).sort_values("DS", ascending=False).to_string())

% of unique postings that require each skill
role_family       DA  BI  PA  DS  MLE
python            40  11  52  87  100
machine_learning   1   4  12  74   97
statistics        38  12  69  74   27
sql               86  91  94  72   38
communication     50  39  58  58   14
git                4   9   6  34   70
r                  7   2  12  31    5
a_b_testing        4   2  62  24    5
cloud              9   9   0  24   62
spark              0   0   0  10   27
excel             76  54  33   6    0
power_bi          38  72  10   6    0
tableau           36  54  23   2    0

Read it the same way: among the 86 fictional Data Scientist postings, 87% require Python and 72% require SQL. Postings also list nice-to-have skills. Counting a skill when it appears in either list gives a different number for the same market:

nice = u["nice_to_have"].fillna("").str.get_dummies(sep=";").reindex(columns=skills.columns, fill_value=0)
mentioned = (skills + nice).clip(upper=1)
compare = pd.DataFrame({
    "required %": 100 * skills[u["role_family"] == "Data Scientist"].mean(),
    "mentioned %": 100 * mentioned[u["role_family"] == "Data Scientist"].mean(),
}).round().astype(int)
print(compare.loc[["python", "sql", "git", "cloud", "spark"]].to_string())

        required %  mentioned %
python          87           87
sql             72           72
git             34           49
cloud           24           44
spark           10           31

Git is required in 34% of these Data Scientist postings but mentioned in 49%. O*NET's figure counts mentions. Whenever you compare two skill shares, check that they use the same definition, the same kind of posting, the same period and the same place.

Part C — Salaries: ranges, missing values, medians

Salaries in postings are ranges, often missing, and the postings that show a salary may differ from those that do not. Start with how many show one:

u["has_salary"] = u["salary_min_eur"].notna()
print("% of postings that show a salary range")
print((100 * u.groupby("role_family")["has_salary"].mean()).round().astype(int)[FAM].to_string())

% of postings that show a salary range
role_family
Data Analyst       37
BI Analyst         46
Product Analyst    52
Data Scientist     36
ML Engineer        49

Between 36% and 52% of the postings in each family show pay (142 of 342 overall), so any salary summary describes the postings that publish one. Summarise each range by its midpoint, then compare the median and the mean, and give the middle half with the 25th and 75th percentiles:

s = u[u["has_salary"]].copy()
s["mid_eur"] = (s["salary_min_eur"] + s["salary_max_eur"]) / 2
summary = s.groupby("role_family")["mid_eur"].agg(
    n="count", median="median", mean="mean",
    p25=lambda x: x.quantile(0.25), p75=lambda x: x.quantile(0.75)).loc[FAM]
money = ["median", "mean", "p25", "p75"]
summary[money] = summary[money].round(-2)
print(summary.astype(int).to_string())

                  n  median   mean    p25    p75
role_family                                     
Data Analyst     42   35000  36500  28200  41200
BI Analyst       26   37800  42800  33400  51600
Product Analyst  25   44800  45100  38000  51000
Data Scientist   31   44500  50600  38100  60100
ML Engineer      18   58600  59000  47100  64600

For Data Scientists the mean is well above the median: a few senior postings with high ranges pull the mean up. The median wage describes the middle posting and is the usual summary for pay. With 18 to 42 postings per family, these numbers are rough.

Market matters even more. The same table by market, for Data Analysts only:

da = s[s["role_family"] == "Data Analyst"]
by_market = da.groupby("market")["mid_eur"].agg(n="count", median="median")
by_market["median"] = by_market["median"].round(-2)
print(by_market.astype(int).to_string())

            n  median
market               
Eastvale   18   30500
Northport  17   38000
Remote      7   38500

A median from 7 to 18 postings per market is a signal to check, not a fact. And a salary has to be read against the local cost of living, taxes and what the range includes (gross or net, bonus, benefits). The same caution applies to any published figure: ONET and BLS give the 2025 US median for Data Scientists as $120,230 a year (BLS, opened 27 Oct 2026). That is a US national figure in US dollars for employed data scientists of all levels*: it is not what a junior analyst will be offered in Eastvale, Lisbon or Cairo.

Part D — Growth and outlook: the same data, presented differently

BLS projects employment of data scientists to grow 35% from 2025 to 2035, "much faster than average" (Occupational Outlook Handbook, page modified 27 Aug 2026, opened 27 Oct 2026). ONET shows the same projection as a category: "Much faster than average (7% or higher)". Both rest on BLS projections for the United States*.

The WEF Future of Jobs Report 2025 (published 7 Jan 2025) takes a different view: a survey of "over 1,000 leading global employers" across 55 economies. It reports that technology roles, among them Big Data Specialists and AI and Machine Learning Specialists, are "the fastest-growing jobs in percentage terms", and that "AI and big data top the list of fastest-growing skills". That is what employers expect, not a count of hires.

Part E — Your own evidence: the posting log

General sources are a starting point. The evidence that fits your situation is a posting log: a dated list of real postings for your target role and market, kept in a spreadsheet or CSV. Each row records the date you saw it, the link, the company, the title, the level, the location, and the required and nice-to-have skills, written as short tags (sql;python;power_bi). Open u23_data/posting_log_template.csv: it has the columns and two clearly fictional example rows to delete.

Rules that keep a log honest:

1. Real and dated. Only postings you have opened, with the URL and the date you collected them.
2. One row per vacancy. If the same job appears on two boards, keep one.
3. Tags, not sentences. Use the same short tag for the same skill every time, so you can count them.
4. Required separate from nice-to-have, as written in the posting.
5. No personal data. Do not copy recruiters' names, emails or phone numbers.

With at least 10 rows, the same code as Part B gives the skill shares of your log, which you can set beside the national figures, each with its own source and date.

5. Worked Example

Fictional markets, synthetic postings. A learner, Amira, is choosing between Data Analyst and Data Scientist roles in Northport.

Step 1 — Clean the evidence: 360 postings, 18 reposted copies removed: 342 unique.

Step 2 — Tasks: Data Analyst postings centre on SQL reports (79%), cleaning and dashboards; Data Scientist postings on models (87%). 9 of the 48 postings titled "Data Scientist" are analyst work, so she searches by tasks too.

Step 3 — Skills: SQL is required in 86% of Data Analyst and 72% of Data Scientist postings; Python in 40% and 87%; machine learning in 1% and 74%.

Step 4 — Pay: 142 of the 342 postings show pay. Among those, the median midpoint is about €35,000 for Data Analysts and €44,500 for Data Scientists; the Data Scientist mean (€50,600) is pulled up by senior postings.

Step 5 — Market note: "In 342 unique fictional postings (Jul–Sep 2026), SQL is the most common requirement for analyst roles and Python for data-science roles. Salary figures come from the 42% of postings that publish a range, so they are rough. National US figures (O*NET/BLS) are context only. Next: my own log of 10 real Northport postings."

6. Visual Explanation

 A MARKET NUMBER IS ONLY AS GOOD AS ITS LABEL
 ┌─────────────────────────────────────────────────────────────────────────────┐
 │ "Python 66%"                                                                │
 │   WHAT?   share of unique postings that MENTION Python (not jobs, not people)│
 │   WHO?    occupation: Data Scientists (O*NET 15-2051.00)                    │
 │   WHERE?  United States, nationwide                                         │
 │   WHEN?   postings from 2025 (Lightcast), page read 27 Oct 2026             │
 │   LIMITS? mentions ≠ requirements; titles vary; other countries differ      │
 └─────────────────────────────────────────────────────────────────────────────┘
 general signal (O*NET / BLS / WEF)  ──compare──▶  YOUR posting log (real, dated, local)

Alt text: A box shows how to label the market figure "Python 66%": what it measures (share of unique postings mentioning Python, not jobs or people), who (Data Scientists, ONET code 15-2051.00), where (United States), when (2025 postings, page read 27 October 2026) and its limits (mentions are not requirements, titles vary, other countries differ). An arrow shows general signals from ONET, BLS and WEF being compared with the learner's own real, dated, local posting log.

7. Guided Practice

In L98_starter.ipynb:

1. Load postings_2026q3.csv, remove the reposts and confirm 342 unique postings.
2. Build the task table of Part A. Which two tasks best separate BI Analysts from Data Analysts?
3. List the titles used for Product Analyst postings, and say which one you would not have guessed.
4. Build the required-skill table of Part B. Name the three most common required skills for the family you are targeting.
5. For your target family, compute the salary midpoint median, mean, 25th and 75th percentiles by market, with the number of postings behind each figure.
6. Write three sentences comparing your table with O*NET's Hot Technologies page for the closest occupation (Data Scientists 15-2051.00, or Business Intelligence Analysts 15-2051.01). Name a source, a date and a place in each sentence.

8. Independent Practice

Part 1 — Your posting log (real data). Choose a target role and a market (a city or country, or "remote" with time zones). Collect 10 real postings from at least two job boards or company career pages, all opened within the last 30 days, and record them in a copy of u23_data/posting_log_template.csv (delete the two example rows). Follow the five rules of Part E.

Part 2 — Your skill shares. Load your log and compute the share of postings that require each skill, and the share that mention it in either list. Show the five most common skills. If any postings show pay, report the number of postings with pay and their median midpoint, in the currency of the postings.

Part 3 — Market note (about 150 words). Write a note for yourself with: the target role and market; the five most common required skills in your log; one comparison with O*NET, BLS or WEF, each figure with source, date and place; what your log cannot show (it is small, collected by you, and from one period); and one decision you take from it.

9. Knowledge Check — Roles and Market Signals

Q1. Two postings are both titled "Data Scientist". One lists building and evaluating predictive models; the other lists weekly SQL reports and dashboards. What is the best description of the second posting?

• A) A data-science role, because the employer chose that title for the posting
• B) Analyst work under a data-science title; judge the role by its tasks
• C) A senior role, because "Data Scientist" titles are usually senior ones
• D) A mistake by the job board that should be removed from any analysis

Q2. O*NET reports "Python 66%" for Data Scientists. What does the figure mean?

• A) 66% of all data scientists in the world use Python in their daily work
• B) Python is required in 66% of jobs and optional in all of the others
• C) 66% of unique 2025 US postings for the occupation mention Python
• D) Python makes up 66% of all the skills that data-science postings list

Q3. Why remove reposted copies before computing skill shares?

• A) pandas cannot group a table that contains rows that are fully duplicated
• B) Reposts are always older vacancies that have been filled in the meantime
• C) Job boards charge employers for every repost, so the copies are paid ads
• D) Each vacancy should count once; copies over-weight some employers

Q4. Among postings that show a salary, the mean midpoint is €50,600 and the median is €44,500. What is the most likely reason?

• A) A few high ranges pull the mean up; the median is the middle posting
• B) The median was computed in a different currency from the mean
• C) The mean ignores missing salaries, while the median counts them as zero
• D) Medians are always lower than means in every salary dataset

Q5. Only 42% of postings show a salary range. What should a salary summary say?

• A) Nothing: the missing salaries can be filled in with the overall median
• B) It describes only the postings that publish a range, which may differ
• C) It is accurate for the market as long as more than 40% show a salary
• D) It should use the minimum of each range, because offers start there

Q6. BLS gives a 2025 US median wage of $120,230 for data scientists. A learner in another country targets a junior analyst role. How should she use this figure?

• A) As her salary target, converted into local currency at today's exchange rate
• B) As proof that analyst roles in her country pay more than they used to
• C) As US context for all levels; local pay needs local, level-specific evidence
• D) As irrelevant, because US government statistics are not reliable sources

Q7. A posting lists Git under "nice to have". In the practice data, Git is required in 34% of Data Scientist postings and mentioned in 49%. What explains the difference?

• A) The two figures come from two different datasets collected by different people
• B) Some postings were counted twice in the mentioned figure but not in the other
• C) Git was removed from some postings after they were collected by the analyst
• D) "Mentioned" also counts postings that list Git only as nice to have

Q8. What makes a posting log stronger evidence for your own decisions than a national skill table?

• A) It is real, dated and from your target role and market
• B) It is always larger than any national dataset of job postings
• C) It is collected automatically, so no human choices affect it
• D) It contains salaries for every posting, unlike national data

10. AI in Practice (optional, bounded)

Goal: use AI to describe a role, then test every claim.

1. Ask: "Describe the main tasks, outputs and tools of a [target role] in [market]. Give sources for each claim."
2. Copy the answer into a table with one claim per row.
3. For each claim, mark supported (by ONET, BLS or one of your logged postings, with link and date), contradicted, or unsupported*. Delete numbers without a checkable source.

Boundaries: AI is optional. Never paste personal data. AI answers about labour markets are often out of date, invented, or about the US by default; your log and the dated sources decide.

11. AI Verification

1. Source: every number in the AI's answer has a source you opened, with its date.
2. Place and period: the source matches your market and is recent; US data is labelled as US.
3. Definition: "share of postings", "share of jobs" and "share of workers" are not mixed up.
4. Recount: any share you keep from your own log is recomputed with your code.

12. Business Lens

Employers hire for outcomes. A posting is a list of problems the employer wants solved: reports that arrive on Monday, dashboards that managers trust, tests that settle product debates, models that cut late deliveries. Reading postings as outcome lists makes applications sharper: instead of "I know Power BI", you can write "built the dashboard a shop manager uses to reorder stock". The same habit protects you from hype: the tool with the most mentions is not always the one that decides who gets hired.

13. Workplace Task — The Market Brief

Fictional business: Cedar Lane. Cedar Lane's operations lead wants to hire its first data analyst in Northport and asks you what to put in the posting and what pay range to expect. Using the practice dataset only, write a 120-word brief: the five skills most often required for Data Analysts, the median salary midpoint in Northport with the number of postings behind it, and two limits of this evidence.

14. Mini Challenge — Which Denominator?

Fictional markets, synthetic postings. A blog post claims: "Python is only 17% of what data-science employers ask for." Compute two numbers for the Data Scientist postings:

ds_skills = skills[u["role_family"] == "Data Scientist"]
print("postings:", len(ds_skills), "| skill mentions:", int(ds_skills.sum().sum()))
print("Python, share of postings:", round(100 * ds_skills["python"].mean()), "%")
print("Python, share of all skill mentions:", round(100 * ds_skills["python"].sum() / ds_skills.sum().sum()), "%")

postings: 86 | skill mentions: 434
Python, share of postings: 87 %
Python, share of all skill mentions: 17 %

1. Before you open the output, predict whether both numbers will be close to the blog's 17%.
2. What is the denominator of each number?
3. Which number answers the question "how many employers ask for Python?"
4. Rewrite the blog's sentence so that it is correct.

Submit before feedback. No solution is provided here.

15. Resources

Required (about 30 min):

• O*NET OnLine: Data Scientists, 15-2051.00 (tasks, technology skills, wages and outlook). https://www.onetonline.org/link/summary/15-2051.00 (Opened 27 Oct 2026.)
• O*NET OnLine: Hot Technologies, Data Scientists (shares of 2025 US postings, Lightcast). https://www.onetonline.org/link/hot_tech/15-2051.00 (Opened 27 Oct 2026.)

Recommended:

• U.S. Bureau of Labor Statistics: Occupational Outlook Handbook, Data Scientists. https://www.bls.gov/ooh/math/data-scientists.htm (Opened 27 Oct 2026.)
• World Economic Forum: The Future of Jobs Report 2025. https://www.weforum.org/publications/the-future-of-jobs-report-2025/ (Opened 27 Oct 2026.)
• O*NET OnLine: Hot Technologies, Business Intelligence Analysts, 15-2051.01. https://www.onetonline.org/link/hot_tech/15-2051.01 (Opened 27 Oct 2026.)

16. Person to Follow / Role Model

Emily Robinson and Jacqueline Nolis.

• Verified fact: they are the authors of Build a Career in Data Science (Manning, March 2020), which the publisher describes as "your guide to landing your first data science job and developing into a valued senior employee" (manning.com, opened 27 Oct 2026).
• Why D.World recommends them: the book treats a data career as a series of decisions backed by evidence: which role, which company, which portfolio, which offer.
• Honest note: the book was written in 2020 and from mostly US experience; tools, salaries and hiring processes have changed since, so check its market statements against current sources.
• Try this: read the publisher's description and table of contents, and note which chapter matches each lesson of this unit.

17. Glossary

Review: median and percentiles (L52) · grouped aggregation (L27).

18. Reflection

1. Which of your beliefs about data jobs did this lesson's evidence confirm, and which did it weaken?
2. Which role family's tasks suit you best, whatever its title?
3. What would you need to collect to trust a salary figure for your market?

19. Next Step

Next: L99 — Job Descriptions, Skill Gaps & Evidence Mapping. From the market to single postings: you decompose job descriptions into requirements and map each one to your own evidence.

20. Assessment Evidence

References

1. ONET OnLine. Summary Report for 15-2051.00 Data Scientists*. https://www.onetonline.org/link/summary/15-2051.00 (ONET-SUM). Supports: tasks (quoted), median wage, projected growth category. Site updated 6 Oct 2026.
2. ONET OnLine. Hot Technologies: 15-2051.00 Data Scientists*. https://www.onetonline.org/link/hot_tech/15-2051.00 (ONET-HOT). Supports: Python 66%, SQL 51%, R 34%, Tableau 22%, Git 5%; source and definition (quoted).
3. U.S. Bureau of Labor Statistics. Occupational Outlook Handbook: Data Scientists. https://www.bls.gov/ooh/math/data-scientists.htm (BLS-OOH). Supports: 2025 median pay $120,230; 2025–35 outlook 35%. Page modified 27 Aug 2026.
4. World Economic Forum. The Future of Jobs Report 2025 (7 Jan 2025). https://www.weforum.org/publications/the-future-of-jobs-report-2025/ (WEF). Supports: survey scope; fastest-growing jobs and skills (quoted).
5. ONET OnLine. Hot Technologies: 15-2051.01 Business Intelligence Analysts*. https://www.onetonline.org/link/hot_tech/15-2051.01 (ONET-HOT-BI). Supports: comparison occupation for BI roles.
6. Manning Publications. Build a Career in Data Science (Robinson, E. and Nolis, J., 2020). https://manning.com/books/build-a-career-in-data-science (MANNING-BCDS). Supports: role model (quoted description).
7. D.World Stage 5 Detailed Lesson Map v1.0 (L98 row); Stage 5 decision D06 (method-first market evidence plus a posting log). Internal.

L98 — أدوار البيانات وإشارات السوق: قراءة الأدلة بأمانة

ملف المتعلّم. الإجابات والحلول النموذجية في ملف منفصل خاص بالمدرّس فقط. الإصدار: U23 Production v1 · تاريخ المحتوى: 27 أكتوبر 2026. تقديرات الوقت تقديرات للتخطيط إلى أن يختبرها المتعلّمون. الكود في هذا الدرس شُغّل باستخدام Python 3.13.16 وpandas 3.0.5 (مسجّل في تقرير اختبار الكود الداخلي في D.World)؛ وPython 3.13 هو الإصدار المعتمد في المقرر. ولم يُشغَّل باستخدام Python 3.14 ولا داخل JupyterLab.

أرقام السوق المنقولة عن O*NET، ومكتب إحصاءات العمل الأمريكي (BLS)، والمنتدى الاقتصادي العالمي (WEF) قُرئت في 27 أكتوبر 2026؛ وهي تتغير عندما تُحدِّث هذه المصادر بياناتها. وبيانات التدريب مصطنعة: أسواقها (Northport وEastvale) وشركاتها خيالية، وأرقامها لا تصف أي سوق عمل حقيقي.

1. بطاقة الدرس

تفصيل الوقت (تقدير للتخطيط):

• المفهوم والمثال المحلول: 60 دقيقة.
• التدريب الموجَّه: 30 دقيقة.
• التدريب المستقل: 35 دقيقة.
• اختبار الفهم: 10 دقائق.
• الذكاء الاصطناعي: 5 دقائق (اختياري).
• مهمة العمل والتحدي القصير: 10 دقائق.

ما تحتاج إليه: Python مع pandas؛ ومجلد practice_files (L98_starter.ipynb؛ وu23_data/postings_2026q3.csv وu23_data/posting_log_template.csv)؛ ومتصفح ويب للمصادر ولسجل الإعلانات الخاص بك.

2. هدف التعلّم

في نهاية هذا الدرس، ستكون قادرًا على أن:

• تقارن بين أدوار البيانات بحسب المهام التي تؤديها والمخرجات التي تسلّمها، لا بحسب مسمياتها الوظيفية؛
• تفسّر إشارات السوق (market signals) (نِسب المهارات في الإعلانات، والأجور، والنمو) مع مصدرها، وتاريخها، ونطاقها الجغرافي، وحدودها؛
• تبدأ سجل إعلانات مؤرَّخًا لدورك المستهدف وسوقك.

الهدف المعتمد من D.World (بنصّه): Compare data roles by their tasks and outputs, and interpret market signals (skill shares in postings, wages, growth) with their source, date, geography and limits.

(وبالعربية: قارن بين أدوار البيانات بحسب مهامها ومخرجاتها، وفسّر إشارات السوق (نِسب المهارات في الإعلانات، والأجور، والنمو) مع مصدرها، وتاريخها، ونطاقها الجغرافي، وحدودها.)

3. لماذا يهمّك هذا؟

النصائح المهنية عن وظائف البيانات مليئة بأرقام واثقة: "Python is required in two thirds of jobs" (أي: "Python مطلوبة في ثلثي الوظائف")، و"data scientists earn $120,000" (أي: "علماء البيانات يكسبون 120,000 دولار")، و"demand will grow 35%" (أي: "سينمو الطلب 35%"). كل واحد من هذه الأرقام قد يكون صحيحًا لمصدر محدد، وفترة محددة، ومكان محدد، وخاطئًا تمامًا إذا نُقل إلى غيرها. فوسيط الأجر في الولايات المتحدة لا يقول الكثير عن الأجور في القاهرة أو لشبونة؛ ونسبة من الإعلانات ليست نسبة من الوظائف؛ والمسمى الوظيفي يخبرك أقل مما تخبرك به قائمة المهام تحته.

قضيت أربع مراحل تتعلم أن تسأل: من أين جاء الرقم، وماذا يقيس، وما الذي لا يستطيع أن يُظهره. وهذا الدرس يطبّق الانضباط نفسه على سوق العمل، حتى تقوم الخطة التي تبنيها في L99 والسيرة الذاتية التي تكتبها في L100 على أدلة لا على شعارات.

المبدأ الأساسي: صِف الدور بمهامه ومخرجاته؛ وأرفق بكل رقم عن السوق مصدره، وتاريخه، ونطاقه الجغرافي، وتعريفه؛ وتحقق من الإشارات العامة مقابل سجل مؤرَّخ لإعلانات حقيقية في سوقك أنت.

4. المفهوم

افتح L98_starter.ipynb (أو دفترًا جديدًا) في practice_files، وشغّل كل كتلة وأنت تقرأ.

الجزء A — عائلات الأدوار: المهام والمخرجات، لا المسميات

معظم وظائف البيانات للمبتدئين تقع في عدد قليل من عائلات الأدوار (role families). وهي متداخلة، والشركات تستخدم أسماءها بطرق مختلفة، لذلك صِف كل عائلة بما تفعله وما تسلّمه:

يصف O*NET، وهو قاعدة بيانات المهن التابعة لوزارة العمل الأمريكية، علماء البيانات بهذه المصطلحات نفسها. فقائمة مهامه (فُتحت في 27 أكتوبر 2026) تبدأ بـ "Analyze, manipulate, or process large sets of data using statistical software" (أي: "تحليل مجموعات كبيرة من البيانات أو معالجتها باستخدام برامج إحصائية")، و"Create graphs, charts, or other visualizations to convey the results of data analysis using specialized software" (أي: "إنشاء رسوم ومخططات وتصويرات أخرى لنقل نتائج تحليل البيانات باستخدام برامج متخصصة")، و"Test, validate, and reformulate models to ensure accurate prediction of outcomes of interest" (أي: "اختبار النماذج والتحقق منها وإعادة صياغتها لضمان دقة التنبؤ بالنتائج المطلوبة")، و"Recommend data-driven solutions to key stakeholders." (أي: "التوصية بحلول مبنية على البيانات لأصحاب المصلحة الرئيسيين").

تحتوي بيانات التدريب على 360 إعلان وظيفة (job posting) جُمعت من يوليو إلى سبتمبر 2026 في ثلاثة أسواق: مدينتين خياليتين (Northport وEastvale) والوظائف عن بُعد (Remote). حمّلها:

import pandas as pd

p = pd.read_csv("u23_data/postings_2026q3.csv")
print(p.shape)
print(p[["posting_id", "collected_date", "market", "title", "level", "role_family"]].head(4).to_string(index=False))

(360, 13)
posting_id collected_date    market                         title  level    role_family
     P0001     2026-07-01 Northport Senior Applied Data Scientist senior Data Scientist
     P0002     2026-07-01  Eastvale                MLOps Engineer junior    ML Engineer
     P0003     2026-07-01  Eastvale                Data Scientist junior Data Scientist
     P0004     2026-07-01 Northport                  Data Analyst    mid   Data Analyst

مواقع التوظيف تعيد نشر الوظيفة الشاغرة نفسها، لذلك فالخطوة الأولى في أي تحليل للإعلانات هي حذف النسخ المكررة. هنا، الإعلان المُعاد نشره له الشركة نفسها، والمسمى نفسه، والسوق نفسه، والمتطلبات نفسها:

key = ["company", "title", "market", "required_skills"]
print("reposted copies:", p.duplicated(key).sum())
u = p.drop_duplicates(key, keep="first").reset_index(drop=True)
print("unique postings:", len(u))
print(u["role_family"].value_counts().to_string())

reposted copies: 18
unique postings: 342
role_family
Data Analyst       114
Data Scientist      86
BI Analyst          57
Product Analyst     48
ML Engineer         37

(المخرجات: "reposted copies" = النسخ المُعاد نشرها؛ "unique postings" = الإعلانات الفريدة.)

قارن الآن بين العائلات بحسب المهام. الدالة str.get_dummies(sep=";") تحوّل قائمة مثل write SQL reports;build dashboards إلى عمود 0/1 لكل مهمة، فيصبح متوسط المجموعة هو نسبة الإعلانات التي تذكر المهمة:

FAM = ["Data Analyst", "BI Analyst", "Product Analyst", "Data Scientist", "ML Engineer"]
SHORT = {"Data Analyst": "DA", "BI Analyst": "BI", "Product Analyst": "PA", "Data Scientist": "DS", "ML Engineer": "MLE"}

tasks = u["tasks"].str.get_dummies(sep=";")
task_share = tasks.groupby(u["role_family"]).mean().T[FAM].rename(columns=SHORT)
print("% of postings listing each task")
print((100 * task_share).round().astype(int).to_string())

% of postings listing each task
role_family              DA  BI  PA  DS  MLE
build dashboards         66  88  44  14    0
build predictive models   4   0  19  87   73
clean data               69  40  38  62   22
define KPIs              39  49  85  28    0
deploy models             1   2   0  33   97
present to stakeholders  52  40  73  55    8
run A/B tests             8   2  79  34   11
write SQL reports        79  79  62  36   16

(ترجمة الجدول: "% of postings listing each task" = نسبة الإعلانات التي تذكر كل مهمة؛ build dashboards = بناء لوحات المعلومات؛ build predictive models = بناء نماذج تنبؤية؛ clean data = تنظيف البيانات؛ define KPIs = تعريف مؤشرات الأداء؛ deploy models = نشر النماذج؛ present to stakeholders = العرض على أصحاب المصلحة؛ run A/B tests = إجراء اختبارات A/B؛ write SQL reports = كتابة تقارير SQL. والاختصارات: DA محلل بيانات، BI محلل ذكاء أعمال، PA محلل منتج، DS عالم بيانات، MLE مهندس تعلّم الآلة.)

لكل عائلة جوهر يمكن تمييزه: التقارير ولوحات المعلومات لـ DA وBI، والاختبارات ومؤشرات الأداء لـ PA، والنماذج لـ DS، والنشر لـ MLE. انظر الآن إلى مسمى واحد:

titled_ds = u[u["title"] == "Data Scientist"]
print(titled_ds["role_family"].value_counts().to_string())
for t in titled_ds.loc[titled_ds["role_family"] == "Data Analyst", "tasks"].head(3):
    print("-", t)

role_family
Data Scientist    39
Data Analyst       9
- write SQL reports;clean data;present to stakeholders;define KPIs
- write SQL reports
- write SQL reports;clean data;present to stakeholders;define KPIs

9 من أصل 48 إعلانًا بمسمى "Data Scientist" تصف عمل محلل: تقارير SQL، وتنظيف البيانات، ومؤشرات الأداء، بلا نماذج. المسمى لا يحدد العمل؛ قائمة المهام هي التي تحدده. وعندما تبحث عن وظائف، ابحث بالمهام والأدوات إلى جانب المسميات.

الجزء B — نِسب المهارات: ماذا يعني "Python 66%"؟

صفحة "Hot Technologies" (التقنيات الرائجة) في O*NET لعلماء البيانات (فُتحت في 27 أكتوبر 2026) تسرد مثلًا: Python 66%، وSQL 51%، وR 34%، وTableau 22%، وGit 5%. وتذكر الصفحة مصدرها وتعريفها: "Lightcast job postings data for the US nationwide between January 1, 2025 and December 31, 2025" (أي: "بيانات إعلانات الوظائف من Lightcast على مستوى الولايات المتحدة كلها بين 1 يناير 2025 و31 ديسمبر 2025")، وأن النسبة "represents the ratio of unique postings which mention the skill to all unique postings" (أي: "تمثّل نسبة الإعلانات الفريدة التي تذكر المهارة إلى كل الإعلانات الفريدة").

إذن "Python 66%" تعني: من بين الإعلانات الفريدة في الولايات المتحدة سنة 2025 لهذه المهنة، 66% تذكر Python. وهي لا تعني أن 66% من علماء البيانات يستخدمون Python، ولا أن 34% من الوظائف لا تحتاج إليها، ولا أن الأمر نفسه ينطبق في بلدك هذا العام. فالإعلانات تذكر ما اختار أصحاب العمل كتابته، والمهارة البديهية جدًا لدرجة أنها لا تُذكر قد تُحسب أقل من حقيقتها.

احسب النوع نفسه من النِّسب في بيانات التدريب، باستخدام المهارات المطلوبة (required) في الإعلانات الفريدة:

skills = u["required_skills"].str.get_dummies(sep=";")
skill_share = skills.groupby(u["role_family"]).mean().T[FAM].rename(columns=SHORT)
print("% of unique postings that require each skill")
print((100 * skill_share).round().astype(int).sort_values("DS", ascending=False).to_string())

% of unique postings that require each skill
role_family       DA  BI  PA  DS  MLE
python            40  11  52  87  100
machine_learning   1   4  12  74   97
statistics        38  12  69  74   27
sql               86  91  94  72   38
communication     50  39  58  58   14
git                4   9   6  34   70
r                  7   2  12  31    5
a_b_testing        4   2  62  24    5
cloud              9   9   0  24   62
spark              0   0   0  10   27
excel             76  54  33   6    0
power_bi          38  72  10   6    0
tableau           36  54  23   2    0

(عنوان الجدول: "% of unique postings that require each skill" = نسبة الإعلانات الفريدة التي تطلب كل مهارة.)

اقرأه بالطريقة نفسها: من بين إعلانات Data Scientist الخيالية البالغة 86 إعلانًا، 87% تطلب Python و72% تطلب SQL. وتسرد الإعلانات أيضًا مهارات مرغوبة (nice-to-have). وإذا حسبت المهارة عندما تظهر في أيٍّ من القائمتين، تحصل على رقم مختلف للسوق نفسه:

nice = u["nice_to_have"].fillna("").str.get_dummies(sep=";").reindex(columns=skills.columns, fill_value=0)
mentioned = (skills + nice).clip(upper=1)
compare = pd.DataFrame({
    "required %": 100 * skills[u["role_family"] == "Data Scientist"].mean(),
    "mentioned %": 100 * mentioned[u["role_family"] == "Data Scientist"].mean(),
}).round().astype(int)
print(compare.loc[["python", "sql", "git", "cloud", "spark"]].to_string())

        required %  mentioned %
python          87           87
sql             72           72
git             34           49
cloud           24           44
spark           10           31

(الأعمدة: "required %" = نسبة الطلب؛ "mentioned %" = نسبة الذِّكر في أيٍّ من القائمتين.)

Git مطلوبة في 34% من إعلانات Data Scientist هذه، لكنها مذكورة في 49%. ورقم O*NET يحسب مرات الذِّكر. وكلما قارنت بين نسبتين لمهارة، تحقق من أنهما تستخدمان التعريف نفسه، والنوع نفسه من الإعلانات، والفترة نفسها، والمكان نفسه.

الجزء C — الرواتب: النطاقات، والقيم الناقصة، والوسيط

الرواتب في الإعلانات تأتي في نطاقات (ranges)، وكثيرًا ما تكون ناقصة، والإعلانات التي تُظهر راتبًا قد تختلف عن التي لا تُظهره. ابدأ بعدد الإعلانات التي تُظهر راتبًا:

u["has_salary"] = u["salary_min_eur"].notna()
print("% of postings that show a salary range")
print((100 * u.groupby("role_family")["has_salary"].mean()).round().astype(int)[FAM].to_string())

% of postings that show a salary range
role_family
Data Analyst       37
BI Analyst         46
Product Analyst    52
Data Scientist     36
ML Engineer        49

(العنوان: "% of postings that show a salary range" = نسبة الإعلانات التي تُظهر نطاقًا للراتب.)

بين 36% و52% من الإعلانات في كل عائلة تُظهر الأجر (142 من 342 إجمالًا)، لذلك فأي ملخّص للرواتب يصف الإعلانات التي تنشر راتبًا. لخّص كل نطاق بنقطة منتصفه (midpoint)، ثم قارن بين الوسيط (median) والمتوسط (mean)، وأعطِ النصف الأوسط بـ المئين (percentile) الخامس والعشرين والخامس والسبعين:

s = u[u["has_salary"]].copy()
s["mid_eur"] = (s["salary_min_eur"] + s["salary_max_eur"]) / 2
summary = s.groupby("role_family")["mid_eur"].agg(
    n="count", median="median", mean="mean",
    p25=lambda x: x.quantile(0.25), p75=lambda x: x.quantile(0.75)).loc[FAM]
money = ["median", "mean", "p25", "p75"]
summary[money] = summary[money].round(-2)
print(summary.astype(int).to_string())

                  n  median   mean    p25    p75
role_family                                     
Data Analyst     42   35000  36500  28200  41200
BI Analyst       26   37800  42800  33400  51600
Product Analyst  25   44800  45100  38000  51000
Data Scientist   31   44500  50600  38100  60100
ML Engineer      18   58600  59000  47100  64600

(الأعمدة: n = عدد الإعلانات؛ median = الوسيط؛ mean = المتوسط؛ p25 وp75 = المئين 25 والمئين 75، باليورو.)

بالنسبة لعلماء البيانات، المتوسط أعلى بكثير من الوسيط: فعدد قليل من إعلانات الوظائف العليا ذات النطاقات المرتفعة يرفع المتوسط. أما الوسيط فيصف الإعلان الذي في المنتصف، وهو الملخّص المعتاد للأجور. ومع 18 إلى 42 إعلانًا لكل عائلة، تبقى هذه الأرقام تقريبية.

والسوق يهم أكثر من ذلك. الجدول نفسه بحسب السوق، لمحللي البيانات فقط:

da = s[s["role_family"] == "Data Analyst"]
by_market = da.groupby("market")["mid_eur"].agg(n="count", median="median")
by_market["median"] = by_market["median"].round(-2)
print(by_market.astype(int).to_string())

            n  median
market               
Eastvale   18   30500
Northport  17   38000
Remote      7   38500

الوسيط المحسوب من 7 إلى 18 إعلانًا لكل سوق إشارة تستحق التحقق، لا حقيقة. ويجب أن يُقرأ الراتب مقابل تكلفة المعيشة المحلية، والضرائب، وما يشمله النطاق (إجمالي أم صافٍ، ومكافآت، ومزايا). والحذر نفسه ينطبق على أي رقم منشور: يذكر O*NET وBLS أن وسيط أجر علماء البيانات في الولايات المتحدة سنة 2025 هو 120,230 دولارًا في السنة (BLS، فُتح في 27 أكتوبر 2026). وهذا رقم على مستوى الولايات المتحدة كلها، وبالدولار الأمريكي، ولعلماء البيانات العاملين من كل المستويات: وهو ليس ما سيُعرض على محلل مبتدئ في Eastvale أو لشبونة أو القاهرة.

الجزء D — النمو والتوقعات: البيانات نفسها، بعرض مختلف

يتوقع BLS أن ينمو توظيف علماء البيانات بنسبة 35% من 2025 إلى 2035، أي "much faster than average" (أي: "أسرع بكثير من المتوسط") (Occupational Outlook Handbook، دليل التوقعات المهنية، عُدّلت الصفحة في 27 أغسطس 2026، وفُتحت في 27 أكتوبر 2026). ويعرض O*NET التوقع نفسه في صورة فئة: "Much faster than average (7% or higher)" (أي: "أسرع بكثير من المتوسط (7% أو أكثر)"). وكلاهما يستند إلى توقعات BLS للولايات المتحدة.

أما تقرير WEF Future of Jobs Report 2025 (تقرير مستقبل الوظائف 2025، نُشر في 7 يناير 2025) فينظر من زاوية مختلفة: استطلاع لـ "over 1,000 leading global employers" (أي: "أكثر من 1,000 من كبار أصحاب العمل في العالم") في 55 اقتصادًا. ويذكر أن الأدوار التقنية، ومنها Big Data Specialists (متخصصو البيانات الضخمة) وAI and Machine Learning Specialists (متخصصو الذكاء الاصطناعي وتعلّم الآلة)، هي "the fastest-growing jobs in percentage terms" (أي: "الوظائف الأسرع نموًا بالنسبة المئوية")، وأن "AI and big data top the list of fastest-growing skills" (أي: "الذكاء الاصطناعي والبيانات الضخمة يتصدران قائمة المهارات الأسرع نموًا"). وهذا ما يتوقعه أصحاب العمل، لا عدد من تم توظيفهم فعلًا.

الجزء E — أدلتك أنت: سجل الإعلانات

المصادر العامة نقطة بداية. أما الدليل الذي يناسب وضعك أنت فهو سجل الإعلانات (posting log): قائمة مؤرَّخة بإعلانات حقيقية لدورك المستهدف وسوقك، تحفظها في جدول بيانات أو ملف CSV. كل صف يسجّل تاريخ رؤيتك للإعلان، والرابط، والشركة، والمسمى، والمستوى، والموقع، والمهارات المطلوبة والمرغوبة، مكتوبة في صورة وسوم قصيرة (sql;python;power_bi). افتح u23_data/posting_log_template.csv: فيه الأعمدة وصفّان مثالان خياليان بوضوح عليك حذفهما.

قواعد تُبقي السجل أمينًا:

1. حقيقي ومؤرَّخ. فقط الإعلانات التي فتحتها بنفسك، مع الرابط وتاريخ جمعها.
2. صف واحد لكل وظيفة شاغرة. إذا ظهرت الوظيفة نفسها على موقعين، فاحتفظ بواحد.
3. وسوم، لا جُمل. استخدم الوسم القصير نفسه للمهارة نفسها في كل مرة، حتى تستطيع عدّها.
4. المطلوب منفصل عن المرغوب، كما هو مكتوب في الإعلان.
5. لا بيانات شخصية. لا تنسخ أسماء مسؤولي التوظيف ولا بريدهم الإلكتروني ولا أرقام هواتفهم.

مع 10 صفوف على الأقل، يعطيك الكود نفسه في الجزء B نِسب المهارات في سجلك، فتضعها بجانب الأرقام الوطنية، كلٌّ بمصدره وتاريخه.

5. مثال محلول

أسواق خيالية، وإعلانات مصطنعة. متعلّمة اسمها أميرة تختار بين أدوار Data Analyst وData Scientist في Northport.

الخطوة 1 — نظّف الأدلة: 360 إعلانًا، حُذفت منها 18 نسخة مُعاد نشرها: 342 إعلانًا فريدًا.

الخطوة 2 — المهام: إعلانات Data Analyst تتمحور حول تقارير SQL (79%)، والتنظيف، ولوحات المعلومات؛ وإعلانات Data Scientist حول النماذج (87%). و9 من أصل 48 إعلانًا بمسمى "Data Scientist" عمل محلل، لذلك تبحث بالمهام أيضًا.

الخطوة 3 — المهارات: SQL مطلوبة في 86% من إعلانات Data Analyst و72% من إعلانات Data Scientist؛ وPython في 40% و87%؛ وتعلّم الآلة في 1% و74%.

الخطوة 4 — الأجر: 142 من 342 إعلانًا تُظهر الأجر. ومن بينها، وسيط نقطة المنتصف حوالي 35,000 يورو لمحللي البيانات و44,500 يورو لعلماء البيانات؛ ومتوسط علماء البيانات (50,600 يورو) ترفعه إعلانات الوظائف العليا.

الخطوة 5 — ملاحظة السوق:

"In 342 unique fictional postings (Jul–Sep 2026), SQL is the most common requirement for analyst roles and Python for data-science roles. Salary figures come from the 42% of postings that publish a range, so they are rough. National US figures (O*NET/BLS) are context only. Next: my own log of 10 real Northport postings."

وبالعربية: "في 342 إعلانًا خياليًا فريدًا (يوليو–سبتمبر 2026)، SQL هي المتطلب الأكثر شيوعًا لأدوار المحللين، وPython لأدوار علم البيانات. وأرقام الرواتب مأخوذة من 42% من الإعلانات التي تنشر نطاقًا، لذلك فهي تقريبية. والأرقام الوطنية الأمريكية (O*NET/BLS) للسياق فقط. التالي: سجلي الخاص لعشرة إعلانات حقيقية في Northport."

6. شرح بصري

 A MARKET NUMBER IS ONLY AS GOOD AS ITS LABEL
 ┌─────────────────────────────────────────────────────────────────────────────┐
 │ "Python 66%"                                                                │
 │   WHAT?   share of unique postings that MENTION Python (not jobs, not people)│
 │   WHO?    occupation: Data Scientists (O*NET 15-2051.00)                    │
 │   WHERE?  United States, nationwide                                         │
 │   WHEN?   postings from 2025 (Lightcast), page read 27 Oct 2026             │
 │   LIMITS? mentions ≠ requirements; titles vary; other countries differ      │
 └─────────────────────────────────────────────────────────────────────────────┘
 general signal (O*NET / BLS / WEF)  ──compare──▶  YOUR posting log (real, dated, local)

وصف الرسم: مربع يوضح كيف تُعنوِن رقم السوق "Python 66%": ماذا يقيس (نسبة الإعلانات الفريدة التي تذكر Python، لا الوظائف ولا الأشخاص)، ومن (علماء البيانات، رمز O*NET 15-2051.00)، وأين (الولايات المتحدة)، ومتى (إعلانات 2025، وقُرئت الصفحة في 27 أكتوبر 2026)، وحدوده (الذِّكر ليس طلبًا، والمسميات تختلف، والدول الأخرى مختلفة). وسهم يوضح مقارنة الإشارات العامة من O*NET وBLS وWEF بسجل الإعلانات الحقيقي المؤرَّخ المحلي الخاص بالمتعلّم. (نصوص الرسم: A MARKET NUMBER IS ONLY AS GOOD AS ITS LABEL = رقم السوق لا يساوي أكثر من عنوانه؛ WHAT? = ماذا؟؛ share of unique postings that MENTION Python (not jobs, not people) = نسبة الإعلانات الفريدة التي تذكر Python (لا الوظائف، ولا الأشخاص)؛ WHO? = من؟؛ occupation = المهنة؛ WHERE? = أين؟؛ United States, nationwide = الولايات المتحدة كلها؛ WHEN? = متى؟؛ postings from 2025, page read 27 Oct 2026 = إعلانات من 2025، وقُرئت الصفحة في 27 أكتوبر 2026؛ LIMITS? = الحدود؟؛ mentions ≠ requirements; titles vary; other countries differ = الذِّكر ≠ الطلب؛ المسميات تختلف؛ الدول الأخرى مختلفة؛ general signal = إشارة عامة؛ compare = قارن؛ YOUR posting log (real, dated, local) = سجل إعلاناتك أنت (حقيقي، ومؤرَّخ، ومحلي).)

7. تدريب موجَّه

في L98_starter.ipynb:

1. حمّل postings_2026q3.csv، واحذف الإعلانات المُعاد نشرها، وتأكد من وجود 342 إعلانًا فريدًا.
2. ابنِ جدول المهام في الجزء A. أي مهمتين تفصلان بين محللي ذكاء الأعمال ومحللي البيانات أكثر من غيرهما؟
3. اسرد المسميات المستخدمة في إعلانات Product Analyst، وقل أيها ما كنت لتخمّنه.
4. ابنِ جدول المهارات المطلوبة في الجزء B. اذكر المهارات المطلوبة الثلاث الأكثر شيوعًا للعائلة التي تستهدفها.
5. للعائلة التي تستهدفها، احسب وسيط نقطة منتصف الراتب، والمتوسط، والمئين 25 والمئين 75 بحسب السوق، مع عدد الإعلانات وراء كل رقم.
6. اكتب ثلاث جمل تقارن فيها جدولك بصفحة Hot Technologies في O*NET لأقرب مهنة (Data Scientists 15-2051.00، أو Business Intelligence Analysts 15-2051.01). واذكر مصدرًا وتاريخًا ومكانًا في كل جملة.

8. تدريب مستقل

الجزء 1 — سجل إعلاناتك (بيانات حقيقية). اختر دورًا مستهدفًا وسوقًا (مدينة أو دولة، أو "عن بُعد" مع المناطق الزمنية). اجمع 10 إعلانات حقيقية من موقعين للتوظيف أو صفحتي وظائف لشركتين على الأقل، كلها فُتحت خلال آخر 30 يومًا، وسجّلها في نسخة من u23_data/posting_log_template.csv (احذف الصفين المثالين). واتبع القواعد الخمس في الجزء E.

الجزء 2 — نِسب مهاراتك. حمّل سجلك واحسب نسبة الإعلانات التي تطلب كل مهارة، ونسبة الإعلانات التي تذكرها في أيٍّ من القائمتين. اعرض المهارات الخمس الأكثر شيوعًا. وإذا أظهرت بعض الإعلانات الأجر، فاذكر عدد الإعلانات التي فيها أجر ووسيط نقطة منتصفها، بعملة الإعلانات.

الجزء 3 — ملاحظة السوق (حوالي 150 كلمة). اكتب ملاحظة لنفسك فيها:

• الدور المستهدف والسوق؛
• المهارات المطلوبة الخمس الأكثر شيوعًا في سجلك؛
• مقارنة واحدة مع O*NET أو BLS أو WEF، لكل رقم مصدره وتاريخه ومكانه؛
• ما لا يستطيع سجلك أن يُظهره (فهو صغير، وجمعته بنفسك، ومن فترة واحدة)؛
• وقرار واحد تتخذه بناءً عليه.

9. اختبار الفهم (Knowledge Check) — الأدوار وإشارات السوق

Q1. إعلانان مسمى كل منهما "Data Scientist". الأول يذكر بناء نماذج تنبؤية وتقييمها؛ والثاني يذكر تقارير SQL أسبوعية ولوحات معلومات. ما أفضل وصف للإعلان الثاني؟

• A) دور في علم البيانات، لأن صاحب العمل اختار هذا المسمى للإعلان
• B) عمل محلل تحت مسمى علم البيانات؛ احكم على الدور بمهامه
• C) دور في مستوى عالٍ، لأن مسميات "Data Scientist" عادة ما تكون لمستويات عليا
• D) خطأ من موقع التوظيف يجب حذفه من أي تحليل

Q2. يذكر O*NET "Python 66%" لعلماء البيانات. ماذا يعني هذا الرقم؟

• A) 66% من كل علماء البيانات في العالم يستخدمون Python في عملهم اليومي
• B) Python مطلوبة في 66% من الوظائف واختيارية في كل الوظائف الأخرى
• C) 66% من الإعلانات الفريدة في الولايات المتحدة سنة 2025 لهذه المهنة تذكر Python
• D) Python تمثّل 66% من كل المهارات التي تسردها إعلانات علم البيانات

Q3. لماذا تحذف النسخ المُعاد نشرها قبل حساب نِسب المهارات؟

• A) لأن pandas لا تستطيع تجميع جدول فيه صفوف مكررة بالكامل
• B) لأن الإعلانات المُعاد نشرها دائمًا وظائف قديمة شُغلت في هذه الأثناء
• C) لأن مواقع التوظيف تحاسب أصحاب العمل على كل إعادة نشر، فالنسخ إعلانات مدفوعة
• D) يجب أن تُحسب كل وظيفة شاغرة مرة واحدة؛ والنسخ تعطي بعض أصحاب العمل وزنًا زائدًا

Q4. من بين الإعلانات التي تُظهر راتبًا، متوسط نقطة المنتصف 50,600 يورو والوسيط 44,500 يورو. ما السبب الأرجح؟

• A) عدد قليل من النطاقات المرتفعة يرفع المتوسط؛ والوسيط هو الإعلان الذي في المنتصف
• B) الوسيط حُسب بعملة مختلفة عن عملة المتوسط
• C) المتوسط يتجاهل الرواتب الناقصة، بينما يحسبها الوسيط أصفارًا
• D) الوسيط دائمًا أقل من المتوسط في كل بيانات الرواتب

Q5. 42% فقط من الإعلانات تُظهر نطاقًا للراتب. ماذا يجب أن يقول ملخّص الرواتب؟

• A) لا شيء: يمكن ملء الرواتب الناقصة بالوسيط العام
• B) إنه يصف فقط الإعلانات التي تنشر نطاقًا، وهي قد تختلف عن غيرها
• C) إنه دقيق للسوق ما دام أكثر من 40% من الإعلانات يُظهر راتبًا
• D) يجب أن يستخدم الحد الأدنى لكل نطاق، لأن العروض تبدأ من هناك

Q6. يذكر BLS أن وسيط أجر علماء البيانات في الولايات المتحدة سنة 2025 هو 120,230 دولارًا. متعلّمة في بلد آخر تستهدف دور محلل مبتدئ. كيف تستخدم هذا الرقم؟

• A) هدفًا لراتبها، بعد تحويله إلى العملة المحلية بسعر الصرف اليوم
• B) دليلًا على أن أدوار المحللين في بلدها تدفع أكثر مما كانت تدفع
• C) سياقًا أمريكيًا لكل المستويات؛ والأجر المحلي يحتاج إلى أدلة محلية خاصة بالمستوى
• D) رقمًا لا علاقة له بها، لأن الإحصاءات الحكومية الأمريكية ليست مصادر موثوقة

Q7. إعلان يذكر Git تحت "nice to have" (مرغوب). في بيانات التدريب، Git مطلوبة في 34% من إعلانات Data Scientist ومذكورة في 49%. ما الذي يفسّر الفرق؟

• A) الرقمان من مجموعتي بيانات مختلفتين جمعهما أشخاص مختلفون
• B) بعض الإعلانات حُسبت مرتين في رقم الذِّكر ولم تُحسب كذلك في الآخر
• C) حُذفت Git من بعض الإعلانات بعد أن جمعها المحلل
• D) رقم "الذِّكر" يحسب أيضًا الإعلانات التي تذكر Git على أنها مرغوبة فقط

Q8. ما الذي يجعل سجل الإعلانات دليلًا أقوى لقراراتك أنت من جدول مهارات وطني؟

• A) أنه حقيقي، ومؤرَّخ، ومن دورك المستهدف وسوقك
• B) أنه دائمًا أكبر من أي مجموعة بيانات وطنية لإعلانات الوظائف
• C) أنه يُجمع آليًا، فلا تؤثر فيه أي اختيارات بشرية
• D) أنه يحتوي على رواتب لكل إعلان، بخلاف البيانات الوطنية

10. الذكاء الاصطناعي في التطبيق (اختياري، وفي حدود)

الهدف: أن تستخدم الذكاء الاصطناعي لوصف دور، ثم تختبر كل ادعاء فيه.

1. اسأل:

"Describe the main tasks, outputs and tools of a [target role] in [market]. Give sources for each claim."

وبالعربية: "صِف المهام والمخرجات والأدوات الرئيسية لـ [الدور المستهدف] في [السوق]. واذكر مصادر لكل ادعاء."

2. انسخ الإجابة إلى جدول فيه ادعاء واحد في كل صف.
3. لكل ادعاء، ضع علامة مدعوم (من O*NET أو BLS أو أحد الإعلانات في سجلك، مع الرابط والتاريخ)، أو متناقض، أو غير مدعوم. واحذف الأرقام التي ليس لها مصدر يمكن التحقق منه.

الحدود:

• استخدام الذكاء الاصطناعي اختياري.
• لا تلصق أبدًا بيانات شخصية.
• إجابات الذكاء الاصطناعي عن أسواق العمل كثيرًا ما تكون قديمة، أو مختلَقة، أو عن الولايات المتحدة افتراضيًا؛ وسجلك والمصادر المؤرَّخة هي التي تحسم.

11. التحقق من مخرجات الذكاء الاصطناعي

1. المصدر: لكل رقم في إجابة الذكاء الاصطناعي مصدر فتحته بنفسك، مع تاريخه.
2. المكان والفترة: المصدر يطابق سوقك وحديث؛ والبيانات الأمريكية مُعنوَنة على أنها أمريكية.
3. التعريف: لا خلط بين "نسبة من الإعلانات" و"نسبة من الوظائف" و"نسبة من العاملين".
4. إعادة العدّ: أي نسبة تحتفظ بها من سجلك تُعاد حسابها بكودك أنت.

12. منظور الأعمال

أصحاب العمل يوظّفون من أجل النتائج. الإعلان قائمة بالمشكلات التي يريد صاحب العمل حلّها: تقارير تصل يوم الاثنين، ولوحات معلومات يثق بها المديرون، واختبارات تحسم نقاشات المنتج، ونماذج تقلّل التوصيلات المتأخرة. وقراءة الإعلانات على أنها قوائم نتائج تجعل طلبات التوظيف أدق: فبدلًا من "I know Power BI" (أي: "أعرف Power BI")، تستطيع أن تكتب "built the dashboard a shop manager uses to reorder stock" (أي: "بنيت لوحة المعلومات التي يستخدمها مدير متجر لإعادة طلب المخزون"). والعادة نفسها تحميك من المبالغات: فالأداة الأكثر ذكرًا ليست دائمًا هي التي تحدد من يتم توظيفه.

13. مهمة عمل — ملخّص السوق

نشاط خيالي: Cedar Lane. تريد قائدة العمليات في Cedar Lane توظيف أول محلل بيانات في Northport، وتسألك ماذا تضع في الإعلان، وما نطاق الأجر المتوقع. باستخدام بيانات التدريب فقط، اكتب ملخّصًا من 120 كلمة فيه: المهارات الخمس الأكثر طلبًا لمحللي البيانات، ووسيط نقطة منتصف الراتب في Northport مع عدد الإعلانات وراءه، وحدّين لهذه الأدلة.

14. تحدٍّ قصير — أي مقام؟

أسواق خيالية، وإعلانات مصطنعة. تدّعي تدوينة: "Python is only 17% of what data-science employers ask for." (أي: "Python تمثّل 17% فقط مما يطلبه أصحاب العمل في علم البيانات.") احسب رقمين لإعلانات Data Scientist:

ds_skills = skills[u["role_family"] == "Data Scientist"]
print("postings:", len(ds_skills), "| skill mentions:", int(ds_skills.sum().sum()))
print("Python, share of postings:", round(100 * ds_skills["python"].mean()), "%")
print("Python, share of all skill mentions:", round(100 * ds_skills["python"].sum() / ds_skills.sum().sum()), "%")

postings: 86 | skill mentions: 434
Python, share of postings: 87 %
Python, share of all skill mentions: 17 %

1. قبل أن تفتح المخرجات، توقّع: هل سيكون الرقمان كلاهما قريبين من رقم التدوينة 17%؟
2. ما المقام (denominator) في كل رقم؟
3. أي رقم يجيب عن سؤال "كم صاحب عمل يطلب Python؟"
4. أعد كتابة جملة التدوينة بحيث تصبح صحيحة.

سلّم عملك قبل أن تتلقى الملاحظات. لا يوجد حل منشور هنا.

15. المصادر

مطلوب (حوالي 30 دقيقة):

• O*NET OnLine: Data Scientists, 15-2051.00 (المهام، والمهارات التقنية، والأجور، والتوقعات). https://www.onetonline.org/link/summary/15-2051.00 (فُتح في 27 أكتوبر 2026.)
• O*NET OnLine: Hot Technologies, Data Scientists (نِسب من إعلانات الولايات المتحدة سنة 2025، من Lightcast). https://www.onetonline.org/link/hot_tech/15-2051.00 (فُتح في 27 أكتوبر 2026.)

موصى به:

• U.S. Bureau of Labor Statistics: Occupational Outlook Handbook, Data Scientists. https://www.bls.gov/ooh/math/data-scientists.htm (فُتح في 27 أكتوبر 2026.)
• World Economic Forum: The Future of Jobs Report 2025. https://www.weforum.org/publications/the-future-of-jobs-report-2025/ (فُتح في 27 أكتوبر 2026.)
• O*NET OnLine: Hot Technologies, Business Intelligence Analysts, 15-2051.01. https://www.onetonline.org/link/hot_tech/15-2051.01 (فُتح في 27 أكتوبر 2026.)

16. شخصية تتابعها / قدوة

Emily Robinson وJacqueline Nolis.

• حقيقة مُتحقَّق منها: هما مؤلفتا كتاب Build a Career in Data Science (Manning، مارس 2020)، الذي يصفه الناشر بأنه "your guide to landing your first data science job and developing into a valued senior employee" (أي: "دليلك للحصول على أول وظيفة لك في علم البيانات والتطوّر إلى موظف أول ذي قيمة") (manning.com، فُتح في 27 أكتوبر 2026).
• لماذا توصي بهما D.World: يتعامل الكتاب مع المسار المهني في البيانات على أنه سلسلة من القرارات المبنية على الأدلة: أي دور، وأي شركة، وأي بورتفوليو، وأي عرض.
• ملاحظة صادقة: كُتب الكتاب في 2020 ومن خبرة أمريكية في معظمها؛ وقد تغيّرت الأدوات والرواتب وإجراءات التوظيف منذ ذلك الحين، لذلك تحقق من عباراته عن السوق مقابل المصادر الحالية.
• جرّب هذا: اقرأ وصف الناشر وفهرس المحتويات، ودوّن أي فصل يطابق كل درس من دروس هذه الوحدة.

17. المصطلحات

للمراجعة: الوسيط والمئينات (L52) · التجميع حسب المجموعات (L27).

18. تأمّل

1. أي من قناعاتك عن وظائف البيانات أكّدتها أدلة هذا الدرس، وأيها أضعفتها؟
2. أي عائلة أدوار تناسبك مهامها أكثر، أيًّا كان مسماها؟
3. ماذا تحتاج أن تجمع حتى تثق برقم راتب في سوقك؟

19. الخطوة التالية

التالي: L99 — الأوصاف الوظيفية، وفجوات المهارات، وربط الأدلة (Job Descriptions, Skill Gaps & Evidence Mapping). من السوق إلى الإعلانات المفردة: تفكك الأوصاف الوظيفية إلى متطلبات، وتربط كل متطلب بأدلتك أنت.

20. أدلة التقييم

المراجع

1. O*NET OnLine. Summary Report for 15-2051.00 Data Scientists. https://www.onetonline.org/link/summary/15-2051.00 (ONET-SUM). يدعم: المهام (اقتباس)، ووسيط الأجر، وفئة النمو المتوقع. حُدّث الموقع في 6 أكتوبر 2026.
2. O*NET OnLine. Hot Technologies: 15-2051.00 Data Scientists. https://www.onetonline.org/link/hot_tech/15-2051.00 (ONET-HOT). يدعم: Python 66%، وSQL 51%، وR 34%، وTableau 22%، وGit 5%؛ والمصدر والتعريف (اقتباس).
3. U.S. Bureau of Labor Statistics. Occupational Outlook Handbook: Data Scientists. https://www.bls.gov/ooh/math/data-scientists.htm (BLS-OOH). يدعم: وسيط الأجر لسنة 2025 وهو 120,230 دولارًا؛ وتوقعات 2025–2035 بنسبة 35%. عُدّلت الصفحة في 27 أغسطس 2026.
4. World Economic Forum. The Future of Jobs Report 2025 (7 يناير 2025). https://www.weforum.org/publications/the-future-of-jobs-report-2025/ (WEF). يدعم: نطاق الاستطلاع؛ والوظائف والمهارات الأسرع نموًا (اقتباس).
5. O*NET OnLine. Hot Technologies: 15-2051.01 Business Intelligence Analysts. https://www.onetonline.org/link/hot_tech/15-2051.01 (ONET-HOT-BI). يدعم: مهنة المقارنة لأدوار ذكاء الأعمال.
6. Manning Publications. Build a Career in Data Science (Robinson, E. and Nolis, J., 2020). https://manning.com/books/build-a-career-in-data-science (MANNING-BCDS). يدعم: القدوة (الوصف المقتبس).
7. D.World Stage 5 Detailed Lesson Map v1.0 (صف L98)؛ وقرار المرحلة 5 رقم D06 (أدلة السوق القائمة على المنهج، مع سجل للإعلانات). وثيقة داخلية.

L101 — Capstone Scoping: Stakeholder Requirements & a Proposal

Learner file. Answers and model solutions are in a separate instructor-only file. Version: U24 Production v1 · Content date: 27 October 2026. Time estimates are planning estimates until learners have tested them. The code in this lesson was run with Python 3.13.16 and pandas 3.0.5 (recorded in D.World's internal Code Test Report); Python 3.13 is the accepted course version. Not run with Python 3.14 or inside JupyterLab.

All businesses and people in the dry-run case are fictional and all its data is synthetic.

1. Lesson Identity

Time breakdown (planning estimate): concept and worked example 60 min · guided practice 30 min · independent practice 35 min · knowledge check 10 min · AI 5 min (optional) · workplace task and mini challenge 10 min.

What you need: Python with pandas; practice_files (L101_starter.ipynb; u24_data/stakeholder_interview.md, u24_data/cedar_deliveries_aug_sep_2026.csv, u24_data/data_README.md); U24_CAPSTONE/ (brief, capstone register, rights-and-privacy checklist, proposal template).

2. Learning Objective

By the end of this lesson, you will be able to:

• elicit and record stakeholder requirements, separating requests, needs and constraints;
• choose and check a dataset for rights, privacy, size and fit, and test feasibility in a notebook;
• write a capstone proposal with a decision, a success metric, feasibility evidence, milestones and risks.

D.World approved objective (verbatim): Elicit and record stakeholder requirements, choose and check a dataset, and write a capstone proposal with a decision, success metric, feasibility evidence, milestones and risks.

3. Why It Matters

Your capstone is the project a reviewer, an employer or a client will judge you by. Most projects that disappoint do not fail in the modelling: they answer a question nobody needed answered, on data that could not be used, by a date that had already passed. In U17 you turned a given request into a charter. Here you go one step earlier: you find out what the request is, by asking.

Stakeholders usually start with a solution ("I want an AI model"), not with the decision they face. Your job is to get to the decision, the people it affects, the measure of success, the limits nobody mentioned at first, and the deadline, and to check, before you promise anything, that the data can support it and that you may use it.

Key principle: start from the decision, not the request; write requirements as decision, user, metric, threshold and deadline; check the data's rights and fit before you promise; and get the proposal approved before you build.

4. Concept

You will scope a dry-run capstone on a fictional case, so that every step can be checked; your own capstone (section 8) follows the same steps on a real dataset from the D.World capstone register.

Part A — The stakeholder interview: requests, needs and constraints

Read the transcript u24_data/stakeholder_interview.md once from start to end. Then look at how it opens:

from pathlib import Path

interview = Path("u24_data/stakeholder_interview.md").read_text(encoding="utf-8")
turns = [line for line in interview.splitlines() if line.startswith("**Nadia:**") or line.startswith("**Karim:**")]
print(len(turns), "turns by the stakeholders")
for line in turns[:3]:
    print(line[:110])

14 turns by the stakeholders
**Nadia:** Thanks for coming. I'll be direct: I want an AI model that predicts late deliveries. Everyone has o
**Nadia:** Honestly? The complaints are the problem. Customer service tells me late deliveries are most of the
**Nadia:** Two things, really. We can give a longer promised time when the customer books, or we can add drive

The first sentence is a request for a solution: "an AI model that predicts late deliveries". By the third turn the need appears: fewer complaints before the holiday season. Sort everything said in the interview into four kinds of statement:

Three habits made this interview work: Amira asked what would change if the answer were known; she asked who else is affected (marketing joined with a constraint that changes the whole project); and she asked what failure looks like. Write the stakeholder map in one line each: who decides (Nadia), who can veto (Karim, on promise length), who uses the result (customer service, the booking page), who is affected (customers).

Part B — Requirement statements

A good requirement names the decision, the user, the metric, the acceptance threshold and the deadline, so that anyone can tell later whether it was met:

R1. Recommend a change to the promised-time rule (decision) that operations can apply on the booking page and explain to customer service (users), such that the evening late rate is below 5% and the average promised time rises by at most 3 minutes across all orders (metrics and thresholds), estimated on data not used to design the change, by 15 November 2026 (deadline).

Requirements also say what is not required. Here nothing requires a machine-learning model: a model is one option, judged against a simple rule by the same thresholds. AWS's guidance on data science says it plainly: "Some business problems don't need ML and simple business rules can do a much better job." Write each threshold down before looking at results, so that you cannot move it afterwards.

Part C — Checking the data: rights, privacy, size and fit

Before you promise anything, check the dataset:

1. Rights: who owns it, what licence or terms apply, what attribution is required. Copy them from the source page, with the date you read it.
2. Personal data: does it identify people? If so, it is not a capstone dataset unless it has been properly anonymised and its terms allow your use.
3. Size and fit: enough rows, the right period, the columns the decision needs.
4. Provenance: a fingerprint (L33, L88) so that everyone uses the same file.

Read the data notes and check the fingerprint they state:

import hashlib

notes = Path("u24_data/data_README.md").read_text(encoding="utf-8")
fp = hashlib.sha256(Path("u24_data/cedar_deliveries_aug_sep_2026.csv").read_bytes()).hexdigest()[:12]
print("fingerprint:", fp, "| stated in the notes:", fp in notes)
for line in notes.splitlines():
    if "Synthetic data" in line or "No personal data" in line:
        print(line[:150])

fingerprint: b62ff3952085 | stated in the notes: True
| `cedar_deliveries_aug_sep_2026.csv` | 2,400 | Delivery system export, 1 Aug – 30 Sep 2026, with the complaint flag from customer service | Synthetic
No personal data: order IDs are pseudonymous; no names, addresses or contact details.
**Attribution line (use it when you publish this file or results from it):** Synthetic data generated by D.World for learning; Cedar Lane is a fiction

Now the size and fit:

import pandas as pd

d = pd.read_csv("u24_data/cedar_deliveries_aug_sep_2026.csv")
print(d.shape, "|", d["order_date"].min(), "to", d["order_date"].max())
print("missing values:", int(d.isna().sum().sum()), "| duplicate order ids:", int(d["order_id"].duplicated().sum()))
print(d["slot"].value_counts().to_string())

(2400, 9) | 2026-08-01 to 2026-09-30
missing values: 0 | duplicate order ids: 0
slot
afternoon    906
morning      749
evening      745

The data covers the decision: promised and actual minutes, slot and zone (to target a change), and complaints. It has no information on booking completion, so Karim's constraint (the effect of longer promises on orders) cannot be measured from it; the proposal must say so and plan how to measure it.

For your own capstone, the D.World capstone register (U24_CAPSTONE/CAPSTONE_REGISTER.md) lists public datasets whose licence (CC BY 4.0) and attribution were checked on their UCI pages. If you propose your own dataset, the rights-and-privacy checklist in the same folder must be completed and approved first.

Part D — The feasibility notebook

A feasibility check answers one question: could the requirement be met with this data, by the deadline? It is not the analysis itself, and it uses design data only: here August. September stays untouched for the evaluation in L102. Compute the starting point on August:

d["late"] = d["actual_minutes"] > d["promised_minutes"] + 5
aug = d[d["order_date"] < "2026-09-01"]
print(f"August orders: {len(aug)} | late rate: {aug['late'].mean():.3f}")
print((aug.groupby("slot")["late"].mean().round(3)).to_string())
print(f"complaint rate when late: {aug.loc[aug['late'], 'complaint'].mean():.3f} | when not late: {aug.loc[~aug['late'], 'complaint'].mean():.3f}")

August orders: 1221 | late rate: 0.093
slot
afternoon    0.067
evening      0.183
morning      0.042
complaint rate when late: 0.149 | when not late: 0.018

In August the evening late rate is 18.3%, more than three times the 5% target, and late deliveries draw complaints far more often, so the need is real. Is the target within reach under the 3-minute constraint? Test a few simple buffers, still on August only:

evening = aug["slot"] == "evening"
for extra in (5, 8, 10):
    promised = aug["promised_minutes"] + extra * evening
    late = aug["actual_minutes"] > promised + 5
    print(f"evening +{extra:2d} min: evening late {late[evening].mean():.3f} | "
          f"average extra minutes over all orders {(extra * evening).mean():.2f}")

evening + 5 min: evening late 0.072 | average extra minutes over all orders 1.47
evening + 8 min: evening late 0.047 | average extra minutes over all orders 2.36
evening +10 min: evening late 0.022 | average extra minutes over all orders 2.95

Feasible, but only just: in August an 8-minute evening buffer brings the evening late rate to 4.7%, under 5%, at 2.36 extra minutes on average, inside Karim's limit; 10 minutes gives a lower rate but uses almost the whole limit (2.95 minutes). This is evidence of feasibility, not a result: the final options are compared on September, which this check never looked at.

Part E — The proposal and the approval gate

The capstone proposal turns all of this into one page that a reviewer can approve or send back (template: U24_CAPSTONE/templates/proposal_template.md):

The approval gate means: no analysis starts until the reviewer has approved the proposal. A capstone without an approved proposal is not accepted, however good its results.

5. Worked Example

Fictional business, synthetic data. Amira scopes the dry-run case.

Step 1 — Interview: the request was "an AI model"; the need is fewer late deliveries and complaints before December; the constraints are fixed drivers, ≤ 3 extra minutes on average and an explainable rule.

Step 2 — Requirement: evening late rate below 5%, average promise increase at most 3 minutes, estimated on September data not used for design, by 15 November.

Step 3 — Data: 2,400 orders, no missing values or duplicate IDs, synthetic with D.World attribution, fingerprint confirmed; booking completion is missing from the data.

Step 4 — Feasibility: evening late rate 18.3% in August; an 8-minute evening buffer reaches 4.7% in August at 2.36 extra minutes on average.

Step 5 — Proposal: one page with decision, requirements, data, approach, feasibility, milestones, risks and scope, sent for approval on 28 October.

6. Visual Explanation

 REQUEST ("an AI model")
     │  ask: what would you do differently?  who else?  what is failure?
     ▼
 NEED (decision) ──▶ REQUIREMENT: decision · user · metric · threshold · deadline   (written BEFORE results)
     │
     ├─▶ DATA CHECK: rights & attribution · personal data · size & fit · fingerprint
     ├─▶ FEASIBILITY: baseline numbers · can the threshold be reached? (design data only)
     ▼
 PROPOSAL (one page) ──▶ APPROVAL GATE ──▶ analysis starts

Alt text: A stakeholder's request for an AI model leads, through questions about what would change, who else is affected and what failure looks like, to the underlying need. The need becomes a requirement with decision, user, metric, threshold and deadline, written before results. Two checks follow: a data check of rights and attribution, personal data, size and fit, and fingerprint; and a feasibility check using baseline numbers on design data only. Both feed a one-page proposal, which must pass an approval gate before the analysis starts.

7. Guided Practice

In L101_starter.ipynb:

1. From the transcript, list every constraint with the sentence it comes from. Which one did Nadia not mention at all?
2. Rewrite R1 as two separate requirements (late rate; promise length). Why might a stakeholder prefer them separate?
3. Check the data: rows, period, missing values, duplicates, fingerprint. Add one check of your own (for example, that actual minutes are never negative).
4. Compute the late rate by zone on August. Which zone would an evening-only rule leave worst served?
5. Repeat the August buffer check for a rule "evening or East zone + 8 minutes". Does it meet both thresholds?
6. Fill in proposal_template.md for the dry run.

8. Independent Practice

Your capstone proposal. Choose a dataset from U24_CAPSTONE/CAPSTONE_REGISTER.md (or propose your own and complete the rights-and-privacy checklist), and choose a case brief or a decision of your own that fits the data.

1. Write a short stakeholder interview plan (six to eight questions) for the decision; if you have access to a real person who could use the result, interview them; otherwise write down who the stakeholders would be and which assumptions you are making for them.
2. Write two or three requirement statements with decision, user, metric, threshold and deadline.
3. Build a feasibility notebook: licence and attribution copied from the dataset page (with the date), fingerprint, rows, period, missing values, the baseline value of your metric, and one quick check that the threshold could be reached, on design data only.
4. Write the proposal (template) and submit it for approval.

9. Knowledge Check — Scoping

Q1. A stakeholder opens with "I want an AI model that predicts late deliveries." What is the best next question?

• A) "Which machine-learning algorithm would you like me to use for it?"
• B) "What would you do differently if you knew which deliveries will be late?"
• C) "How accurate does the model need to be before you would accept it?"
• D) "Can I start building a model now and show you the results next week?"

Q2. Which statement is a constraint rather than a need?

• A) Fewer complaints about late deliveries before December
• B) A change to the promised time that operations can use
• C) No more than 3 extra minutes on average across all orders
• D) Fewer late deliveries in the evening than in previous months

Q3. Which requirement statement is the most complete?

• A) "Build a good model for late deliveries as soon as possible."
• B) "Reduce late deliveries in the evening by a meaningful amount."
• C) "Analyse delivery data to understand the drivers of lateness."
• D) "Change the evening promise rule: evening late < 5%, ≤ 3 min extra, by 15 Nov."

Q4. Why write the acceptance threshold before seeing results?

• A) So that it cannot be moved to fit the results afterwards
• B) Because thresholds are required by the template's format
• C) So that the stakeholder does not need to read the results
• D) Because results always fall short of thresholds set later

Q5. A public dataset page shows no licence. What follows for your capstone?

• A) It may be used freely, because it is publicly downloadable from the web
• B) It may be used if you credit the author's name in your README file
• C) It is not usable until the rights are clear; choose another or ask
• D) It may be used for analysis, but not shown in any of your charts

Q6. In the feasibility check, why test buffers on August only?

• A) August has more orders than September, so its results are more precise
• B) September is kept untouched for the evaluation of the final options
• C) The deliveries data for September has not been cleaned yet by anyone
• D) Buffers only apply to summer months, when the evenings are much busier

Q7. Marketing's constraint concerns booking completion, which is not in the data. What should the proposal do?

• A) Ignore the constraint, because the data cannot be used to measure it
• B) Assume booking completion does not change and say nothing about it
• C) State the gap and plan how to measure it when the change is tried
• D) Ask marketing to drop the constraint so that the project can proceed

Q8. What does the approval gate mean?

• A) The reviewer approves the final results before they are published
• B) The stakeholder approves each chart before it goes into the report
• C) The dataset owner approves the code before it is run on their data
• D) The analysis starts only after the reviewer approves the proposal

10. AI in Practice (optional, bounded)

Goal: prepare interview questions with AI, keep only those tied to the decision.

1. Ask: "I will interview an operations lead who asked for a model that predicts late deliveries. Suggest 12 interview questions to understand the decision, constraints, success measures and deadline."
2. Keep a question only if its answer could change the requirement, the data you need or the approach. Delete the rest.
3. Add any question the AI missed (for example: "Who else is affected?" or "What would failure look like?").

Boundaries: AI is optional. Never paste interview notes that identify real people. AI does not decide what the stakeholder needs; the stakeholder's answers do.

11. AI Verification

1. Relevance: each kept question is linked to the decision, a constraint, a metric or the deadline.
2. Licence facts: licence and attribution in the proposal are copied from the dataset's own page with the access date, never from an AI summary.
3. Numbers: feasibility numbers come from your notebook output.
4. Record: note in your AI-use trail which questions came from AI and which you added.

12. Business Lens

Most failed projects answer a question nobody needed answered. The dry run shows why: a model that predicts late deliveries is easy to build, but the business cannot add drivers, cannot promise much longer, and must explain every change to customers. The useful project changes one rule on the booking page, by a date, within limits that came from a second stakeholder who was not in the first meeting. Scoping is where an analyst saves the most money.

13. Workplace Task — The Scoping Email

Fictional business: Cedar Lane. Write the email (100–150 words) that Amira sends Nadia and Karim after the interview: the decision as she understood it, the two thresholds and the deadline, what the data cannot show, and the date she needs approval of the proposal.

14. Mini Challenge — When the Constraint Bites

Fictional business, synthetic data. Karim later says: "Actually, no more than 2 extra minutes on average." Rerun the August check with that limit in mind:

for extra in (6, 7, 8):
    promised = aug["promised_minutes"] + extra * evening
    late = aug["actual_minutes"] > promised + 5
    print(f"evening +{extra} min: evening late {late[evening].mean():.3f} | average extra {(extra * evening).mean():.2f}")

evening +6 min: evening late 0.058 | average extra 1.77
evening +7 min: evening late 0.056 | average extra 2.06
evening +8 min: evening late 0.047 | average extra 2.36

1. Before you open the output, predict whether an evening-only rule can still reach the 5% target within 2 minutes.
2. What does the output show?
3. Which two options does Amira now have, and what would she ask the stakeholders?
4. Write one sentence for the proposal's risk list.

Submit before feedback. No solution is provided here.

15. Resources

Required (about 25 min):

• D.World capstone register (U24_CAPSTONE/CAPSTONE_REGISTER.md): the three datasets, their UCI pages, licences and case briefs. UCI dataset pages (opened 27 Oct 2026): Online Shoppers Purchasing Intention https://archive.ics.uci.edu/dataset/468/online+shoppers+purchasing+intention+dataset, Bike Sharing https://archive.ics.uci.edu/dataset/275/bike+sharing+dataset, Default of Credit Card Clients https://archive.ics.uci.edu/dataset/350/default+of+credit+card+clients.
• AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (Opened 27 Oct 2026.)

16. Person to Follow / Role Model

Cassie Kozyrkov.

• Verified fact: her home page describes her as "Decision Intelligence Pioneer" and "Google's First Chief Decision Scientist", and defines decision intelligence as "The discipline of turning information into better actions, in any setting and at any scale." (kozyr.com, opened 27 Oct 2026).
• Why D.World recommends her: she starts every data project from the decision, which is exactly how this lesson scopes a capstone.
• Honest note: her page also contains text addressed to AI tools; D.World quotes only her self-description and definition.
• Try this: for your capstone, write the decision in one sentence before you write anything about data or models.

17. Glossary

Review: charter (U17) · project playbook (L90) · provenance (L33).

18. Reflection

1. In the transcript, which sentence changed the project most, and why?
2. Which constraint of your own capstone are you least sure about, and who could confirm it?
3. What would make you stop and re-scope your capstone halfway through?

19. Next Step

Next: L102 — Executive Summaries & Decision Stories. You compare the options on September and write the one page the decision maker will read.

20. Assessment Evidence

References

1. Amazon Web Services. AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (AWS-DS). Supports: "Begin by defining business problems that can be solved with AI/ML, and have a clear idea of the business value to be gained."; "Some business problems don't need ML and simple business rules can do a much better job."
2. UCI Machine Learning Repository. Dataset pages for the capstone register (Online Shoppers Purchasing Intention, DOI 10.24432/C5F88Q; Bike Sharing, DOI 10.24432/C5W894; Default of Credit Card Clients, DOI 10.24432/C55S3H). Supports: licences (CC BY 4.0), sizes, citations.
3. Kozyrkov, C. Home page. https://www.kozyr.com/ (KOZYR). Supports: role model (quoted).
4. D.World Stage 5 Detailed Lesson Map v1.0 (L101 row); decisions D08 (capstone data) and D09 (defence). Internal.

L101 — تحديد نطاق مشروع التخرج: متطلبات أصحاب المصلحة ومقترح المشروع

ملف المتعلّم. الإجابات والحلول النموذجية في ملف منفصل خاص بالمدرّس فقط. الإصدار: U24 Production v1 · تاريخ المحتوى: 27 أكتوبر 2026. تقديرات الوقت تقديرات للتخطيط إلى أن يختبرها المتعلّمون. الكود في هذا الدرس شُغّل باستخدام Python 3.13.16 وpandas 3.0.5 (مسجّل في تقرير اختبار الكود الداخلي في D.World)؛ وPython 3.13 هو الإصدار المعتمد في المقرر. ولم يُشغَّل باستخدام Python 3.14 ولا داخل JupyterLab.

كل الأنشطة التجارية والأشخاص في الحالة التجريبية خياليون، وكل بياناتها مصطنعة.

1. بطاقة الدرس

تفصيل الوقت (تقدير للتخطيط):

• المفهوم والمثال المحلول: 60 دقيقة.
• التدريب الموجَّه: 30 دقيقة.
• التدريب المستقل: 35 دقيقة.
• اختبار الفهم: 10 دقائق.
• الذكاء الاصطناعي: 5 دقائق (اختياري).
• مهمة العمل والتحدي القصير: 10 دقائق.

ما تحتاج إليه: Python مع pandas؛ ومجلد practice_files (L101_starter.ipynb؛ وu24_data/stakeholder_interview.md وu24_data/cedar_deliveries_aug_sep_2026.csv وu24_data/data_README.md)؛ ومجلد U24_CAPSTONE/ (الموجز، وسجل مشاريع التخرج، وقائمة فحص الحقوق والخصوصية، وقالب المقترح).

2. هدف التعلّم

في نهاية هذا الدرس، ستكون قادرًا على أن:

• تستخلص متطلبات أصحاب المصلحة وتسجّلها، فاصلًا بين الطلبات والاحتياجات والقيود؛
• تختار مجموعة بيانات وتفحصها من حيث الحقوق، والخصوصية، والحجم، والملاءمة، وتختبر الجدوى في دفتر؛
• تكتب مقترحًا لمشروع التخرج فيه قرار، ومقياس للنجاح، وأدلة على الجدوى، ومراحل، ومخاطر.

الهدف المعتمد من D.World (بنصّه): Elicit and record stakeholder requirements, choose and check a dataset, and write a capstone proposal with a decision, success metric, feasibility evidence, milestones and risks.

(وبالعربية: استخلص متطلبات أصحاب المصلحة وسجّلها، واختر مجموعة بيانات وافحصها، واكتب مقترحًا لمشروع التخرج فيه قرار، ومقياس للنجاح، وأدلة على الجدوى، ومراحل، ومخاطر.)

3. لماذا يهمّك هذا؟

مشروع التخرج (Capstone) هو المشروع الذي سيحكم عليك به المراجع أو صاحب العمل أو العميل. ومعظم المشاريع المخيِّبة للآمال لا تفشل في بناء النماذج: بل تجيب عن سؤال لم يحتج أحد إلى إجابته، ببيانات لم يكن مسموحًا باستخدامها، وفي موعد كان قد فات بالفعل. في U17 حوّلت طلبًا معطى إلى ميثاق مشروع. وهنا تعود خطوة إلى الوراء: تكتشف ما هو الطلب فعلًا، بالسؤال.

عادة ما يبدأ أصحاب المصلحة بحلّ ("I want an AI model"، أي: "أريد نموذج ذكاء اصطناعي")، لا بالقرار الذي يواجهونه. ومهمتك أن تصل إلى القرار، والأشخاص الذين يتأثرون به، ومقياس النجاح، والقيود التي لم يذكرها أحد في البداية، والموعد النهائي، وأن تتحقق، قبل أن تَعِد بأي شيء، من أن البيانات تستطيع أن تدعمه وأن من حقك استخدامها.

المبدأ الأساسي: ابدأ من القرار، لا من الطلب؛ واكتب المتطلبات في صورة قرار، ومستخدم، ومقياس، وحد، وموعد نهائي؛ وافحص حقوق البيانات وملاءمتها قبل أن تَعِد؛ واحصل على الموافقة على المقترح قبل أن تبني.

4. المفهوم

ستحدد نطاق مشروع تخرج تجريبي (dry-run capstone) على حالة خيالية، حتى يمكن التحقق من كل خطوة؛ أما مشروع تخرجك أنت (القسم 8) فيتبع الخطوات نفسها على مجموعة بيانات حقيقية من سجل مشاريع التخرج في D.World.

الجزء A — مقابلة صاحب المصلحة: الطلبات، والاحتياجات، والقيود

اقرأ نص المقابلة u24_data/stakeholder_interview.md مرة واحدة من أوله إلى آخره. ثم انظر كيف يبدأ:

from pathlib import Path

interview = Path("u24_data/stakeholder_interview.md").read_text(encoding="utf-8")
turns = [line for line in interview.splitlines() if line.startswith("**Nadia:**") or line.startswith("**Karim:**")]
print(len(turns), "turns by the stakeholders")
for line in turns[:3]:
    print(line[:110])

14 turns by the stakeholders
**Nadia:** Thanks for coming. I'll be direct: I want an AI model that predicts late deliveries. Everyone has o
**Nadia:** Honestly? The complaints are the problem. Customer service tells me late deliveries are most of the
**Nadia:** Two things, really. We can give a longer promised time when the customer books, or we can add drive

(ترجمة المخرجات: "14 turns by the stakeholders" = 14 مداخلة لأصحاب المصلحة. والسطر الأول لنادية: "شكرًا لحضورك. سأكون صريحة: أريد نموذج ذكاء اصطناعي يتنبأ بالتوصيلات المتأخرة…"؛ والثاني: "بصراحة؟ الشكاوى هي المشكلة. خدمة العملاء تقول لي إن التوصيلات المتأخرة هي معظم…"؛ والثالث: "شيئان في الحقيقة. نستطيع أن نعطي وقتًا موعودًا أطول عندما يحجز العميل، أو نضيف سائقين…". والأسطر مقطوعة عند 110 أحرف.)

الجملة الأولى طلب (request) لحلّ: "an AI model that predicts late deliveries" (أي: "نموذج ذكاء اصطناعي يتنبأ بالتوصيلات المتأخرة"). وبحلول المداخلة الثالثة يظهر الاحتياج (need): شكاوى أقل قبل موسم الأعياد. صنّف كل ما قيل في المقابلة إلى أربعة أنواع من العبارات:

ثلاث عادات أنجحت هذه المقابلة: سألت أميرة ما الذي سيتغير لو عُرفت الإجابة؛ وسألت من غيرهم يتأثر (فانضم التسويق بقيد يغيّر المشروع كله)؛ وسألت كيف يبدو الفشل. اكتب خريطة أصحاب المصلحة (stakeholder map) في سطر واحد لكل منهم: من يقرر (نادية)، ومن يستطيع الاعتراض (كريم، في طول الوقت الموعود)، ومن يستخدم النتيجة (خدمة العملاء، وصفحة الحجز)، ومن يتأثر (العملاء).

الجزء B — صياغة المتطلبات

المتطلب (requirement) الجيد يسمّي القرار، والمستخدم، والمقياس، وحد القبول (acceptance threshold)، والموعد النهائي، حتى يستطيع أي شخص أن يعرف لاحقًا هل تحقق أم لا:

R1. أوصِ بتغيير في قاعدة الوقت الموعود (القرار) تستطيع العمليات تطبيقه على صفحة الحجز وشرحه لخدمة العملاء (المستخدمون)، بحيث يكون معدل التأخير المسائي أقل من 5% ولا يزيد متوسط الوقت الموعود بأكثر من 3 دقائق على مستوى كل الطلبات (المقاييس والحدود)، مقدَّرًا على بيانات لم تُستخدم في تصميم التغيير، بحلول 15 نوفمبر 2026 (الموعد النهائي).

والمتطلبات تقول أيضًا ما هو غير مطلوب. هنا لا شيء يتطلب نموذج تعلّم آلة: فالنموذج خيار واحد، يُحكم عليه مقابل قاعدة بسيطة بالحدود نفسها. ودليل AWS عن علم البيانات يقولها بوضوح: "Some business problems don't need ML and simple business rules can do a much better job." (أي: "بعض مشكلات الأعمال لا تحتاج إلى تعلّم الآلة، والقواعد البسيطة يمكن أن تؤدي المهمة أفضل بكثير.") واكتب كل حد قبل أن تنظر إلى النتائج، حتى لا تستطيع تحريكه بعدها.

الجزء C — فحص البيانات: الحقوق، والخصوصية، والحجم، والملاءمة

قبل أن تَعِد بأي شيء، افحص مجموعة البيانات:

1. الحقوق: من يملكها، وما الترخيص أو الشروط التي تنطبق عليها، وما الإسناد (attribution) المطلوب. انسخها من صفحة المصدر، مع تاريخ قراءتك لها.
2. البيانات الشخصية: هل تحدد هوية أشخاص؟ إذا كان الأمر كذلك، فهي ليست مجموعة بيانات لمشروع تخرج، إلا إذا أُخفيت هويتها بشكل صحيح وكانت شروطها تسمح باستخدامك.
3. الحجم والملاءمة: صفوف كافية، والفترة الصحيحة، والأعمدة التي يحتاج إليها القرار.
4. الأصل (Provenance): بصمة (L33، L88) حتى يستخدم الجميع الملف نفسه.

اقرأ ملاحظات البيانات وتحقق من البصمة التي تذكرها:

import hashlib

notes = Path("u24_data/data_README.md").read_text(encoding="utf-8")
fp = hashlib.sha256(Path("u24_data/cedar_deliveries_aug_sep_2026.csv").read_bytes()).hexdigest()[:12]
print("fingerprint:", fp, "| stated in the notes:", fp in notes)
for line in notes.splitlines():
    if "Synthetic data" in line or "No personal data" in line:
        print(line[:150])

fingerprint: b62ff3952085 | stated in the notes: True
| `cedar_deliveries_aug_sep_2026.csv` | 2,400 | Delivery system export, 1 Aug – 30 Sep 2026, with the complaint flag from customer service | Synthetic
No personal data: order IDs are pseudonymous; no names, addresses or contact details.
**Attribution line (use it when you publish this file or results from it):** Synthetic data generated by D.World for learning; Cedar Lane is a fiction

(ترجمة المخرجات: "fingerprint … | stated in the notes: True" = البصمة … | مذكورة في الملاحظات: نعم. والسطر الثاني من جدول الملفات: 2,400 صف، تصدير من نظام التوصيل من 1 أغسطس إلى 30 سبتمبر 2026، مع علامة الشكوى من خدمة العملاء، مصطنعة. والثالث: "لا بيانات شخصية: أرقام الطلبات مستعارة؛ ولا أسماء ولا عناوين ولا بيانات اتصال." والرابع: "سطر الإسناد (استخدمه عندما تنشر هذا الملف أو نتائج منه): بيانات مصطنعة أنشأتها D.World للتعلّم؛ وCedar Lane خيالية…".)

والآن الحجم والملاءمة:

import pandas as pd

d = pd.read_csv("u24_data/cedar_deliveries_aug_sep_2026.csv")
print(d.shape, "|", d["order_date"].min(), "to", d["order_date"].max())
print("missing values:", int(d.isna().sum().sum()), "| duplicate order ids:", int(d["order_id"].duplicated().sum()))
print(d["slot"].value_counts().to_string())

(2400, 9) | 2026-08-01 to 2026-09-30
missing values: 0 | duplicate order ids: 0
slot
afternoon    906
morning      749
evening      745

(missing values = القيم الناقصة؛ duplicate order ids = أرقام طلبات مكررة؛ slot = فترة التوصيل: afternoon بعد الظهر، morning الصباح، evening المساء.)

البيانات تغطي القرار: الدقائق الموعودة والفعلية، والفترة والمنطقة (لتوجيه التغيير)، والشكاوى. لكنها لا تحتوي على أي معلومات عن إتمام الحجز، لذلك لا يمكن قياس قيد كريم (أثر الوقت الموعود الأطول على الطلبات) منها؛ ويجب أن يذكر المقترح ذلك ويخطط لطريقة قياسه.

بالنسبة لمشروع تخرجك أنت، يسرد سجل مشاريع التخرج في D.World (U24_CAPSTONE/CAPSTONE_REGISTER.md) مجموعات بيانات عامة فُحص ترخيصها (CC BY 4.0) وإسنادها على صفحاتها في UCI. وإذا اقترحت مجموعة بيانات خاصة بك، فيجب أولًا ملء قائمة فحص الحقوق والخصوصية الموجودة في المجلد نفسه والموافقة عليها.

الجزء D — دفتر الجدوى

فحص الجدوى (feasibility check) يجيب عن سؤال واحد: هل يمكن تحقيق المتطلب بهذه البيانات، قبل الموعد النهائي؟ وهو ليس التحليل نفسه، ويستخدم بيانات التصميم فقط: هنا شهر أغسطس. ويبقى سبتمبر دون أن يُلمس من أجل التقييم في L102. احسب نقطة البداية على أغسطس:

d["late"] = d["actual_minutes"] > d["promised_minutes"] + 5
aug = d[d["order_date"] < "2026-09-01"]
print(f"August orders: {len(aug)} | late rate: {aug['late'].mean():.3f}")
print((aug.groupby("slot")["late"].mean().round(3)).to_string())
print(f"complaint rate when late: {aug.loc[aug['late'], 'complaint'].mean():.3f} | when not late: {aug.loc[~aug['late'], 'complaint'].mean():.3f}")

August orders: 1221 | late rate: 0.093
slot
afternoon    0.067
evening      0.183
morning      0.042
complaint rate when late: 0.149 | when not late: 0.018

(August orders = طلبات أغسطس؛ late rate = معدل التأخير؛ complaint rate when late / when not late = معدل الشكاوى عند التأخير / عند عدم التأخير.)

في أغسطس، معدل التأخير المسائي 18.3%، أي أكثر من ثلاثة أضعاف هدف 5%، والتوصيلات المتأخرة تجلب شكاوى أكثر بكثير، إذن فالاحتياج حقيقي. فهل الهدف في المتناول تحت قيد الدقائق الثلاث؟ اختبر بعض الهوامش (buffers) البسيطة، على أغسطس فقط أيضًا:

evening = aug["slot"] == "evening"
for extra in (5, 8, 10):
    promised = aug["promised_minutes"] + extra * evening
    late = aug["actual_minutes"] > promised + 5
    print(f"evening +{extra:2d} min: evening late {late[evening].mean():.3f} | "
          f"average extra minutes over all orders {(extra * evening).mean():.2f}")

evening + 5 min: evening late 0.072 | average extra minutes over all orders 1.47
evening + 8 min: evening late 0.047 | average extra minutes over all orders 2.36
evening +10 min: evening late 0.022 | average extra minutes over all orders 2.95

(evening +N min = المساء + N دقائق؛ evening late = معدل التأخير المسائي؛ average extra minutes over all orders = متوسط الدقائق الإضافية على كل الطلبات.)

ممكن، لكن بالكاد: في أغسطس، هامش مسائي من 8 دقائق ينزل بمعدل التأخير المسائي إلى 4.7%، أي أقل من 5%، بمتوسط 2.36 دقيقة إضافية، ضمن حد كريم؛ و10 دقائق تعطي معدلًا أقل لكنها تستهلك الحد كله تقريبًا (2.95 دقيقة). وهذا دليل على الجدوى، لا نتيجة: فالخيارات النهائية تُقارن على سبتمبر، الذي لم ينظر إليه هذا الفحص أبدًا.

الجزء E — المقترح وبوابة الموافقة

مقترح مشروع التخرج (capstone proposal) يحوّل كل هذا إلى صفحة واحدة يستطيع المراجع أن يوافق عليها أو يعيدها (القالب: U24_CAPSTONE/templates/proposal_template.md):

بوابة الموافقة (approval gate) تعني: لا يبدأ أي تحليل قبل أن يوافق المراجع على المقترح. ومشروع التخرج الذي ليس له مقترح موافَق عليه لا يُقبل، مهما كانت نتائجه جيدة.

5. مثال محلول

نشاط خيالي، وبيانات مصطنعة. تحدد أميرة نطاق الحالة التجريبية.

الخطوة 1 — المقابلة: الطلب كان "an AI model" (نموذج ذكاء اصطناعي)؛ والاحتياج توصيلات متأخرة وشكاوى أقل قبل ديسمبر؛ والقيود: عدد سائقين ثابت، و≤ 3 دقائق إضافية في المتوسط، وقاعدة قابلة للشرح.

الخطوة 2 — المتطلب: معدل تأخير مسائي أقل من 5%، وزيادة في الوقت الموعود لا تتجاوز 3 دقائق في المتوسط، مقدَّرة على بيانات سبتمبر التي لم تُستخدم في التصميم، بحلول 15 نوفمبر.

الخطوة 3 — البيانات: 2,400 طلب، بلا قيم ناقصة ولا أرقام مكررة، مصطنعة مع إسناد D.World، والبصمة مؤكدة؛ وإتمام الحجز غير موجود في البيانات.

الخطوة 4 — الجدوى: معدل التأخير المسائي 18.3% في أغسطس؛ وهامش مسائي من 8 دقائق يصل إلى 4.7% في أغسطس بمتوسط 2.36 دقيقة إضافية.

الخطوة 5 — المقترح: صفحة واحدة فيها القرار، والمتطلبات، والبيانات، والمنهج، والجدوى، والمراحل، والمخاطر، والنطاق، أُرسلت للموافقة في 28 أكتوبر.

6. شرح بصري

 REQUEST ("an AI model")
     │  ask: what would you do differently?  who else?  what is failure?
     ▼
 NEED (decision) ──▶ REQUIREMENT: decision · user · metric · threshold · deadline   (written BEFORE results)
     │
     ├─▶ DATA CHECK: rights & attribution · personal data · size & fit · fingerprint
     ├─▶ FEASIBILITY: baseline numbers · can the threshold be reached? (design data only)
     ▼
 PROPOSAL (one page) ──▶ APPROVAL GATE ──▶ analysis starts

وصف الرسم: طلب صاحب المصلحة لنموذج ذكاء اصطناعي يقود، عبر أسئلة عمّا سيتغير، ومن غيرهم يتأثر، وكيف يبدو الفشل، إلى الاحتياج الحقيقي وراءه. ويصبح الاحتياج متطلبًا فيه قرار، ومستخدم، ومقياس، وحد، وموعد نهائي، يُكتب قبل النتائج. ويتبعه فحصان: فحص للبيانات (الحقوق والإسناد، والبيانات الشخصية، والحجم والملاءمة، والبصمة)؛ وفحص للجدوى بأرقام خط الأساس على بيانات التصميم فقط. وكلاهما يغذّي مقترحًا من صفحة واحدة، يجب أن يعبر بوابة الموافقة قبل أن يبدأ التحليل. (نصوص الرسم: REQUEST = الطلب؛ ask: what would you do differently? who else? what is failure? = اسأل: ماذا ستفعل بشكل مختلف؟ من غيرهم؟ ما الفشل؟؛ NEED (decision) = الاحتياج (القرار)؛ REQUIREMENT: decision · user · metric · threshold · deadline = المتطلب: القرار · المستخدم · المقياس · الحد · الموعد النهائي؛ written BEFORE results = يُكتب قبل النتائج؛ DATA CHECK: rights & attribution · personal data · size & fit · fingerprint = فحص البيانات: الحقوق والإسناد · البيانات الشخصية · الحجم والملاءمة · البصمة؛ FEASIBILITY: baseline numbers · can the threshold be reached? (design data only) = الجدوى: أرقام خط الأساس · هل يمكن بلوغ الحد؟ (بيانات التصميم فقط)؛ PROPOSAL (one page) = المقترح (صفحة واحدة)؛ APPROVAL GATE = بوابة الموافقة؛ analysis starts = يبدأ التحليل.)

7. تدريب موجَّه

في L101_starter.ipynb:

1. من نص المقابلة، اسرد كل قيد مع الجملة التي جاء منها. أي قيد لم تذكره نادية على الإطلاق؟
2. أعد كتابة R1 في صورة متطلبين منفصلين (معدل التأخير؛ وطول الوقت الموعود). لماذا قد يفضّل صاحب المصلحة فصلهما؟
3. افحص البيانات: الصفوف، والفترة، والقيم الناقصة، والتكرارات، والبصمة. وأضف فحصًا واحدًا من عندك (مثلًا: أن الدقائق الفعلية ليست سالبة أبدًا).
4. احسب معدل التأخير بحسب المنطقة على أغسطس. أي منطقة ستتركها قاعدة المساء وحده في أسوأ حال؟
5. كرّر فحص الهوامش على أغسطس لقاعدة "المساء أو المنطقة الشرقية + 8 دقائق". هل تحقق الحدين؟
6. املأ proposal_template.md للحالة التجريبية.

8. تدريب مستقل

مقترح مشروع تخرجك. اختر مجموعة بيانات من U24_CAPSTONE/CAPSTONE_REGISTER.md (أو اقترح مجموعة خاصة بك واملأ قائمة فحص الحقوق والخصوصية)، واختر موجز حالة أو قرارًا من عندك يناسب البيانات.

1. اكتب خطة مقابلة صاحب مصلحة قصيرة (من ستة إلى ثمانية أسئلة) للقرار؛ وإذا كان بإمكانك الوصول إلى شخص حقيقي يمكن أن يستخدم النتيجة، فقابله؛ وإلا فاكتب من سيكون أصحاب المصلحة، وما الافتراضات التي تضعها نيابة عنهم.
2. اكتب متطلبين أو ثلاثة في صياغة متطلبات فيها القرار، والمستخدم، والمقياس، والحد، والموعد النهائي.
3. ابنِ دفتر جدوى: الترخيص والإسناد منسوخان من صفحة مجموعة البيانات (مع التاريخ)، والبصمة، والصفوف، والفترة، والقيم الناقصة، وقيمة خط الأساس لمقياسك، وفحص سريع واحد لإمكانية بلوغ الحد، على بيانات التصميم فقط.
4. اكتب المقترح (القالب) وقدّمه للموافقة.

9. اختبار الفهم (Knowledge Check) — تحديد النطاق

Q1. يبدأ صاحب مصلحة بقوله: "أريد نموذج ذكاء اصطناعي يتنبأ بالتوصيلات المتأخرة." ما أفضل سؤال تالٍ؟

• A) "أي خوارزمية تعلّم آلة تريدني أن أستخدمها لذلك؟"
• B) "ماذا ستفعل بشكل مختلف لو عرفت أي التوصيلات ستتأخر؟"
• C) "ما الدقة التي يجب أن يبلغها النموذج قبل أن تقبله؟"
• D) "هل أبدأ بناء نموذج الآن وأريك النتائج الأسبوع القادم؟"

Q2. أي عبارة قيد وليست احتياجًا؟

• A) شكاوى أقل عن التوصيلات المتأخرة قبل ديسمبر
• B) تغيير في الوقت الموعود تستطيع العمليات استخدامه
• C) ما لا يزيد على 3 دقائق إضافية في المتوسط على كل الطلبات
• D) توصيلات متأخرة أقل في المساء مقارنة بالأشهر السابقة

Q3. أي صياغة متطلب هي الأكمل؟

• A) "ابنِ نموذجًا جيدًا للتوصيلات المتأخرة في أسرع وقت ممكن."
• B) "قلّل التوصيلات المتأخرة في المساء بقدر ملموس."
• C) "حلّل بيانات التوصيل لفهم أسباب التأخير."
• D) "غيّر قاعدة الوعد المسائي: تأخير مسائي < 5%، و≤ 3 دقائق إضافية، بحلول 15 نوفمبر."

Q4. لماذا تكتب حد القبول قبل أن ترى النتائج؟

• A) حتى لا يمكن تحريكه لاحقًا ليناسب النتائج
• B) لأن شكل القالب يتطلب الحدود
• C) حتى لا يحتاج صاحب المصلحة إلى قراءة النتائج
• D) لأن النتائج دائمًا تقصر عن الحدود التي توضع لاحقًا

Q5. صفحة مجموعة بيانات عامة لا تُظهر أي ترخيص. ماذا يترتب على ذلك لمشروع تخرجك؟

• A) يمكن استخدامها بحرية، لأنه يمكن تنزيلها علنًا من الويب
• B) يمكن استخدامها إذا ذكرت اسم المؤلف في ملف README
• C) لا يمكن استخدامها حتى تتضح الحقوق؛ اختر غيرها أو اسأل
• D) يمكن استخدامها في التحليل، لكن لا تُعرض في أي من رسومك

Q6. في فحص الجدوى، لماذا تختبر الهوامش على أغسطس فقط؟

• A) لأن طلبات أغسطس أكثر من سبتمبر، فنتائجه أدق
• B) لأن سبتمبر يبقى دون أن يُلمس من أجل تقييم الخيارات النهائية
• C) لأن بيانات توصيلات سبتمبر لم ينظّفها أحد بعد
• D) لأن الهوامش لا تنطبق إلا على أشهر الصيف، حين يكون المساء أكثر ازدحامًا

Q7. قيد التسويق يخص إتمام الحجز، وهو غير موجود في البيانات. ماذا يجب أن يفعل المقترح؟

• A) يتجاهل القيد، لأن البيانات لا يمكن استخدامها لقياسه
• B) يفترض أن إتمام الحجز لا يتغير ولا يقول شيئًا عنه
• C) يذكر الفجوة ويخطط لطريقة قياسها عند تجربة التغيير
• D) يطلب من التسويق التخلي عن القيد حتى يمضي المشروع

Q8. ماذا تعني بوابة الموافقة؟

• A) يوافق المراجع على النتائج النهائية قبل نشرها
• B) يوافق صاحب المصلحة على كل رسم قبل أن يدخل التقرير
• C) يوافق مالك البيانات على الكود قبل تشغيله على بياناته
• D) لا يبدأ التحليل إلا بعد أن يوافق المراجع على المقترح

10. الذكاء الاصطناعي في التطبيق (اختياري، وفي حدود)

الهدف: أن تُعدّ أسئلة المقابلة بالذكاء الاصطناعي، وتحتفظ فقط بما يرتبط بالقرار.

1. اسأل:

"I will interview an operations lead who asked for a model that predicts late deliveries. Suggest 12 interview questions to understand the decision, constraints, success measures and deadline."

وبالعربية: "سأقابل قائدة عمليات طلبت نموذجًا يتنبأ بالتوصيلات المتأخرة. اقترح 12 سؤالًا للمقابلة لفهم القرار، والقيود، ومقاييس النجاح، والموعد النهائي."

2. احتفظ بالسؤال فقط إذا كانت إجابته قد تغيّر المتطلب، أو البيانات التي تحتاج إليها، أو المنهج. واحذف الباقي.
3. أضف أي سؤال فات الذكاء الاصطناعي (مثلًا: "من غيرهم يتأثر؟" أو "كيف سيبدو الفشل؟").

الحدود:

• استخدام الذكاء الاصطناعي اختياري.
• لا تلصق أبدًا ملاحظات مقابلات تحدد هوية أشخاص حقيقيين.
• الذكاء الاصطناعي لا يقرر ما يحتاج إليه صاحب المصلحة؛ إجابات صاحب المصلحة هي التي تقرر.

11. التحقق من مخرجات الذكاء الاصطناعي

1. الصلة: كل سؤال تحتفظ به مرتبط بالقرار، أو بقيد، أو بمقياس، أو بالموعد النهائي.
2. حقائق الترخيص: الترخيص والإسناد في المقترح منسوخان من صفحة مجموعة البيانات نفسها مع تاريخ الوصول، وليس أبدًا من ملخّص كتبه الذكاء الاصطناعي.
3. الأرقام: أرقام الجدوى تأتي من مخرجات دفترك.
4. السجل: دوّن في سجل استخدامك للذكاء الاصطناعي أي الأسئلة جاءت منه وأيها أضفتها أنت.

12. منظور الأعمال

معظم المشاريع الفاشلة تجيب عن سؤال لم يحتج أحد إلى إجابته. والحالة التجريبية توضح السبب: نموذج يتنبأ بالتوصيلات المتأخرة سهل البناء، لكن النشاط لا يستطيع إضافة سائقين، ولا يستطيع أن يَعِد بوقت أطول بكثير، ويجب أن يشرح كل تغيير للعملاء. أما المشروع المفيد فيغيّر قاعدة واحدة في صفحة الحجز، بحلول موعد محدد، ضمن حدود جاءت من صاحب مصلحة ثانٍ لم يكن في الاجتماع الأول. وتحديد النطاق هو المرحلة التي يوفّر فيها المحلل أكبر قدر من المال.

13. مهمة عمل — بريد تحديد النطاق

نشاط خيالي: Cedar Lane. اكتب البريد الإلكتروني (من 100 إلى 150 كلمة) الذي ترسله أميرة إلى نادية وكريم بعد المقابلة: القرار كما فهمته، والحدّان والموعد النهائي، وما لا تستطيع البيانات أن تُظهره، والتاريخ الذي تحتاج فيه إلى الموافقة على المقترح.

14. تحدٍّ قصير — حين يضيق القيد

نشاط خيالي، وبيانات مصطنعة. يقول كريم لاحقًا: "Actually, no more than 2 extra minutes on average." (أي: "في الحقيقة، ما لا يزيد على دقيقتين إضافيتين في المتوسط.") أعد تشغيل فحص أغسطس مع وضع هذا الحد في الاعتبار:

for extra in (6, 7, 8):
    promised = aug["promised_minutes"] + extra * evening
    late = aug["actual_minutes"] > promised + 5
    print(f"evening +{extra} min: evening late {late[evening].mean():.3f} | average extra {(extra * evening).mean():.2f}")

evening +6 min: evening late 0.058 | average extra 1.77
evening +7 min: evening late 0.056 | average extra 2.06
evening +8 min: evening late 0.047 | average extra 2.36

1. قبل أن تفتح المخرجات، توقّع: هل تستطيع قاعدة للمساء وحده أن تبلغ هدف 5% في حدود دقيقتين؟
2. ماذا تُظهر المخرجات؟
3. ما الخياران المتاحان لأميرة الآن، وماذا ستسأل أصحاب المصلحة؟
4. اكتب جملة واحدة لقائمة المخاطر في المقترح.

سلّم عملك قبل أن تتلقى الملاحظات. لا يوجد حل منشور هنا.

15. المصادر

مطلوب (حوالي 25 دقيقة):

• سجل مشاريع التخرج في D.World (U24_CAPSTONE/CAPSTONE_REGISTER.md): مجموعات البيانات الثلاث، وصفحاتها في UCI، وتراخيصها، وموجزات حالاتها. صفحات مجموعات البيانات في UCI (فُتحت في 27 أكتوبر 2026): Online Shoppers Purchasing Intention https://archive.ics.uci.edu/dataset/468/online+shoppers+purchasing+intention+dataset، وBike Sharing https://archive.ics.uci.edu/dataset/275/bike+sharing+dataset، وDefault of Credit Card Clients https://archive.ics.uci.edu/dataset/350/default+of+credit+card+clients.
• AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (فُتح في 27 أكتوبر 2026.)

16. شخصية تتابعها / قدوة

Cassie Kozyrkov.

• حقيقة مُتحقَّق منها: تصفها صفحتها الرئيسية بأنها "Decision Intelligence Pioneer" (رائدة ذكاء القرار) و"Google's First Chief Decision Scientist" (أول كبيرة علماء القرار في Google)، وتعرّف ذكاء القرار بأنه "The discipline of turning information into better actions, in any setting and at any scale." (أي: "علم تحويل المعلومات إلى أفعال أفضل، في أي سياق وبأي حجم.") (kozyr.com، فُتحت في 27 أكتوبر 2026).
• لماذا توصي بها D.World: تبدأ كل مشروع بيانات من القرار، وهذه بالضبط الطريقة التي يحدد بها هذا الدرس نطاق مشروع التخرج.
• ملاحظة صادقة: صفحتها تحتوي أيضًا على نص موجّه إلى أدوات الذكاء الاصطناعي؛ وD.World تقتبس فقط وصفها لنفسها وتعريفها.
• جرّب هذا: لمشروع تخرجك، اكتب القرار في جملة واحدة قبل أن تكتب أي شيء عن البيانات أو النماذج.

17. المصطلحات

للمراجعة: ميثاق المشروع (U17) · دليل تشغيل المشروع (L90) · أصل البيانات (L33).

18. تأمّل

1. في نص المقابلة، أي جملة غيّرت المشروع أكثر من غيرها، ولماذا؟
2. أي قيد في مشروع تخرجك أنت أقل يقينًا منه، ومن يستطيع أن يؤكده؟
3. ما الذي قد يجعلك تتوقف وتعيد تحديد نطاق مشروع تخرجك في منتصف الطريق؟

19. الخطوة التالية

التالي: L102 — الملخّصات التنفيذية وقصص القرار (Executive Summaries & Decision Stories). تقارن الخيارات على سبتمبر وتكتب الصفحة الواحدة التي سيقرؤها صاحب القرار.

20. أدلة التقييم

المراجع

1. Amazon Web Services. AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (AWS-DS). يدعم: "Begin by defining business problems that can be solved with AI/ML, and have a clear idea of the business value to be gained." (أي: "ابدأ بتحديد مشكلات الأعمال التي يمكن حلّها بالذكاء الاصطناعي وتعلّم الآلة، وكوّن فكرة واضحة عن القيمة التي ستعود على العمل.")؛ و"Some business problems don't need ML and simple business rules can do a much better job." (أي: "بعض مشكلات الأعمال لا تحتاج إلى تعلّم الآلة، والقواعد البسيطة يمكن أن تؤدي المهمة أفضل بكثير.")
2. UCI Machine Learning Repository. صفحات مجموعات البيانات في سجل مشاريع التخرج (Online Shoppers Purchasing Intention، DOI 10.24432/C5F88Q؛ وBike Sharing، DOI 10.24432/C5W894؛ وDefault of Credit Card Clients، DOI 10.24432/C55S3H). يدعم: التراخيص (CC BY 4.0)، والأحجام، والاستشهادات.
3. Kozyrkov, C. Home page. https://www.kozyr.com/ (KOZYR). يدعم: القدوة (اقتباس).
4. D.World Stage 5 Detailed Lesson Map v1.0 (صف L101)؛ والقراران D08 (بيانات مشروع التخرج) وD09 (الدفاع عن المشروع). وثيقة داخلية.