Minor fixes + Subsubsections deletion

sections/practice.tex

@@ -2,7 +2,6 @@
 
 \subsection{Основные характеристики разрабатываемого программного продукта}
 
-\subsubsection{Формулировка проблемы и постановка целей разработки}
 Несмотря на обилие существующих решений для сжатия данных, анализ современного open-source ландшафта, проведённый в отчёте Linux Foundation (Census III), выявляет системную проблему: многие критически важные проекты, включая базовые утилиты, десятилетиями поддерживаются силами 1-2 разработчиков, что создаёт риски для безопасности и устойчивости цифровой инфраструктуры \cite{linux_census3_2024}. Парадокс заключается в том, что при высокой общественной ценности такие проекты не имеют прозрачных экономических моделей, позволяющих оценить реальную стоимость их создания и поддержки.
 
 Таким образом, проблема заключается не в отсутствии функционального аналога, а в недостатке методик для экономического обоснования разработки и поддержки малых, но инфраструктурно значимых open-source проектов. Данная работа рассматривает создание нового консольного архиватора не как цель саму по себе, а как практический кейс для апробации такой методики.
@@ -16,7 +15,6 @@
 	\item Time-bound (Ограниченная по времени): Срок полной разработки MVP — 3 календарных месяца.
 \end{itemize}
 
-\subsubsection{Анализ целевой аудитории и сценариев использования}
 Разрабатываемый продукт позиционируется как учебно-демонстрационный, но его целевая аудитория отражает реальные сегменты потребителей подобных утилит:
 \begin{enumerate}
 	\item Студенты и начинающие разработчики: Для изучения основ алгоритмов сжатия, работы с файловыми системами и практики разработки на Си/C++.
@@ -24,7 +22,6 @@
 	\item Сообщество open-source: Как потенциальная основа для форка или экспериментальной площадки для тестирования новых модификаций алгоритмов сжатия.
 \end{enumerate}
 
-\subsubsection{Формирование требований к минимально жизнеспособному продукту (MVP)}
 Минимально жизнеспособная версия продукта (MVP) включает следующий функционал, структурированный по модулям:
 \begin{itemize}
 	\item Модуль ввода/вывода: Чтение и запись данных из файлов, передача данных через стандартные потоки (stdin/stdout).
@@ -34,14 +31,13 @@
 \end{itemize}
 Архитектура проекта сознательно упрощена по сравнению с промышленными аналогами (такими как `bzip2` или `xz`) и ориентирована на наглядность реализации и лёгкость оценки трудозатрат.
 
-\subsubsection{Верификация оценки трудозатрат на основе анализа исторических данных аналогов}
 Для обоснования реалистичности планируемых трудозатрат был проведён самостоятельный количественный анализ истории разработки трёх классических open-source архиваторов. Методология заключалась в сборе и обработке данных из публичных git-репозиториев с использованием скриптов на основе команд `git log` и `git diff` \cite{git_log_docs}.
 
 \begin{longtable}{|p{0.28\textwidth}|p{0.22\textwidth}|p{0.2\textwidth}|p{0.2\textwidth}|}
 	\caption{Результаты сравнительного анализа истории разработки open-source архиваторов (по данным git-репозиториев)} 
 	\label{tab:project_analysis_long} \\
 	\hline
-	Критерий & \texttt{bzip2} & \texttt{xz utils} & \texttt{zstd} \\ \hline
+	Критерий & bzip2 & xz utils & zstd \\ \hline
 	\endfirsthead
 	
 	\multicolumn{4}{c}{Продолжение таблицы \thetable{}} \\
@@ -61,9 +57,8 @@
 \vspace{5pt}
 \noindent {\footnotesize *Расчёт выполнен автором на основе агрегированной статистики git-репозиториев.}
 
-Анализ показал, что проект \texttt{bzip2}, являющийся полнофункциональным архиватором, был создан и длительно поддерживался силами, эквивалентными работе одного разработчика. Его итоговый объём кода ($\approx$ 16.6 тыс. строк) и история коммитов позволяют сделать вывод о реалистичности разработки аналогичного по масштабу, но более простого (использующего стандартный DEFLATE) продукта в сжатые сроки.
+Анализ показал, что проект bzip2, являющийся полнофункциональным архиватором, был создан и длительно поддерживался силами, эквивалентными работе одного разработчика. Его итоговый объём кода ($\approx$ 16.6 тыс. строк) и история коммитов позволяют сделать вывод о реалистичности разработки аналогичного по масштабу, но более простого (использующего стандартный DEFLATE) продукта в сжатые сроки.
 
