Tool Selection & BBA vs. BCA Comparison
Session at a Glance
Matching analytical tools to research scenarios; BBA and BCA discipline-specific pipelines; how research traditions shape tool choices; intensive execution strategies
Building and executing a complete analysis pipeline for your capstone; BBA/BCA cross-disciplinary peer review; intensive data collection or artefact development
2 hrs Lecture + 12 hrs Lab-Intensive
Complete analysis pipeline + data collection progress checkpoint
Learning Objectives
By the end of this session, you will be able to:
- Match specific analytical tools to research scenarios by systematically evaluating tool requirements against your RQs, data type, analytical method, and reproducibility needs — not by defaulting to the most familiar tool
- Construct a complete, reproducible analysis pipeline for your capstone — from raw data import through data cleaning, assumption testing, primary analysis, and output generation — using syntax/scripts rather than point-and-click operations
- Compare BBA and BCA research traditions across key dimensions — types of RQs, dominant paradigms, data types, analytical approaches, and evaluation criteria — identifying where the disciplines converge and where they meaningfully differ
- Critique a peer's analysis pipeline from a different disciplinary perspective — a BBA student reviewing a BCA pipeline (and vice versa) — identifying assumptions, potential weaknesses, and opportunities for cross-disciplinary learning
- Execute an intensive data collection or artefact development sprint, applying project management techniques to make measurable progress on the most critical remaining capstone task
Session Planner
Suggested breakdown of the 4-hour contact session.
| Time | Segment | Activity | Mode |
|---|---|---|---|
| 0:00–0:10 | Opening | Recap Week 16 tools orientation; "Last week you saw the landscape. This week: matching the right tools to YOUR research, and building YOUR pipeline." | Whole class |
| 0:10–0:30 | Lecture 1 | Tool selection framework — 7 criteria for evaluating analytical tools. BBA pipelines: survey data → SPSS/R workflow; financial data → regression/diagnostic workflow. BCA pipelines: ML evaluation → Python scikit-learn workflow; system benchmarking → metrics + statistical comparison workflow. | Lecture |
| 0:30–0:55 | Lecture 2 | BBA vs. BCA research traditions — a systematic comparison: RQ types, dominant paradigms, data characteristics, analytical approaches, evaluation criteria, contribution types. Where the disciplines converge (shared methodological foundations), where they diverge (different knowledge claims), and what each can learn from the other. | Lecture |
| 0:55–1:10 | Activity | Tool matching: given 6 research scenarios (3 BBA, 3 BCA), select the optimal tool stack and justify. Exchange with a partner from the OTHER discipline — critique each other's choices. What would you do differently? | Pairs (cross-discipline) |
| 1:10–1:25 | Discussion | Cross-discipline pairs share insights: what surprised you about the other discipline's approach? What could your discipline learn? | Whole class |
| 1:25–1:40 | Break | — | — |
| 1:40–2:00 | Pipeline Demo | Live demonstration: build a complete analysis pipeline in R (BBA) and Python (BCA) side by side — same analytical steps, two different tools. Show the code, the output, the reproducibility. Emphasise the logic that transfers across tools. | Demo |
| 2:00–3:30 | Lab Work | Part A: Build your complete analysis pipeline; Part B: Cross-disciplinary peer pipeline review; Part C: Intensive data collection or artefact development sprint | Individual/Pairs |
| 3:30–3:50 | Pipeline Clinic | Open troubleshooting — students raise pipeline problems; facilitator and peers debug. Common issues: data import failures, package version conflicts, assumption violations requiring alternative approaches. | Whole class |
| 3:50–4:00 | Exit Ticket | Submit pipeline script + cross-disciplinary peer review feedback | Individual |
1. A Decision Framework for Selecting Analytical Tools
Week 16 introduced the research tools ecosystem. This week develops a systematic framework for choosing among those tools — not based on familiarity or peer pressure, but on a structured assessment of your research requirements against each tool's capabilities. The framework applies whether you are selecting a statistical package, a qualitative analysis platform, or a writing and version control environment.
For each candidate tool, evaluate it against seven criteria weighted by their importance to YOUR specific capstone. Rate each criterion on a 1–5 scale (1 = poor fit, 5 = excellent fit). Multiply by the weight (1–3) to get a weighted score. The tool with the highest total weighted score is the best analytical choice — NOT necessarily the one you already know best.
1.1 The Seven Selection Criteria
| # | Criterion | What to Ask | Example (BBA Survey Study) | Example (BCA ML Study) |
|---|---|---|---|---|
| 1 | Analytical Capability Weight: 3 (Critical) | Can the tool perform ALL the analyses specified in my methodology chapter? Are there analyses I need that it CANNOT do? | SPSS handles t-tests, ANOVA, regression, factor analysis — everything in the methodology. Score: 5. Python can also do all of these. Score: 5. | Python (scikit-learn) handles all planned ML evaluation metrics, cross-validation, and statistical comparisons. Score: 5. SPSS cannot do ML evaluation. Score: 1. |
| 2 | Reproducibility Weight: 3 (Critical) | Can my entire analysis be scripted and rerun from raw data with a single command? Is there an audit trail? | SPSS syntax: Yes (if you write syntax). SPSS GUI: No (point-and-click leaves no trail). R/Python: Yes (scripts are inherently reproducible). | Python scripts + Jupyter notebooks: Yes. Every step from data loading to final figure is documented in executable code. Score: 5. |
| 3 | Data Compatibility Weight: 2 (Important) | Can the tool read my data format natively? Will I need to convert, reshape, or export/import between tools? | SPSS reads .sav, .csv, Excel natively. Score: 5. R reads everything. Score: 5. | Python reads .csv, JSON, SQL databases, and specialised formats (HDF5, Parquet). Score: 5 for typical ML data formats. |
| 4 | Learning Investment Weight: 2 (Important) | Given my current skills, how much time will I need to invest to use this tool competently for my specific analyses? Is that investment justified? | SPSS: Low (already know it). Score: 5. R: Moderate (6–10 hours to learn tidyverse basics). Score: 3. Is R's superior reproducibility worth the learning time? | Python: Low (already know it). Score: 5. R: Moderate (different syntax paradigm). Score: 3. |
| 5 | Output Quality Weight: 2 (Important) | Does the tool produce publication-quality tables and figures? Will I need to manually format output for my dissertation? | SPSS output requires substantial manual formatting for APA. Score: 2. R (ggplot2 + apaTables): publication-quality by default. Score: 5. | Python (matplotlib/seaborn): high-quality, customisable. Score: 4. R (ggplot2): slightly more elegant defaults. Score: 5. |
| 6 | Community & Support Weight: 1 (Nice to have) | Can I get help when I'm stuck? Are there tutorials, forums, and local expertise available? | SPSS: extensive documentation, widely used in BBA programmes. Score: 5. R: enormous online community (StackOverflow, R-bloggers). Score: 5. | Python: largest ML community globally. Score: 5. R: strong statistics community. Score: 4. |
| 7 | Cost & Access Weight: 1 (Nice to have) | Do I have access through my institution? Will I still have access after graduation? | SPSS: institutional licence (access during capstone; uncertain after). Score: 3. R: free forever. Score: 5. | Python: free forever. Score: 5. SPSS: irrelevant (can't do the required analyses). Score: N/A. |
1.2 The Most Common Tool Selection Errors
| Error | What It Looks Like | Correct Approach |
|---|---|---|
| The Familiarity Trap | "I'll use SPSS because that's what we used in the statistics lab." — Selecting a tool solely because you know it, ignoring whether it is capable of your required analyses or produces reproducible output. | Start from your analytical requirements (criterion #1), not from your comfort zone. If SPSS meets all requirements, use it confidently — but write syntax, not point-and-click. If it doesn't, the learning investment in R or Python is justified. |
| The Shiny Object Fallacy | "Everyone in data science uses Python — I should too." — Selecting the most prestigious or popular tool without evaluating whether its capabilities match YOUR specific analytical needs. | A BBA student running t-tests, ANOVA, and regression does not need Python's ML ecosystem. SPSS with syntax or R with RMarkdown are equally valid. Choose for capability fit, not prestige. |
| The Single-Tool Dogma | "I've committed to R for everything." — Forcing all tasks through one tool when a combination would be more efficient or more reliable. | It is acceptable to use SPSS for data cleaning (familiar, efficient) and R for analysis and visualisation (reproducible, publication-quality). The key is documenting the transition — save intermediate data files and script all steps. |
| The GUI-Only Approach | Conducting all analysis through menus and dialogue boxes, with no record of steps taken, options selected, or cases excluded. | Every GUI-based tool (SPSS, JASP, jamovi) has a syntax/scripting mode. Use it. The "Paste" button in SPSS generates syntax for every menu operation. Save that syntax. It is your analysis audit trail. |
Tool selection is not about identity ("I'm an R person" / "I'm a Python person") or comfort ("I've always used SPSS"). It is a methodological decision with consequences for the rigour, reproducibility, and credibility of your findings. A tool that cannot perform your required analyses is not an option, regardless of how well you know it. A tool that leaves no audit trail undermines the trustworthiness of your results. The framework above makes these trade-offs explicit. Complete the decision matrix for your capstone — the numbers will tell you what to use, even if the answer is not what you expected.
2. BBA and BCA Analysis Pipelines — End-to-End Workflows
An analysis pipeline is the complete, scripted sequence of operations that transforms raw data into reported findings. Building your pipeline as a single, executable script (or a set of modular scripts) ensures that every analytical decision is documented and every result is reproducible. Below are three canonical pipeline templates, each mapped to a common capstone research design.
2.1 BBA Pipeline 1 — Survey-Based Correlational/Regression Study
| Step | Operation | SPSS Syntax / R Code Fragment | Output |
|---|---|---|---|
| 1 | Import & Screen | R: df <- read.csv("data.csv"); summary(df); boxplot(df)SPSS: GET FILE='data.sav'. FREQUENCIES VARIABLES=ALL. EXAMINE VARIABLES=ALL /PLOT BOXPLOT. | N, missing %, min/max for all variables; box plots |
| 2 | Reverse Code & Compute Scales | R: df <- df %>% mutate(sat3_r = 6 - sat3, satisfaction = rowMeans(select(., sat1:sat5)))SPSS: RECODE sat3 (1=5)(2=4)(3=3)(4=2)(5=1). COMPUTE satisfaction = MEAN(sat1, sat2, sat3_r, sat4, sat5). | Scale totals for each construct |
| 3 | Reliability | R: psych::alpha(df[, c("sat1","sat2","sat3_r","sat4","sat5")])SPSS: RELIABILITY /VARIABLES=sat1 sat2 sat3_r sat4 sat5 /SCALE('Satisfaction') ALL /MODEL=ALPHA. | Cronbach's α for each scale (target: ≥ .70) |
| 4 | Descriptives & Correlations | R: df %>% select(sat, aut, wlb, perf) %>% psych::describe(); cor(.)SPSS: DESCRIPTIVES VARIABLES=sat aut wlb perf. CORRELATIONS /VARIABLES=sat aut wlb perf. | M, SD, correlation matrix |
| 5 | Regression | R: model <- lm(sat ~ aut + wlb + tenure, data = df); summary(model)SPSS: REGRESSION /DEPENDENT sat /METHOD=ENTER aut wlb tenure /STATISTICS COEFF CI R ANOVA COLLIN TOL. | R², F-test, b, β, t, p, VIF, CI for all predictors |
| 6 | Diagnostics | R: plot(model); car::durbinWatsonTest(model); car::vif(model)SPSS: Check output from /STATISTICS COLLIN TOL; request Durbin-Watson; request residual plots | Residual plots, Durbin-Watson, VIF, Cook's distance |
2.2 BCA Pipeline 1 — ML Model Evaluation
| Step | Operation | Python Code Fragment | Output |
|---|---|---|---|
| 1 | Load & Explore | df = pd.read_csv("data.csv"); print(df.info(), df.describe(), df['label'].value_counts(normalize=True)) | Data types, missing values, class distribution |
| 2 | Preprocess | X_train, X_test, y_train, y_test = train_test_split(X, y, stratify=y, test_size=0.2); vectorizer = TfidfVectorizer(); X_train_vec = vectorizer.fit_transform(X_train) | Train/test split (stratified), transformed features |
| 3 | Cross-Validate | cv = StratifiedKFold(n_splits=10, shuffle=True); scores = cross_val_score(model, X_train_vec, y_train, cv=cv, scoring='f1_macro') | Mean and SD of F1 across 10 folds |
| 4 | Train & Predict | model.fit(X_train_vec, y_train); y_pred = model.predict(X_test_vec) | Trained model, predictions on test set |
| 5 | Evaluate | print(classification_report(y_test, y_pred)); print(confusion_matrix(y_test, y_pred)); fpr, tpr, _ = roc_curve(y_test, y_score); auc = roc_auc_score(y_test, y_score) | Precision, recall, F1 per class; confusion matrix; ROC-AUC |
| 6 | Compare Models | Repeat Steps 3–5 for each model. For statistical comparison: from statsmodels.stats.contingency_tables import mcnemar; print(mcnemar(contingency_table)) | McNemar's test result; model comparison table |
2.3 Universal Pipeline — Qualitative Thematic Analysis
| Step | Operation | Tool/Procedure | Output |
|---|---|---|---|
| 1 | Familiarise | Read each transcript twice. Make margin notes. Record initial impressions in a research journal. | Familiarisation notes; research journal entries |
| 2 | Code | NVivo/Taguette: create nodes/codes. Code each transcript systematically. Maintain a codebook with definitions. | Coded transcripts; codebook (exportable from CAQDAS) |
| 3 | Cluster Codes → Candidate Themes | Export code list. On paper/digital canvas: group codes into clusters. For each cluster, articulate the central organising concept. | Candidate themes with constituent codes; draft thematic map |
| 4 | Review & Refine Themes | Re-read coded data for each theme. Check internal coherence. Review entire dataset: do themes capture the data? Revise, merge, split, discard. | Refined thematic map; theme definitions |
| 5 | Write Thematic Narrative | For each theme: write theme introduction, present evidence (quotes), provide analytic commentary. Connect to RQs. | Findings chapter draft, organised by theme |
3. BBA vs. BCA Research Traditions — Convergence and Divergence
The SEC701 course deliberately brings BBA and BCA students together within a shared research methodology framework. The foundational principles — paradigms, problem formulation, literature review, ethics, sampling, analysis logic — are common to both disciplines. But the expression of those principles differs. Understanding what is shared and what is distinct is essential for cross-disciplinary literacy and for positioning your own research within its disciplinary tradition.
3.1 A Systematic Comparison
| Dimension | BBA (Management/Business Research) | BCA (Computing/IT Research) | Convergence / Divergence |
|---|---|---|---|
| Dominant RQ Types | "What is the relationship between X and Y?" "What factors influence Z?" "How do people experience W?" — Emphasis on understanding and explaining human and organisational phenomena | "Can we build X to solve Y?" "How does algorithm A perform compared to B on task Z?" — Emphasis on creating and evaluating technical artefacts and systems | Divergent question types but shared requirement for specificity, researchability, and gap-groundedness |
| Dominant Paradigms | Post-positivist (surveys, experiments), Interpretivist (qualitative interviews, phenomenology), Pragmatist (mixed methods) | Post-positivist (experiments, benchmarks), Design Science Research (artefact creation and evaluation), Pragmatist (mixed methods) | Convergent: both use post-positivist and pragmatist paradigms. BBA uses interpretivism more; BCA uses DSR uniquely. |
| Typical Data | Survey responses (Likert scales), interview transcripts, financial/economic secondary data, organisational documents | Model outputs (predictions, classifications), performance metrics (accuracy, F1, time), system logs, code repositories, benchmark datasets | Divergent data types requiring different analytical tools, but shared principles of systematic collection and documentation |
| Primary Analytical Methods | Descriptive and inferential statistics (t-tests, ANOVA, correlation, regression, factor analysis); thematic analysis; content analysis | ML evaluation metrics (precision, recall, F1, ROC-AUC); statistical comparison of model performance; error analysis; complexity analysis | Different specific techniques; shared underlying logic of systematic comparison and inference from data |
| Quality Criteria | Validity (internal, external, construct, statistical conclusion); reliability (Cronbach's α); trustworthiness (credibility, transferability, dependability, confirmability) | Predictive performance (accuracy, F1, AUC); generalisation (cross-validation, benchmark testing); efficiency (time, memory); reproducibility (open code and data) | Different operationalisations of quality, but shared commitment to rigorous, evidence-based knowledge claims |
| Typical Contribution | Empirical evidence about relationships, experiences, or processes; extension or refinement of theory; context-specific knowledge about Indian business phenomena | A designed artefact (model, method, system); evidence about the artefact's effectiveness; design knowledge that informs future artefact development | Fundamentally different contribution types — explanatory vs. design-oriented — but both must demonstrate significance and novelty |
3.2 What BBA and BCA Students Can Learn from Each Other
- Reproducibility as default: BCA projects routinely version-control code and data. BBA projects often rely on point-and-click analysis with no audit trail. Scripting your analysis and using version control transforms the trustworthiness of your work.
- Systematic evaluation frameworks: BCA's ML evaluation tradition — with its clearly defined metrics, cross-validation protocols, and baseline comparisons — offers a model of systematic, multi-criteria evaluation that BBA research can adopt.
- Open science practices: Sharing code, data, and materials on GitHub/OSF is standard in computing research. These practices are increasingly expected in management research as well — adopting them early builds a professional habit.
- Human-centred research design: BBA's emphasis on understanding human experience — through interviews, surveys, and qualitative analysis — provides methods for studying how people actually use and experience technology, not just how well the technology performs.
- Theoretical grounding: BBA research routinely engages with theory from psychology, sociology, and economics to explain why observed patterns exist. BCA research can strengthen its contributions by connecting technical findings to human and organisational theory.
- Ethical reasoning beyond compliance: BBA's engagement with research ethics — informed consent, power dynamics, vulnerable populations — offers frameworks that complement the ACM Code of Ethics and address the human dimensions of computing research that algorithmic fairness alone does not capture.
Management research increasingly involves computational methods (text mining of annual reports, ML analysis of consumer behaviour, network analysis of organisational communication). Computing research increasingly involves human and organisational factors (UX research, technology adoption studies, socio-technical system design). A BBA student who can script an analysis and version-control their work, and a BCA student who can interview users and analyse their experiences thematically, possess skills that are valuable in both disciplines and highly marketable in industry. Your capstone is an opportunity to develop cross-disciplinary literacy — not despite the BBA/BCA distinction, but because the SEC701 structure makes that literacy accessible.
4. Intensive Execution — Making Measurable Progress
By Week 17, the capstone timeline is tightening. Data collection should be substantially complete; analysis should be well underway. This section provides strategies for the focused execution sprint — making measurable progress on the most critical remaining task, whether that is completing data collection, finishing analysis, or developing your artefact.
4.1 The Critical Path Method for Capstone Completion
| Task Category | Status Check | If Behind Schedule | If On/ Ahead of Schedule |
|---|---|---|---|
| Data Collection | What % of your target sample/experiments/interviews is complete? Is the collected data of sufficient quality? | Identify the bottleneck. Is it access (need gatekeeper approval?), recruitment (need to expand channels?), or response rate (need to improve incentives/reminders?). Take ONE concrete action TODAY. | Close data collection cleanly — don't keep collecting "just a few more." Declare the dataset closed, document its characteristics, and move to analysis. |
| Data Preparation | Is your raw data in a clean, documented, analysis-ready format? Are all transformations scripted? | Dedicate one full lab day to data cleaning. Write cleaning scripts. Document every exclusion, transformation, and imputation decision. This is tedious but essential. | Ensure your cleaning scripts run from scratch on the raw data. Test this: delete all processed files and regenerate them. If it doesn't work, fix it now before you forget the steps. |
| Analysis | What % of your planned analyses are complete? For incomplete analyses: are they blocked by data, by skills, or by tools? | Prioritise the analyses that answer your PRIMARY RQs. Secondary/supplementary analyses can be deprioritised. Run what you can now; flag what needs statistical consultation. | Begin writing the results chapter. Writing reveals gaps in analysis — things you thought you knew but cannot articulate, findings you need to double-check. Write while analysing; don't wait for analysis to be "finished." |
| Artefact Development (BCA/DSR) | Is your artefact functional? Is it ready for evaluation? Have you documented your design decisions? | Focus on getting a working, evaluable version. Perfection is the enemy of completion. A working artefact evaluated systematically is better than a perfect artefact never evaluated. | Begin systematic evaluation. Run your evaluation protocol — CV, baselines, metrics. Document results as you go. Don't wait for "all experiments to finish" before writing. |
4.2 The Pomodoro-for-Capstone Method
Capstone work is cognitively demanding and psychologically daunting. Breaking it into focused, time-boxed sessions prevents paralysis and builds momentum:
- Define ONE concrete deliverable for this lab session — not "work on analysis" but "run the regression for RQ2 and write the results paragraph."
- Work in 50-minute focused blocks with 10-minute breaks. No email, no social media, no phone. One task, one focus.
- After each block, record what you accomplished in one sentence. This builds visible evidence of progress — essential for motivation during the long middle phase of the capstone.
- When stuck for more than 20 minutes, escalate: ask a peer, consult documentation, post on a forum, or flag for your supervisor. Do not spend hours stuck in silence.
Think Deeper — Cross Questions
Discuss in pairs — ideally cross-discipline (BBA + BCA).
Complete the tool selection decision matrix (Section 1.1) for your own capstone. What is the tool you SHOULD use based on the weighted scores? Is it the tool you ARE using? If there is a gap, what is the single most important reason you are not using the optimal tool — and is that reason defensible?
Exchange your analysis pipeline with a peer from the OTHER discipline. Review each other's pipelines. Identify: (a) one thing their discipline does that you could adopt to strengthen your own research, (b) one thing your discipline does that you think they should adopt, and (c) one assumption in their pipeline that they may not have recognised as an assumption.
A BBA student running regression in SPSS says: "I don't need to script my analysis — I know what I'm doing, and the output is right there." A BCA student training an ML model in a Jupyter notebook says: "My notebook IS my analysis — it's already reproducible." Critique both positions. What are the specific reproducibility risks in each approach? What minimum standard should ALL capstone analyses meet regardless of discipline?
Reflect on your capstone's critical path (Section 4.1). Identify the ONE task that, if not completed in the next two weeks, will put your entire capstone timeline at risk. What is your specific, concrete plan to complete it? What is your contingency plan if your primary approach fails?
Quick Check — Pipeline and Tool Diagnosis
Diagnose the primary problem with each scenario.
1. A BBA student runs their entire regression analysis through SPSS menus. They have no syntax file. Their supervisor asks them to re-run the analysis excluding 12 outlier cases. The student cannot remember exactly which menu options, settings, and case selections they used the first time.
2. A BCA student's Jupyter notebook runs from top to bottom and produces all results. However, cells were executed in a non-linear order during development. Running "Restart & Run All" produces different results than the saved output. The student submits the notebook with the original output and does not test "Restart & Run All."
3. A student evaluating two ML models reports: "Model A achieved F1 = 0.85, Model B achieved F1 = 0.83. Therefore Model A is superior." No statistical test, no cross-validation variance reported, no baseline comparison.
4. A BBA student doing thematic analysis says: "I don't need CAQDAS — I'll just highlight my transcripts and group the quotes manually." They have 18 interview transcripts averaging 12 pages each.
Knowledge Check — Interactive Quiz
Test your understanding of tool selection and disciplinary comparison.
Q1. According to the tool selection framework, which criterion should carry the HIGHEST weight when choosing an analytical tool?
Q2. What is the primary difference between BBA and BCA research contributions?
Q3. A Jupyter notebook that produces correct output when cells are run in order during development, but produces different (or error) output on "Restart & Run All," has what problem?
Q4. What is the "critical path" in capstone project management?
Q5. Which of the following is a valid cross-disciplinary insight that a BBA student might gain from reviewing a BCA student's analysis pipeline?
Lab Activity — Pipeline Construction & Cross-Disciplinary Review
Part A: Build Your Complete Analysis Pipeline (75 min)
- Using the pipeline templates in Section 2 as models, construct a single executable script or notebook that takes your raw data and produces your primary results. Include: data import, cleaning/screening, primary analysis, assumption checks, and output generation.
- Test your pipeline: delete all intermediate files and outputs. Run the pipeline from scratch. Does it reproduce your results exactly? If not, fix the pipeline until it does.
- Add comments to every section explaining WHAT each step does and WHY. Another researcher should be able to read your script and understand your analytical logic.
Part B: Cross-Disciplinary Peer Pipeline Review (45 min)
Pair with a student from the OTHER discipline. Exchange pipelines. Review using the structured protocol:
- Comprehensibility: Can you understand what each step does and why? Rate 1–5.
- Reproducibility: Could you run this pipeline on your machine? What would you need to install/configure? Are the dependencies documented?
- Completeness: Does the pipeline cover all steps from raw data to reported results? Are there gaps where manual intervention would be required?
- Cross-Disciplinary Insight: Identify one thing from this pipeline that you could adopt in your own discipline. Explain specifically how.
Part C: Intensive Execution Sprint (60 min)
Identify the single most critical remaining task on your capstone critical path. Work on it for 60 focused minutes using the Pomodoro-for-Capstone method (Section 4.2). Before starting, write: "By the end of this hour, I will have accomplished: [specific, verifiable deliverable]." After, record what you achieved. If you did not achieve it, identify what blocked you and what you need to unblock.
Exit Ticket
Submit with your pipeline script.
- Submit your analysis pipeline script/notebook. Does it run from scratch and reproduce your results?
- Complete the tool selection decision matrix (Section 1.1) for your capstone. What is your total weighted score for your current tool vs. the best alternative?
- From the cross-disciplinary peer review: What was the most valuable insight you gained from seeing how the other discipline approaches analysis?
- What is your critical path task — the one thing that, if delayed, jeopardises your timeline? What progress did you make on it today?
- On a scale of 1–10: How reproducible is your current analysis workflow? If below 8, what is the single biggest barrier?
Key Takeaways — Week 17
The tool selection framework forces an honest evaluation: is your chosen tool the best for your research, or just the most familiar? Analytical capability and reproducibility carry the highest weight because without them, all other criteria are irrelevant.
An analysis pipeline transforms your methodology chapter's analytical plan into executable, reproducible operations. Every step from raw data to reported results should be scripted. The pipeline IS the evidence that your analysis was conducted as described.
BBA and BCA research ask different questions, use different data, and produce different contributions. But both require systematic procedures, rigorous evaluation, and transparent reporting. Cross-disciplinary literacy makes you a better researcher in your own discipline.
By Week 17, time is the scarcest resource. Identify the critical path — the sequence of tasks that determines completion. If a critical task is delayed, everything is delayed. Focus relentlessly on unblocking the critical path. Everything else is secondary.
Facilitator Notes
Preparation Checklist
- Prepare the dual-pipeline demo (R for BBA, Python for BCA) carefully — both must execute the same analytical steps (import → screen → test → report) so that the transferable logic is visible across the syntax differences.
- Prepare 6 research scenario cards for the tool-matching activity: 3 BBA (survey study, financial secondary data, qualitative case study) and 3 BCA (ML classification, system benchmarking, UX study). Each should specify: RQs, data type, sample size, analytical requirements.
- Ensure the cross-disciplinary pairing works logistically. Ideally, pair BBA and BCA students for the activity and peer review. If the cohorts are unbalanced or on different schedules, prepare BBA and BCA "persona" cards with pipeline descriptions that students can review even without a live partner.
- Prepare the pipeline templates (Section 2) as downloadable script files with placeholder comments — students replace the placeholders with their own data and variable names rather than writing from scratch.
Common Student Difficulties
- Pipeline "works on my machine" syndrome: Students run their pipeline successfully and assume it is reproducible, but it depends on undocumented packages, specific file paths, or environment variables. The "delete everything and rerun" test catches this. Enforce it.
- Cross-disciplinary defensiveness: BBA students may feel their methods are being judged as "less rigorous" by BCA peers (because they don't script); BCA students may feel their work is being criticised as "not about people." Frame the cross-disciplinary exchange as mutual learning, not competition. Both traditions have strengths; both have blind spots.
- Critical path denial: Students whose data collection is significantly behind may avoid thinking about the critical path because it is anxiety-provoking. The 60-minute execution sprint (Part C) is designed to break this avoidance — one focused hour can produce surprising progress and rebuild momentum.
- Over-engineering the pipeline: Students spend the entire lab perfecting their pipeline structure (directory layout, function documentation, error handling) and run no actual analysis. The pipeline is a means to an end — the analysis results. Ship a working pipeline now; refine it later.
Pacing Tips
- The dual-pipeline demo (R + Python side by side) is the pedagogical centrepiece — it makes visible that the analytical LOGIC is the same across tools, even though the syntax differs. Allocate adequate time and test the demo thoroughly beforehand.
- The BBA vs. BCA comparison (Section 3) can spark productive discussion — or unproductive disciplinary stereotyping. Steer the conversation toward "what can we learn from each other" (Section 3.2) rather than "which discipline is more rigorous."
- Week 17 is a natural checkpoint: by the end of this week, every student should have a working analysis pipeline and a clear picture of their critical path. Flag students who have neither — they need individual intervention before Week 18.