A data science lifecycle describes how raw data moves from business problem to deployed model, while workflows and pipelines define how the work is organized and automated end to end.The CRISP‑DM framework is a widely used way to structure this lifecycle, and real datasets like the Titanic survival data or vehicle price data illustrate each phase concretely.

Data science lifecycle

The CRISP‑DM lifecycle has six main phases: business understanding, data understanding, data preparation, modeling, evaluation, and deployment.These phases are iterative rather than strictly linear, so projects often loop back from modeling or evaluation to earlier steps as new insights appear.

Another common view is the OSEMN lifecycle: Obtain, Scrub, Explore, Model, and iNterpret.Both CRISP‑DM and OSEMN emphasize that most effort goes into understanding and preparing data rather than just training models.

Workflow vs pipeline

A workflow is the logical sequence of tasks a team follows (for example: define KPI → collect data → clean → train → review → deploy).A pipeline is a more automated, usually code‑driven realization of this workflow, chaining steps such as preprocessing, feature engineering, model training, and evaluation so they can run repeatedly and reliably.

In modern practice, workflows are designed with both business and technical constraints in mind, and then implemented as pipelines that manage dependencies and ensure data flows smoothly from one stage to the next.This separation allows experimentation at the workflow level while keeping execution consistent and reproducible at the pipeline level.

Example lifecycle: Titanic dataset

A classic real dataset for end‑to‑end projects is the Titanic passenger survival dataset hosted on Kaggle.It contains information such as passenger class, sex, age, and fare, with a label indicating whether each passenger survived, making it suitable for a supervised classification pipeline.

Using CRISP‑DM with this dataset:

• Business understanding: Define the goal as predicting passenger survival given known attributes, analogous to predicting customer churn or loan default in real businesses.Success could be measured using metrics like accuracy or F1 score on unseen passengers.
• Data understanding: Load the CSV files from Kaggle, inspect columns, visualize distributions (for instance age distribution by survival), and check missing values in features like age and cabin. This step reveals data quality issues and signals which engineered features might be helpful, such as family size or ticket groupings.

Next:

• Data preparation: Handle missing ages (for example by imputing based on class and sex), encode categorical variables like sex and embarked port, and create features such as “family size” or “title” extracted from names.The prepared dataset is then split into training and validation subsets while keeping the target label (survived) separate.
• Modeling: Train baseline models such as logistic regression, decision trees, and random forests using the engineered features. Hyperparameter tuning (for example grid search for tree depth or number of estimators) refines model performance.

Finally:

• Evaluation: Compare models using cross‑validation and validation metrics, checking not only overall accuracy but also how well the model distinguishes survivors from non‑survivors.Feature importance analysis from tree‑based models highlights which attributes (for example sex, passenger class, and family size) drive predictions.
• Deployment: In the Kaggle competition context, deployment means generating predictions for a held‑out test set and submitting a CSV for scoring on a public leaderboard.In a real product, the same pipeline structure could be wrapped behind an API so new passenger‑like records receive live predictions.

Example lifecycle: Vehicle price prediction

A more business‑oriented example is predicting used car prices, using the “vehicle dataset from Cardekho” and its associated car price prediction project.This dataset contains details such as car brand, model year, fuel type, mileage, and selling price, making it a typical regression problem for pricing or recommendation systems.

The lifecycle plays out as:

• Business understanding: The objective is to estimate a fair selling price for a car, helping dealers or marketplaces optimize pricing and improve user trust. Success might be defined by low mean absolute error on historical sales and improved conversion rates when integrated into a platform.
• Data understanding and preparation: Analysts explore the distribution of prices across brands and model years, detect outliers, and handle missing or inconsistent entries.Data preparation includes encoding fuel type and transmission, deriving car age from registration year, and normalizing numerical features such as mileage and engine size.

Then:

• Modeling and evaluation: Several regression algorithms (for example linear regression, random forest, or gradient boosting) can be trained to predict price from features.Models are evaluated with regression metrics such as mean squared error and R² on validation sets to choose the best trade‑off between bias and variance.
• Deployment and monitoring: A selected model can be deployed as a web service that powers a “suggested price” widget on a listing page. Ongoing monitoring checks whether prediction errors drift over time as market conditions or car portfolios change, prompting retraining when needed.

From workflow to production pipeline

To operationalize these projects, teams define pipelines that automate data ingestion, transformation, training, and deployment. For example, a Python pipeline using libraries such as scikit‑learn might encapsulate preprocessing steps (like imputation and encoding) and model training in a single object, ensuring any new data is processed identically to training data.

Beyond modeling code, a full data science pipeline integrates with storage and orchestration layers, sending ingested data through ETL or ELT processes into a data lake or warehouse before feeding models. Production pipelines typically include scheduled retraining jobs, automated evaluation against benchmarks, and deployment steps that update serving endpoints or batch scoring outputs with minimal manual intervention.