Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Чтобы узнать о концепции управления проектом, см. « Расползание объема» .

Особенность ползучесть является чрезмерным постоянным расширением или добавление новых функций в продукте, [1] , особенно в компьютерных программах , видеоигры и потребительской и бизнес электронике . Эти дополнительные функции выходят за рамки основных функций продукта и могут привести к раздуванию программного обеспечения и чрезмерному усложнению, а не к простому дизайну.

Причины [ править ]

Наиболее частая причина расползания функций - желание предоставить потребителю более полезный или желаемый продукт, чтобы увеличить продажи или распространение. Однако, как только продукт достигает точки, в которой он делает все, для чего он предназначен, производителю остается выбор между добавлением функций, которые некоторые пользователи могут посчитать ненужными (иногда в ущерб эффективности), и использованием старой версии. (ценой предполагаемого отсутствия улучшений).

Другой важной причиной расползания функций может быть компромисс со стороны комитета, который решает реализовать несколько разных точек зрения или вариантов использования в одном и том же продукте. Затем, по мере добавления дополнительных функций для поддержки каждого подхода, может потребоваться наличие функций перекрестного преобразования между несколькими парадигмами, что еще больше усложняет общие функции.

Характеристики [ править ]

Характеристика ползучести один из наиболее распространенных источников затрат и график перерасход. [2] [ требуется проверка ] Таким образом, это подвергает опасности и даже может убить продукты и проекты.

Контроль [ править ]

Существует несколько методов управления расползанием функций, в том числе: строгие ограничения для допустимых функций, несколько вариантов и удаление лишних функций.

Разделение [ править ]

Соблазна появления новых функций в будущем можно в некоторой степени избежать, основывая первоначальный проект на сильных основах программного обеспечения, таких как логическое разделение функциональности и доступа к данным, например, используя подменю, которые могут быть доступны опытным пользователям, которые желают большей функциональности и большей детализации информации. . Его можно активно контролировать с помощью строгого управления изменениями и отсрочки внесения изменений на более поздние этапы реализации проекта. [3]

Варианты и варианты [ править ]

Еще один метод управления постепенным увеличением количества функций - поддерживать несколько вариантов продуктов, при этом функции ограничены и сокращены в более основных вариантах, например, в версиях Microsoft Windows . Для программных пользовательских интерфейсов могут использоваться режимы просмотра или режимы работы (например, базовый режим или экспертный режим), между которыми пользователи могут выбирать в соответствии со своими потребностями.

Как во многих графических пользовательских интерфейсах, так и в интерфейсах командной строки пользователи могут выбрать более высокий уровень детализации вручную. В последнем случае во многих программах командной строки при добавлении параметра -vили --verboseвручную отображается более подробная информация, которая может быть менее актуальной для минимальных пользователей, но полезной для опытных пользователей или для целей отладки и устранения неполадок.

Поскольку постоянно растущее, постоянно расширяющееся добавление новых функций может превышать доступные ресурсы, минимальная базовая «базовая» версия продукта может поддерживаться отдельно, чтобы обеспечить работу в небольших операционных средах. Используя « правило 80/20 », более простые варианты продукта могут удовлетворить потребности большинства (например, ~ 80%) пользователей, поэтому они не будут подвергаться сложности (или дополнительным расходам) функций, запрошенных продвинутые 20% пользователей. Дополнительные функции по-прежнему доступны, но являются необязательными и готовы к использованию теми, кто их запрашивает, но они не были реализованы в базовых версиях продуктов.

Модульность [ править ]

Еще одно решение проблемы расползания функций - модульность. Опытные пользователи , которым требуется больше функциональные возможности могут модифицировать необходимые функции путем загрузки программных модулей, плагин , надстройки (также известный как надстройки) и пользовательские темы , чтобы соответствовать их личным требованиям.

Обрезка [ править ]

В какой-то момент стоимость поддержки определенного подмножества функций может стать непомерно высокой, и можно будет использовать сокращение. В новой версии продукта можно просто опустить дополнительные функции, или, возможно, будет использован переходный период, когда старые функции будут объявлены устаревшими перед окончательным удалением из системы. Если существует несколько вариантов продуктов, некоторые из них могут быть выведены из употребления. Одним из основных примеров является Samsung Galaxy S6 , выпущенный в марте 2015 года, из которого были сокращены многие функции программного обеспечения / меню, а также некоторые аппаратные функции. Его «более функциональный» вариант еще не выпущен.

Последствия [ править ]

Расширение сферы применения [ править ]

Иногда неконтролируемое распространение функций может привести к выпуску продуктов, выходящих далеко за рамки того, что было задумано изначально; это известно как ползучесть прицела . Однако более частым последствием потери функции является задержка или аннулирование продукта, что может стать дороже, чем предполагалось изначально. [ необходима цитата ]

Задержки [ править ]

Часто программный проект с достаточно полным набором функций или проект с умеренным набором функций может выжить и даже преуспеть в течение многих итераций, но его последующий выпуск может испытывать значительные задержки после того, как будет принято решение переписать всю базу кода в дополнение к внедрение новых технологий. Например, Windows Vista от Microsoft планировалась как второстепенный выпуск между Windows XP и ее преемником под кодовым названием Windows «Blackcomb» , но после адаптации все большего и большего количества функций Blackcomb (многие из которых в конечном итоге были отменены), Vista стала основным выпуском. релиз, разработка которого длилась пять лет.