-\subsubsection{Оценка трудозатрат и ресурсов для разработки}
 На основе проведённого сравнительного анализа, а также с учётом принципов декомпозиции работ по методологии, изложенной в \cite[с. 86--90]{polyansky_ekonomika_2017}, составлена детальная оценка трудозатрат. Для расчёта фонда оплаты труда (ФОТ) принята рыночная ставка разработчика средней квалификации (C-программист/инженер ПО) в размере 1 200 руб./час, что соответствует данным по региональному рынку труда на 2024--2025 гг.
 
 \begin{longtable}{|p{0.35\textwidth}|p{0.2\textwidth}|p{0.15\textwidth}|p{0.15\textwidth}|}
@@ -85,12 +80,11 @@
 	Программирование (реализация модулей) & 100 & 1 200 & 120 000 \\ \hline
 	Тестирование и отладка & 40 & 1 200 & 48 000 \\ \hline
 	Написание документации и подготовка релиза & 20 & 1 200 & 24 000 \\ \hline
-	Итого по ФОТ & 200 & {} & 240 000 \\ \hline
+	Итого по ФОТ & 200 & {} & 240 000 \\
 \end{longtable}
 
 Таким образом, общая оценка трудозатрат на создание MVP консольного архиватора составляет 200 человеко-часов, а фонд оплаты труда (ФОТ) — 240 000 рублей. Данная оценка является консервативной и опирается на анализ наиболее релевантного аналога (\texttt{bzip2}), что обеспечивает запас при планировании и соответствует принципам реалистичного прогнозирования в условиях малого open-source проекта.
 
-\subsubsection{Оценка трудоёмкости по модели COCOMO I}
 Для дополнительной верификации полученной оценки воспользуемся классической параметрической моделью COCOMO I (Constructive Cost Model). Базовая формула для органического типа проектов, к которому может быть отнесён разрабатываемый архиватор, имеет вид \cite[p.~87]{polyansky_ekonomika_2017}:
 \begin{equation}
 	PM = 2,4 \times (KSLOC)^{1,05} \times \prod_{i=1}^{n} EMF_i,
@@ -106,7 +100,6 @@ PM = 2,4 \times 5^{1,05} \times 0,90 \approx 2,4 \times 5,38 \times 0,90 = 11,6
 
 \subsection{Расчёт экономических показателей разработки программного продукта}
 
-\subsubsection{Расчёт капитальных затрат (CAPEX)}
 Капитальные затраты (CAPEX) включают все единовременные инвестиции, необходимые для создания программного продукта. Для проекта, использующего исключительно открытые инструменты, структура CAPEX существенно отличается от типичной коммерческой разработки.
 
 \begin{longtable}{|p{0.4\textwidth}|p{0.35\textwidth}|p{0.2\textwidth}|}
@@ -129,12 +122,11 @@ PM = 2,4 \times 5^{1,05} \times 0,90 \approx 2,4 \times 5,38 \times 0,90 = 11,6
 	Оборудование (амортизация) & Ноутбук разработчика (80 000 руб.), срок службы 3 года, период разработки 3 мес. (0.25 года). \newline Амортизация: \( \frac{80\,000}{3} \times 0.25 = 6\,667 \) & 6 667 \\ \hline
 	Накладные расходы & 15\% от ФОТ (аренда рабочего места дома, интернет, электричество) \newline \( 240\,000 \times 0.15 = 36\,000 \) & 36 000 \\ \hline
 	Резервный фонд & 10\% от суммы прямых затрат (ФОТ + Оборудование) на непредвиденные расходы \newline \( (240\,000 + 6\,667) \times 0.10 = 24\,667 \) & 24 667 \\ \hline
-	ИТОГО CAPEX &  & 307 334 \\ \hline
+	ИТОГО CAPEX &  & 307 334 \\
 \end{longtable}
 
 Таким образом, общий объём капитальных вложений, необходимых для запуска проекта, составляет 307 334 рубля. Критически важным отличием от коммерческого сценария является нулевая стоимость лицензионного ПО, что напрямую вытекает из философии открытого кода и является ключевым фактором снижения первоначального барьера для входа \cite{raymond_cathedral}.
 
-\subsubsection{Расчёт операционных затрат (OPEX)}
 Операционные затраты (OPEX) — это ежегодные расходы на поддержку и эксплуатацию работающего программного продукта после его релиза.
 
 \begin{table}[h!]
