| Математика |
 |
|
 | ||||||||||||
 |
 |
|
Система планирования ресурсов в масштабе предприятия. .
|
|||
|
Предприятие никогда не получает прибыли,
соразмерной уровню его инвестиций в информационную систему (IS). Данный факт хорошо известен как парадокс производительности в IT-индустрии. Это реальность, с которой приходилось мириться. В течение нескольких последних десятилетий мы стали свидетелями вереницы многочисленных методологий, инструментальных средств и технических приемов, зародившихся в этой индустрии, и оказавших огромное влияние на саму суть и деятельность предприятий. Но среди этого беспорядочного движения, один факт остался незыблемым, а именно — недостаточное увеличение производительности, вне зависимости от масштаба и характера компьютеризации. Однако с самого начала существует еще одна основная проблема, состоящая в количестве действительно успешно завершенных и реализованных приложений. Большинство из них было написано во время программного кризиса, охватившего группы информационного сервиса в 80-х. Причин для этого было несколько: • С появлением PC-ориентированных функциональных возможностей, запросы пользователей стали сложнее и требовательнее. • Как следствие, приложения стали более крупными и комплексными. • Соответственно, производительность скорее падала, чем увеличивалась. • Время разработки программного обеспечения возросло, увеличение затрат и времени стали обычной практикой. • Высококвалифицированные профессионалы всегда были в цене, и это требовало увеличения затрат на содержание штата программистов; поэтому затраты на разработку систем неуклонно возрастали. • Процент прекращения эксплуатации систем был очень высок. В среднем, из общего числа IT-систем, находящихся в разработке, более половины прекращают свое существование, а из второй половины приблизительно две трети идут в разработку. Половина этих систем так никогда и не реализуется, а реализация другой четверти не доводится до середины. В свою очередь, из оставшейся четверти половина систем не способна обеспечить необходимый набор функциональных возможностей, и, вследствие этого, отбраковывается за ненадобностью. И лишь остаточная половина систем используется после внесения значительного количества модификаций, что влечет дополнительные задержки и издержки практически бесконечного процесса. Одной из главных причин вышеперечисленных проблем являлась наследуемая слабость стадии приема и анализа требований!!!!. Считалось, что на данной стадии невозможно собрать корректные и полные требования. В результате, завершенные проекты не предлагали всей обещанной полноты функциональных возможностей, вынуждая возвращаться к стадии дополнительного анализа и доработки. Процесс сопровождения и усовершенствования был практически бесконечным, и с течением времени все труднее реализовывался. Вследствие того, что индивидуумы меняются как со стороны разработчиков, так и пользователей, системные требования менялись соответственно, продлевая весь процесс практически до бесконечности. Основная причина этого состоит в фундаментальном разрыве между людьми бизнеса и работниками IT/IS. Несмотря на попытки обеих сторон сократить этот разрыв, существует огромное расхождение между восприятием бизнес-пользователя и тем, что подразумевается системным персоналом; оба класса людей говорят на абсолютно разных языках. Даже при использовании системным персоналом методологий и инструментов для дополнительных спецификаций и описаний, пользователи не в состоянии в полной мере ратифицировать документированные требования вследствие неосведомленности о таких инструментах. Судя по проводимым исследованиям, от 50 до 80% ресурсов IT/IS расходуются на сопровождение приложений. Прибыли по отношению к инвестируемому капиталу в IT-отрасли были крайне низки в соответствии с любым стандартом и уровнем ожиданий. При бюджетах IT/IS, значительно превышающих возможности большинства организаций, существовала настоятельная необходимость в радикально новом подходе, результатом которого явились бы удобные и простые в использовании функциональные средства, разработанные на высоком профессиональном уровне и в установленные временные рамки. Это является своеобразной постмодернистской версией понятия «двух культур», введенного Ч.П.Сноу в середине прошлого столетия для обсуждения мира искусства и мира науки. Традиционный процесс реализации программных решений, включающий разработку приложений, характеризовался следующими особенностями: • Функциональное рассредоточение, задаваемое требованиями. • Более позднее разрешение рисков. • Более позднее обнаружение ошибок. • Использование различных языков или артефактов на различных стадиях проекта. • Большой процент отбраковки и необходимости дальнейшей доработки. • Сложные взаимодействия с пользователями, не занятыми в сфере IT. • Приоритет технических приемов над инструментальными средствами. • Приоритет качества разработанного программного продукта над функциональностью как таковой. • Значительный акцент на создании текущей правильной, полной и последовательной документации. • Акцент на тестировании и периодическом просмотре. • Большая работа в области контроля и управления изменениями. • Многочисленные и разнообразные требования к ресурсам. • Выполнение планов в авральном режиме. • Особое внимание аспекту планируемой или ориентировочной целевой производительности. • Унаследованные ограничения масштабируемости. • Слабая интеграция между системами. Многие альтернативные стратегии были задуманы как Автоматизированная Разработка Программного Обеспечения (Computer Aided Software Engineering, CASE) |
|
|