Похожая судьба постигла Netscape 6 , который изначально должен был называться Netscape 5 . Решение компании Netscape Communications в 1998 году об открытии исходного кода для своего браузера Netscape Navigator и пакета Communicator Internet (оба под кодовым названием Mozilla) вскоре сделало очевидным, что лежащий в основе код был слишком сложным и потребовал полного переписывания Mozilla, что способствовало созданию фреймворк Mozilla. Это вызвало значительные задержки, Netscape 5 был пропущен, и компания была куплена AOL. Последующий выпуск Netscape 6.00 в 2000 году был широко раскритикован как код альфа-уровня, и проект достиг стабильности в Netscape 6.1 в 2001 году, через три года после решения о переработке пакета Internet. К тому времени браузер Microsoft Internet Explorer уже давно затмил Netscape по доле использования, которая сократилась до однозначных цифр.

Даже после достижения стабильности и получения некоторых необходимых новых функций пакет приложений Mozilla с открытым исходным кодом (тогда называемый просто Mozilla), на котором AOL построил Netscape, считался « раздутым ». Всего через год группа разработчиков Mozilla решила отделить компонент браузера, который в конечном итоге стал Firefox .

Проект Double Fine Adventures на Kickstarter Broken Age - еще один пример того, как проект откладывается из-за расползания функций. Первоначально предполагалось, что дата выпуска игры - октябрь 2012 года, первая половина игры была выпущена в январе 2014 года, а вторая половина последовала за концом апреля 2015 года, и для завершения потребовалось два отдельных раунда финансирования. [4]

Пищевой креационизм [ править ]

Распространение функций в сочетании с короткими сроками часто приводит к «хакерскому решению» . Желаемое изменение может быть достаточно большим, чтобы оправдать переработку существующей основы проекта, но давление крайних сроков вместо этого требует, чтобы разработчики просто «заставили его работать» с менее элегантным подходом. Юмористический непроизвольная перестановка звуков «feeping creaturism» был придуман , чтобы подчеркнуть нелюбовь разработчика этой ситуации, [5] олицетворяющий сфера-закралась продукт как «уродливое существо писак ... рыскать во тьме», [6] и предвестником еще больше ползучести. [7] («Пить» - это жаргонный синоним «писк».) [8]

См. Также [ править ]

  • Ползучая элегантность
  • Проектный документ
  • Цифровое накопление
  • Emacs , текстовый редактор , расширенный для решения многих других задач.
  • Десятое правило Гринспана
  • Принцип KISS
  • Минимализм в вычислениях
  • Ползучесть миссии
  • Сверхинженерия
  • Ползучесть прицела
  • Эффект второй системы
  • Раздутие программного обеспечения
  • Плагин (вычисления)
  • Философия Unix
  • Закон Завинского оболочек программного обеспечения

Ссылки [ править ]

  1. ↑ JM Sullivan (8–10 июня 2005 г.). «Препятствия и стимулы для автоматизации в ВВС». Ход работы. 2005 Международный симпозиум по технологиям и обществу, 2005. Оружие и провода: предотвращение и безопасность во время страха. ИСТАС 2005 . 2005 Международный симпозиум по технологиям и обществу . С. 101–110. DOI : 10.1109 / ISTAS.2005.1452719 . ISBN 0-7803-9284-1. S2CID  21079766 .
  2. ^ Дэвис, ФД; Венкатеш, В. (февраль 2004 г.), «К тестированию допрототипа пользователей новых информационных систем: значение для управления проектами программного обеспечения», IEEE Transactions on Engineering Management , 51, 51 (1): 31–46, doi : 10.1109 / TEM. 2003.822468 , ISSN 0018-9391 , S2CID 1204079  
  3. ^ Кеннет С. Нортон (2001), Применение кросс-функциональных эволюционных методологий к веб-разработке , статья в веб-инженерии: управление разнообразием и сложностью Интернета, опубликованная Springer, ISBN 3-540-42130-0
  4. ^ Double Fine делит Broken Age пополам, чтобы финансировать завершение , Крис Лигман, 2013-07-02, Gamasutra
  5. ^ feeping creaturism , 2016-05-27, FOLDOC.org - Бесплатный он-лайн словарь по вычислениям
  6. ^ Раймонд, Эрик S .; и другие. (29 декабря 2003 г.). "питающееся творчество" . Файл жаргона . Вер. 4.4.7 . Проверено 20 июня 2017 года .
  7. ^ Раймонд, Эрик S .; и другие. (29 декабря 2003 г.). "кормящееся существо" . Файл жаргона . Вер. 4.4.7 . Проверено 20 июня 2017 года .
  8. ^ Раймонд, Эрик S .; и другие. (29 декабря 2003 г.). "feep" . Файл жаргона . Вер. 4.4.7 . Проверено 20 июня 2017 года .

Внешние ссылки [ править ]

  • Creeping Featuritis , ContentCreationWiki (зарегистрировано не позднее 23 октября 1995 г.)