@@ -156,7 +148,6 @@ PM = 2,4 \times 5^{1,05} \times 0,90 \approx 2,4 \times 5,38 \times 0,90 = 11,6
 
 Основной статьёй OPEX является техническая поддержка. В модели open-source проекта \cite{raymond_cathedral} часть этой работы может выполняться сообществом, однако для гарантированного поддержания проекта в работоспособном состоянии в расчёт заложены минимальные затраты на частичную занятость разработчика.
 
-\subsubsection{Прогнозирование выручки от внедрения продукта}
 Для open-source проекта, распространяемого под лицензией GPL, традиционная модель монетизации через продажу лицензий неприменима. В качестве основной модели принята модель платной поддержки и консалтинга для корпоративных пользователей, желающих гарантировать работоспособность и безопасность утилиты в своей инфраструктуре. 
 
 Согласно исследованию Д. Рихле, для компаний, работающих по модели single-vendor commercial open source, типичная конверсия пользователей в платящих клиентов составляет от 0,5\% до 2\% \cite{riehle_single_vendor_2012}. Это значение значительно ниже использованного в первоначальном прогнозе, поэтому для получения более реалистичной картины целесообразно рассмотреть несколько сценариев.
@@ -195,7 +186,6 @@ PM = 2,4 \times 5^{1,05} \times 0,90 \approx 2,4 \times 5,38 \times 0,90 = 11,6
 
 Прогнозируемая годовая выручка в реалистичном сценарии составляет 37 500 рублей, что заметно ниже оптимистичной оценки в 125 000 руб. Данная цифра отражает реальную сложность монетизации нишевого open-source продукта, где лишь небольшая доля пользователей готова оплачивать поддержку \cite{linux_census3_2024}. В дальнейших расчётах будем опираться на реалистичный сценарий.
 
-\subsubsection{Расчёт прибыли и рентабельности}
 На основе прогноза выручки (реалистичный сценарий) и затрат формируется прогнозный отчёт о прибылях и убытках (Таблица \ref{tab:pnl}).
 
 \begin{table}[h!]
@@ -219,7 +209,6 @@ PM = 2,4 \times 5^{1,05} \times 0,90 \approx 2,4 \times 5,38 \times 0,90 = 11,6
 
 Как видно из расчётов, проект является убыточным при рассмотрении исключительно прямых финансовых потоков. Годовой убыток составляет 437 375 рублей. Рентабельность продаж (ROS) отрицательна. Данный результат является типичным для многих open-source проектов, ценность которых заключается не в прямой монетизации, а в создании общественного блага, построении репутации, портфолио разработчика и косвенных экономических эффектах \cite{eu_report}.
 
-\subsubsection{Адаптация методики для индивидуальной open-source разработки}
 Приведённый выше расчёт соответствует формальному «коммерческому» сценарию. Однако для индивидуального разработчика или малой команды энтузиастов экономическая модель кардинально меняется. Как отмечает Рихле в своём исследовании single-vendor open source, важным нематериальным активом становится так называемая «коммиттер-премия» — повышение рыночной стоимости разработчика благодаря статусу коммиттера в значимом проекте \cite{riehle_single_vendor_2012}. Ссылаясь на эмпирические данные Ханна и др., Рихле указывает, что разработчики, достигшие статуса коммиттера, могут рассчитывать на прирост заработной платы в размере 20–40\%.
 
 Количественная оценка нематериальных выгод может быть выполнена с использованием следующего подхода:
@@ -254,7 +243,6 @@ V_{reputation} = \Delta S \times T_{car} \times P_{comm},
 
 Таким образом, экономическая целесообразность индивидуальной open-source разработки оценивается не через призму прямых финансовых результатов, а через анализ долгосрочных нематериальных выгод и альтернативных издержек.
 
-\subsubsection{Выводы по подразделу 2.2}
 Расчёт экономических показателей разработки консольного архиватора с открытым исходным кодом показал:
 \begin{enumerate}
 	\item Структура затрат для open-source проекта радикально смещена: CAPEX минимизирован за счёт бесплатных инструментов, основную долю в нём составляет ФОТ.
@@ -266,7 +254,6 @@ V_{reputation} = \Delta S \times T_{car} \times P_{comm},
 
 \subsection{Анализ эффективности внедрения программного продукта}
 
-\subsubsection{Расчёт точки безубыточности (ТБУ)}
 Точка безубыточности определяет минимальный объём продаж, необходимый для покрытия операционных затрат. Для проекта с выручкой от платной поддержки она рассчитывается по формуле:
 
 \begin{equation}
@@ -292,7 +279,6 @@ V_{reputation} = \Delta S \times T_{car} \times P_{comm},
 
 Вывод 1: Для покрытия затрат проект должен заключать не менее 20 контрактов платной поддержки в год. При прогнозе в 1,5 контракта (реалистичный сценарий) проект заведомо убыточен в рамках данной модели.
 
-\subsubsection{Расчёт срока окупаемости и возврата на инвестиций (ROI)}
 Срок окупаемости (PP) и возврат на инвестиции (ROI) рассчитываются для капитальных затрат (CAPEX).
 
 \begin{table}[h!]
@@ -316,8 +302,6 @@ V_{reputation} = \Delta S \times T_{car} \times P_{comm},
 
 Вывод 2: С точки зрения классического финансового анализа, проект абсолютно неэффективен: CAPEX не окупается, на каждый вложенный рубль приходится 2,42 рубля убытка.
 
-\subsubsection{Критический анализ результатов и адаптация методики оценки для open-source}
-
 Полученные в предыдущих расчётах отрицательные показатели — убыток 437 тыс. руб. в год, отрицательная рентабельность инвестиций ( –242 \%), недостижимая точка безубыточности — на первый взгляд свидетельствуют о полной экономической несостоятельности проекта. Однако такой вывод был бы поспешным и методологически неверным. Как справедливо отмечается в отраслевых дискуссиях, попытки оценить open-source исключительно через прямые финансовые потоки заведомо ведут к отрицательным выводам, поскольку игнорируют принципиально иную природу ценности, создаваемой открытыми проектами \cite{habr_oss_value_2024}. Этот феномен получил название «парадокс open source»: высокая общественная полезность сочетается с низкой или отрицательной коммерческой рентабельностью, если измерять её традиционными показателями.
 
 Для понимания корней этого парадокса обратимся к работе Д. Рихле, посвящённой экономической мотивации участников open-source экосистемы \cite{riehle_economic_2007}. Рихле подчёркивает, что разные стейкхолдеры имеют принципиально различные интересы и, соответственно, по-разному извлекают выгоду из существования открытого ПО:
@@ -343,7 +327,7 @@ V_{reputation} = \Delta S \times T_{car} \times P_{comm},
 
 Ответ на этот вопрос необходимо формулировать в два этапа.
 
-\textbf{1. Можно ли получить деньги с open-source проекта?}
+1. Можно ли получить деньги с open-source проекта?
 
 Да, безусловно, можно, но не через прямую продажу лицензий на само ядро (в классическом понимании). Мировая практика выработала несколько устойчивых моделей монетизации, которые успешно применяются десятками компаний \cite{palark_monetization, wikipedia_business_models}:
 
@@ -359,7 +343,7 @@ V_{reputation} = \Delta S \times T_{car} \times P_{comm},
 
 Важно понимать, что эти модели не исключают друг друга. Многие успешные проекты комбинируют несколько подходов: например, предлагают бесплатную версию (Open Core), платную поддержку и облачный хостинг (SaaS). Это позволяет диверсифицировать доходы и охватить разные сегменты пользователей.
 
-\textbf{2. Как правильно рассчитать рентабельность open-source проекта?}
+2. Как правильно рассчитать рентабельность open-source проекта?
 
 Классический расчёт ROI, основанный на сопоставлении прямых денежных притоков и оттоков, в чистом виде неприменим, поскольку игнорирует ключевые нематериальные выгоды, ради которых, собственно, и затеваются многие открытые проекты. Необходима адаптированная методика, включающая следующие компоненты:
 
@@ -383,8 +367,6 @@ V_{reputation} = \Delta S \times T_{car} \times P_{comm},
 
 Таким образом, отрицательные цифры, полученные нами, — это не приговор, а сигнал о необходимости расширения модели оценки. Они показывают, что чисто сервисная модель поддержки в данном конкретном случае недостаточна, и проект требует либо комбинирования с другими подходами, либо должен рассматриваться как инвестиция в человеческий капитал и репутацию.
 
-\subsubsection{Сводные показатели и практические рекомендации}
-
 Для наглядности сведём основные количественные результаты и дадим их интерпретацию с учётом проведённого анализа.
 
 \begin{table}[h!]